Runner in the High

技術のことをかくこころみ

Elmを書くなら見ておきたいRichard Feldmanのトーク4選

弊社では「筋肉の人」*1として知られるRichard FeldmanはElmの創造神ことEvan擁するNoRedInkに所属するエンジニア。

Evanが比較的キーノート的なElmの未来やらビジョンを語るトークをする一方で、RichardはどちらかといえばElmをプロダクションで使うにあたって、どのように書くことでスケーラブルにできるか、のようなはなしをメインに据えている感じがある。

彼はアメリカで開催されているelm-confや、ヨーロッパのelm Europeなどで割と長尺のトークを務めることが多く、その内容もElm中上級者になるにはうってつけの内容ばかり。どのトークもElmの基礎的な文法や紹介は完全に端折られていて、Elmを使うこと前提でどのようにうまく使うかにフォーカスしている。

彼の動画は会社のElmメンの会(?)の中で一気に集中して見たことがあり、僕含めみんなにとって非常に学びが多かった。ということで、中でもこれだけは!というものをこの記事では紹介したい。

twitter.com

"Making Impossible States Impossible"

2016年のelm-confでのトーク。Elmではカスタムタイプを使って排他的な状態をモデリングすることで、ビジネスルール上起き得ない状態を作り出すことを不可能にすることができる。たとえば、絶対に空にならないリスト、というモジュールを作りたければ、型をしっかりとモデリングすることで空状態のリストを作れないようにすることができるし、それをコンパイル時に検出することができる。

また、カスタムタイプに対する操作を制限して内部の情報をカプセル化するためのテクニックとして、Elmのモジュールシステムを用いたOpaque Typeが紹介されている。

www.youtube.com

"Immutable Relational Data"

データソースがアプリケーションの中に分散すると、どうしても同期をとらないといけなくなってしまう。そして、同期をとる部分というのはerror-prone(エラーが起こりやすい)部分でもある。なので、できるだけデータというのは重複しないようにして、パフォーマンス改善のキャッシュ戦略などを除いては可能な限りSingle Source of Truthを守ろう、というはなし。

Elmで配列の値を扱う際、なにも考えないとすぐに「これはListでいいかな」みたいな発想をしてしまいがちだが、ListよりもSetやDictなどのコレクションを適切に使うほうが、そのデータの集まりはどういう集まりなのか(たとえば、ユニークなデータのあつまりなのか、それとも重複を許すのか等)が意図が明確になるのでよい。これはElmに限らずJavaScalaなど、コレクションの種類が豊富な言語でも同じかなと思う。

www.youtube.com

"Scaling Elm App"

題名の通りで、デカいElmアプリケーションに起こりがちなあれこれに関するTipsのトーク

上のふたつのトークと比べて、実際のアプリケーションに起こりがちなことにフォーカスしている。たとえば、Modelが大きくなってきたときにはどうするのがいいか。再利用可能なパーツをTEAモジュールにするにはどうすればいいか、などなど。

www.youtube.com

"Make Data Structures"

2018年のelm Europeでの彼のトーク。個人的には一番推し。

プロダクションで作るようなアプリケーションでどのようにカスタムタイプを使ったデータ構造のモデリングをするのが望ましいかについて話している。

このトークではDreamwriterと呼ばれるサンプルのElmアプリがお題となっていて、アプリケーションの仕様としてデータをWeb APIとIndexedDBへ同時に取得しに行き、どちらにもデータがなければ空の状態とする、というものがある。単純に考えると、すぐに個別のデータの有無をMaybeで表現しようとしてしまいがちだが、カスタム型でデータの取得状態をLoading/LoadingProblem/LoadedOne/Loaded などのように表現をすることで、仕様上ありえない競合状態を作り出せなくできる。

加えて今回もまたOpaque Typeに言及しており、今回はモジュールのAPIとしてどのような関数を公開すべきか(セッター/ゲッターではなくマッパーを公開しよう、など)という内容も含まれる。非常に充実した内容だ。

www.youtube.com

余談

この記事を書いたとき、4番目の動画がYoutubeで見つからなかったので本人にメンションしていた。実際には自分の見落としだったけれどリプがもらえて、Elm界隈の距離の近さいいナ〜と思った瞬間でもあった。

