Runner in the High

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

Elmにおける依存性逆転(DIP)の表現

この記事を読んでなるほどな〜と思ったので記事にしてみる。

medium.com

依存性逆転とは

雑にいうと実装ではなくインターフェイスに依存させ、モジュール間の依存関係を疎結合にする手法。英語ではDependency-Inversion Principleと呼ばれ、頭文字をとってDIPとすることが多い。

www.martinfowler.com

ElmではDIPをどう表現するか

一般的な静的型付け言語ではインターフェイス相当の言語機能が提供されている。たとえばScalaだとtraitだし、Javaだとinterfaceあたり。しかしElmにはそれらがない。

そこで、Elmでは型エイリアスを使ってインターフェイスっぽい表現をする

type alias Score
    = Int

type alias PersistScore msg
    = Score -> Cmd msg

上のPersistScoreインターフェイス相当になっている。Scoreを受け取り、なんらかの手段で永続化を行うCmd型に変換するインターフェイスである。

もう少し詳しく

ellieで用意されているTODOアプリを例にする。実際のコードのリンクは以下。
https://ellie-app.com/7Z52XPNmbfca1

IncrementDecrementに加えて、データの永続化を行うSaveというメッセージが新しく定義されている。Saveメッセージを受け取ると、何らかの方法で現在のcountの永続化を実行する。

type Msg
    = Increment
    | Decrement
    | Save


type alias Persist msg =
    Int -> Cmd msg


update : Persist msg -> Msg -> Model -> ( Model, Cmd msg )
update persist msg model =
    case msg of
        Increment ->
            ( { model | count = model.count + 1 }, Cmd.none )

        Decrement ->
            ( { model | count = model.count - 1 }, Cmd.none )

        Save ->
            ( model, persist model.count )

update関数は第一引数に永続化のためのアダプタを受け取るため、main関数での繋ぎこみの際に実装を差し込む。ここでは実装はlocalStorageへの永続化を行うlocalStoragePersisterになる。

port localStoragePersister : Int -> Cmd msg


main : Program () Model Msg
main =
    Browser.element
        { init = init
        , view = view
        , update = update localStoragePersister
        , subscriptions = \_ -> Sub.none
        }

この実装はupdate関数がPortに依存しないため、テストの際に以下のようなモックの関数を渡してupdate関数内部でのPort呼び出しの挙動などをテストできるようになる。Portに依存しなくなることでピュア度が増すし、テストもしやすくなる。

-- Portの実装をモックする関数

mockPersister : Int -> Cmd msg
mockPersister _ =
    Cmd.none

このようなPortの抽象化は、Portをたくさん使うプロダクトになればなるほど、意外に必要な場面が出てくる。

完全な抽象化は難しい

しかし、この抽象化はあまり完全なものであるとは言えない。

たとえば、実際にありえるかは分からないが「開発環境ではLocalStorageへ永続化するが、本番環境ではWebAPIへ永続化する」のような機能を抽象化するのは少し無理がある。

そもそも、PortはElmランタイムに処理を投げて終わりであるのに対して、HTTPリクエストの場合にはTaskの結果としてResult型を受け取る必要がある。 メッセージとしてリクエストの結果を受け取らないことが許されてないため、そもそもPortとTaskでモノが違うだろというハナシになってくる。 PortとのデータのやりとりがTaskで行えるようになればちょっとは可能性が出てくるが、あまり可能性はないと考えてよいだろう。

とにかくいろんな会社でインターンしていた学生時代

テック系の学生というと、やはりいろんな会社のインターンに参加していろんなイケてるナウい技術を触って「圧倒的成長!」を求めますよね。 自分もそうでした。

自分はかなり極端な例で、大学を1年休学してまでインターンしてコロコロと会社変えながら10社くらいは行きました。 今思うと楽しかったしお金ももらえるし最高じゃんって感じだったんですが、ぶっちゃけじゃあインターンしまくってずっと成長してたかって言われると微妙です。

会社によってはただバグ潰したりするだけのインターンもあったりして、いわゆる限界効用逓減にぶち当たってただコードをかいてるだけの学生だった気がします。 あとはやっぱ学生でコードかけるとすごいチヤホヤしてくれるのでそれが嬉しい、みたいな。

f:id:IzumiSy:20200129094151p:plain

