とらきす の ぐだログ

とらきすのぐだログ

ぐだぐだとなんかするブログ。

持ってる古い音源のやつ

2021/10/02: Virtual Guitarist Electric Edition の存在を完全に忘れていたので追記。


ども。

最近はお仕事が楽しくてしかたがない日々を過ごしているのですが、逆にそれ以外の時間は YouTube とニコニコ観てるか寝てるかくらいしかしてなくてですね。
仕事が趣味みたいになってしまうと良くないなと思い、最近また DTM を少しずつやりはじめています。

それで、ついに MIDI キーボードを買いました。Nektar Technology の GXP 49 ってやつ。
今までずっとマウスぽちぽちだけでノート置いてたんですが、なにせ音感がまるっきりないもので、頭の中に出てきたフレーズをピアノロールに描くのがすっごく時間かかるんです。なので、そのインターフェースとして MIDI キーボードがほしかった。
今はがんばってピアノのお勉強中。両手を別に動かすのに慣れていなくてヒィヒィ言いながら練習してます。一時的にミギー寄生してくんないかな。

あとオーディオインターフェースもほしい。ずっと Roland UA-M10 を使っていたんですが、なんか定期的にブツブツ音が切れるようになってしまいました。
Windows 11 に上げたのが悪かったのかな... Mac だと普通に使えてるんですけど、もうサポート切れてますし。この製品は Roland にしてはめずらしくサポート期間がやけに短命で困ったものです。

さて、なんとなく気が向いたので、所持している古い音源をいくつか紹介してみます。

Roland / EDIROL Super Quartet

2001年に RolandEDIROL ブランドより発売されたマルチティンバー音源。兄弟分の GM2 音源である Hyper Canvas、ならびにそのスーパーセットである音源モジュール SD-90 と同時に発売されました。

ピアノ、ギター、ベース、ドラムの4構成マルチティンバー音源で、今は亡き Cakewalk Music Creator 2002 がバンドルされています。

f:id:trackiss:20210925053350j:plain
これがパッケージ。ロット番号的なものがディスクに書いてあったので念のため消してあります

わたしが持っているのは英語版で、日本版のものとパッケージがやや異なっています。ただ、ディスクおよびソフトウェアは日本版のものと共通のようです。
なぜ英語版なのかというと、海外から購入したから。イタリアのとある楽器店のオンラインストアでたまたま売っているのを見かけたのです。まだ在庫残ってたりして。

ここに書き連ねている中では最上級のレア音源。同じビンテージものでも、Virtual Guitarist みたいなよく売れた音源とは違って出荷数が少ないせいでしょうか。ともかく、日本ではもうなかなか手に入らないもののうちのひとつです。

シリアル番号によるライセンス認証 (オフラインなので単に番号のバリデーションしてるだけだと思います) を導入していますが、それとは別に、およそ2週間に1度の頻度でディスク挿入を要求してくるという悪名高い不正防止策を導入しています。
加えて、リングプロテクト、いわゆる SafeDisc というプロテクトがディスクにかかっていて、吸い出しておくという手段をとることができない。SafeDisc とは、不正なセクターをディスクに仕込むことで違法コピーを防ぐ (苦しまぎれの) 技術ですね。

こう考えると、USB-eLicenser はなんとも優秀なライセンス認証方法だったということがわかりますね。これをあんな初期から導入していた Steinberg、すごい。
ま、あれはあれで、USB-eLicenser 壊れたら云々みたいな話はありますけども。

この Super Quartet という名前ですが、実は Roland の歴史にこの名が出てくるのはこれが2度目のことだったりします。
1度目は、1985年にリリースされた最初期の音源モジュール MKS-7 Super Quartet。これまたメロディ、コード、ベース、ドラムの4構成からなるマルチティンバー構成となっています。
いかにも80年代らしいパワーのある音で、特にドラムの音が個人的には好き。というか、ほぼ完全に TR-707 の音ですが。

UVI が MKS-7 を Super-7 としてソフトシンセ化しているので、気になる人はどうぞ。

Steinberg Hypersonic 2

2005年に Steinberg より発売されたマルチティンバー音源。今でいう HALion Sonic 的な立ち位置の製品、いわゆるロムプラーってやつですね。

f:id:trackiss:20210925053418j:plain
USB-eLicenser つき。なぜかディスクのパッケージがめっちゃ安っぽい

たまにサンプルを読み取ってくれなかったりして、現在の環境ではちょっと完動は厳しいかもしれないです。独自のフォーマットでサウンドコンテンツを管理してるので、HALion に読ませたりして使うこともできません。カナシヒ

Hypersonic 2 は、泣く子も黙る Wizoo がまだ Steinberg と仲がよかった頃の製品で、わずか 1.7GB のサンプル数 (これでも当時としてはかなりビッグサイズではある) にしてかなり高品質なサウンドを奏でてくれると評判だった。らしいです。

今は、この Hypersonic の直系の子孫 (腹違いの子とも言える) である Xpand! 2 が Air Music Technology からリリースされていますね。

Air Music Technology がかつての Wizoo であることは、この記事を読んでいるような人ならすでに知っていることと思いますが。
伝説のサウンドチーム Wizoo Sound Design は、Air Music Technology と UJAM へと姿を変え、今なお DTM 界で猛威をふるっているんですねぇ。

Steinberg HALion 2

2003年に Steinberg より発売されたサンプラー

f:id:trackiss:20210925050803j:plain
HALion 1.1 と HALion 2 のインストーラーディスク、そして4枚組のコンテンツディスク。外箱は持っていない

コンテンツディスクは4枚組で、Wizoo と eLab のロゴが入っています。
ただ、この写真に写っているものは HALion 2 のものではなくて初代 HALion のコンテンツディスクです。
HALion 2 のメインのサウンドコンテンツは初代 HALion のものと変わらないため、アップグレード版を購入したユーザーの場合は HALion 2 のインストーラーディスク (この中に少し追加サウンドも収録されている) のみが送られてきていたんですよね。

HALion 2 はそれなりに古い VST なので、Windows 11 が動いてる今の PC ではあまりマトモに動いてくれません。かなしいね。jBridge をかましてもだめ。

数日前に Absolute 5 を買ったので HALion 6 に読ませてみたら、HALion 3 Contents という扱いになりました。バリバリ使える。

Steinberg Virtual Guitarist Electric Edition

2002年に Steinberg より発売されたエレクトリックギター音源。実際のギタリストが演奏したギターの音を収録している超リアル (というか、実際リアルですし) な音源です。

f:id:trackiss:20211002171544j:plain
インストールディスクは3枚組。ディスクパッケージの気合いの入れようがすごい

Virtual Guitarist が発売されてからわずか半年ちょっとしか経っていないのに発売されたというのがすごいですね。当時の Steinberg はかなりハイペースで新製品を出していたという感じを受けます。

Virtual Guitarist Electric Edition はその名のとおりエレクトリックギターに特化した音源で (無印の Virtual Guitarist はアコースティックもエレクトリックもまんべんなく収録してました)、マルチエフェクターもついてきます。
このエフェクターVSTe としても使用できるんですが、こいつがかなり優秀で、普段使いにも適しています。

わたしは今は無印 Virtual Guitarist は持っていないんですが、Virtual Guitarist と Virtual Guitarist Electric Edition のサウンドがすべて収録されている Virtual Guitarist 2 は持ってるんです。ただ、Virtual Guitarist Electric Edition とはエフェクターの互換性がなく、ちょっと出音が変わってしまうため継続して持っているという感じ。

Steinberg Studio Case

2003年に Steinberg より発売されたスタジオバンドル。Cubase の廉価版である Cubase SE に加え、Steinberg 謹製 VSTi の廉価版が5つもバンドルされたお得製品!

f:id:trackiss:20210925053546j:plain
ジェラルミンケースをモチーフにした特大パッケージ。届いたときに「デカすぎんだろ...」と素で口に出してしまった

f:id:trackiss:20210925054105j:plain
中身。日本語版 PDF マニュアル、Cubase SE のインストーラー、プラグインインストーラー2枚、ストーム・ハウス・スタジオのインストーラーといった計5枚のディスク、USB-eLicenser、説明書など

とにかくケースがでかいのなんの。それでいて中身は CD-ROM 数枚、USB-eLicenser、説明書のみなので、がら空きです。
Hypersonic 2 とか、大きめの箱はこの中にいっしょにしまってあります。

付属するプラグインは次の5つ:

  • D'cota SE
  • Groove Agent SE
  • HALion SE
  • Virtual Guitarist Electric Editon SE
  • The Grand SE