基礎からわかる Elm

基礎からわかる Elm

  • 作者:鳥居 陽介
  • 発売日: 2019/02/27
  • メディア: 単行本(ソフトカバー)

*1:昔の動画はそうでもないが、年々筋骨隆々になってきている。実際に結構トレーニングはしているようだ。

GolangでUnmarshallerインターフェースを実装した構造体をフィールドの型として使うと便利

例えばこんな構造体が定義されているとして

type User struct {
    Name   string `json:"name"`
    Status int    `json:"status"`
}

この構造体をJSONからUnmarshalしてマッピングする際に、以下のような要件があるとする

  • statusの取りうる範囲は1,2だけ、かつそれぞれACTIVE, INACTIVEという定数にマッピングしたい。
    • 1,2以外の数値が来たらエラーにしたい。
  • statusフィールドがないときもエラーにしたい。

User構造体を受け取ってバリデーションをする関数を作ってもよいが、以下のようにStatus型を新しく作り、それにUnmarshallerインターフェースを実装させるとグッとスマートにできる。

type User struct {
    Name   string `json:"name"`
    Status Status `json:"status"` // int型からStatus型に変更
}

Unmarshallerインターフェースを実装したStatus型

Unmarshallerインターフェースは以下のような定義になっている

type Unmarshaler interface {
    UnmarshalJSON([]byte) error
}

JSONのUnmarshalをする際、マッピング対象のフィールドにUnmarshallerインターフェースを実装したものがあると、そのフィールドへのマッピングの際に自動的に実装されたUnmarshalJSONメソッドが呼ばれるようになる。

つまり、Status型にこのUnmarshallerインターフェースを実装することで、User型がUnmarshalされる際に自動でStatus型に実装された任意のマッピング処理およびバリデーション(!)行えるようになるというわけだ。

Unmarshallerインターフェースを用いて要件を実装したStatus型は以下になる。

type Status int

const (
    ACTIVE Status = iota + 1
    INACTIVE
)

// Unmashaller
func (status *Status) UnmarshalJSON(data []byte) error {
    var value int

    if err := json.Unmarshal(data, &value); err != nil {
        return fmt.Errorf("Failed decoding status: %s", err.Error())
    }

    switch value {
    case 1:
        *status = ACTIVE
    case 2:
        *status = INACTIVE
    default:
        return fmt.Errorf("Invalid status: %d", value)
    }

    return nil
}

statusの取りうる範囲をバリデーションできているか見てみる

上の実装を終えた上で、Status型をフィールドに持つUser型をJSONからマッピングしてみるとこうなる

func main() {
    src := `{ "name": "Jonathan", "status": 3 }`

    var user User
 
    if err := json.Unmarshal([]byte(src), &user); err != nil {
        panic(err) // panic: Invalid status: 3
    }

    // ...
}

statusに3が与えられているのはUnmarshal時にマッピングエラーになる! すばらしい

statusフィールドが存在しない場合にどうするか

実はこれだけではまだ、以下のようにstatus型が抜け落ちているJSONマッピングに対するエラー検知ができていない

{ "name": "Jonathan" }

上のJSONマッピングするとどういう挙動になるかというと以下のようになる。

func main() {
    src := `{ "name": "Jonathan" }`

    var user User
 
    if err := json.Unmarshal([]byte(src), &user); err != nil {
        panic(err)
    }

    fmt.Printf("%#v\n", user) // main.User{Name:"Jonathan", Status:0}
}

つまりint型の初期値である0が代入される。

自分の場合は以下の IsEmpty のようなレシーバメソッドを生やして、仮にUnmarshalが成功したとしても、必ず直後にIsEmptyを事前条件チェックとして呼ぶようにしているが、若干微妙ではある。

type Status int
 

const (
    ACTIVE Status = iota + 1
    INACTIVE
)

func (status Status) IsEmpty() bool {
    return status == 0
}

// ...

func main() {
    src := `{ "name": "Jonathan" }`

    var user User
 
    if err := json.Unmarshal([]byte(src), &user); err != nil {
        panic(err)
    }
 
    if user.Status.IsEmpty() {
        panic("status is empty")
    }

    fmt.Printf("%#v\n", user)
}