いまでこそ社会人になって仕事でコードを書くようになったんで分かるんですが、別に起業家じゃなくともエンジニアだって自分のビジョンが必要だよなって感じます。 そうじゃないと、ただのコード生成機みたいな存在にしかなれないんだなと。

ビジョンっていうとなんか壮大ですが、たとえばプロダクトにチョー愛を注ぎたい熱意があるとか、組織を全力でイイものにしたいというアツい想いがあるとか、学生の頃は胡散臭いと思ってたあれこれが結局一番重要なんじゃないかって今は思います。

なにかに強く共感できるとか、全力で入れ込めるってある意味スキルだと思う今日このごろ。学生の頃の自分は「エンジニアとして技術をめちゃくちゃに極めたい」としか思ってなかったけど、じゃあ技術を極めた先になにがあるの?と聞かれても何も答えられなかっただろうな。

ビジョナリーカンパニー 1~4巻+特別編

ビジョナリーカンパニー 1~4巻+特別編

Elmにおける「型によるルールづけ」の考え方

Elmは静的型付言語なので、型のチカラを活かすことでコンパイラに「あっては行けない状態や組み合わせ」をチェックさせることができる。 高度な例としては前回書いた以下の幽霊型(Phantom Type)の記事があるが、もう少し簡単な例を紹介しようと思う。

www.izumisy.work

自作Error型の例

以下は自作のError型を定義した例だ。Error型はカスタムタイプになっていて、エラーのパターンを表現している。 それぞれのエラーはエラーのメッセージを持っていて、それらをtoString関数で取り出す事ができる

module Error exposing (Error, handle, toString)


type Error
    = Internal String
    | Connection String
    | Unknown String
   

type HandledError =
    HandledError String


handle : Error -> HandledError
handle error =
    case error of
        Internal msg ->
            HandledError msg

        Connection msg ->
            HandledError msg ->

        Unknown msg ->
            HandledError msg
            

toString : HandledError -> String
toString (Error msg) =
    msg

このモジュールにはルールがあり、メッセージをStringとして取り出す前には絶対にhandle関数が呼び出される必要がある。

したがって、Errorモジュールを呼び出すにあたっては、以下のようなコードはコンパイルエラーになる

import Error


-- ...


msg = 
    somethingReturningError -- Error型を返す関数
        |> Error.toString   -- Error型を文字列に変換したい(が、コンパイルエラーになる)

なぜなら、Errorモジュールの実装によればtoString関数は必ずHandleError型しか受け取れないからだ。

HandleError型はhandle関数を呼ばなければ受け取ることができない。 なので、以下のようにhandle関数の呼び出しを挟まなければtoString関数は呼び出せない。

import Error


-- ...

msg = 
    somethingReturningError -- Error型を返す関数
        |> Error.handle     -- Error型をハンドリング(←これが必須)
        |> Error.toString   -- Error型を文字列に変換したい

何がうれしいのか

この例は極端に簡潔な例で、別にhandle関数のcase...ofはtoString関数にあってもいいのでは? と思う人もいるのは納得できる。

しかし、上の例で伝えたい点は「型によってモジュールの使い方にルールを与えることができる」という点だ。例えば、Error型とは別にHandledError型がモジュールに用意されていることで、モジュール内部でHandledError型をとる関数というのは、必ずhandle関数を経由した上でしか呼ばれないということが自明になる。

関数シグニチャを見ることで、その関数がどのようなタイミングで呼ばれるかが分かるようになるし、コンパイラによるチェックも効く。そして、この仕組みをより高度に使った例が幽霊型(ファントムタイプ)だ。

実際のプロダクトにおいてどこまで型による制約を設けるかは堅牢性と複雑性のトレードオフになるが、型を自分たちのレールとして使うことの重要性は知っておいて損はない。

ElmでPhantom TypeとExtensible Recordを用いて型安全な状態遷移パターンを実装する

このDiscourseスレッドがかなり面白かった。

OPは「幽霊型(Phantom Type)を使うと特定の順序でしか型安全に状態遷移できないように実装できると思うんだけど、どうしたらいいかな?」と質問している。

discourse.elm-lang.org

実装してみる

回答者からのアイデアによると、Phantom TypeとExtensible Recordを組み合わせて実装することで型安全な状態遷移が作れる。

