msgpack-erlangのはなし

この記事は Erlang Advent Calendar 2014 の三日目の記事です。

MessagePackというシリアライゼーションのフォーマットがある。これはまあまあ有名じゃないかもしれないけど、今をときめく fluentd の裏側で使われているプロトコルだ。この手のシリアライザは多種多様で、圧縮まで考えると歴史的にも沢山あって死屍累々の歴史でもある。モダンなやつだとAvro, Thrift, ProtocolBuffers などがあるが、サイズ、速度、柔軟性のバランスを考えるとかなり独特な位置にある。興味があるひとはTwitterでMessagePackってつぶやいてみると作者たちが釣れるかもしれない。今日はこの Erlang/OTP での実装について話をしよう。


使い方

基本的にはこれを単体で使うことはないだろうと思うが、簡単に試したいかたは次のようにすればよいだろう。システムに Erlang/OTP (R15B ~ 17.x) と git がインストールされていることが前提だ。

$ git clone git://github.com/msgpack/msgpack-erlang
$ cd msgpack-erlang
$ ./rebar compile
$ erl -pa ebin
> Bin = msgpack:pack([<<"spam">>, <<"ham">>, <<"egg">>, 42]).
<<148,164,115,112,97,109,163,104,97,109,163,101,103,103,42>>
> msgpack:unpack(Bin).
{ok,[<<"spam">>,<<"ham">>,<<"egg">>,42]}

他にもいくつかAPIがあり、ドキュメントはないが、関数そのものは4つしかない。 msgpack.erl をみれば概要がわかるだろう。ちなみに Erlang/OTP 専用になるが、 "msgpack:term_to_binary/1" と "msgpack:binary_to_term/1" という便利関数も用意している。これは、 MessagePack の新仕様の拡張型を使って、ErlangのTermを全部エンコードできるようにしたものだ。これを使えば、 ナマのMessagePackでサポートしているプリミティブなErlang Termはそちらに変換され、 pid() などどうにもしにくいものは t2b なり b2t に部分的にフォールバックしてくれるというスグレモノだ。ちなみにコレを使っている人はまだみたことがない。速いかどうかは知らない。

自分のErlang/OTPのソフトウェアに組み込みたいときは、 rebar.config に次のように書くとよいだろう。

{deps, [
        {msgpack, "0.*",
         {git, "git://github.com/msgpack/msgpack-erlang", {tag, "0.3.2"}}}
       ]}.

事例

  • 今をときめくアドテクの会社、VOYAGE GROUPで使われているとのこと
  • 某社で内部のプロトコルで使われているそう
  • たまに海外からメールが来る

今の実装の問題点

  • NIF版に手をつけられていない。拡張型が入った時点で一旦外していたのだが、戻ってこられず…
  • jiffyやjsxインターフェースを捨てたいが捨てられない
  • 最適化？なにそれ？
  • テストが足りてない

今後の方向性

− Pull Request がいつの間にか来てたので対応したい

コントリビュート

こちらまで。Apache 2ライセンスに同意していただくことが必要。OSSのソフトウェアを開発する仕事をしているくせに、OSSの開発にあまり時間を割けていないというみっともない状態なので、メンテナが増えてくれると嬉しいなあ…

歴史とポエム

いま改めて検索してみると、最初の実装を発表したのは5年以上も前になる。最初のコードはわずか300行ちょっとの1ファイルで、シリアライザとデシリアライザが全部入ってしまって、Erlangのパターンマッチすげえ！と感動したのを5年ぶりに思い出せた。当時はまだ僕はErlangを始めたばっかりで…（以下ポエム）

それが、8ヶ月後には公式ライブラリの仲間入りをして…それも4年前のことであるから、思えば遠くまで来たもんだ。

日本のデータベース系のコミュニティ、なぜイマイチ盛り上がらないのか

