アメリカ、セントルイスにて。 以下、終わった後に記憶を頼りに書き起こした雑極まりないメモ。
雰囲気
写真は休憩中だから人少ないけど。
トーク
Keynote: Code is the easy part (by Evan Czaplicki)
コードを書くのは一番簡単な部分。言語設計として何を書くかが問題。 Pythonは最初の５年ほぼプライベートで、ドキュメントが整うのには１０年かかった。Elmはまだ４年。 要求を一つずつコードで実装して解決することはしない。数ある要求を集めてパターンを見つける。そのためにたくさんのフィードバックが欲しい。 0.18に向けて今取り組んでるのがデバッガー。モデルの状態を全部記憶できるし、状態を保存してリロードできたりする。あとサーバーサイドレンダリングとか。細々したタスクは今はあえて無視してる。
Beyond Hello World and Todo Lists (by Ossi Hanhinen)
リアルワールド体験談。割と苦労した話とか。 すべてをコンポーネントにしてはいけない。問題を一般化せずに体当たりしていけ。 パッケージの切り分け方とかルーティングとかデバッグとかのTips紹介。
Compilers as Therapists, or Why Elm is Good for ADHD (by Luke Westby)
会場沸いてたけど、ほとんど聞き取れなかったごめん。 ADHDは注意力（集中力）に難のある障害なんだけど、Elmだと大丈夫だった。という話だったと思う。
LT: Rich Animation (by Matthew Griffith)
同時にアニメーションさせるときに割り込むかキューに積むかとか、真面目に考えると結構難しい。 elm-style-animationだとエレガントにできる。
LT: Functional Data Structures (by Tessa Kelly)
バイナリツリーを４種類の方法で実装して比較してみた。 インデックスとかよりもポインタ（union typeとかで）実装した方が明らかにエレガント。
LT: 0-60 in 15 Minutes: Building a Realtime App With Elm and Horizon (by Abadi Kurniawan)
とにかくサーバサイド書きたくない。なら書かなきゃいいじゃん。 Elmを使ってHorizon.js（RethinkDB）のインターフェイスを実装したら、Elmだけでチャットアプリが作れた。
Rolling Random Romans (by Joël Quenneville)
ローマ人の名前の付け方の法則をモデル化してランダム生成してみた。 文脈によって制約が変わったりしてとても複雑。 純粋な関数型でランダム値を生成するにはSeedが必要で面倒だが、0.17でCmdによる生成が可能になった。 ランダムのパターンを自由に組み立てられるのが便利。ボトムアップに組み立てると良い。
Building an Interactive Storytelling Framework in Elm (by Jeff Schomay)
ユーザ選択によって変わるストーリーを生成する。 会場のリクエストで選択肢を決定してストーリーを進めるデモ。最高の盛り上がり。 ３パターンくらい試行錯誤した。union type使うと網羅できるけど、書き方が冗長になるのとフレームワークの場合は具体的な内容を知ることができないので万能ではなかった。最終的にリストを使ったDSLに。
The Clockwork Gardener: Growing an Elm App With Templates (by Jessica Kerr)
AtomエディタでElmの良くあるボイラープレートを生成する。（Atomist） 「〜〜を〜〜で〜〜しろ」みたいな一行のコマンドでどんどんElmコードを生成するテンプレート芸。 だいぶ頭おかしい（良い意味で）。 コードの自動生成が怖い？Elmコンパイラがついてるから全然怖くないよ。
Nightingale.space - Elm and Crowd-Source Music-Making (by Murphy Randle)
Twitter上に楽譜を置いたらキューに積んで片っ端から再生していくアプリ。 Elixir(Phoenix) + Elm + JavaScript。 パースに使ってるelm-combine最高（とても同意）。 会場でリアルタイムにツイートされた楽譜を再生していくデモ。楽しい。
Making Impossible States Impossible (by Richard Feldman)
データ構造がしっかりしていればinvalidな状態を作ることは原理的に不可能。 たとえばCSSの@は順番がある。ユーザにリストで書かせるとバリデーションとかテストが必要。 テストはいいけど、しなくて済むならその方がいいよね。 その他の例としてはHistoryとか。 あとは、シングルコンストラクタのパターンを使ってデータをプライベート化した上で、公開したい操作だけを関数で提供する。
トーク全体の感想
とにかく全員トークのクオリティが高くて、どうやったら面白くなるかが真剣に練られてるのがすごいと思った。見習わないと。 英語はほとんど聞き取れなくてスライドの文字情報と雰囲気で補完した。無理。全然無理。
最後のMaking Impossible States Impossibleは、基本的だけどなかなかはっきり言及されてない部分なので、何気に名トークかも。いつも関数型の人が雑に「型があるから安全」って言ってるけど、実は構造体の定義の話もあって「じゃあJavaも型あるじゃん」とか言われてなかなか伝わらない部分。
Q/Aセッション
スピーカー全員が回答者。言語の開発に関してはEvanだったけど。
Q: プロダクションで客にどう説明してる？
A: リスクは確かにあるけど、そこで議論がストップするの良くない。
それに見合うだけあるいはそれを上回るメリットがあるならリスクは取っていい。
Q: Haskell使えない人がコントリビュートするには？
A: Haskellコードいきなりいじる前にコミュニティのコンセンサスとって。あとドキュメントを直接直してくる人も居るけど、いや待ってこれ君の本じゃないから。
Q: デザイナーと協業するには？
A: 前提としてデザイナーは頭がいい。CSSが使えるんだから。
Elmを理解してもらおう。（ツールについての言及もあったけど聞き取れず）
Q: Effect Managerどうなるの？
A: 現時点でほとんど完成してる(Stablish)とは思うけど、今後の展開によっては変えないといけない部分があるかもしれないから安易に公開OKにできない事情がある。
他にもあったけど忘れた。
Evanに話しかけてみた
アイコン見せたらお前かー！みたいな感じだった。elm-time-travelの存在は認知してたけど見てはいなかったみたいで、デモ見せてみたら「これ今まさに作ってるやつじゃん」って言ってた。モデルの出力どうやってるのか聞かれたので、toStringしたやつをパースしてると白状したら爆笑してた。
Evanめっちゃいい人。 唯一知ってる日本語は「仕事がありません」らしい。