たとえば、以下のようなゲーム上での状態遷移のパターンが仕様としてあるとしよう。

f:id:IzumiSy:20200104151513p:plain

これを実際に今回のパターンで表現すると、このようになる。

type Transition a =
    Transition


type Allowed
    = Allowed


type Game
    = Loading (Transition { ready : Allowed }) -- ロード中
    | Ready (Transition { playing : Allowed }) -- プレイ可能
    | Playing (Transition { paused : Allowed, gameOver : Allowed }) -- プレイ中
    | Paused (Transition { playing : Allowed }) -- 一時停止
    | GameOver (Transition { ready : Allowed }) -- ゲーム終了


toReady : Transition { a | ready : Allowed } -> Game
toReady _ =
    Ready Transition


toPlaying : Transition { a | playing : Allowed } -> Game
toPlaying _ =
    Playing Transition


toPaused : Transition { a | paused : Allowed } -> Game
toPaused _ =
    Paused Transition


toGameOver : Transition { a | gameOver : Allowed } -> Game
toGameOver _ =
    GameOver Transition

最も重要な部分は、Transition型が幽霊型として次に遷移する状態の許可レコードのようなものを保持している箇所で、遷移の際に呼び出すtoReadytoPlayingなどの関数が引数としてTransitionの保持しているレコードをチェックするようになっている。

この実装表現の優れている点は

  • 型安全性が高い。
  • Game型を見るだけで「次にどういう状態への遷移が許されているか」がすぐに分かる。
  • 状態と遷移のパターンが増えたとしてもGame型を修正するだけでよいので修正範囲が少ない。

などが挙げられ、正直イイことしかない。コードとしても、ある程度Elmに習熟していればさほど難しいものでもなく理解しやすいだろう。

あとはGame型をOpaque Typeなモジュールにでもしてやれば、明示的にLoadingReadyなどのバリアントを利用できなくなるのでより安全性が増すだろう。

型の恩恵を確かめてみる。

上の型を操作するにあたって、遷移の関数ではモデルの状態と遷移の組み合わせがほぼ強制される。

update : Game -> Game
update game =
    case game of
        Loading transition ->
            { state = toReady transition }
            
        Ready transition ->
            { state = toPlaying transition }
            
        Paused transition ->
            { state = toPlaying transition }
            
        Playing transition ->
            { state = toGameOver transition }
            
        GameOver transition ->
            { state = toReady transition }

試しにLoadingからGameOverに遷移するようなコードに書き換えてみる

これはあってはいけない遷移だ。

update : Game -> Game
update game =
    case game of
        Loading transition ->
+           { state = toGameOver transition }

        Ready transition ->
            { state = toPlaying transition }

コンパイルしてみると、以下のようなエラーになる。すばらしい!

The 1st argument to `toGameOver` is not what I expect:

72|             { state = toGameOver transition }
                                     ^^^^^^^^^^
This `transition` value is a:

    Transition { ready : Allowed }

But `toGameOver` needs the 1st argument to be:

    Transition { a | gameOver : Allowed }

Hint: Seems like a record field typo. Maybe gameOver should be ready?

Hint: Can more type annotations be added? Type annotations always help me give
more specific messages, and I think they could help a lot in this case!

ellieで実際のコードも用意したので、興味があればどうぞ。

2019年を振り返ってみる

振り返っちゃいます

1月

  • 圧倒的な家賃の無駄さに耐えられず千葉への引っ越しを決めた。

2月

  • 千葉へ引っ越した。引越し業者にはアーク引越センターというところを使ったが、激安でびっくりした。なお、引っ越しの経緯は去年末のブログに書いている。 www.izumisy.work

  • あとは友達とか会社のひとたちとスノボに2回くらい行ったりした。やはりスノーシーズンと言えばスノボである。ウェアもコロンビアの新しいのを買ったので、気合が入っていた。

3月

  • 会社の同期と@sadnessOjisanとでEastgate HACKATHONに参加した。及川さんとかトレタの増井さんとかを生で見れてよかった。賞は取れなかったが、やはりハッカソンはギリギリで戦っているあの感じが良い。しかし、毎度のこと徹夜による燃え尽き感に慣れない。

  • elm Europe 2019のスピーカーに選ばれた。朝起きてスマホでメールを見たら、オーガナイザーから「あんたスピーカーに選ばれたよ、OKなら返信して」みたいなメールが英語で来ていて、まったく期待していなかったのでちょっと悩んだがすぐにOKの返信をした。こういうチャンスは行動しないほうが絶対に損をするに決まっている。まずやる精神である。

  • こんな社会人ポエムも書いていたっぽい。 www.izumisy.work