本当はUnmarshalJSONメソッドの中でどうにかしたいが、Unmarshal対象のフィールドがない場合には当たり前だが呼ばれない。ここはちょっと苦しい。

Opinionatedなライブラリとチーム開発

 GitHubなどで作者がライブラリ(やフレームワーク)をopinionatedであると形容しているのを見ることがある。Opinionatedというのは直訳すると「意固地な」「意志のかたい」のような雰囲気になるが、意固地なライブラリというのは正直意味が通らない。ではどういう意味なのかというと、そのライブラリが、作者によって強く方向付けられていることを意味する。言い換えれば、利用者がある種のルールを強制されるものだ。

 フロントエンドのはなしをするが、たとえばElmはとてもopinionatedな言語(このケースはライブラリではないが)であると言える。創造神エヴァンによって、言語自体にSPA開発用のフレームワークが内蔵されているし、JSによくあるような裏技やハックを使うことが言語仕様上できなくなっている。TEAというアーキテクチャによって、アプリケーションの構造やデータの流れが統一されている。これはまさに彼自身の思想そのものだ。

 他のものでいうと、Vue.jsも比較的フレームワークという観点では微妙にopinionatedだと言えるが、細かい部分ではそうではない。一方、Reactはビューのみに責務を絞っているという点でless opinionatedに見える。ReduxはJavaScriptなライブラリの中では最もopinionatedだろう。

ライブラリと思想

 ちゃんとした意図や背景があって作られたものには、公式のページかどこかに丹精込めて作者が思想を説明しているページがあるケースが多い。たとえばReduxのMotivationROM.rbのCore Conceptsはすごくいい例で、既存の解決策やアプリケーション・アーキテクチャのどこがイケてないのかを説明した上で、自分たちの思想を実装したライブラリがどう優れているのかを説明している。

 思想が弱いライブラリというのは、使っているうちに思わぬところで綻びが出るものが多い。とくに誰彼構わずいい顔しようとするタイプのものに顕著な印象がある。オールインワンだとか、初心者に優しいと謳うもの、easyやsimpleなどのフレーズを使うものが怪しい。パフォーマンスが優れていることをアピールして、肝心な思想を煙に巻くケースも多い(もちろん、パフォーマンスに優れていることがそのライブラリ自体の思想ならおかしくはないが)

 Less opinionatedなライブラリは利用者にルールを強いない代わりに、ルールを作りを委ねてくる。小規模な開発では問題にならないが、チームが大きくなる頃には必ずコンセンサスゲームをすることになる。ライブラリを使う我々側に、それなりの思想を持つことが期待される。しかもチーム開発ともなれば、チーム全体で思想が共有されている必要がある。運用に乗せるのも頑張らねばならない。これがまた、人が増えたときに骨が折れるのだが...

ElmのSlackチャンネルが情報収集をするのに便利

世界中のElmエンジニアが集まるSlackワークスペースがあり、情報収集をするには非常によい。

あまり日本のElm界隈では知られてないのかな? と思ったのでメモ程度に周知しておく。以下のページからSlackのワークスペースに入れる。基本的に全部の会話が英語なので、英語が読み書きできるとなおよい。

elmlang.herokuapp.com

様々なチャンネルがあるが、基本的には #general#begineers に入っておけば良いと思う。質問に対する回答は、参加者人数が多いだけあってめっちゃはやいし、とくにディスカッションが活発でおもしろい。 Elmのカンファレンス情報は #conferences にまとまっているし、作ってみた系の告知やニュースは #news-and-links にどんどん流れてくる。

その他にもローカルなミートアップに関するチャンネルなど腐るほどチャンネルがあるので好きなのに入ればよいと思う。たいてい、あまりメジャーじゃない言語やフレームワークに関しては、日本語情報に触れているうちは最新の情報や尖ったコンテンツにはアクセスできない。なので、こういうグローバルなSlackワークスペースにいるほうが学びが多い。

Elm Europe 2019 にスピーカーとして参加した

2019/6/27-28にかけて開催されていた Elm Europe 2019 というカンファレンスにスピーカーとして参加した

f:id:IzumiSy:20190630225553p:plain

