Erlang で仕事する一つの方法

これは 2007 年頃の話です

Erlang/OTP って何?という時期に Erlang/OTP で製品を作って利益を上げた日本人はあまりいないとおもう。

せっかくなので振り返りついでに、自分の昔話を書くことにする。

Erlang/OTP の導入まで

仕事でネットワークサーバを触ることになったのだが、当時の製品はシングルスレッドだった。当時はもうマルチコアだという話がでており、ではマルチコアを有効に使えるネットワークサーバを書くにはどうしたらいいのだろうか?というところから入った。

Erlang/OTP をやる前は Python で Django というところに興味があったくらい普通のウェブアプリスキーだった。

そのため何を血迷ったか Python でとりあえずネットワークサーバーを書いてみることにした。

stackless python 使ったり Twisted 使ったり multiprocessing もどき使ったりしてみたが、どうも明らかに性能がでないし、コード書くのが難しかった。というか単に自分の頭が足りてない。

素直に C/C++ で書けよという話なのだが、当時の自分はそこに至らず。なぜか Erlang/OTP という言語を見つけてしまう。

これは、ぐぐっていて簡単にネットワークサーバを書くには Python じゃダメだから、他の言語をという感じで調べていた。 Java で書くというのもあったがストップザワールドがあるので、受け入れにくい。C/C++ は自分のスキル的に無理。ということでたどり着いたのが Erlang/OTP だった。

Erlang を学ぶ

Erlang の解説を見てるとどうも、欲しいのはこれだった感があった。ただ文法的によくわからなかった。まずは Erlang のドキュメントを眺めてみることにした。

当時はまだ本が出ておらず、ドキュメントしかなかった。

The Pragmatic Bookshelf | Programming Erlang 2007–07–01 にこの本がでるのだが、この本がでるより少し前に勉強し始めたのを覚えている。

本は買って読んでいたのだが、なんと半年後にはもう日本語訳が出てしまう。

プログラミングErlang: Joe Armstrong, 榊原一矢

通称飛行機本(戦闘機本)だ。この本は本当に素晴らしい翻訳だった。自分の人生を変えた一冊だと思う。
この本を徹底的に読み込むというのが自分の取った手段だった。何度も何度も読んで頭にたたき込んだ。

不思議な縁もあり、この本の翻訳者である榊原さんと編集者である鹿野さんにお会いすることもできた。

ひたすら飛行機本を読んで、既存製品と似たような機能を持つ製品を Erlang/OTP で書き始めた。最初は OTP とかわからずに書いていた。

Erlang での製品作り

とにかくマルチコアでスケールするかどうか、既存製品よりメンテナンスやテストがしやすいかに焦点を当てて製品を作った。
当時は rebar なんて便利なものは無く、テストをするだけでも大変だった。

僕らの rebar は 2009 年ごろ登場する

社内へのアピール

Erlang で書いた製品のアピールを社内にし続けた。ちなみに仕事はあったので Erlang で書いている暇は完全に土日だった。土日に書いた製品を社内でアピールしていた、今考えるとあまりよろしくない。

  • DSL なのでコードが短く書ける
  • テストしっかり書かれている
  • プロセスが独立してるので落ちにくい
  • 既存製品に近い機能を持っている
  • 既存製品には無い機能を持っている

このあたりをアピールしていたと思う。同じような製品を作ってもアピールは正直難しいと判断した。
そのため、既存製品の機能は実装して、さらに新しい機能を実装した。

よほど新製品に興味を持ってくれない場合は、そんな時間を取ってくれる会社はないのでとにかく一人でコードを書いては捨ててた。

人材の確保

そろそろ一人でかくのがしんどくなってきたので、誰か仲間が欲しいなと思ったタイミングで @itawasa を捕まえることができた。そこからは会社としても Erlang/OTP の製品を採用することにとんとん拍子でいった。

これには既存製品の限界というのが見えていたし、経営者の英断があったのだとおもう。ここはもう完全に運だとおもう。

パッケージング

あとはリリースだが、その頃は Erlang 製品のパッケージング方法など全然決まっていなかった。かなり苦戦して reltool を勉強したのを覚えている。ただかなり運が良かったとおもっているが、製品リリースあたりで rebar が出てきて、それを採用した。

土日に一人で出社して全てのテストを Eunit 化したのはいい思い出だ。

rebar

rebar には本当に助けられた。@itawasa は rebar の改修/bugfix とコードレビューという今考えると不思議な仕事をずーっとやり続けてくれた。

rebar は本当に便利で、今も相変わらず使い続けている。そろそろ rebar 3 に移行したい。

ドキュメント

なんやかんやあって、無事リリースできた。Mnesia をフル活用してクラスターでのデータ共有も持たせた製品。

ただ何が大変だったってドキュメントが凄い大変だった。この辺は Sphinx を PDF に変換する仕組みを作った。ドキュメントへかなりの時間をかけられたのは本当にありがたかった。

自動ビルドと自動テスト

これは @aohta が Jenkins をガッツリやってくれて、対応できた。当時から EtoE でテストしたいという気持ちがあった。Python でテストクライアントを作ってくれてそれを自動で流すという仕組みを作ってくれた。

自動ビルドと自動テストがあり、これらを継続的にメンテナンスしていく必要性はこのときに学んだ。そしてそのメンテナンスコストはとても高いことも思い知らされた。一ヶ月間は開発を止めて皆で環境を見なおしたりしていた。

Erlang のアピールをしない

製品を Erlang で作っているという話は口ではしても、アピールに使う事は少なかった。言語アピールは顧客に響くことは無い。

大事なのは製品の品質や性能であって別に言語は関係ない。

Erlang かどうか関係なく必要とされる製品であれば売れるというのを学んだのもこのときだ。ちなみに Erlang で書いていることを理解してくれた顧客は一人くらいしかおらず、その人とはまだ付き合いがある。

Erlang で製品を作ってお金を稼ぐ方法

Erlang を採用するかどうかが先に来るのでは無く、どんな製品を作りたいかで言語を選べば良い。その製品がいいものであることが知られて値段が適切であれば売れる。当たり前のことだがそんなものだということを学べた。

そして売れるようになった製品が Erlang で書かれていたら Erlang で仕事ができるようになる。

まとめ

課題から入ろう、言語からはいるのは卒業しよう。

Written by

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store