4月

  • 応用情報技術者試験を受けた。当日は千葉工業大学新習志野キャンパスが会場だったが、マジで周りに何もなくて勉強に集中できそうだなと思った。学生はとにかく勉強に集中できる環境があるのが一番だ。

  • 6月のelm Europeに向けてパスポートを作り直した。去年Web Summitに行った時点でギリギリだったのでさっさと更新すればよかったマジで。

5月

6月

  • 応用技術者試験にギリギリ1点オーバーで受かっていた。正直受けた当日は「これ落ちたな」と思ったが、結果オーライである。受かれば官軍とはまさにこのことだ。 f:id:IzumiSy:20191229220657j:plain

  • とうとうフランスへ渡りelm Europe 2019で登壇した。人生初の英語トークが海外カンファレンスでの登壇で緊張感はとんでもなかったけれど、同時に最高の体験でもあった。海外の技術コミュニティのホットな感じを身を持って体験できたのも本当に大きいと思う。これによってElmに対する思いをさらに熱くした。 www.izumisy.work

  • ブログで書いたこの記事がものすごくバズってびっくりした。 www.izumisy.work

7月

  • elm Europeに自分が登壇したのを知って、楽天のElmエンジニアである@luca_mugからDiscord上でメッセージをもらい、来年開催のElm Japanの企画について話を聞く。彼もまたElm Oslo Dayでの登壇経験があり、カンファレンスに関していろいろ情報交換をした。

  • Elm界隈で有名な@ababupdownbaさんに連絡をとり、8月のElmミートアップの開催に関して飯をたべながら話し合った。

8月

9月

  • 千葉県を台風15号が襲い、自分が住んでいる地域一帯が大規模停電した。その日はまだ比較的夏日で蒸し暑く、夜になっても35度とかそれくらい。クーラーが動かなくて死ぬかと思った。水は出るものの、さすがに裸に浴びるには冷たすぎてにっちもさっちもいかなかった。人間、電気がないとこうも脆弱なものなのかと思わされた。うちは1日と半日で復旧したが、これが1週間とか続くとマジで死人がでる。 www.nikkei.com

  • 会社のメンバーと技術書典で本を販売した。自分は1章でElmのことを書いている。初参加でかつブース側という特異なアレだったが、やはりテッキーなイベントのフェス感はなかなかイイものがある。Elmについて書いてるなんてウチだけやろ〜とおもったら、なんとmixiが無料頒布している冊子でもElmが取り上げられていた。まあ嬉しいことではあるが。 techbookfest.org

  • ブログで書いたこの記事がバズった。設計の本というのは自分も学生とかもう少し経験が浅い頃にたくさん知りたかったし、当時の自分だったらこういうのが知りたいだろうな〜と思いながら書いた。 www.izumisy.work

  • 夏休みに福岡と長崎へ旅行に行った。正直かなり弾丸ツアーだったので楽しかったと言うより疲労感のが先にきてしまった。博多や天神あたりは想像よりも街全体がコンパクトかつ成熟していて、夜もしずかでおどろいた。いつか福岡に住んでみたいと思う。長崎はハウステンボスに行ったりイージス艦を見たりしたが、路面電車がよく分からんICカードだったのと坂が多いという印象しかない。

10月

  • Architecture Nightというイベントに参加したが、かなりよかった。また開催してほしい。アーキテクチャというと、どうしても抽象的な話になってしまうことが多く勉強会のトピックとしては難しいのかもしれないが、それでもこのイベントはかなり学びがあった。 www.izumisy.work

  • 去年の抱負に書いたとおり不動産投資の本を何冊かちゃんと読んだ。結論、不動産投資はやるならガチじゃないと大ケガすると思った。そもそも不動産を扱うというのは完全に事業を自分でやっているのと同じで、そこには営業、会計、マーケティングなどビジネスをやるにあたって必要なモノすべてが詰まっている。逆に言えば不動産投資をガチでやれる人間は充分ビジネスの素養があると思う。 www.izumisy.work