このような海外カンファレンスへの参加は、だいぶ昔にサンフランシスコへ行ったとき以来だし、とくにスピーカーとして登壇するというのは人生初だった。英語でトークをやるというのは非常に緊張する体験だったけれど、率直に言ってめちゃくちゃ楽しかった。

詳しいカンファレンスの内容などはおそらく所属している会社のブログの方で書くはずなので、こっちではもう少しパーソナルなことを書こうと思う。

CFPの応募

Elm Europe は日本のちょっと大きめのカンファレンスと同じで、スピーカーを CFP で募集している。3月ごろに、会社の同僚から募集しているということを知らされ、雑な CFP をサブミットした。このとき、たしかインターンのイベントかなにかがあり、社内で酒を飲んでいたのでかなり適当な英文を書いた。

後日、朝起きて携帯でメールチェックをすると Elm Europe から以下の内容でメールが届いており、腰を抜かした。

f:id:IzumiSy:20190630231524p:plain

CFP の応募から当日までほぼ2,3ヶ月ほどの時間があったにも関わらず、結局スライドはギリギリまで作っていた気がする。

一方で、他の参加者とは Discord のチャンネルで細々としたやりとりを(もちろん英語で)していたが、みんなスライドづくりを始めるのが非常に早い。1ヶ月くらい前には、みんな「もう資料はできてるよ!」というようなことを言っていて、すごくペースが早いな、と思った。

日本からフランスへ

当日は日本の夜11時に羽田の国際便に乗ってフランスへ向かった。途中、機内でなんらかの旅客トラブルがあり、乗務員が「お客様の中にお医者様か看護師の方はいらっしゃいませんか」というアナウンスをしていて、初めてドラマや映画でしか見たことのなかった体験をした。また、前に座っているフランス人カップルがものすごい勢いで機内でイチャイチャしていて、カルチャーを感じた。

朝4時にフランスのシャルルドゴール空港へ到着。スピーカーのホテルはその日は15時からしかチェックインできないということで、どうにかそれまでの11時間を過ごさねばならない... しかし Elm Europe の Discord でいろいろ話しているうちに、オーガナイザーのアパートの部屋へ行ってもいいということで、朝7時ごろにパリの街へ繰り出した。

自分が滞在していた期間、パリはずっと晴れで朝は暑すぎもせず寒すぎもせず非常にちょうどよい気温であった。夜のパリは非常に危険らしいが、朝のパリは非常に趣がある。

f:id:IzumiSy:20190626064414j:plain:w550

というわけでオーガナイザーの住んでいるアパートの住所までテクテク駅から歩き、30分ほど待つも一向に Discord で返事がない。さすがにしびれを切らし、もう自分で会場まで向かってしまおう、ということでその場をあとにした。

会場へ

f:id:IzumiSy:20190626083317j:plain:w550

Elm Europe の会場は Efrei Paris という、いわゆる日本でいうところのコンピューター系の専門学校のようなところだった。

校舎のなかは、こんな感じのキレイめな雰囲気になっていて非常によい。 f:id:IzumiSy:20190626083537j:plain:w550

この日はカンファレンスの前日で、会場では Elm と GraphQL を使ったアプリケーションを開発するワークショップが開催されていた。なんと8時間にも及ぶ長いワークショップとのこと。なお、このワークショップで講師をしていたのは elm-graphql や elm-typescript-interop を作っている人だった。こういう人にサクッと会えるのが海外のカンファレンスのいいところだ。

しばらくすると、お昼ごはんとして軽い食事が出てきた。 f:id:IzumiSy:20190626132744j:plain:w550

こちらは、準備中の会場 f:id:IzumiSy:20190626142959j:plain:w550

お昼を過ぎたあたりから、天候の具合がおかしくなってくる。どう考えても暑すぎるのだ。真夏の日本と同じか、それ以上に暑い。半ズボンを持ってきていなかったことを後悔した。日本に帰国してから知ったのだが、どうやら僕が滞在していた週のフランスは記録的な猛暑に見舞われていたらしい。どうりで暑いわけだ...