11月の19,20日に開催されたWebDB Forumに参加してきた。カンファレンスそのものは、いろんな人に久しぶりに会えたり、ネット上でなんとなく知っていても話したことなかった人と話したり、意外な人の意外な一面をみることができたりと、とても楽しむことができた。立場としては所属している会社のスポンサー枠で参加して目的もあって発表もしてきたわけだが、いくつか思うところがあるのでここにまとめておきたい。

現実にアカデミックで起きていること

WebDB Forumと銘打ってはいるものの、データベースに関する研究発表は非常に少ない。OSやネットワーク、システム系の研究と併せても、機械学習やNLP、Webなどの技術に感心を持つ人は多く数で圧倒されている。体感では 90% だ。それをいえば別に VLDB や SIGMOD などのトップカンファレンスもデータベースの技術を直接扱うことは少ないし、データベースの要素技術は多岐にわたるので一概に定義することは難しいのだが。まあ私が興味を持てる発表が少なかったと言い換えても構わない。

学会がこのようになっているのは、当然の原因があって、そもそもデータベースを扱う研究室が非常に少ない。わたしはそんなに知っているわけではないが、インダストリアルからも見えているのは東大の喜連川研、東工大の首藤研、筑波大の川島研、最近できた阪大の鬼塚研がわずかに取り組んでいるだけだ。それもクラウドの要素技術のひとつとして、研究室の一部で…というのが実態だ。ComSysやDEIMに行けばもっと多様なものが見られるのは知っているが…

現実にインダストリアルで起きていること

まずはいくつかのスライドをはっておく。

これがCassandra