11月

12月

  • なんとDeveloperWeek 2020での登壇が決まってしまった。まさかのPRO SESSIONの枠というサプライズ。応募時に選ばされたライトニング・トーク枠とは一体なんだったのか... 結局こうやって毎年海外へ何かしらで行っている気がする。しかし、やはりこういうチャンスは「まずやる」の精神で積極的に突っ込んでいきたい。 www.izumisy.work

  • オーガナイザーとして関わっているElm Japan 2020の開催が決まる。なんとElmの作者のEvanも来日するというビッグ・イベント。現時点でCFPの応募や国外からの参加者もまあまあいて、みんなElmのために日本に来るんだな〜!という感動がある。とにもかくにも日本で初めてのElmの国際カンファレンスなので必ずやみんなに楽しんでもらえるものにしたい。 elmjapan.org

所感

こう見るとかなりいろんなことをしたな〜という印象。特にフランスへ行って登壇したというのはかなり自分の中でのティッピング・ポイントになった感がある。

事実、学生の頃から「海外のイベントとかで登壇できたらきっと楽しいだろうな〜」と思っていた。特に自分は、アメリカでインターンをしていたときにDeveloperWeekのハッカソンに参加して現地でのトークを生で見ていたこともあり、ある種の憧れの気持ちは強かった。それだけに、今年のelm Europeでの登壇はすごく特別な経験になった。来年には、自分がまさか登壇するとは思ったなかったDeveloperWeekで登壇することになり、やはりこうして人生に弾みをつけていくのはテンションage↑だなと思う。

仕事の話はほとんど書かなかったが、自分が関わっているプロダクトも今がまさに成長の過程そのものという感覚があり、ソフトウェア・エンジニアとしてプロダクトの成長をよりサポートできる存在になっていきたいという意気込みがある。それは技術的な面でもそうだし、ビジネスパーソンとしての価値という点でもそう。

特にエンジニアリングをやる人間として、よりビジネス的観点からの意思決定をちゃんと行えるようになっていきたい。技術的を用いた解決だけではなく、もしもフェーズ的に必要であればマネジメントの領域にも自分を持っていきたいし、いま組織やチームが必要とする人間にどうやったら自分がなれるかを模索している。そのためだったら、去年ポルトガルに行ってWeb Summitでブースに立ったように、コードを書く以外の仕事になってもいいかなとさえ思う。

とはいえ、自分の未来のキャリアをある程度固めて考えないと、ただの器用貧乏にもなってしまいそうな雰囲気もある。とりあえず年末ゆっくり考えようと思う。

来年もとにかく楽しいことをたくさんしたいな。

Elmで再帰構造を使って特定の順序でなければ状態を更新できない型を作る

a, b, c, dという型がある状況でaがなければbが更新できないし、bがなければcが更新できない、のような流れを再帰構造の型で表現する実装。使いどころは謎だが思いついたのでメモしておく。

type Data a b c d =
    Data (Maybe (a, Maybe (b, Maybe (c, Maybe d))))


type alias Payload = 
    Data Int Float String Bool


init : Payload
init =
    Data Nothing


mapA : Payload -> Int -> Payload
mapA (Data data) value =
    case data of
        Nothing ->
            Data (Just (value, Nothing))
        
        _ ->
            Data data
           
           
mapB : Payload -> Float -> Payload
mapB (Data data) value =
    case data of
        (Just (a, Nothing)) ->
            Data (Just (a, Just (value, Nothing)))
           
        _ ->
            Data data
            

mapC : Payload -> String -> Payload
mapC (Data data) value =
    case data of
        (Just (a, Just (b, Nothing))) ->
            Data (Just (a, Just (b, Just (value, Nothing))))
           
        _ ->
            Data data


mapD : Payload -> Bool -> Payload
mapD (Data data) value =
    case data of
        (Just (a, Just (b, Just (c, Nothing)))) ->
            Data (Just (a, Just (b, Just (c, Just value))))
           
        _ ->
            Data data
           

hasAll : Payload -> Bool
hasAll (Data data) =
    case data of
        (Just (_, Just (_, Just (_, Just _)))) ->
            True
            
        _ ->
            False

もし再帰構造にせずデータを全部Maybeで横持ちにすると、cやdのデータだけが存在している状況を作れてしまう。だが、この構造であればそのような状態は作れない。