フランスなどヨーロッパ地域の建造物にはエアコンがないのが普通らしく、このあと向かったスピーカー用のホテルも三ッ星ホテルの癖に部屋には扇風機しかなかった。夜になると、すこしは気温が下がり過ごしやすくなるものの、真っ昼間にエアコン無しで部屋の中にいようものなら、あっという間に脱水して倒れてしまうんではないかと思う。スピーカーホテルは自分含め三人で一部屋という割り振りになっており、なんだか語学留学みたいでおもしろかった。

19時頃からスピーカー限定でディナーが開催され、昼には会えなかった参加者のみんなといろいろな話をする機会があった。丁度隣に座っていた人が SoundCloud のフロントエンドエンジニアで、なんと日本の Elm 勉強会にも参加したことがあるとのことですごく偶然を感じた。この会食には Elm 界隈の超有名なエンジニアであるリチャード・フェルドマンも参加しており(彼は初日のキートーク枠だった)個人的にはとうとう Youtube でしか見たことなかった人が目の前に...! と思ったものの、正直緊張して握手と挨拶しかできなかった。

発表当日

とうとう発表当日を迎える。

会場にはこんな感じののぼりが立てられていて、そこに自分が作っているプロダクトのロゴがあるというのは正直に言ってなんともいえない感動があった。 f:id:IzumiSy:20190627170617j:plain:w550

朝は比較的ひんやりとした天気で、若干半袖だと寒いくらいだった。 f:id:IzumiSy:20190627170658j:plain:w550

iPhoneの紛失

実は発表当日、大きなトラブルに見舞われていた。というのも、スピーカーホテルのルームメイト達と会場にUberで向かう中、なんとポケットから iPhone が滑り落ち、そのままタクシーが行ってしまったのだ。これまで日本で携帯なんか落としたことなんてなかったのにとうとうやっちまった... という失意の念に打ちひしがれながら初日を迎えることになった。

Uber を呼んでくれたルームメイトがドライバーに電話をかけるも、全く出る気配がない。仕方ないのでボイス・メッセージを残してくれたが、これもおそらく気休めにしかならないだろうな、と思った。

しかし、こんなことで凹んでられない。とにかくいまは自分の発表に集中しなくては! と気持ちを立て直す。

自分の番が回ってくる

自分ではナチュラルな笑顔を心がけたつもりだったが、緊張しすぎて引きつった笑顔になってしまっている... 発表前に接続テストがなぜかできず、自分のスライドがまともに映るかも不安だったが、もうここまで来たらやるしかない。

発表中はもう無我夢中だったので、実際どういう感じで自分が話していたのかは全く記憶にない。途中から若干余裕が出てきて、顔を上げて会場を見回したりできたような気がする。発表の直前に、自分の "Review" の発音がちょっとわかりづらいと言われ、正しい発音は日本で言うところの "ウィヴュー" だと教わったが、実際にプレゼンでそのフレーズを話した記憶がない。

下の Age of Empire の壁ユニットを使った型システムのスライドのページはちょっとウケたようで良かった。

発表が終わるとリチャードがステージのところまで来てくれていて「面白かったよ!」と言ってくれた。

こちらからは「僕らのチームも、あなたのカンファレンスでのトークrtfeldman/elm-spa-example を Elm 学習のリソースとして使っていて、すごくインスピレーションをもらっています!」というようなことを伝えたりした。彼は発表中に以下のようなツイートもしてくれていて、わざわざフランスまで来て登壇発表したかいがあったな... という嬉しさがあった。

このツイートは同僚たちにも観測されており、弊社の Elm チャンネルでは「リチャード・フェルドマンがツイートしてる!」と謎の盛り上がりを見せていてウケた。僕らからすれば本当に Youtube の中の存在であった彼が、このようなツイートをしてくれたことには、非常な感動があった。

携帯が帰ってくる

発表の直後、 iPhone のリモートロックの機能を有効にするとスマホ上にメッセージを出せると知り、自分のラップトップからスマホをロックした。

自分は無駄なお金がかからないようにこまめに SIM のローミングを切るようにしていたが、無くしたときはたまたまローミングを有効にしたままだった。スマホの位置情報をチェックすると、どうやらパリの北部にいる。動きが比較的早いところをみると、まだ Uber タクシーの中に残っているようだった。