いずれもライセンス認証が必要ないタイプの VSTi で、ほかの DAW でも普通に使うことができます。今の環境では、HALion SE と The Grand SE は動いてくれませんでしたが。

また、これは日本語版だけかもしれないですが、ストーム・ハウス・スタジオという見慣れないディスクがついてきています。これは、かの Arturia がかつて開発していた STORM という音楽作成ツールの日本向けラインナップのようです。

2005年には、新バージョンである Studio Case II が発売されています。変わったことは、無印 Cubase SE が Cubase SE 3 になったこと、そして Virtual Bassist SE が新たにバンドルプラグインに仲間入りしたということ。
Virtual Bassist SE のみライセンス認証が必要なようで、これもやはりほかの DAW でも使うことができると思います。知らんけど。

今となっては微妙かもしれないですが、音ネタとしてはそれなりに有用。特に D'cota と Groove Agent SE は使えますね。オークション等で安く売っていれば買うのもアリだとは思いますよ。安ければね。

Steinberg Groove Agent 3

2008年に Steinberg より発売されたドラム音源。

f:id:trackiss:20210925054548j:plain
相変わらず箱がでかい。そのかわり説明書もかなり分厚い

前は Groove Agent 2 を持っていて、でもあれは友人に売ってしまっていたんですね。
で、数日前にたまたま Groove Agent 3 を購入できる機会に恵まれたので、せっかくだし新品で購入。新品とはいえ、それなりに古い音源だからか €99 という破格で買えました。

今の Groove Agent にも引き継がれていますが、いわゆるバーチャルドラマーとしての役割が強いのが特徴。年代やスタイルごとにたくさんのプリセットが用意されていて、それぞれ実際のドラマーが演奏した演奏パターンが大量に収録されています。

Groove Agent 3 では Groove Agent 2 に比べてプリセットがいくつか増えているのと、Special Agent、Percussion Agent というモジュールが追加されてます。
前者はいわゆるドラムリプレイサー的な技術を活用したもので、実際のプロによる演奏をうまい具合にリズムに合わせて再構成してくれるとのこと。後者は今の Groove Agent にもあるようなパーカッションのサウンドセットですね。

ただ、なんかファーストインプレッションとしては Groove Agent 2 のほうが使いやすかった... 気がする... まだ慣れてないだけだと思いますが。

余談。
Groove Agent 4、5 は 3 みたいな即戦力みたいな感じではあまりないですが、音作りがとてもやりやすいんですよね。エフェクトもたくさんそろってるし。
あと拡張ライブラリが非常に優秀。唯一残念なのは、TR-808 とか Simons とか、ビンテージドラムマシンの拡張ライブラリがいまだに存在していないことですね。出したら絶対売れるのに。
いちおう標準ライブラリにもそれっぽい音は入ってるんですけどね、Retrospective とかモロ Linn Drum ですし。


ここに書いてないのは写真撮るのが面倒だったやつです。LM4 MKII は実家に置いてきてしまったし、Virtual Guitarist 2 のディスクは... どこやっちゃったっけかな、外箱持ってなくてディスクだけなので、あまり目立たないんですよね。

以上。

Akka を触ってみる 2 - Akka Actor 編 その2

前回は こちら


今回は、子アクターの生成について軽く見ていこう。要件は、こう:

  • 親となる ParentActor、子となる ChildActor を用意する。
  • ParentActor は、生成と同時に ChildActor を子アクターとして生成し、そこへ Request を送信する。Response を受信したら、自らを停止する。
  • ChildActor は、Request を受信したらその中にある文字列を標準出力し、送信元に Response を送信する。

コードはこちら:

Request.scala
import akka.actor.typed.ActorRef

case class Request(message: String, reptyTo: ActorRef[Response])
Response.scala
case class Response()
ParentActor.scala
import akka.actor.typed.Behavior
import akka.actor.typed.scaladsl.Behaviors

object ParentActor {
  def apply(): Behavior[Response] =
    Behaviors.setup { context =>
      val child = context.spawn(ChildActor(), "print-worker")
      child ! Request("Hello, World!", context.self)

      Behaviors.receiveMessage { _ =>
        println("received response.")

        Behaviors.stopped
      }
    }
}
ChildActor.scala
import akka.actor.typed.Behavior
import akka.actor.typed.scaladsl.Behaviors

object ChildActor {
  def apply(): Behavior[Request] =
    Behaviors.receiveMessage { request =>
      println(request.message)
      request.replyTo ! Response()

      Behaviors.same
    }
}
Main.scala
import akka.actor.typed.ActorSystem

object Main extends App {
  val system = ActorSystem(ParentActor(), "parent-actor")
}


ちょっと前回よりも長くなっているが、最も注意を向けるべきは ParentActor だ:

ParentActor.scala
import akka.actor.typed.Behavior
import akka.actor.typed.scaladsl.Behaviors

object ParentActor {
  def apply(): Behavior[Response] =
    Behaviors.setup { context =>
      val child = context.spawn(ChildActor(), "print-worker")
      child ! Request("Hello, World!", context.self)

      Behaviors.receiveMessage { _ =>
        println("Response received.")

        Behaviors.stopped
      }
    }
}

前回は Behaviors.receiveMessage(...) しかなかったのが、それをさらに Behaviors.setup(...) で包んでいる。
Behaviors.setup(...) は、アクターを生成してからメッセージを受け取るまでの間にやっておきたい 前処理 を書いておけるメソッドである。ここで指定した処理は、(基本的に) アクター生成時の一度だけ実行される。

...わざわざ “基本的に” と強調して書いたのは、ここに状態遷移が組み合わさってくると少し事情が異なってくるからだ。といっても、よく考えれば当たり前のことではあるし、対処も非常に簡単ではあるのだが... これは次回説明する。

Behaviors.setup(context => ???)Behaviors.receiveMessage(message => ???) をまとめてしまいたいときは、Behaviors.receive((context, message) => ???) なんてメソッドも用意されている。これが必要になるような場面はあまり思い浮かばないが。

Behaviors.setup(...) の中では、そのインスタンス固有の操作をすることができる ActorContext が使えるようになるので、いろいろうれしい。 まず、ActorContext.spawn(...) で子アクターを生成できる。このメソッドは子アクターを生成したあと ActorRef (アクターインスタンスへの参照) を返すので、変数に入れておくと便利。
名前を指定するのが面倒なら、ActorContext.spawnAnonymous(...) を使えばランダムな名前を割り当ててくれる。
なお、Classic Actor では ActorRef.actorOf(...) で子アクターを生成できていたが、Typed Actor では廃止されている。

ほかにも、ActorContext.self で自分の ActorRef を取得したり、ActorContext.system で自分が所属する ActorSystem の ActorRef を取得したり、子アクターを取得したり停止させたり... いわゆる “ask” メソッドも用意されている (などと格好つけているが、正直 Ask パターンのことはなにも知らない。また後日調べて書く)。

そしてメッセージを受信したら、(前回のように Behaviors.same ではなく) Behaviors.stopped を返すようにしている。これは名のごとく、このアクターを停止させることを表している。このとき、子アクターである print-worker も一緒に停止する。


また、Request.scala の中身を見てみるとわかるが:

Request.scala
import akka.actor.typed.ActorRef

case class Request(message: String, replyTo: ActorRef[Response])

返信先の ActorRef を添付するようにしている。Classic Actor ではこんなことをせずとも sender というオブジェクトが暗黙的に定義されていたが、Typed Actor ではこのように明示的に作ってやる必要がある。
なぜ sender ではなく replyTo という名称にしてあるのかと言えば、まぁ Akka Actor のドキュメントがそうしていたからというのもあるが、もし返信先を送信元と別のところに変えたいケースが出てきたときに sender という名称では不自然だからという理由がある。


今回はここまで。ちょっと詰めが甘いかもですね。まぁいいか。

Akka を触ってみる 1 - Akka Actor 編 その1

N 予備校である程度は触ってみたものの、そのしくみをきちんと理解できたとは言いがたい状況なので、そのおさらいもかねて。


Akka?

リアクティブシステムJava / Scala で構築するためのライブラリ・ツール群。Scala の開発を主導している Lightbend 社が開発している。

リアクティブシステムの概念については、Lightbend 社 CEO の Jonas Bonér 氏を中心とするコミュニティによって発表された リアクティブ宣言 (Reactive Manifesto) を参照。
いくつかの名だたる大企業がリアクティブシステムの採用を発表したり、Linux Foundation が Reactive Foundation を立ち上げたり... 近年いろいろと注目されつつある要出典