Elmをプロダクトで一年書き続けた感想

この記事はElm Advent Calendar 2019最終日の記事です。

去年末あたりから現職のチームでElmを書き始めたので、大体1年程度はプロダクションでElmのコードを書き続けたことになる。学生時代はRubyJavaScriptばっかりだったので、関数型プログラミングとかそういうバックグラウンドは一切なかった。その観点から、改めて率直な感想を申し上げておく。

なお、弊社フロントエンドチームとElmに関するはなしは、私の書いたFringe81アドベントカレンダーの記事を参照のこと。 fringeneer.hatenablog.com

Elmには中毒性がある

Elmを触ったことのない方からすると「?」になるかもしれない(というか、昔の自分がそうだった)が、率直に言ってElmには中毒性がある。一度Elmを知ると、Elm以外の言語を触るたびに「これ、Elmだったら〇〇なのにな〜」と思うことになる。おそらくこれはScalaやらHaskellにも共通な気がする。Elmを知ってしまうと、Elmを知らなかった頃は気付けなかったアラや、改善の可能性がたくさん見えるようになってしまう。

決して他の言語をsageるわけではない。しかし、ひとたび型によるサポートを受けたプログラミングを体験してしまうと、その他のフロントエンド開発のための言語がのきなみ不便に思えてくる。少なくとも、ビルトインで言語機能にADTとパターンマッチングが入っていない言語はなおさらだ。ADTは間違いなく人類の宝だし、フロントエンドにこそパターンマッチによるコンパイラの網羅性チェックは必要だ。

Elmを使うとSPAの仕組みが分かる

ElmでSPAを作るのは難易度が高いと言われるが、実際これはそのとおりだと思う。

事実、ReactやVue.jsではルーターがうまく遷移ロジックをカプセル化してくれるので、仕組みを詳しく知らなくてもSPAが開発できる。けれども、一方でElmを使ってSPAを作ることで、実は画面遷移はブラウザからの入力によって画面という状態が更新されているだけなのだと分かるし、ルーティングを作ることは思ったよりも難しくないと分かる。フロントエンドの人間たるもの、ルーティングの仕組みくらいは知っておきたい。

とはいえ、つい最近elm-spaというスキャフォルディングツールが出たので、これからはもうちょいSPA開発で楽ができるようになるかもしれない。

Elmの本質はアプリケーション設計

基本的にElmは機能の削ぎ落とされた言語なので、Haskellっぽい文法だがモナモナすることもできないし、型レベルでバキバキのプログラミングをすることもできない。その一方で、最終的にElmを使っていて行き着くのはアプリケーション設計そのものになる。モデル設計やモジュール毎の責務分割のような、言語依存でない設計の思想を考える時間が開発の大半を占める。

が、最終的にここに至ると基本的には答えが出ない世界になるのでひたすら探究を続けることになる。アプリケーション設計はフロントエンド、バックエンド問わず最も重要なトピックであるし、ここに集中できる時間が多いほうが間違いなく嬉しい。Elmの言語機能の少なさは、言語表現やツールの選択で無駄に試行錯誤する時間を減らしてくれていると思う。

Elmとオンボーディングについて

Elmは敷居が高い言語だ!と言われるのは分かるが、自分の体感としてElmを触ったことのない人間がプロダクトのコードを読んで機能追加をできるようになるまでにかかる時間は、JSやモジュールバンドラの知識とVue.jsやReactなどの経験があれば、フルタイムで勉強時間を確保するとしても半月か約一ヶ月程度あれば充分ではないかと思う。新卒で入社する社員や、Elmを新しく書き始める既存社員も、同じくらいの学習期間でオンボーディングしている。ここに関数型プログラミングの知識があるかどうかは、ほとんど関係がない。むしろない人のほうが多い。

ReduxやVuexを知っていれば、もはやどちらもElmのアーキテクチャそのものであるし、もっと学習期間は短縮されるだろう。JSでElmのエッセンスを知りたければ、HyperappMithril.js、もしくはChoo.jsあたりもおすすめだ。特にHyperappは作者がElmの思想に大きく共感して生まれたフレームワークだということもあり、Elmの雰囲気を知るにはぴったりだと思う。

Elmをこれからも使いたいか?