ダメ押しで端末のメッセージに会場となっている学校の住所を追加する。これでだめだったらもうダメだ、と思いながらあとはただ帰ってくることを祈りながら他の発表を聞いていると、なんと自分の携帯がいつの間にやら学校の教務課(?)へ届けられていた。まさかこんな異国の地でしらない人間の温かみに触れられるとは思わず、とても感動であった。

ルームメイトの二人に「携帯が帰ってきた!」と伝えると、「オイオイマジかよ、信じらんねーぜ。最高の一日だな!」みたいなテンションで、やっぱりこんなふうな落としものが帰ってくるというのはなかなかにレアなことなんだなと再認識した。

感想

Elmの開発者は全世界的に見ても非常に少ない。それだけに、コミュニティがすごく親密で、新しい人に対して開いている。 Elm 本体の開発者を擁する NoRedInk のエンジニア達も大抵会うことができるし、すごくフレンドリーだ。海外の開発者コミュニティに足を踏み入れるのは、確かにこれが初めてだったし、ちょっと英語が話せるとはいえ普段は日本語しか話さない自分が馴染めるのか非常に不安な部分があった。しかし Elm Europe は非常に多様なカルチャーのエンジニア達で構成されていたし、Elmが好きだという気持ちがあれば誰もが楽しめるし、歓迎される場であると思う。

主催者のフランス人である Assus は我々と同じ非ネイティブ・スピーカーで、正直彼の英語は僕から見ても流暢であるとは言えなかった。けれども、参加者のひとりは彼の存在がコミュニティにおける Stress Remover であると言っていた。副次的な効果であるとは思うが、彼自身が Elm Europe のモデレータであるということ、そしてまた彼のキャラクターが Elm Europe の親密で誰もを受け入れるような雰囲気を作っているようにも見えた。このような多様性がコミュニティの中で感じられることは、非常に素晴らしいことだと思う。

下は、アフターパーティで鍵盤ハーモニカを演奏する Assus の写真。こちらも上手いのか下手なのかよく分からなかったが、おもしろかった。

f:id:IzumiSy:20190627185909j:plain:w550

また、今回スピーカーとして参加したことによって、おそらくただの Attendee としての参加では出会わなかったであろう人との出会いもあった。大学を卒業してから、おそらくもう英語を使う機会は無いだろうなと思っていたが、思いがけずこのような形で自分の英語力が生きる機会があり、とても嬉しかった。文化や母語は違えど、プログラミング言語という共通のコンテキストを通してこのような交流ができるというのは、我々ソフトウェア・エンジニアならではではないかと思う。渡航するまでは途方もない緊張感でナーバスだったが、終わってみると想像の200倍は楽しかった。

次はどのカンファレンスで話そうかなぁ。

dayjsと謎の挙動

年と月だけの文字列をDateへ変換すると2月だけおかしくなる

console.log(dayjs('201901', 'YYYYMM').toDate()); // Tue Jan 29 2019 00:00:00 GMT+0900 (日本標準時)
console.log(dayjs('201902', 'YYYYMM').toDate()); // Fri Mar 01 2019 00:00:00 GMT+0900 (日本標準時)
console.log(dayjs('201903', 'YYYYMM').toDate()); // Fri Mar 29 2019 00:00:00 GMT+0900 (日本標準時)
console.log(dayjs('201904', 'YYYYMM').toDate()); // Mon Apr 29 2019 00:00:00 GMT+0900 (日本標準時)

なんで?

github.com

新しいフレームワークを学ぶならTodoMVCではなくRealWorldを参考にしよう

よく新しいフレームワークを学ぶにはTodoアプリを作ってみるのがよい、と言われる。実際、Todoアプリを様々なフレームワークで作ってみたサンプルをまとめたサイトもあったりする。

ところが、実際に業務で作るようなアプリケーションはTodoアプリの範疇を超えている。とくにSPAにもなると、画面遷移やWebAPI連携、大規模な状態管理などなどの条件が増えるので、Todoアプリを作っているときには考慮できていなかった大変さが出てくる。

そこで参考になるのが RealWorld example apps と呼ばれるプロジェクト

f:id:IzumiSy:20190609165127p:plain

端的に言うと、TodoMVCの大規模版

規定のスペックに沿って、様々なウェブフレームワークで作られたアプリケーションのリポジトリがリストアップされている。