今回はこの Akka のうち、Akka Actor という アクターモデル を実装するためのライブラリを触ってみる。

アクターモデル

f:id:trackiss:20210612194342p:plain

このへんは詳しくは各自ググってほしい。

アクターモデルは、メッセージ によって情報をやりとりする アクター というものを中心にロジックを組み上げていくパターン。
アクターはそれぞれメッセージキューを持っており、そこにメッセージが格納されていれば、それを順に取り出して淡々と処理を進めていくだけ。アクターそのものは逐次処理しかできないが、それを複数同時に走らせることで分散処理を実現する。

基本的にアクターはアクターによって生成され、ツリー状に配置される。すなわち、最上位に位置するアクター (ActorSystem) を除くすべてのアクターは親アクターを持つ。
Akka では、親アクターが子アクターを監督 (supervise) する役割を持っている。 子アクターになんらかの障害が発生したとき、親アクターはその対処をおこなう。
障害が発生した子アクターのみを再起動するのか、あるいは自身のすべての子アクターを再起動するのか、はたまた無視して再トライさせるのか... さらに親のアクターに判断を仰ぐことも可能だ。

アクターモデルのなにがうれしいのか。

まず並行処理ができる。
基本的には、従来であればクラスに分けていたものをアクターに置き換えることになるわけだが... もし従来の方式であれば、複数のスレッドから呼び出したいときにそのメソッドがスレッドセーフであるか否かが重要になってくる。スレッドセーフでないのなら、Java でいう synchronized のような排他制御のしくみが必要となる (もっとも、それでもデッドロックを引き起こす可能性はある)。
アクターでは、同期的なメソッド呼び出しではなく非同期的なメッセージパッシングがトリガーとなるうえ、個々のアクターは逐次処理をおこなうので排他制御が必要なくなる。

次に、スケーラビリティにすぐれている。
もしボトルネックとなる部分があるのなら、その部分のアクターをかんたんに増やすことができる。スレッド等でも似たようなことは実現できるが、アクターなら前述の厄介ごとがクリアできるし、より高度に抽象化されていて理解もたやすい。いわばソフトウェアのマイクロサービス化... のようなものだろうか。

そして、耐障害性にもすぐれている。
アクターモデルにしたがって適切に設計されたシステムは、なにか障害が発生したとしても、多くの場合 人為的な手を加えずとも自然に復帰する。

余談。アクターモデルは、Erlang という言語で取り入れられたことで一躍有名になったパターンである。
もともとエリクソン社 (現在では日本国内のモバイル通信網基地局のベンダーとしてトップシェアを誇っている) が開発した言語で、同社の AXD 301 というスイッチに採用され 99.9999999% もの信頼性を実現したことで知られる (もっとも、この数字は統計的なものでありかならずしも信頼できるものではないが、それでも驚くべき数字だ)。

Typed Actor?

従来の Akka Actor ではメッセージの型を宣言することができず、動的に型を振り分ける必要があった。

Akka 2.6.0 から、型安全な Akka Actor の API が正式に追加された。これは一般に Typed Actor と呼ばれる (2.5.x の段階ではまだ実験的機能であり、Akka Typed と呼ばれていた)。
対照的に、従来の APIClassic Actor と呼ばれる。

無論、この記事では Typed Actor を触ってみる。

セットアップ

とりあえず手を動かしてみよう。
build.sbt を適当に書く (よいこはきちんとかきましょうね):

name := "typed-actor-test"
version := "0.1"

scalaVersion := "2.13.6"

lazy val akkaV = "2.6.14"
lazy val logbackV = "1.2.3"

libraryDependencies ++= Seq(
  "com.typesafe.akka" %% "akka-actor-typed" % akkaV,
  "ch.qos.logback" % "logback-classic" % logbackV)

Akka はログの出力に slf4j を使っているので、とりあえず logback-classic を入れておく。

Hello, World!

今回のコードは、Message を受け取ってその中身を標準出力するだけの非常にシンプルなアクターを書いてみる。

百聞は一見にしかず。まずはコードから:

Message.scala
case class Message(value: String)
PrintActor.scala
import akka.actor.typed.Behavior
import akka.actor.typed.scaladsl.Behaviors

object PrintActor {
  def apply(): Behavior[Message] =
    Behaviors.receiveMessage { message =>
      println(message.value)

      Behaviors.same
    }
}
Main.scala
import akka.actor.typed.ActorSystem

object Main extends App {
  val system = ActorSystem(PrintActor(), "print-actor")

  system ! Message("Hello, World!")
}

アクターの終了処理などはいったん抜きにしておく。

Typed Actor では、従来の object-oriented style に加えて、functional style というアクターの宣言方法が導入されている。
前者では一般的なクラス指向のスタイルを重んじているのに対して、後者ではふるまいによってのみアクターを宣言するという より関数型プログラミングに近いスタイルに重きを置いている。

object-oriented style では、Actor トレイトを継承したクラスを使い、メソッドによってふるまいを、プロパティによって状態をそれぞれ表現していた。
functional style では、Behavior[T] 型の関数 (メソッドでもいいし、関数でもいい) によってふるまいを、その引数によって状態を表現する。

アクター内という局所的なものであるとはいえ、あまりミュータブルなものは扱いたくないので、今回は functional style を触ってみることにした。

先ほどの例をもう一度見てみよう:

PrintActor.scala
import akka.actor.typed.Behavior
import akka.actor.typed.scaladsl.Behaviors

object PrintActor {
  def apply(): Behavior[Message] =
    Behaviors.receiveMessage { message =>
      println(message.value)

      Behaviors.same
    }
}

Behavior[Message] 型を返す PrintActor.apply() を定義している。最もシンプルかつわかりやすい例として apply メソッドを使っているだけで、Behavior[T] さえ返すのであればでなんでもいい。もちろん、PrintActor オブジェクトの中にある必要すらない。
今さら書くほどのことでもないが、この T こそがアクターが受け取るメッセージの型である。

さて、例にある PrintActor.apply() の中身を見てみると、実質的に Behaviors.receiveMessage(...) という関数に完全に乗っ取られている状況であることがわかる。この関数を使って、メッセージを受け取ったときのふるまいを指定することができる。
より複雑な使い方をする際にはもっと別の関数を使う必要があるが、今回の用途ではこれで十分。

Behaviors.receiveMessage(...) に渡しているラムダ式は、最終的に Behaviors.same という謎の値を返している。これは、このアクターの状態は一切変更されなかったよ というサインである。

なお、この Behaviors.same は、PrintActor() (もとい PrintActor.apply()) に置き換えることでも同じ動作を実現できる。むしろこのほうがよりわかりやすくなるのだが、要するに関数の再帰呼び出しを使ってアクターの状態遷移を表現しているのである。勘の良い人はここでなにか違和感を覚えるかもしれないが、そのへんはマジック (トランポリンとか) でうまく調整されている。詳しくはおいおい説明予定。
ただ、余計な初期化処理等をスキップしてくれるので、特別な理由がないかぎりはおとなしく Behaviors.same を使おう。


今回はここまで。

紙ブログ

しばらくブログ放置してたので、なんか適当に書いた。

もともとは「ここ1年で学んだこと」みたいな趣旨で書き始めたはずなんですけど、言いたいことを言う記事になりました。久米田先生の紙ブログみたい。そうでもないかな。

まぁたまにはそういうのも良いかなと。


TOC


Scala すき...

Scala を触りはじめたのはちょうど1年前くらい。

なんで Scala なのかというと、単純明快、周りに書いてる人がいなかったからですね。

マイナー言語... 逆にメジャー言語ってなんなんですかね。
C、C++C#JavaJavaScriptPythonRuby あたりはメジャーといえるでしょうが、その線引きはひどく曖昧です。まぁ、しかし Scala がメジャーということはないと思うので、とりあえずマイナー言語ということで。

高専にいたころは、これとまったく同じ理由で Haxe というもっとマイナーな言語を触っていました。といっても、それは当時の観測範囲がせまかったのが問題で、Scala 詳しい界隈の人たちは普通に Haxe を知っていて、書けたりするんですよね。すごいや。
えー、まぁそれと少し方向性の似ている言語ということで Scala をチョイスしたんです。

いや、いい言語ですよ Scala は。だいいち書いていて楽しい。これ大事です。

関数型プログラミング

先の話のつづきになりますが、やはり関数型プログラミングの考え方はいいものです。