いや、間違いなく使いたい。意外に思われるかもしれないが、その理由はElmの生産性の高さが一番に来る。Elmは型のある言語なので、いわゆる「型安全性」がよくワーワー言われるが、型安全性であることで生産性が上がる。ドカンと大きな機能追加をしたり修正をしたりしても、まずデグレすることがないのは大きな恩恵だと思う。

デグレしないということは、あとからバグを治す時間もいらなくなる。結果、エンジニアは新規機能の開発に注力でき、顧客に常に新しい価値を届けることができる。こう書くと安っぽいが、プロダクトでElmを使う価値は全方位的にあるし、特にエンタープライズなフロントエンド・アプリケーションを作る場面ではElmが使いものにならない状況はほとんどない。ビジネスでちゃんとお金を生むようなソフトウェアこそ安全性と生産性が大事になる。「開発スピードを求めるとバグは出るものだ」と考えている人ほど、Elmを触る価値があると思う。「型のある言語は難しい」と思っている人もまた、Elmを触る価値があるだろう。


正直、自分もここまでElmにいれ込むとは思ってもなかった。だが、今となってはフロントエンド開発をするとなったら個人開発でもElmを選ぶし、使えば使うほど良さが感じられる。言語そのものだけではなく、国内外のElmコミュニティも活発であることもElmが好きな理由の一つだ。プログラミングは大抵の場合個人作業だが、それでも気軽に情報共有のできるコミュニティがあるのは、大きな助けになる。

そして来年2020年には、アジア圏で初めてのElmカンファレンスが開催される。これは日本のElmコミュニティにとってとても大きな一歩だと思うし、多くのエンジニアが来てくれることを願ってやまない。

DeveloperWeek 2020のCFPが通ったので登壇する

「Elm Europe楽しかったし、またなにか海外のカンファレンスに参加しがてらElmのトークしたいな〜」と思っていたところ、DeveloperWeek 2020がCFPを募集しているのを知ったのでJavaScript Conferenceの枠で応募したら通ってしまった。

応募上は単なるLT枠だったはずが、なぜかタイムラインを見るとPRO SESSIONの枠になっているので驚いている。グランド・ボール・ルームとかいうデカい部屋でやるっぽいのでかなりハードコアだが、こうなったらもうやるしかない。

f:id:IzumiSy:20191214215633p:plain DeveloperWeek 2020: PRO SESSION: Elm, the Future of Function...

DeveloperWeekについて

www.developerweek.com DeveloperWeekは毎年サンフランシスコで開催されている非常に大規模なテックイベントのひとつ。Googleで検索するとどうやら2013年頃から開催されているらしい。じつは自分も休学していた2016年にDeveloperWeekの企画のひとつとしてGalvanize*1で開催されていたハッカソンに参加していた。あれから4年の歳月を経て再びスピーカーとして参加できることになるとは、夢にも思わなかった。

このイベントが大規模な理由は、いまホットなテック・フィールドのセッションを開催4日間のうちに一気に開催するからだ。DeveloperWeekというイベントの中に、異なるジャンルのカンファレンスが複数存在する形になる。

例えば僕が登壇するJavaScript Conference以外にも、機械学習人工知能などのセッションがメインのAI Dev Conferenceや、ブロックチェーンにフォカスしたBlock Dev、その他にもマイクロサービスやコンテナ技術がメインのセッション・トラックで構成されるカンファレンスが一気に開催される。

自分が参加したGalvanizeでのハッカソンはサンフランシスコ市内での開催だったが、トークセッションなどが開催されるのはオークランド・コンベンション・センターとのこと。

f:id:IzumiSy:20160213130941j:plain
2016年のハッカソン会場(Galvanize)の様子。入場しようと思ったらIDとしてパスポートをもってこいと言われ、取りに戻ったら座れるスペースがほとんどなくなっていた。

海外のカンファレンスに参加するのは自分のキャリアのためというよりかは、現地ならではのお祭り感を味わいたい!という理由のほうが大きい。

特にDeveloperWeekはチケットが普通に高いが、スピーカーになるだけで無料でSPEAKER PRO Passを手に入れることができる。みんなの前でトークできてイベントも楽しめるなんて、こんなに最高なことはない。

*1:サンフランシスコにあるブートキャンプのひとつ。DevBootcampなどもその当時は有名だったが2017年になくなってしまったらしい。