f:id:IzumiSy:20190609165323p:plain

スペックについて

"Conduit" is a social blogging site (i.e. a Medium.com clone). It uses a custom API for all requests, including authentication.

要求されているスペックはConduitと呼ばれるMediumクローンを作る、というもので、具体的には以下のような機能を満たしているとのこと。

  • ホーム画面
  • JWTを使ったユーザー登録・ログイン画面
  • ユーザーの設定画面
  • 記事の投稿/編集画面
  • 他ユーザーをフォローする
  • お気に入り記事一覧

ここまでの機能を実装しているアプリケーションとなると、わりとかなり本格派なんじゃないだろうか。

ちなみに、フロントエンド以外にもサーバーサイド・フレームワークによる実装もあるので、サーバーメン的にも参考になると思われる。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

"初夏のJavaScript祭り2019" にElmのはなしで登壇した

 6/1に開催されたJavaScript祭りというイベントに「jQueryからElmまで」というタイトルで15分枠の登壇をした

 内容はjQueryからJavaScriptを触り始めた自分が、Elmを書くまでにどういう困難を経験してどういう学びを得たのか、にフォーカスを当てたもの。

 フロントエンド界隈はトレンドの変化が早いと言われがちだが、闇雲に新しいフレームワークが乱立しているというわけではなく、どのフレームワークもアプリケーションを作る上での問題を解決するために生まれているのは間違いない。これはjQueryprototype.jsのころから変わっていないし、そもそもテクノロジー自体が問題解決をするためのものであることからも自明だと思う。そう考えると、いまElmを書いている自分は割と遠いところまで歩いてきたなぁ、と感じさえする。

Prop Drilling について

 懇親会の際に、スライドの中で触れていた Prop Drillingアンチパターンなのか? という話になったが、これは正直スライドの表現が悪かったと思っている。

 自分としては、Prop Drilling はその後に触れられるイベント・エミッタを乱用するパターンを説明するきっかけとして使いたいだけで、アンチパターンだとは思っていない。まずモジュール結合度の観点からみても、コンポーネントに渡されるパラメータが増えても結合度は低い状態であるし、コンポーネントに対する入力が増える以外の欠点がないからだ。

余談

 もともと、この発表のインスピレーションは過去のこの記事にある izumisy-tech.hatenablog.com

 ReactのSFCやChoo.jsなどを知ってときに「ビューって関数やん!」と気付いたのを覚えている。

 その後、偶然にもElmを使っている会社へ新卒入社し、前提としてフロントエンド・アプリケーションは関数の組み合せで作れるということが自分の中での当たり前になっていった。一方で、その考えに至るまでに自分が書いていたフロントエンドは全く異なるものだったことを思い出した。一度なにかを知ってしまうと、それを知らなかった頃の自分には戻れない。それでも、どのように自分の考え方が変わっていったかはまだ思い出せる。こんなことを考えながら、今回はスライドを作った。

 登壇にあたっては、最終的にはJavaScriptにトランスパイルされるとはいえ、ElmはほとんどJavaScriptとは別の言語なので参加者層的に楽しんでもらえるかなという不安もあった。事前に主催の方から頂いたアンケートをみてもやはりVue.jsを書いている、という方が多かったし、発表内容にもVue.jsとVuexにフォーカスを当てたものが多かった。

 かくいう自分も、仮に開発対象のアプリケーションがのちのち自分の手を離れることになる場合、あるいは組織自体がElmをキャッチアップできる状態でない場合には、Elmを選択することはいまのところないだろうなと思っている。Vue.jsやVuexであれば、コミュニティの大きさから後任の開発者が確保できる可能性が充分にあるからだ。

 Elmの堅牢な型システムやある意味 "ズル" できないアーキテクチャは、必ず大規模なアプリケーションに必要なものであることには間違いないが、そもそも書ける人間がいない状態になってしまっては元も子もない。とはいえ、JavaScriptを触っている人間であれば、文法がパッと見で目新しいものあるだけで、Elmにはすぐに馴染めると信じている。そのような意味で、自分の発表を聞いてElmの存在だけでも知ってくれる人が増えてくれたとしたら非常にありがたい。