ほかにも、 CyberAgentにおけるMongoDB や [C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは？ by Taichi Umeda など、アカデミックとは違うことが起きているのが分かるだろうか。

これは単なる人材の需給のミスマッチで説明できる現象ではなくて、そもそもこういった下回りの技術に若者たちが興味を持たないという傾向がここ十年以上続いていることが遠因だ。現に私が学生だったときも、OSやデータベース、ネットワークにまだまだ研究課題があるとは思っていなかった。それは教科書や論文の延長で考えれば確かにそうなのだけど、現実世界に引き込んだ瞬間に違うことになる*1。…のだが、その魅力に気付いたのは、私の場合は大学を出てサラリーマンになってからだった。分散システムやデータベースに出会って、自分で設計してみて、実装してみて初めて分かることがあまりに多い。とんでもなく優秀な人なら、周囲の助けも得て学部から修士の3,4年でその境地に辿り着けるだろうが、私のようなふつうの学生 はそうではなかった。

あと最近はAWS使えばそれで大抵うまく動くので別にいいよね、みたいな。身近に問題がないというのも問題なのだけど、…。

どうしたらよいのか

WebDB Forumで何人かアカデミックやその出身の人と話した限りでは、やはり講義が少ないという現実があって、それは学生が興味を持たないことも原因だし、教授陣があまりそっち系の講義をやっていない＆できる人がいないことも原因でもある。人が集まらないのはなぜかというと、…という言葉を考えるとちょっと言葉に詰まる。

とりあえず分散システムの人はトランザクションを学ぶべきだし、トランザクションの人は分散システムを学ぶべきだ。だから、とりあえず、Bashoという会社に行くと（どっちかというと分散システムの知識にかたよるけど）両方の経験が身につくので、行ってみるといいと思うよ！


奇しくも、5年も前に 基盤系プログラマ - kuenishi's blog などという煽り記事を書いた問題がわりと近い方向であたっていて、今ではどんな会社もちゃんとしたインフラエンジニア（当時はそういう言葉がまだなかった）を欲しがっている。これからデータ量やトラフィックが益々増えていくとそういう人種の価値がますます上がるわけで、この需給のギャップを解決するためには、やっぱり最初の一歩は大学の講義が増えて「こういう技術、ものすごく金になるんですよ」とか、「本当に賢いヤツらはここに集まっている」ということを滾々ともう一度伝えていくしかないのだろうかとか最近考えている。

追記

欧米でわぁ〜、というのはあまり言いたくはないのだが UCB の cs262 をネット上で貼ってくれている人がいたのでここでもリンクしておこうと思う。わたしもあまり多く追えてはいないのだけど、アメリカでCSの強い大学だとどこでもこのレベルの講義があって、学生がヒィヒィ言いながら履修している（という印象だ）。日本だとこういうのなかったよね、少なくとも私が学生だった頃は。

*1:某ﾁｮﾌﾟﾘﾝ氏がよい例だと思う

ラスベガスで開催されたRICON 2014に行ってきました

日本でもそうなのだが、アメリカでも分散システム専門で、しかもアカデミアと産業が両方出てくるカンファレンスはRICONを除いてほとんどない。確かに分散データベースに関するカンファレンスはアメリカではいくつかあるのだが、わりと商業的であったり、運用や実装に近い問題が多く分散システムの難しい側面にフォーカスされることはあまりない。

そんな素晴らしいカンファレンスが今年も開催されたので参加してきた。わたしが所属している会社が主催しているので、まあ主催者枠である。肝心のカンファレンスそのものは、アカデミアと運用事例、分散システムのエンジニアリングに関するはなしが同じくらいの割合でされていてまあ面白かった。圧巻はPeter Alvaroによる2日目のキーノート講演だった。

分散システムで難しいのは、AsynchronyとPartial Failureで、単体だと話はとても簡単なのだけど、現実世界はこれが揃っているせいで理論的には難しいものになっているというので、それをFault Injectionで検証する方法を考えてみたところ、Kyle KingsburyがJepsenで見つけたKafkaのデータロスもちゃんと出たし、Paxosは正しいことが証明できた。これまで分散システムを形式検証するよい方法はほとんどなかったのだけど、実際使えそうなものが出てきたことは本当にすごい。
動画はこちら：


Keynote 2 Day 2: Peter Alvaro - Outwards from the ...

RICONのよいところは、商業的な話も少しだけしつつ、Riakに限らず他の話もわりといろいろ入る。個人的に一番勉強になったのはMesosの話だった。

…とまあ、ここまでは表の顔で、裏の顔は普段リモートワークしているBashoの社員が集まってじゃれ合うイベントでもある。他にも沢山の画像が上がっているが、いかに楽しんでしまったかを一部の写真からご想像いただきたい






最後、ホテルの部屋の窓からチェックアウト直前に撮った一枚が個人的にはベストショットでありました。
100D3300-DSC_1818
100D3300-DSC_1818 | Flickr - Photo Sharing!

バグの間抜けな倒しかた

プログラムを書いていると、間抜けなバグをいくらでも仕込むことができる。たとえば一文字だけのTypoだったり、ifの括弧のつけわすれであったり、エラー処理をひとつ忘れていたり、もしくはその言語特有の間抜けなバグというものもあるだろう。そういったバグは往々にしてコードレビューはテストを掻い潜ってしまう。製品や本番のコードに残ったままリリースされ、とてもヘンなデータが入ったり障害が起きたりしたときにだけ発露する。今回のはなしもそのエラー処理をひとつ忘れてリリースしてしまったことがきっかけではあるのだが、むしろバグの見つけ方が間抜けであったことをここに書いて今後の反省の材料としたい。

riak_cs#985 はそんなバグのひとつで、エラー処理をひとつ忘れて Riak CS のコネクションプールが漏れていたという話だ。再現条件としては、ユーザに関するAPI（一覧GETなど）を叩いたり、 Authorization ヘッダなしで存在しないバケットを GET すると、コネクションがプールからひとつ漏れていく。コネクションプールが枯れてしまうと全てのAPIリクエストが503だか何だかのエラーしか返らなくなってしまって、まあ要はサービスが落ちるわけだ。これの原因が分からなくて、2日ほどうんうんと唸っていた *1 。

僕が非常に間抜けな見つけかたをしたのは後者の再現条件だ。 Riak には /ping という簡単な動作確認用のAPIがある。これをGETでたたくと、 "OK" という2文字がBodyに入ったレスポンスが返ってくるので、RiakのプロセスがすくなくともHTTPのレベルで生きていることはわかる。同様に、 Riak CS には /riak-cs/ping というAPIがあって、これを叩くと生きているかどうかがわかる。 #985 が問題になっているときに焦ってしまって、思いつく限りのAPIを適当に叩きまくっていたのだけど、そのなかに /ping というAPIがあると仕様を間違って理解していて、その実装は riak_cs_wm_ping.erlだと思っていた。これがコネクションを使っているし、あまりテストもないし、これが怪しいんじゃないかと疑っていた。これだと認証ヘッダがつかないので、ふつうのAPIアクセスとは違った挙動になる…ことを期待していたわけではなく、八方塞がって s3curl ではなく curl を使って叩いていた。ほんとうは /riak-cs/* のAPIも認証ヘッダが必要なのだけど、頭が混乱していたわけだ。
それで、

$ curl http://localhost:8080/ping

というコマンドを叩くとコネクションが漏れることを発見した。これがきっかけで問題箇所を特定できた（特定したのは僕ではない）のだけど、これは riak_cs_wm_ping.erl のコードを使っていなくて、 riak_cs_wm_objects.erl という全く別のAPIを叩いていたのである。どれくらい的外れかというと、この手の死活監視ならふつうは200が返ってくるのが相場だが、ステータスコードは404が返ってきてそういうXMLが表示されるくらい的外れだ。そして404が返っていても、リークを見つけて興奮していたのでそれにしばらく気付かなかったくらいボケていた。
ぼくの仮説の設定は全くの検討外れで、今回は運良くたまたま原因となるところにリーチできたわけだ。

ぼくはわりと性急な性格なので、勤務時間中は給料をもらっていると考えると効率を上げるために焦る傾向があるようで、デスクトップは片付けないし、かなりの数のメールをタイトルだけ読んでArchiveする。同様にドキュメントやコードを読むときは要点だけを知りたいので、細かい所はわりと飛ばしてよむ癖がある。それが今回は幸いしたわけだが、お前は本当にそれでよかったのかと問いたい。

じゃあバグの体系的な倒しかた、とかバグを仕込みにくい開発やプログラミング言語とは、という話になるのだけど、再発予防とか水平展開とか一般論に陥りがちで難しい。まあ QuickCheck でテストを書けという話ではある。

*1:まあ2日で見つかるんだからいいじゃないかという気もする

Riak 2.0がリリースされていた

9月に入ってから、Riak 2.0がリリースされた。昨年の今頃から動き始めて、1年かけてようやっとリリースにこぎつけた。あちこちで繰り返されているが、ここでも新しい機能をちょっとずつ試していきたいと思う。マーケティング的には華々しく4つくらいの新機能が宣伝されているが、ここでは地味でマニアックなことから。とりあえず思いつくものをここから。

  • Erlang/OTPをR16に更新（ようやく）
  • Cuttlefish: 設定フォーマットの簡単化
  • Bucket Types: Bucket名前空間の追加
  • Strong Consistency: レプリケーションの強い整合性
  • Riak Search 2.0: Solrを組み込んだ高機能な分散インデックス
  • Security: 認証認可と通信路の暗号化
  • Java Client 2.0: 進化したJavaクライアントとか、ほかにもいろいろ

進化とか書いてしまってカッコイイな。と思ったら、hiroeさんがQiitaに注意点をまとめていたのでとりあえずそのリンクを貼ってお茶を濁しておこう。

日本でも新機能をバンバン使っていろいろやろうとしているのでなんか追加の記事を書くかもしれない。

システム系論文輪読会で話してきた #pfisystemreading

先週の金曜日に、PFIで開催されたシステム系論文輪読会で話してきた。いい加減に積んであるものが多すぎて、こういった機会に便乗して自分を追い込まないと何もできないからである。


第2回 システム系論文輪読会 - connpass

僕が読んで解説したのは Peter Bailis et al., "Coordination-Avoiding Database Systems" VLDB 2015, to appear である。この論文がどれだけすごいものであるかという話についてはぼくのレジュメを参照いただくとして…この論文は神林さんに教えてもらったのだけど、VLDBやBailisのグループは要チェックだということを再確認した。この論文、なかに分散システムの証明が書いてあったりするのだけど、21回も続いている分散合意本読書会で鍛えた証明の読解力で割とスラスラとノリを理解できたので感動した。というわけで合意本を読めば…

Fault-Tolerant Agreement in Synchronous Message-Passing Systems (Synthesis Lectures on Distributed Computing Theory)

Fault-Tolerant Agreement in Synchronous Message-Passing Systems (Synthesis Lectures on Distributed Computing Theory)

といいたいところであるが、この本は一人で読み進めることは素人には不可能なのでなかなかキビシイ。ちなみに、わりとついてきた地力を使えば、CAP定理の証明 [1] くらいであれば、サクサクと読めるようになったりはする。

話を戻すと、この論文の内容はともかくとして、この論文がどうすごいのかを書いておこう、と思ったけど上のGistにだいたい書いてあった。クラウドとか分散KVSとか言ってるひとたち、この論文読まないとだめだよ。あとサーベイとしても非常によくできていて（各方面の歴史たちが共著者になっているので、歴史的に漏れがほとんどない）、参考文献リストの長さに顔が青くなること必至である。

まあ、流れでいうと、NoSQL的にトランザクションとかACIDとかレプリケーションをそこそこで割り切って作ったデータベースのよいところと、RDBMSとか2PCとかデータの整合性をキッチリキッチリやってきた流れがここで融合しているのがすごいのである。市場にも「トランザクションできるNoSQLだぜー」とか高速なRDBMSだぜーみたいな話は死ぬほどあるのだけど、どれもこれまでのデータベースの研究と製品の歴史を無視したマーケティングなので無視したらよい。製品にして使ったところでどこかでハマるのが原理的にわかっているので（ハマらないことが証明された設計になっているのであれば、それは論文にして出した方がマーケティングとしても効果が高い）。MongoDBやMySQLのようなタイプのレプリケーションをやっていると、ネットワーク分断、耐障害性、スケーラビリティのどこかで問題が出てくるし、CassandraやRiakのような設計でレプリケーションをやっているとスケーラビリティや耐障害性が十分であっても、整合性に限界があったりアプリケーション的なユースケースが限られたりする。

これはひとつのパラダイムでいろいろなデータベースの問題を解いて全てのユースケースをカバーできないということの証左であるわけだが、このCoordination Avoidingなデータベースでは、ひとつのデータベースで、ユースケース毎に理論的な限界をギリギリまで詰められることを証明した。具体的には、整合性を保ちつつスケーラビリティや分断耐性を追うためのユースケース分析をして、それをうまく使い分ける提案をしたわけだ。I-Confluenceの概念とその証明でだんだんテンションは上がって、TPC-Cのアクセスパターン分析でこの論文は最高に盛り上がる。

しかし原理の解説やTPC-Cの分析と実験は非常に興味深いのだけど、実装や設計の話がほとんどなくて、これじゃあちょっと再現とか実装してテストしてみるというわけにはいかなそうなのが難点である。きっとベンチャーを立ち上げるのだろう。

個人的には、この論文の実装が世にでるか出ないかのタイミングで「ひとつの用途にひとつのデータストア」の時代が終わるのではないかと予想している。今でも、AWSに入ってる各種データストアや、Orchestrate.ioなどが登場しており、データベースを個別にデプロイして使い分けるのではなく、複数のユースケースをなるべくシンプルなサービスにまとめて使い分けるという形が主流になっていくのではないか。手前味噌であるが、Riak も2.0のリリースでその第一歩を踏み出している。

  • [1] Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.

退路を断つ

ベルセルクのドルドレイ攻略戦で、鷹の団が川を背にして陣をとるシーンがある。グリフィスはそこで「後ろは川だ！退路はない！ここで踏ん張って勝つぞ」といった趣旨の発言で味方に発破をかけて大軍に勝つというシーンがある。人間が自分で何かを達成したいときも、似たような考え方をしてモチベーションを整えていく方法がある。大学受験に失敗して浪人をするとき、就職活動がうまくいかなくて留年するとき、卒業のための最後の2単位をとろうとするとき、などなど。一旦これで成功体験を得てしまうと、次の挑戦でも同様に自分を追い込んでからが勝負になりがちだが、良い子はマネをしてはいけない。

ベルセルク (7) (Jets comics (542))

ベルセルク (7) (Jets comics (542))

いくつか理由がある。

グリフィスは勝つ見込みがあって勝負をかけた

何を言ってるか分からないと思うが、ドルドレイ攻略戦ではグリフィスは寡軍を更に分割して、別働隊を出している。鷹の団の本隊が押され気味になったときに要塞内の守兵を戦功を餌に誘き出して、守りがほとんどいないドルドレイ要塞は別働隊が簡単に占拠してしまったのだ。また、中世の戦闘では大将の強さが軍隊の強さを決める側面があるが、敵の大将のボスコーン将軍をガッツが倒してしまうのである。漫画の主人公が負けるわけはないのだから、グリフィスはそこも計算していたことだろう。漫画のキャラクターが漫画の外の事情を考慮することは一般にご都合主義と呼ばれるが、ベルセルクという漫画はグリフィスをそういう物理的制約の外側にいる神秘的なキャラクターとして漫画内で上手く描いている。そうやってお膳立てを全部整えた上で「退路はない」と煽るのである。つまり計算づくなわけだ。

ちなみにこの退路を断つ戦略は、私が知る限り「項羽と劉邦」で韓信が中盤で用いている（確か楚との一連の戦いの中で）。おそらくはどこかの古典に載っている戦術だと思われる。どうしてこれが成功するのかという戦史上の分析はリデル・ハートの「戦略論」にタップリと書かれているのでお楽しみ頂きたい。

翻って、自分がそういったことを考えるときに勝つ見込みは十分にあるだろうか？火事場の馬鹿力という言葉を信じすぎていないだろうか？自分が普段できないこと、していないことを計算や予測に入れてはいけない。もし入れるなら、火事場になって突然腰が抜けて動けなくなるリスクも計算に入れなければならない。

そんなことを考えた時点で本人は十分に真剣だ

鷹の団の士気が低かったとはいわないが、この方法はあくまで「大将が兵士たちのモチベーションを高めるため」に用意した状況である。自分が自分のモチベーションを高める、という風に自分を客体的に扱ってコントロールすることに使えるかもしれない。しかし、私の理解だとそれは必要以上にモチベーションを高めてしまい、思考を停止させる。そのような方法は持続的ではないし、人間はそんなに強くない。

他にも敵を誘き出すすためという目的もあったが、個人での内面のメンタル維持であれば、その状況を外から観測することはできないので敵はおびき出されないし、外部の状況が何か変化することはないから、好転することもない。

リラックスした方がパワーは出る

常に退路を用意しておく方がリラックスできる。「逃げちゃダメだ」みたいな有名シーンもあるが、それは本当に退路がどこにもない場合だ。大抵の人生では、退路や他の選択肢は本人が思っている以上に多く用意されている。ダメそうだったら早めに諦めてまた仕切りなおせばいいじゃない。ぼくは高校3年の冬に「えー、キミたちは大学受験まであと13ヶ月ありますが」とかセンター試験の一週間前に「ほんまに大丈夫なん？今年は諦めてまた来年頑張ってもええねんで」とか言われたことがある。冗談めかして言われたわけではなく真剣にだ。それはどうかと思う、というか、それを真に受けつつ真に受けないくらいの余裕をちゃんと用意しておこう。

たまにはスピリチュアルなことを書いてみた。

在宅勤務環境を整備した

2年前に一念発起して組んだマシンがあって、Core i7と32GBものRAMを節操無く積んでいたもののファンの音が気になるとか子供が邪魔をするとか、ディスプレイが小さいとか理由であまり使っていなかった。引越を機会に自分の仕事場がつくれそうなので、これを機会にデスクトップ環境をもう一度整備した。

ディスプレイ

やはりこれが一番大切だろう。必須条件は解像度がいわゆる4Kあること。MacBook Proを使ってRetinaの美しさに慣れてしまった今、これまでの普通の液晶モニタでは何インチあっても意味がない。もともと液晶のサイズそのものではなく、解像度に興味があったので必然だ。本当は海のむこうだと$500とかそういうレベルで変えるらしいのだが、日本に住んでいるのでなんか出てるかなーと思ったらASUSからPB287QとIODATAからM4K281XBがそれぞれ出ていた。ぼくは海よりも深い理由からASUSを選んだ。

と、それだけではいけない。なぜならこのディスプレイ、DisplayPort経由じゃないとフル解像度じゃないと表示できないのだそうだ。HDMI規格が悪いのかディスプレイが悪いのかはわからないが、とにかくグラフィックボードも買うことにした。

ビデオカード

@moriyoshit とかいう人によると、LinuxのドライバはGeForceの方がそれなりに動くそうなので、AMD党としては残念だがGTX750あたりを目指して探してみることにする。MacBook Proの最上位モデルはこのボードが入っているそうだからというだけの理由である。もともとゲームはやらないので、そんなに強力な3D性能が必要になるわけでもない。と思っていろいろ探していたが、DisplayPortを持っているボードはELSAだとGTX760からのものしかないらしい。というわけでこれにした。

ELSAにしたのは積極的な理由はないのだが。。。本当はマザーボードと同じメーカーにしたかったのだが、ASRockのZ77 Extreme4という、グラフィックボードを出していないメーカーのマザーボードを使っていたので、逆に、GIGABYTEなどのマザーボードも作っているところはあえて避けてみた。非常に消極的で根拠のないことなのだが。

そういうわけで4Kになった。すばらしい

ちなみに、ドスパラでは、間違った機種をWeb経由で注文しても他社のようにキャンセルはできないので注意。キャンセルの代わりに返品か、同額以上のものに追加で支払って交換してもらおう。

キーボード

人間の両手は、ふつうのキーボードを叩くと両手首が極端に曲がってしまう構造になっている。ふつうのキーボードではもう手首が痛いのでKinesisのエルゴノミクスキーボードを買うことにした。日本だと代理店のエジクン総研から買うのが一番安かった。配達も早かったのでオススメ。この画像のときはまだ全部環境揃ってなかったからMBPで最初に試してたのかな。今はふつうに4Kのディスプレイの前で使っている。

ちなみにこのキーボード、いちおうUS配列を謳ってはいるが、通常のUS配列とは全くの別物で慣れるまでに1週間以上かかると覚悟したほうがよい。仕事で使う場合は、少なくとも3日ほどは練習期間に充てた方がよいだろう。いきなり仕事で使おうとすると、Typoばかりで（自分が）使い物にならないので注意が必要だ。しかし10年以上も使い慣れたものとは全く異なる配列に挑戦するのは、脳の普段使ってない神経をこじ開けていくような気分がしてとても新鮮だった。人間慣れすぎてしまうのもよくない。

マウス

G700sってかいてある。まあこれはあまり使わないので別に何でもよい。スワイプとかXfceにねーし。

椅子

まだ買ってないが、なんかいいやーつがほしい。

まとめ

ちなみに電話会議とかパワポやるときはふつうにMBP使うよ。さて、これでバリバリとErlangを書く！はず…