Haskell の美しさはようやく理解できるようになってきましたが、やはり実用的かと言われると素直に首を縦にふるわけにはいかないもので、その点に関して Scala はよく考えられていると思います。

Haxe を触っていたころから、強力な型推論や if / switch 式、パターンマッチなど、なぜこの機能がほかの言語にないんだ? と思うような数々の機能に魅力を感じていました。

最近はいろいろな言語に関数型プログラミング由来の要素が取りこまれつつありますが、やはり知らなければみずから使おうとは思わない (というか気づけない) ので、一度自分から大海に飛びこむ勇気が必要ですね。

Scala では、さらに Option や Either、map に flatten といったモナド周りであったり、カリー化や部分適用、高カインド型、そしてそれまでボンヤリとしていた型システム全般に関する理解を改めました。

デザイン パターンとアーキテクチャ

Chatwork のインターンではじめて設計手法云々を勉強しました。それまでは完全に個人で開発してたので、そういった類のものはあまり触れてこなかったんです。

もっとも、DDD はそこまで違和感なく受け入れられることができました。
私はもともとゲーム作りからプログラミングに入門しているので、オブジェクト指向的な DDD は、なんかこう、わりとスッと頭に入ってきました。

逆に、トランザクション スクリプトの話が出てきたときなんかは「そんな気持ち悪いデザイン パターンなんてあるのか...」と、むしろ違和感しかなかったです。

Clean Architecture は、いまだにベストプラクティスがわかりません。一応自分で書いてみたりはしましたが、やはり要件によって形は変わってくるものです。

先人の実装例を見てみても千差万別、Layered Architecture 派生の中では Clean Architecture は詳細がしっかり定められているほうだとは思うのですが、やはり必要なエッセンスをどれだけ抽象的に捉えられるかが大事なようです。

なので、あまり規模の大きなアプリケーションでないのなら、より抽象的な Leyered Architecture からスケールしていくのが良い気がしています。

CQRS は、データソースまで分けなければ、わりと気軽にプロジェクトに取り入れられそう。というか、取り入れるべきでしょう。Event Soucing しないからやめておこう、なんてことは言わずに、可能なら採用すべきだと思っています。

Event Soucing は、個人レベルのプロジェクトだとあまり触る機会がないのがつらいですね。Akka の勉強もかねて、一度組んでみようかしら...

Japanese traditional xxxxx

卒研やってます。専門学校とはいえ、そのへんは一応きちんとあるんです。
何人かでグループになり、各々すきなテーマに沿ってなにか作ります。

で、うちの学科はですね、10人もいない極小学科なので、全体で卒研することになったのですが。

なんと、「卒研として某企業のシステム開発をしないか」という先生からの提案が!


いや提案っていうか、半ば強制なんですけどね。事後報告。

まぁ滅多にない経験であるのは間違いないし、とりあえず要件を決めて作業にとりかk...


_人人人人人人人人_
> 突然のコロナ <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^ ̄


でました。

あちらさんの社員の方が出社できないので、当然なにも進みません。
先生は今のうちにできることをやっておいてなどとおっしゃってますが、いやいや、なにもできないですから。

とはいうものの、時間を無駄にするわけにもいかないので、とりあえず TypeScript + PWA でやってみるかー という話に。
私も TypeScript と NestJS の勉強してたんですよ、ここ最近は。

で、TypeScript の話はなくなりました (は?)。
社外秘なので、企業内の端末からしかアクセスできないようでなくてはダメだと。

いや、うん。それはまったくもってそのとおりなんですが、少し前に、この方向性でやるよっていうプレゼンやったじゃないですか。そのときに言えよ。

早いところ MTG の機会を設けてほしいものです。別にオンラインでだってできるでしょうに。
ですが、そもそもこのプロジェクトの調印式が終わってないんだそうです。これが噂に聞く調印ってやつか...! ジャパニーズ・トラディショナルは実在した!

結局、フロントエンドは C#、バックエンドは未定。

ま、個人的にはもちろん Scala で書きたいわけなんですが...
書き慣れているのだけでなく、私がこうして内定を頂けたのは完全に Scala のおかげですから、そういう意味でも思い入れがある言語だというだけで。かならずしもベストな言語とは言いきれないわけです。そんな銀の弾丸みたいな言語はないんですが。

Event Sourcing とかやるなら Akka が使える Scala がよさそうですけどね、今回はそこまでやらない予定ですしおすし。

Scala それ自体は実にすばらしい言語だし、もちろん必要であれば Scala を教えることもできますが、それでも、ほとんどの人にとっては書き慣れない言語であることには違いないわけで。
クリーンでスケーラブルな設計と習得難度はトレードオフの関係にあるのです。私自身も、まだ Scala をフルに使いこなせていないと自覚しています。

万が一、結果的に私がほとんど書いてしまうようなことになってしまっては元も子もありません。
ただでさえ今の設計段階でもかなりオレオレなデザインになってしまっていて、少し申し訳ないと思っているぐらいです。軽量 DDD + オリジナルの Layered Architecture + 軽量 CQRS、みたいな。

でも来年以降もこのプロジェクト引き継ぐらしいので、多少複雑になってでも合理的なアーキテクチャを導入したほうが、のちのち破綻するようなことにはなりにくいかなと。 一応そういう考えはあるのです。

そんなこんなで、どうしようかねー ってなってるとこです。

技術選定難しい

結局、プログラミング言語の違いなんて些細なもので、DB だとかコントローラーだとか、そういった外部的な部分を要件に合わせてまず選ばなければいけない。もしくは、使用するフレームワークアーキテクチャが、要件にマッチしているかどうか、とかですかね。

もっとも、今どきのたいていの言語にはどんな DB のドライバーでも用意されているでしょうし、結局のところはチームの合意が取れればいいわけです。
強いていうなら ORM。ORM はモノによって使いやすいか使いやすくないかの差がとても大きいので、慎重に吟味する必要があります。

というか、今回のケースだとそもそも要件が不確定なので技術選定もなにもないんですけど。

Kotlin、お前 Scala でいいだろ

先の件にともなって、少し Kotlin を触ってみました。

ビックリするくらいそっくりですね。なので、これもう Scala で書けばいいやん... ってなる。精神的につらみが深いです。
Scala ユーザー的には、後発のくせにどんどんと市民権を得てきている Kotlin の存在を危惧しているわけなのですが (私だけじゃないよね?)、やはり言語としては Scala のほうがはるかに多機能です。

そもそも Kotlin の設計思想のひとつに「Scala よりも学習しやすい言語」というのがあるそうで、Android 開発なら Kotlin、バックエンドなら Scala というようにまずまず住み分けられているのかな、と思いきや、最近はサーバーサイド Kotlin が増えてきているんですよね。

JVM 以外の実装にしても、Scala.js と Kotlin/JS、Scala Native と Kotlin/Native... 完全に食いにきてますね。

Kotlin、Either がないのがしんどいですね。もし使うときがきたら、DB 周りのエラーの扱いとかに便利なので、絶対に Either を導入するライブラリを使うと思います。
Scala でいう Try.apply() がわりに使える Result なんてのがありますが、型としては使えないもよう。ゴミ

結局は、学習コストとのトレードオフScala のほうがややコスト高めなのは間違いないと思います。
もっとも、Kotlin -> Scala だともちろん追加で勉強は要りますけれど、Java -> Kotlin と Java -> Scala だったら、なんかそこまで差はないのではないかと。

Rust 難しいね

若者もすなる Rust といふものに、私も手を出してみました。

言語仕様をざっと見た感じ、いろんな言語のいいとこどりって感じですね。ただ、API Docs を眺めていると、これ欲しい! っていうのが experimental だったりして、少し物足りない感もありました。

標準でイミュータブルなのはとてもいいですね。
エラーが Result<T, E> なのもいい。Go も少し書いてみて、やはりこの言語は私には合わないとはっきり感じ取りましたが、ことエラー処理に関しては実に合理的にできていると思います。

Java は例外とエラーを区別しなかった、より厳密には、例外処理と大域脱出を融合させてしまった、というアレ。

あと検査例外。それ自体は、閉鎖/開放原則に違反しているとはいえ、堅牢性とのトレードオフということでなら全然許されてもいいのではないかと思います。
Rust の Result<T, E> だって、実質的な検査例外です。Go はエラーチェックを強制しないことで閉鎖/開放原則に違反しない道を選びましたが、それでも、Java における非検査例外とは違って、基本的にはチェックすべきものです。
Java の場合、やはり検査例外と大域脱出とを組み合わせてしまったのはよくないですよね。エフェクトが大きくなりすぎます。

