教えちゃお
Scala+PlayでDIする情報を漁っていたらScalaでDI(Play framework2.7 + Guice編)を発見した。控えめに言ってこれは神。一番素晴らしいのはPlay framework2.7で2019年7月12日という新しさ。Playやその他Scalaのフレームワークは容赦のない変更をぶっこんでくる（慣れてないからそう感じるだけかもしれないが）ので、バージョンが違うと全然動かないということはよくある。
技術情報で何より重要なのは新しさだ。記事になっているからには書いた人の環境で、書いたときには動いていたのだろう。しかし時間が経てば経つほど同じコードが動く確率は下がっていく。
だから古い記事の内容を持ち出してきて「これは今でも動く」と書いてくれているだけの情報でも素晴らし価値がある。発信していけ。
何もわかってないけどPlayFramework2.4におけるDIのテスト方法とかWriting functional tests with ScalaTestとかトレイトの応用編：依存性の注入によるリファクタリングとか読みながらそれっぽい形をした何かを書いている。DIが何をするものなのかはわかってきたが、結局それを実現するためのライブラリの使い方もわからなきゃいけないのでは…？
今週末はすごい嵐になるらしい。停電覚悟で本でも買っておこうか。水と食料。なんで台風いつも休日に来るの？
いつもは日曜日にやることだが、3連休なので今日銭湯に行った。サウナは磨りガラスで仕切られていて、そこに中でタオルを振り回す人間の影が映っていてちょっとしたホラーだった。
この3連休で割と熱心にDota2をプレイした。最近は上達の感覚がある。行動とその効果の関係を以前よりも鋭く捉えられるようになった気がする。ちょっとした移動や位置取りでより貪欲にアドバンテージを取っていけるようになった。現在のMMRは4051だ。
Scalaはなかなか進まない。GETリクエストを受けてDBからデータを取り出して返すメソッドのテストをどう書くべきか思案している。DBという外部システムへの依存はユニットテストには持ち込まないのが原則だ。つまりDBからデータを取り出す部分を別の関数に切り出し、本番とテストで別の関数を呼び出すようにする。逆に言えば2種類の実装を本番とテストでそれぞれ注入するということになり、このテクニックを依存性注入（Dependency Injection）と呼ぶ。たぶん合ってるはず。
ガチで知りたい人はこの辺読んでください。僕も今読んでます。
今日は10時に出勤して19時に帰ってみた（帰れてはいない）。
夜に空腹になる前に帰宅できるので間食を削減する効果は確かにありそうだ。午前10時は午前11時に比べて涼しいというのもいい。
逆に世の一般的な通勤時間に近づくので電車は混む。難しいところだ。多数派と違うことをすることでメリットが生じる場合もあるが、それ以前に多数派というのはメリットがあって多数になっているのだ。
帰宅してScalaを書いていた。PlayのFormではmodelのunapplyメソッドが必要になる。フォームのデフォルト値としてmodelの情報を入れておくような機能のためだ。
unapplyはcase classだと勝手に作ってくれるのだが、そうでなければ自分で実装する必要がある。コップ本の26章を読むといろいろわかる。Scalaの武器であるパターンマッチの一種、コンストラクターパターンに使われているとか。
Dota2のSoloMMR（サポート）が4051になり過去最高になった。最近はDazzleスパムをやめてAncient ApparitionやWarlockを使っている。どちらもダメージを出せるサポートヒーローで楽しい。だが両者の操作感は全く違う。前者はスキルのクールダウンが短く、アイテムとのコンボも必要になるアクション要素の高いヒーローだ。一方で後者はスキルのクールダウンが長く、タイミングや立ち回りが求められる。
未来のある時点に向かって準備しなくてはいけないものが出現したのでなんとなく落ち着かない気分だ。大学にいる頃からこの感覚がひどく苦手で、会社員になるとだいぶ緩和されていたのだが、やはり人生そう甘くはない。毎日死の準備をしながら生きていこうな。
Scalaのクラスはcase classにするとapplyメソッドが自動で生えるのだが、これと合わせてコンパニオンオブジェクトで自前のapplyも実装するとコンパイラがどっちを使うか判断できなくて怒る。
sealed abstract case classという手もあるらしいが、インスタンス化したいクラスなのでこの手は使えない。結局どうにも出来なかったのでcase classにすることをやめた。それほど恩恵を受けていたわけでもないし。
普段仕事ではTypeScriptを書いているので
const x: "kinoko" | "takenoko" = "kinoko";
みたいなの（Union型という）に見慣れていた。
趣味ではScalaを書いており、同じようなものを書きたくなった。具体的にはActiviryPubのActor Typesを表現するためにApplication, Group, Organization, Person, Serviceのどれかの値（いずれも文字列）をとるという型を作りたかった。
しかし調べてみるとScalaにUnion型はない。自分でパッと思いついたのはcase classだ。ドワンゴのScalaテキストに近い用例が載っている。下にそれを引用する。
sealed abstract class DayOfWeek
case object Sunday extends DayOfWeek
case object Monday extends DayOfWeek
case object Tuesday extends DayOfWeek
case object Wednesday extends DayOfWeek
case object Thursday extends DayOfWeek
case object Friday extends DayOfWeek
case object Saturday extends DayOfWeek
sealed修飾子をスーパークラス/トレイトに付けることによって、その（直接の）サブクラス/トレイトは同じファイル内にしか定義できない
ので、パターンマッチするときにコンパイラがいい感じにチェックしてくれるというメリットがある。
上記を参考にこんな感じで実装してみた。欲しいのは文字列なので、toStringをoverrideしてクラス名をそのまま取得できるようにした。
objectにするとgetClass.getNameの末尾に$がついてしまうのでinitしている。最後の1文字を除去するというメソッドがある多機能さ、いかにもScalaっぽい。あるいはcase objectじゃなくてcase classにすればこんな小細工は不要だが、パラメータリストが必要になるという面倒臭さがある。どうあるべきなのか、自信ニキは教えてほしい。
もう一つ、これは同僚に教えてもらったものだが、Enum型を使う方法もある。
こちらは採用しなかったのであまり深入りしていない。もしかしたらこっちのほうが良かったかもしれない。いや、いま猛烈にそんな気がしている（表現したいのが単なる文字列なので）。
それにしても大事なのはググり力だ。僕が「Scala ユニオン型」で検索してもいい情報は得られなかったが、「代数的データ型」という言葉を知っていればこの記事に辿り着けただろう。思うに、体系的な勉強は裏切らないのだ。
型の道は深く険しい…
8/29
月末なので労働時間調整のために早く退勤した。時間が出来たのでDota2を3ゲームやったが全部負けた。自分一人の力ではどうしようもないと感じる負け方だったので辛い。
Scala+Play FrameWorkで作っているアプリケーションでDBの初期化のためにEvolutionsを使おうとしていたのだが
Unexpected exception[JdbcSQLSyntaxErrorException: Table "PLAY_EVOLUTIONS" not found;
というエラーがでてどうやっても解決できなかったので諦めた。情報がなさすぎる。
Evolutionsを使わなくても、適当なクラスのコンストラクタでcreate tableすれば済む話だった。ちゃんと公開するときはDBは別で作ればいいし。
vscodeにMetals拡張を入れてScala+PlayFrameworkの開発をしている。
import play.api.db.Databaseがエラー扱いになるが、コンパイルは通るし動く。play.api.dbはplayそのものには存在せず、プラグインに追加によってインポート可能になるからだろうか。よくわからん。
ずーっとエラーと格闘してなんとなく回避法を見つけつつ結局よくわからんになるの、実に個人開発みがあって良い。
日曜なので意識的に在宅していた。
Dota2のTI9がアツい。FnaticがVPに勝つ番狂わせが起きるかと思いきや起きなかった。Dota2の試合時間はだいたい30分から40分くらいだ。ヒーローは大まかにスキルで戦うヒーローと通常攻撃で戦うヒーローに分類される。前者の方が早熟だが、金を稼いでアイテムが揃うにつれて後者の方が強くなる（基本的に時間が経てば金は貯まる）。金を横軸・強さを縦軸に取ると当然右上がりのグラフになるが、グラフの形はヒーローごとに様々だ。たとえば特定のアイテムを持つことで格段に強くなるということがある。プロレベルの試合では味方のヒーローに重要アイテムが入り、かつ敵のヒーローがまだ重要アイテムを手に入れていない絶妙なタイミングで戦いを仕掛けに行くということもある。そこで勝てば金が手に入り、また有利になる。
しかしこうして有利を拡大していっても決めきれなければ大器晩成型のヒーローによって逆転されることもある。たとえばMedusaは通常攻撃が4体攻撃になるスキルを持つ。単純に考えて通常攻撃を強化するアイテムのもたらす恩恵は4倍だ。だから強力なアイテムを揃える前に勝ちきらなければならない。
以前vscodeでScala開発を試みたときはまともに使える拡張機能がなく補完が効かなかったのだが、今はMetalsを入れるだけでいい。補完があるとプログラミングは楽だ。ミスに気づくのは早ければ早いほどいい。
今はActivityPubの実装に挑戦している。仕様が固まっているものなのでTDDしている。ActivityPubではObjectはTypeという属性を持つことを定めているが、これは予約語なので`type`と表現する必要がありややこしい。ScalaTestの機能と思っていたmatcherが実はPlayの機能だったりして難しい。フレームワーク周りの知識がない。
素人丸出しのアレだが、package hogeはそのファイルの内容をhogeに所属させるために使うことを知った。つまり他のファイルからhoge.fugaという呼び出しができるようになる。ファイルでもオブジェクトでもクラスでもなく「パッケージに所属させる」という操作の感覚が新しかった。
今日はもうひとつ、droneのデプロイもした。droneはCIの一種でgitリポジトリにpushしたときに.drone.ymlを読んで自動でテストやビルドを行う。1回毎にdockerコンテナを作って捨てることでクリーンな環境でテストできるのがdroneの特徴だが、1回毎にsbtの初期化を行うせいで（貧弱なサーバーでは）1時間以上かかってしまい、タイムアウトしてしまった。
口内の傷が嫌な感じに痛み出していて口内炎になりそうで嫌だ。口内炎は食事が楽しめないのが辛い。ただ、火曜に右上の親知らずを抜くのでどうせ1週間くらいはろくな食事ができない。
※この記事はビールを2本飲んで書かれた。
という気分になっているのだなあ。
今月末を持ちましてドワンゴを退職します。本日が最終出社日ですので、退職エントリを書きました。https://t.co/0AVDqB95lP
— Toshihiro Shimizu (@meso) 2019年6月28日
mesoさんには2017年のインターンのときに初めてお会いした。中間発表会に遅れてきたとき、席は用意してあったのに入り口の近くの床に座っていた。当時人事部長という立場にありながら偉ぶらず人を緊張させない振る舞いとしてとても印象に残った。フランクな人柄と組織の中核としての毅然とした態度の両方を尊敬している。
はてなブログに投稿しました
株式会社ドワンゴを退職します - kmizuの日記 https://t.co/OeorHfRiAm #はてなブログ— Kota Mizushima (@kmizu) 2019年6月28日
kmizuさんは新卒Scala研修の講師だった。Scalaのことなら何でも知っている。言語の第一人者から教わることで、細かな仕様にも妥当性や事情があることがわかった。動けばいいやのアマチュアではなく、隅々まで理解し尽くしたプロとしての仕事を求められることを実感した。
お二人とも新天地でのご活躍を祈っています。
くる人は誰かって？それは僕です。