いや、でも難しいですね。Rust。
まだ見よう見まねで書いてただけなので、IDE で書いたらもう少し感想が変わるかとは思いますが、うん、難しい。Scala よりだいぶ難しい気がします。

ドキュメントを読みあさることにします。

YouTube を観るようになった

遅くね?
はい、遅いですね。

流行りものが嫌いなめんどくさい性格なので、どうしてもニコニコから離れられないでいたのです。結果、Vtuber の波からも遅れてしまいましたが。

かといって、ニコニコを観ているかといえばそうでもない。
最近はめっきり観てないです。気に入っている数人の投稿者の動画を追っているくらい。

で、ちょっとひさびさにニコニコでゲーム実況を観てたんですよ。懐かしいな、こんな実況者いたなー、とか思いながら。

でも、もうニコニコで新作はアップロードされないんです。
みんな YouTube 行っちゃったもんね。

ということで、ようやく YouTube を観るようになりました。でも、まだニコニコ出身の実況者の動画しか観てないですね。キヨさん、ガッチマンさんの2人。

最近はホラー実況をよく観てます。普通のゲームなら、実況観るよりも自分でプレイしたいって思いますもん。
ホラーだと自分でプレイできないので、申し訳ないですが動画で終わらせることにしてます。

ゲームやりたい

もしかしたら自分はゲームがあまり好きじゃないのかも、と思うことはあります。
すごく飽きっぽいので、ひとつのゲームをプレイし続けられません。

もっと言うなら、オンラインの対人ゲームが苦手です。見ず知らずのオンラインの相手と接するのが怖くてしょうがない。

よく Twitter とかで、ネットで知り合った人と通話してる人を見かけるんですよ。ほんとすごいなと思います。

せっかくグラボはそこそこ良いの持ってる (Radeon RX Vega 64) のに、あまり活かしきれてないんですよね。2D ゲームが好きなので。
下手なインディーズ ゲームよりも、RPG ツクール製のゲームのほうがおもしろいって何度でも言います。

ツクール製のフリーゲームはだいたいやり尽くしてしまって、今後もあまりおもしろそうなものに出会える可能性は限りなく低いでしょう。ホラーゲームが多いのも、個人的にはあまり歓迎したくない傾向...

そういうのを求めているのなら、🔞のツクール製ゲーム、すごくいいですよ。かなり長時間遊べるものが多いです。特に RPG 系だと寄り道クエストがたくさん用意してあったり、めちゃくちゃマップが広かったり、無駄にやりこみ要素が充実してたりして、100時間とか遊べるものもザラにあります。
むしろアレなイベントやシーンとかは飛ばしちゃうことが多いですね、長いし、そこにあまり興味を持ってるわけではないんです。

まぁそんなことは置いておいて、TL を見てるとですね、つよつよな方たちは普通にゲームやってたりするんですよ。でも強い。
いっぽう私は、コードを触っていたり読んでいる時間はまぁまぁ長いのですが、強くはない。

だからなんだって話なんですが。要領の良さを見習いたいものです。


いつもどおり収集つかなくなってきたのでここらでいったんストップ。

でもなにも気にせず書けるので、書きたいことが出てきたらこういうの書くかもしれません。

bye

Dell製のWindows 7ノートの復旧に手間取った結果、Dellが嫌いになった件

おひさ。

どうにも就活がうまく行かない というか、内定が出ない。1社しか。
1社出てるだけでもそりゃ大変にありがたいことなんですが、逆に言えばそこ以外は落ちてる訳でして、精神ガリガリ削れてくっぞ。
こりゃアピールポイントが薄いのなー と思ってC#で色々書いてるとこです。

3月までには就活終わるつもりでいるのでそこまでの辛抱。
そこからはほぼ丸一年暇になる訳なので。 (一人暮らしの費用はバイトで稼がないとなので、まるきり暇ではないですが

でも周りの人らみんなお強いので勝てる気がしないねっ! ハム太郎! ぐへッ




さて、久々にブログを書くモチベが出てきたので書きます。
殺意駆動執筆ってやつですな。

ことの発端は、我が家に眠っていた10年モノのDell製ノートPCを掘り起こしてきたときのこと。

ちなみに機種名はInspiron 15 N5010。
第1世代のi5を積んだ、まぁー古いPCです。OSはWindows 7
リカバリディスクやWindowsのインストールディスクが付属していないDtoDタイプ (リカバリ領域を使ってリカバリする)。

これを初期化して売ろうと思い、Dell DataSafe Local BackupというDell謹製のツールで作成したUSBメモリリカバリしてみたんだけど… できない。

いや、リカバリそのものは成功するんです。ちゃんと起動もする。

ただ、一度シャットダウンするともうダメ。0xc000000eのエラー吐いて起動しなくなります。
どうやらブートセクタがぶっ壊れてしまっているようです。

こういう時はシステム修復ディスクを使ってコマンドプロンプトから直してやるのが定石。

再度リカバリして、適当なCD-Rを突っ込んでシステム修復ディスクを作ってみると…

0x4001100200001012 のエラー表示。 (なげぇ

これは何? 頼みの綱のシステム修復ディスクでエラーって何事?
と思ってググってみると、同じ現象に悩まされている人が何人かいるようでした。

簡潔にまとめると、DellWindowsに独自に組み込んだリカバリ機能のせいで、システム修復ディスクが正常に作成されないという不具合があったようです。

まぁ、昔はWindowsのインストールディスクが付属するのが当たり前だったので、そちらをシステム修復ディスク代わりに使えば良いだけのこと。あまり問題にはならなかったのでしょうが。
最近はインストールディスクなんて付いてきません。自分でシステム修復ディスクを作る必要があります。

だと言うのに、Dellはこの不具合を「そういった問題が出ていることは把握しているが、不具合ではない。修正する予定もない」とのたまっているらしく。
あまりに杜撰な対応で、しかも不具合を放置したままインストールディスクを別売にしたというのは、Dellのシステム修復ディスクに対する重要性の認識が甘すぎるのではないかと言わざるを得ません。

前々からDellのサポートはよくわからんことを言うのであまり信用しないことにしていたのですが、今回の件で決定的に信用ガタ落ちしました。
一生買わねぇ。

私の場合は、ほかにDVDドライブ付きのPCがあったのでそちらで作ったシステム修復ディスクを使って対処できましたが、そのPCしか持っていないと言う人も少なくないでしょう。
その場合、Dellに頼み込んで (そのDellのせいでこんなことになっているのに!)インストールディスクを送ってきてもらうか、もしサポートが切れているのなら、違法に出回っているシステム修復ディスクのイメージを使うしかないでしょう。

私が自作PCを好むようになったのは、もちろんコスパのこともありますが、純粋なWindowsを使用したいという気持ちが強かったからです。
OEM版のWindowsというのは少なからずメーカーのカスタマイズが施されています。それに依存したくないというか。自作PCならリカバリディスクなんてものはありませんからね。インストールディスクがそのままリカバリディスク代わりになるので。

あ、Intel NUC Kitとかも良いね。プレーンなWindowsらしいですから。


まァとにかく、そんな訳で Dellが嫌いになりましたというお話でした。

高専を辞めて半年が経過したので進捗報告 〜三重苦を背負っての就活〜

高専OBOG Advent Calendar 2019 11日目の記事になります。


本当にごめんなさい、遅刻しました
言い訳をすると、とある企業さんへ提出する選考課題があったんです。
課題が提示されたのが一昨日で、つまり制作期間が2日間しかなくてですね。徹夜して 先ほどなんとか提出できましたが、コレ書いてなくても危うかったくらいなんです。提出期限の15分前くらいに提出しましたもん。


えー、私が高専を辞めて専門学校へ入学してから半年が経過しましたので、この記事ではその所感をざっくりと記しておきたいと思います。
課題やってから大急ぎで書いてるので、収集がつかなくなるであろうことは自明です。読みにくいかとは思いますが、許してください。


つーかもう半年が経ったんですか?
2019年終わるってマジ? 早すぎないですかホント。歳とると時間の流れが〜 って本当ですね。怖い。

そうそう、私は特にWebエンジニア志望なので、そちらへ沿った内容になるかと思います。ほかの業界のことはわからないので期待しないでください。


目次


なぜ辞めた?

もういい加減 この辺のネタは色んなところで話してるので、ここでは書きません。

かと言って、なんか 高専辞めたのはこれが原因で〜 とか 所詮は言い訳みたいなそんな見苦しい記事にリンク貼るのも恥ずかしいので、探してください。noteとかに書いてます。


三重苦を背負っての就活

そろそろと就活を始めた私ですが、そんな私の背中には3つの重荷がのしかかっていたのです。

これらの三重苦は、実際に就活をする上でどれほど障害になるのか? そもそも障害となり得るのか?
というのが段々とわかりかけてきたので、軽くまとめます。

まずは三重苦。

1. 高専を辞めた

なんだかんだ言って、高専を辞めることによって生じる最大のデメリットは「高専生でなくなること」なんですよね。

高専コミュニティの力は絶大です。エンジニア志望なら尚更です。
ここまで日本中に網を張っている技術者のネットワークはそうないのではないでしょうか?

とかく、大学生や院生には与えられない、高専生だけのチャンスというものが 思いのほかたくさんあるということを、高専辞めてから知りました。

私が高専コミュニティに関わり始めたのが、高専を辞める少し前からだったんです。
今でこそ私のTwitterのFF人数は結構な多さになってきましたが、高専在学中はもっと規模が小さかったんです。
それが、わりと最近になって高専生のアカウントをTwitterでフォローするようになり、そこからぐんぐんと増えていった感じ。

私の通っていた某高専は、あまり(全く?)情報系の分野に強くなく、それが影響しているのかわかりませんが、高専カンファレンスなどの存在も全く知りませんでした。
Twitterって大事ですね。

こうして高専生や技術系のアカウントがFF内に増えてくると、TLが高専と技術の話題で埋まるようになってくるんですね。
こうなってくると、Twitterは非常に効率の良い情報収集ツールに化けます。 普段通りにTLを眺めているだけで、IT業界の動向や新技術などの情報がどんどん脳内に流れ込んできます。スピ◯ドラーニングです。

更にその上もあります。
過度に技術系アカウントが増えたTLというのは、私よりもはるかに格の高い魑魅魍魎 (つよつよエンジニア)たちが蔓延る混沌の世界と化します。
私のようなへっぽこエンジニアはガリガリと自尊心が削られていきますが、それはそれで良いモチベーションの維持に繋がるのです。
Twitterを軸に開発を進めていくTDD (Twitter-Driven-Development、Twitter駆動開発)という手法は、通常の開発よりもはるかに優れた効率を叩き出すことが証明されています (個人調べ)。

もっと早くに高専コミュニティに関わるようになっていれば、高専に残るという選択肢を選んでいた可能性は十分にあったと思います。

2. 名古屋の専門学校に通っている

私は岐阜県に住んでいて、毎朝 名古屋にある情報系の専門学校まで通っています。一応言っておくと、HALではないです。

やはり地方の学生にとっては、IT業界の就活は少し辛いものがあるのではないでしょうか?

「名古屋ならまだマシじゃねーか!」という声が飛んできそうですが、とんでもない。
名古屋なんて、東京や福岡、大阪に比べたら、IT関連の規模ははるかに下です。IT企業の数そのものは少なくはないのですが、Web系となるとその数はガクッと減ります。
上場しているような有名な企業さんでいえば、ATEAMさんくらいでしょうか。

まぁ地理的アドバンテージはまだ良いのです。これは私に限らず、多くの高専生にも該当することだと思うので。

それよりも問題なのは、「専門学校生」という点。

専門学校というのは、大学とは違って 普通の高校と同じように授業がビッシリ入ってます。つまり、平日に就活を行うのが難しいです。

…ちょっと口が悪くなってしまいますが、私の場合、別に就職さえできれば専門学校にはあまり用はないのです。
しかし、教師との関係が悪化するのは私としても避けたいので、そう目立った行動は起こせません。

そもそも、なぜ就職でもなく大学に入るでもなく専門学校を選んだのかと言いますと。

まず、高専を辞めると決めたのが2018年の12月頃とかなり遅めでした。あと1、2ヶ月で大学入試なんて不可能。この線はナシです。

そして、私は2016年4月に高専へ入学し、2019年3月に退学しました。ぱっと見、3年課程を修了しているように思えるじゃないですか。
でも私は2年生のときにワンクッション挟んでいる (察してくれ)ので、3年課程修了してないんです。

最終学歴中卒で就職はちょっと… ねぇ?

IT業界、特にWeb業界はあまり学歴を気にしないとは言います。
しかし実際のところは、大学の偏差値や文系・理系による違いとかはあまり考慮しないよ〜 というくらいのことで、高等教育課程 (高専5年、専門学校、大学、大学院など)を修了しておくのはほぼマストです。

強いて言うなら、それこそ高専の3年課程修了が唯一の例外と考えて良いでしょう。
Twitterでの知り合いにも、高専を3年修了と同時に辞め、フロントエンド界隈ではかなり有名な某企業へ就職を果たした方がいます。しかし、これはかなりのレアケースではあることは間違いないです。

そんな訳で、私はほぼ学歴作りのためだけに専門学校へ来たのです。

そして、専門学校というだけでなく「名古屋の」という点もここでかなり影響してきます。

名古屋周辺はトヨタ系列の企業が根強く残っており、それに伴ってSIerの業種がほとんどとなっています。私はWebエンジニア志望だったのですが、学校へ来る求人とか そういうのは全部やはりSIer系ばかり。
全くアテにできません。自分だけで就活を進めていく必要があります。

と、地理的にも環境的にもやや就活しづらい状況になってしまっている訳です。

3. 実績がない

一番困るやつです。

先述した内容でなんとなく察せるかと思いますが、高専にいた頃の私は、就活に関して全く関心がありませんでした。
いわゆるハッカソンやコンテスト、カンファレンスなど、そういった類の催し物への参加経験も一切ありませんでした。

プログラミング自体は好きでやっていて、いくつか制作物もありました。
Haxeで書いたゲームボーイエミュレータとか… そうそう手を出すことのない領域だろうし、これは実績として使えそうだと思っていました。

…2019年の夏までは。

ここで悲しい悲しい事件が起こります。
それが「GitHubアカウント消失事件」です。

私は、これまでのほぼ全てのプロジェクトをGitHubPrivateリポジトリで管理していました。
だいぶ昔のプロジェクトの中にはまだGitで管理していなかったものもいくつかありましたが、PCを買い換えたときにバックアップとして一通りGitHubへ投げ、ローカルのデータは全て消去しました。

私はセキュリティにも気を使っていたので、GitHub2段階認証を有効にしていました。iPhoneGoogle Authenticatorアプリを入れ、そこでワンタイムトークンを管理していました。

私はその頃、iPhone 7 Plusを脱獄 (Jailbreak)して使っていたのですが、もうiOS 13が登場しようとしているのにiOS 9.1のまま止まっているのが段々嫌になってきたので、入獄することにしました。
で、なんか脱獄してゴミとか溜まってそうだったし どうせならクリーンインストールしちゃおう、と。

あとはわかりましたね?
そう、GitHubの2段階認証を有効にしたまま、iPhoneのデータを消してしまったのです。
あたしってほんとバカ…

こうして2段階認証によって締め出された私は、なんとバックアップコードも紛失していたことが判明。
サポートに問い合わせたところ、「オーケー、わかった! アカウント消すからPublicリポジトリを一通りCloneしておいてね :) (要約)」との返答。

私が欲しいのはPrivateリポジトリなんだよ!!! と叫びたい衝動を堪え、泣く泣くアカウントを電子の海に葬り去ったという訳です。

えー、今回は私が完全に悪いのですが。
とにかく、Google Authenticatorはオススメしません。バックアップ機能がついておらず、端末を移行する際は各サービスの2段階認証をわざわざ手動で無効にしないといけないからです。

オススメはAuthyです。
UIはダサめですが、モバイルアプリ版に限りアイコンをカスタムできる機能が追加され、マイナーなサービスでもある程度見た目を整えられるようになりました。オンラインで同期できるので、万が一 iPhoneが死んでも安心です。

ハイ!
要するに、実績を示すものが何もない状況からのスタートです。きっっっついでしょコレ。


三重苦は実際どうだったか?

さて、この三重苦。実際に就活をやってみたらどうだったのか、についてです。

1. 高専を辞めた -> 概ね問題なし

この点に関しては概ね問題なく就活を進められています。

というか、高専を辞めてまで専門学校に行った理由は何か? っていうの 面接の度にほぼ確実に訊かれるんですよ。
いや、だって こんな経歴、絶対目を引くじゃないですか。普通に大学行きましたー ってのより200%目立ちますからね。

そこを逆手にとって、そこから上手く話を繋げていけて むしろ助かってます。

それに、一応は元高専生ですので、その辺の話で盛り上がれるというのもあります。
カンファレンスの懇親会とか行くとですね、高専卒の社員の方とか結構いらっしゃるんですよ。少なくとも2、3人くらいはいます。

私自身、高専を辞めたことに負い目を感じてはいるのです。だからという訳ではありませんが、正直、高専在校生であったり きちんと高専を卒業している人のアカウントに絡んでいくのは、「チッ オメー高専辞めたクセに話しかけてくんじゃねぇ!」って思われないかなー とか、高専カンファとかも、もし自分がその場にいたら浮かないだろうか… とか考えてしまいます。

だってホラ 例えば自分のクラスにさ、やたらほかの人に干渉してくる留年生降ってきたらさ ウザいじゃん?
そういう経験ないです?

でもまぁ これからは高専退学おじさんとしてもう少し図々しくなってみようかと思います。高専カンファ福岡、行きたいよね…

就活 (特にWeb系)のこととか質問してくれれば、むしろ喜ぶのでバシバシ絡んでやってください。

2. 名古屋の専門学校に通っている -> 概ね問題なし

これも、今のところほぼ不自由なく就活できています。

会社説明会… とかはちょっと厳しいかもしれませんが、インターンシップ等であれば企業側が交通費や宿泊費を負担してくれることが多いです。
それに、どこでも寝れるタイプだというのであれば、夜行バスとカプセルホテルを利用すればかなり安く都会へ行けます。

最近では、地方の就活生のために宿泊施設を無償で提供してくれるサービスなんかもあると聞きます。今度使ってみようかな。

それに、今はだいたいどこの企業さんでもオンラインでの面談を実施してくれます。
選考に関わる面接と言う訳ではなく、カジュアル面談として、本格的な選考に進む前に色々と話せる機会を作ってもらえるのです。

そして、サポーターズさん、キャリアセレクトさんのような、Webエンジニアの就活を支援してくれるサービス。これは是非とも利用すべきです。
交通費を出してくれる逆求人イベントを開催してくれたり、色々な企業さんから説明会のお知らせが届いたりします。
きちんとプロフィールを埋めておけば、スタッフの方と直接やり取りをして企業を紹介して頂けたりもします。

あとWantedlyとか。アレ 結構プロフィール頑張って埋めないとスカウトとか来ないんですよね。
その代わり、各企業から個別のメッセージと共にスカウトが飛んでくるので、しっかりとプロフィールを読んでくれた企業さんなんだなー っていうのがわかりやすくて良いです。

ただ、休みが取れないっていうのは相変わらず困ってます。
何より長期インターンができないっていうのしんどいですね。近場で技術アルバイトを探すほかありません。

私の通っている専門学校は、会社説明会とか面接とかであれば、面倒な手続きを踏むことで公欠扱いにしてもらえます。
ただ、カンファレンスとかはダメなんです。
BIT VALLEY 2019に行くために欠席することを伝えたら、「カンファレンスとか行っても就職に繋がる訳じゃないでしょ。それより授業休まないように」と…

まぁ言いたいことはわかるんです。
でもあんな… クソつまんない授業受けて時間を浪費するより、色んな人の話聞いてコミュニケーション取ってた方がはるかに良いと思うんですけど。皆さんどう思われます?

3. 実績がない -> 困るが絶望的ではない

これはやっぱり今でも困ってます。

これまでの制作物を提出しろっていう企業さんは思ったよりは少ない印象です。
フロントエンドやWebデザイナー、ゲームエンジニアとなると多くなってるのでしょうね。

まぁ、形がないとはいえ、実際に作った経験はあるものなので、その辺のノウハウはキチンとありますよ ってことを上手くアピールできれば良いとは思います。

あと、Chatworkさんのサマーインターンに参加させて頂けたのが良い評価となっているようで、そこからスカウトや招待の数がグンと増えました。
インターンシップは大事ですよ。夏休みとか、是非みんな行きましょう。

カンファレンスなどは、興味を惹かれるものであれば (あと金銭的に厳しくなければ)、なるべく行くようにしています。
また、このまま「セッションやLTを聴いているだけでは嫌だ!」と思い始めてきていたので、学生LTで思い切って登壇してみたり。アウトプットを増やす心がけをするようにしました。

というか、就活がどうの以前に、普通にショッキングですよ。これまで作ったものが跡形もなく消えるってさァ… ホント心臓によくないです。

胸を張って提出できるようなソースコードが残っていれば、今回アドベントカレンダー遅刻することもなかった訳で。
良い子のみんなは2段階認証の管理はちゃんとしようね!


おわり

いつも通り 取り留めがなくなってきたところで終わろうかと思います。

正直、今のところ就活はかなり充実しています。
既に1つ内定は頂いていて、しかも私の志望している業種にとても近い企業さんです。
IT業界でそんなことはないかと思いますが、大卒なのに数十社受けても内定が出ない〜 なんて話もよく聞きますし… この経歴の割には健闘できているほうじゃないでしょうか?

まぁそれはそれとして、就活はまだ続けるつもりです。企業なんて星の数ほどある訳で、自分に最もマッチする企業と出会える確率なんて本当に低いはず。
就活時期に余裕がある間は、そこのところを突き詰めるために 普通に就活を続けていくつもりです。

私は高専を辞めたことがターニングポイントとなって、ここ半年で色々と成長できたという実感があります。
あ、高専を辞めた「から」ではないことには留意してくださいね。そりゃ辞めないに越したことはないので。

そんな感じです。高専辞めたからって希望を失うことはないんやで。


あ、アドベントカレンダー、遅刻して本当に申し訳ありませんでした。徹夜してコード書いてたんです、遊んでた訳ではないので許してください。


ようやく書き終わった…
このあと、面接のために京都行ってきます。夜行バスで。

それでは〜

Chatworkのサマーインターン2019に参加しましたレポ

どうも、とらきすです。
このブログではお久しぶりですね。

ロシア語記事の続きは、色々と忙しいのでしばらくは書けません。就活がひと段落して落ち着いてきたらのんびりと再開させたいと思います。


さて、この記事は、Chatwork株式会社様のScalaサマーインターンシップ2019に参加させて頂いたときのレポートのような何かです。

もっともっと長くてグダい超真面目な記事も書いていたのですが、読んでいて疲れるのでボツにしました。
時系列に沿った詳細なレポートはほかのインターン生の方々が書いてくれるだろうと信じて…

こちら、Chatwork Creator's Note社員さんのセッション資料で大まかには把握できるかと思います。読もう。


目次


それまで

とは言いましても、インターンシップへ参加させて頂けるようになった経緯などは最低限書いていきます。私自身が少し「トガった」経歴を持っているので、これは似た境遇を持つ方へ向けての記事でもあるのです。

簡潔にまとめますと、私はとある高専の電気情報工学科へ入学し、2年生を2回繰り返し、退学して情報系専門学校の2年課程の学科へ入学しました。今はその専門学校の1年生です。

もし詳細が知りたいという物好きな方は私のnoteを読んで頂けると。

さて、私はWebエンジニア、それもバックエンドエンジニア志望でした。C#Scalaなど、バックエンドの静的型付け言語を好んで使っていたためです。しかし、専門学校はどちらかと言えばSIer向けの授業が多く、それに頼りきりになる訳にはいきません。
学校側が出してくるインターンにもWeb系企業なんてありませんので、自分で探す必要がありました。

そこで、私は以下の条件に合致するインターンを探しました。

  1. バックエンド
  2. 静的型付け言語
    • 動的型付け言語があまり好きじゃない
  3. 2週間以上
    • 1Dayとか正直意味ないと思っている
  4. 東京か大阪近辺
    • そりゃIT系なんだから都会の方が良い
    • 名古屋は田舎
  5. 設計から開発までのフローを一通り経験できる
    • 一番重要。私は設計周りの経験が全くの皆無だったので勉強しておきたかった

すると、Wantedlyで見知った8文字を発見。それがChatworkさんでした。
専門学校で教師と学生間の連絡ツールとしてChatworkが使用されていたので、存在は以前から知っていました。
ほかにもScalaを使用している企業はいくつか見つけましたが、その多くがアドテクであったりPlay Frameworkを採用しているなかで、Akkaを中心とした独自のシステムを運用しているというChatworkにはひときわ惹かれ、 これは運命だと言わんばかりに申し込みました。

色々とそれまでの経歴やなけなしの実績を入力し、書類選考は通過、そしてビデオ面接に。面接には、人事の方だけでなくエンジニアの方も同席していました。
なお、私の家にはWebカメラがなかったので、iPhoneで面接を受けました。

けっこう緊張していたので内容までははっきりと覚えていないのですが、わりと色々とカジュアルに話させて頂きました。
やはりエンジニアの方がいるのといないのとでは全然違うなと。ほかの某有名ベンチャー企業インターンにも申し込んだのですが、そちらは人事の方しかいらっしゃらず、なんだか事務的な面接だなーと率直に感じました(なお落選したもよう)。エンジニアの方には技術系の話のウケが良いので、色々とアピールしやすいです。
特に私の場合、ESに書けるような実績がほぼ皆無であるどころか、学歴だけ見たらただのやべーやつですので。面接が鍵になるんですよね。

で、Chatworkさんから合格の通知を頂いたときには、とんでもなく驚きました。まさか私が? と思いましたもん。
聞いたところによると、やはり自分の言葉で話すことのできるスキルが必要だそう。その方面に全く興味がない、あるいは事前に話す内容をキッチリ決めてきちゃっていると、ボロが出てくるらしいんです。
私は… あまり何を話すか事前に考えてなかったのですが、話しやすい方だったので自然と色々話題を出すことができたと思います。


いざインターン

蒲郡で2週間の自動車学校合宿を終え、その3日後には大阪まで飛んで3週間のインターンが始まりました。夏休みはこれだけでほとんど埋まってしまっていて、実際の休日は5日くらいでしたね。
とは言え、インターン就業中は土日休みで大阪を観光できるようになっていたので(したとは言ってない)、とても充実した夏休みになりました。ホテル暮らしが快適すぎた…

ほかのインターン生6名は、全員成人済みの大学生ないし大学院生の方で、バリバリの情報系学生が来るのかと思いきや、意外とそうでもなく、かなりバラエティに富んだ人選でした。
私だけ専門学校生の18歳で、最初はだいぶ緊張していたのですが、皆さんとても良い人で、すごく仲良くしてもらっていました。
3週間とは言え開発の紆余曲折を共に乗り切った訳ですから、インターンが終わってすっげー寂しいです。また7人で集まりたいですね。


カルチャーショック

まずオフィスに入って衝撃

やっぱり会社っていうと、みんなカチッとしたスーツを着て、デスクが島みたいに並んでて、四六時中プルプル電話鳴ってる、みたいな…
いかにもって感じですが、私の中では大まかにそんなイメージが強かったんですね。

それがどうよ。

木目調の床やテーブル、全て窓側を向いていて1つ1つ仕切られたデスク、3つの“Work”、“Fun”、“Creative”と銘打たれた会議室、ところどころに置いてあるLEGO… そして何より、中央に鎮座するバーカウンター(本物の酒も置いてあって雰囲気あります)。

んん? ここはオフィスか? と思いますよそりゃ。

しかし当然というか、居心地がとても良い。
Chatworkの「働くをもっと楽しく、創造的に」というスローガンを体現したかのようなオフィスです(気づきましたか? 3つの会議室の名前はここから取られているんです)。
そういった働き方をするためのツールを作っていく会社なのですから、まずは自分たちの働き方を変えていこうと、そういうことらしいです。


濃密な講義

はじめの1週間は講義パート。とにかく色々と詰め込まれた講義を受け続けていました。

クリーンアーキテクチャドメイン駆動設計などの講義では、その分野では有名なかとじゅん(@j5ik2o)さんに講義して頂きました。あの短時間でものすごくたくさんの情報が脳に流れ込んできて少しビビりましたが、とてもわかりやすい解説でした。こちらがお金を払いたいレベルで勉強になりますよコレ。体感的には、1講義でカンファ5つ分くらいの濃度。

ほかにもチーム開発やインフラ周りのことなどを包括的に教えて頂きました。この1週間だけでもものすごく勉強になりました。

紆余曲折あった開発

講義も終わり、いよいよ2週間の開発パートへ。
7人でスクラムを組み、1週間ずつの2スプリント体制で行いました。内容は、クリーンアーキテクチャドメイン駆動設計に基づいで設計された社内プロダクトへの機能追加です。大まかに言えば、RPCスタイルのWebアプリケーション。
今回は、GitHub Projectを活用したカンバン式チーム開発を意識して進めていきました。

基本的にはモブプログラミング形式を採用。集合知と言いますか、足りない部分を全員で補完し合えるのでとても良かったと思います。
途中からはブランチを更に切って、2チーム体制で開発してました。

とにかく「初めて」だらけでしたね。普段 趣味で開発するぶんには設計とかやらずにぶっつけ本番で作ることが多かったですし、テストをしたこともありませんでした。

学んだことは、とにかく設計にかかる時間の多さ。実装やテストよりも、設計やテストケース作成の時間のかかること。
なにせチーム開発ってのが経験ありませんので… 例えば日本語の文法をどう統一するか、みたいな少し本質とはズレた部分で長々と議論したりしてました。ほかにも、既に実装に取り掛かってるのに(これ、まずいのでは…?)となるケース。社員さんにたくさん頂いた指摘を時間の都合で全部蹴ったり…
恐らく、実装そのものよりも、こういう部分が一番経験の差として現れてくる部分なんだと思います。

結局、スプリントゴールは完全には達成できず!
一応、最低限とよべる部分まではデプロイし終えたのですが。そこは少し心残りでしたね。

もし次のサマーインターンがあれば、どうなるのかすごく気になります… ふふふ…


大阪良いなー

と、わりと本気で思いました。

まず、飯がうまい(ここ大事)。
福島駅の近くまで歩いていけば、安くて美味しいご飯屋さん・呑み屋さんがたくさんあります。これは飽きないですね、どこに入ってもおよそハズレというものがない。
昼と夜は、ほぼ毎日インターン生の皆でご飯食べに行ってました。高専辞めたあとは体重がだいぶ減ってきていたのですが、このインターンで元に戻りましたね。太るぜこれは。
それに、大阪駅から伸びた地下通路がオフィスのすぐ近くまで続いていて、雨の日でも濡れずにご飯にありつけます。最高。

それに、人混みが苦手な人にも良いです。
都会っぽさを感じたいのであれば(私のような田舎者はすごく都会に憧れるのです)、大阪駅の周りに行けば昼も夜もなくめちゃくちゃ人が多くて賑やかです。
しかしそこから10分ほど歩けば、一気に静かな街並みに。ほど良い感じ。

インターンの少し後に、BIT VALLEY 2019やScala秋祭りに参加するために4日間ほど東京に行ってきたのですが、やはり大阪よりも人は多いと感じました。
ただ、私にとってはこれもあまり嫌な感じではなく、慣れれば大丈夫かなと。空気の汚さとか、私 鈍感なので全然気にならなかったです。
ただ、駅の複雑さには閉口しました。新宿駅でずっと迷ってました。そこは大阪駅の方が良かった。あそこも地下街ジャングルだけど。

追記: 食べたご飯たち

ups.hatenablog.jp

↑しゅういちさんのレポでご飯の画像載っけてるのいいなー と思ったので私も載せます。適当にチョイス。


プルコギ定食。



ステーキランチ。1000円でコレ。


からあげ定食。


チキン南蛮。


まるげりーた。


肉そばと焼豚丼


チーズトマトラーメン。


チキンカツライス(だったかな)。


チーズ豚平焼き。



高級イタリアン。

ね、全部美味しそうでしょ? 住みたいよねここ。


さいごに

とてもとても濃い3週間を過ごさせて頂きました。
正直言って、ここ数年で高専や専門学校で学んだことよりも沢山のことを学べたと思う。いやホントに。

そもそも、“こういう話”ができる相手がいるというだけでもすごく楽しかったですね。高専とか、周りにはあまり情報系つよつよな人がいなかったので。
ギーク話で盛り上がれるって良い。これこそ心理的安全性。

ほかにもScalaを書けるインターンシップというのは探せばけっこうあります(私が個人的にまとめたScalaが書けて新卒募集してる企業リストを見よう!)。
しかし、チャットツールのシステムとしてScalaを使っている企業となるとその数は一気に減ります。ほかにはLINE、ヌーラボさんあたりくらいだろうか… とても貴重な体験をさせて頂きました。

あと、もっとScalaを付けなければと切実に思いました。正直、ついていくだけで精一杯だった感が否めない。ScalaMatsuri 2020は絶対行くぞ。
ほかにも身内のLTとかでScalaを布教したいですね。みんなも沼にハマろうよ。


そんな訳で、いつも通り収集が付かなくなってきたところで終わろうと思います。それじゃ。