2017/08/03から2017/08/05までの3日間開催されたbuilderscon tokyo 2017に、弊社エンジニア複数名がスポンサー企業枠または当日スタッフとして参加しました。
以下、
- 気になったセッションのレポート
- The Evolution of PHP at Slack HQ
- 真のコンポーネント粒度を求めて
- Factory Class
- コーヒーカップ裏話
- 当日スタッフ
- 懇親会
について、参加者4名で持ち寄ったレポートをお送りいたします。
The Evolution of PHP at Slack HQ
こちらは田辺がレポートします。普段はGoでSMTPサーバ、HTTP APIサーバ、SQSワーカーなどを書いています。
私が気になったセッションはCarly RobbinsonさんによるSlackにおけるPHPの利用についての セッション “The Evolution of PHP at Slack HQ” でした。
www.youtube.com 余談: Youtubeの自動英語字幕でぜひどうぞ。すごい精度です。
弊社もSlackを利用していますが、その裏側については断片的な情報しか知りませんでした。
この発表では、PHPからHHVM + Hack言語へ完全移行し、パフォーマンスの改善とコードベースの近代化を実現したとのことでした。私の実際の興味はPHPよりもSlackが今、どのような構成なのかがとても知りたくてこの発表を聞きました。
発表やこのレポートを書くにあたっていろいろ調べた結果、PHP（HHVM + Hack）だけでなく、適材適所でGoやJavaを組み合せた設計になっていることがわかりました。
動画の 15:51- では最近の構成図が示されています。また、 Slackのブログ記事や Keith Adams氏によるPodcast でも構成について述べられていました。まとめると、
- Flannel (stateful): エッジロケーション(ユーザーからみて一番近いリージョン)でリアルタイムメッセージング向けのWebsocket接続を終端しつつ、イベントをエッジ側でキャッシュする仕組み。
- 今年になって投入された。
- Goで書かれている。大量のWebsocketの同時接続を終端する必要があるのでまさに適材適所。
- FlannelはさらにWebsocketでメッセージサーバに接続し、リアルタイムにイベントを受信。
- メッセージサーバ (stateful): チャネル内のユーザーへメッセージを配信(複製)する仕組み。
- Javaで書かれていて、in-memoryで複製している。
- 最終的にメッセージはFlannelを通して配信することで、エッジでキャッシュしつつ効率的にユーザーに届く。
- メインアプリケーション (stateless): HTTP経由でAPIを公開していてデータベースへの永続化を担当
api.slack.com- PHP (今は100% HHVM + Hack)で書かれている。
- おそらくほかのビジネスロジックもここにある。
という感じでPHPで書かれているアプリケーションではメッセージの管理（永続化やメンバーの管理など）を担当し、その周りにGoやJavaを使ったリアルタイムメッセージング基盤を整えていることがわかりました。
この設計の範囲では発表などで上げられているPHPの利点は今も妥当だと思いますし、特にHHVM + Hackに移行したことで当面別の言語に書き換える必要性も感じませんでした。
利点についての詳細はぜひセッションやSlackのチーフPHPアーキテクト Keith Adams 氏によるブログ記事 Taking PHP Seriously をご覧ください（氏はHHVMやHack言語の開発者でもあります）。
このセッションを聞いてなお、新規プロジェクトでPHPを採用するかどうかは実行環境としての利点が言語としての欠点を上回ることをビジネス的な視点含めて理解している場合に限られるのではないかというのが正直な感想です。創業者に近い人達は手を動かしてアイデアをすばやく実現する必要があるため、手軽に書けて少々の無茶をしてもリクエスト単位でしか影響がないのは魅力に映るかもしれません。逆にビジネスの基盤がすでにある場合、中長期的な視点でPHP含めGo, Python, Ruby, Node, Java, Scala, C++, C#, Erlang (Elixir)などから広く検討すべきと感じました。もっとも、Slackレベルの規模になれば言語開発者を雇うことでいかようにもできるとは思いますが…。
最後になりましたが、すでにPHPの資産がある人は互換性を維持しつつHHVM + Hack言語へ段階的に書き換えることでパフォーマンスの改善や長期的なコードベースの堅牢化を実現できることが理解できるよいセッションでした。
真のコンポーネント粒度を求めて
こちらは篠原が気になったセッションです。私は主にフロントエンドエンジニアとしてAngularやReactをつかってコンポーネント指向のUIを開発しています。
こちらの株式会社ピクセルグリッド 高津戸さんによるセッション “真のコンポーネント粒度を求めて” では、一般的となりつつあるコンポーネント指向でUIを開発する上で、どのような粒度でコンポーネントを分割したらよいかというトピックが紹介されています。
弊社でも、OOCSSやBEMなどのCSS設計の手法を利用して、WEBページを幾つかのコンポーネントに分割しHTML/CSSを実装することが多くなってきましたが、どのようにコンポーネントを分割するべきかという点で試行錯誤していました。
セッションについて
セッションでは、Atomic DesignとEnduring CSSというCSS設計の方法論が紹介されていました。
違いを解りやすく表すと、以下のような特徴があります。
Atomic Design
- コンポーネントを細かく分割する
- Pages > Templates > Organisms > Molecules > Atoms
- 共通のコンポーネントのセットを作成し繰り返しを避ける
- 繰り返しを避けることで、CSSのサイズを小さく抑えれる
- デザイン→UI実装のウォーターフォールで考えず、それぞれの工程を細かく繰り返す
Enduring CSS (ECSS)
- コンポーネントを大きく分割する
- 共通のコンポーネントは極力作らない
- CSSを修正する影響範囲を狭めることで、修正しやすくする
- CSSのサイズはgzipで小さく抑えることができる
- コンポーネントの分離に重きをおくので、CSSが修正しやすい
言い切ってしまえば、Atomic Designはコンポーネントの抽象度が高く、ECSSは抽象度が低いCSS設計の方法論と言えます。
また、実サービスで上記２つのアプローチを試した経験も話されていました。
Atomic Design的なアプローチでは、膨らむ要望に複雑すぎるコンポーネントを多く作成してしまい、各コンポーネントの深い理解が必要となり開発の負荷が高くなった旨の話をされていました。逆に、ECSS的なアプローチでは、コンポーネントが分離され、複数チームでそれぞれのコンポーネントを担当し効率的に開発できた旨の話をされていました。
所感
私がこのセッションで感じたことは、コンポーネントの粒度は一概には決定せず、プロジェクトに応じてデザインとUI実装を細かく繰り返し粒度を決めることが重要だ、ということです。
ECSSは、コンポーネントの粒度を大きくしコンポーネントの分離に重きを置くことで、デザインの修正を容易にし複数人の開発を効率化できますが、少人数のチームでページ数が多いUIを開発するプロジェクトの場合は、コード量が増えコードの見通しが悪くなってしまうのではないかと感じました。またAtomic Designは、コンポーネントの粒度を小さくしコンポーネントのコードの繰り返しを避けることで、コードの見通しをよく出来ますが、大人数のチームで複雑なデザインのUIを開発するプロジェクトの場合は、デザインの修正が難しくなったり開発者同士のコミュニケーションコストを増やすのではないかと感じました。
つまり、どちらのアプローチを取ろうとプロジェクトの状況次第でメリットにもなりデメリットにもなる可能性があるということです。プロジェクトに応じて、デザインとUI実装を細かく繰り返しながら、両アプローチの良いところを理解して利用してコンポーネントの粒度を決めていくことが必要と感じました。(個人的には、Atomic Designによるコンポーネントの依存関係の複雑化は、CSS Styleguide の自動生成である程度は解決できるのではないかと考えています)
このセッションに参加して、私はEnduring CSSという概念を知らなかったため、よい知見を得ることができました。「知らなかった、を聞く」という機会を与えてくれるbuildersconが開催されたことは、私にとってとてもありがたいことでした。
Factory Class
Shi Hanです。 builderscon tokyo 2017で気に入ったトーク：Jessy Vincentさんの「Factory Class」を紹介したいと思います。このトークは一般の技術トークとは違い、コードの話ではなく、製造に関する話でした。
本業がPerlハッカーのJesseさんは個人のプロジェクトとして、人間工学的キーボードを作りました。そのキーボードが人気が集まり、それが欲しいと思う人が増えてきました。そのきっかけで、大量生産のために、クラウドファンディングによる資金調達し、募集終了時2000台ぐらいの注文を手に入れました。このトークでは、Jessaさんが一台のプロトタイプから大量生産までの経験について語りました。
Coming this summer - Keyboards designed for humans. http://t.co/sDrer6gqQM
— keyboardio (@keyboardio) 2013年4月19日
自分の製品に適している製造業者を選ぶのはものづくりの世界で成功するための第一歩です。Jessyさんはどのように業者を選んだのかをこのトークで共有しました：
- 自分が作りたいもの（Jessyさんの場合キーボード）の製造ノウハウを持っている業者を選ぶのに、Jessyさんが輸入レコード（アメリカでは公開情報です）をもとにし、同じ業界のメーカーはどの製造業者を利用しているのかを参考しながら、業者のリストを作りました。
- 絶対的な規模ではなく、相対的な規模が重要だと言われました。つまり、自分の生産量を対応でき、かつ自分の製品の優先度を高く思っている業者を選ぶことです。特に中国では人間関係が重視されているので、その業者のトップと直接的なつながりを持つことができるのかポイントです。
- 良い業者の見分け方：①必ず現地に行って工場を見学すること。②良い業者が提出した見積書では各パーツ・部品のコストを細かく書かれているらしいです。③アマゾンなどのサイトでその業者が作った製品のレビューを参考したり、同業者を利用したことある友人の話を聞いたりすること（Sneaky referenceと言われます）。
もちろん、製造業者の話だけではありません。入札パケット（bit packet）の作り方も紹介されました。その中に、一番大切な書類は部品表（Bill of materials、BOM）です。製品やパッケージングに使われるすべてのパーツ・材料をBOMに明記するべきです。BOMを作るのにThe Dragon Standard BOMとうGoogle Sheetのアドオンがお勧めされました。また、トークの後半に製品設計から品質管理までの生産製造工程が丁寧に紹介されました。
buildersconの会場で話題のキーボードを試させてもらいました。キーボードの品質と仕上げは自分の期待を超えています。Jessyさんと奥さん二人だけでこんな素晴らしいものが作れたのはとても信じられませんでした。その過程で苦労した点、得られたノウハウを丁寧に報告したJessyさんに感謝します。これからものづくりの世界に足を踏み入れたい人にこのトークをお勧めです。そのほか、より詳細なことはkeyboard.ioのブログとして掲載されているようですので、ぜひ確認してください。
コーヒーカップの裏話
ふたたび田辺です。弊社は会場のドリンクスポンサーもしていまして、Brainf*ckのコードが書かれたコーヒーカップを提供しました。
#builderscon 無限コーヒーありがとうございました pic.twitter.com/WbBpGbkF2D
— Tanabe Ken-ichi (@nabeken) 2017年8月5日
このbfのコードは私が手で書いたもので、実際に実行していただいた方もいたようです。本当に嬉しかったです！
無限コーヒーのコップのコードを実行できました。 #builderscon pic.twitter.com/iNGvaKqBor
— Hiraku (@Hiraku) 2017年8月4日
実のところこのコードは昨年のbuilderscon 2016に向けて仕込んだものでしたが、諸般の事情でお蔵入りしていたのがやっと世に出たものとなります。
これまでbfのコードは「ふーん」という感じで見ていたのですが、急に無茶ぶりをされてしまったので急遽真面目に調べて書きました。 同じ無茶ぶりをされるかもしれない誰かに向けて簡単に解説をします。落ちついてWikipediaの解説を読めば難しくありません。
英語版のWikipediaにはHello Worldを例にした解説があります。つまるところ、ポインターとそれが差す値をインクリメントしたりデクリメントし、その結果を印字することで文字を出力できるのですが、複数のデータポインタを保持することで求めるASCIIコードに一番近いものに対して操作することでコード量を減らすことができます。例題のコード量が少ないのは複数のデータポインターを使用して移動量が少なくなるよう工夫されているためです。
"Hello, world!".scan(/./).map { |a| a.ord } => [72, 101, 108, 108, 111, 44, 32, 119, 111, 114, 108, 100, 33]
ASCIIコードの分布をみると最初の72以外は100台と30台なのでこれに近い初期値を持つようループを駆使して3つのセル初期値を用意しているのです。
といった感じで私はこの例を研究し、これをベースに今回の文字列を出力するように修正を加えました。
そんなこんなで、出来あがったコードが以下でした。
+++++++++[>++++++++>++++<<-]>.----.+.>----.<--.++++++++++++..---.>+.
お粗末様でした。
当日スタッフ
土居です。今回のbuildersconには、Shihanと二人で当日スタッフとして参加しました。
HDEは去年に引き続き今年もbuildersconのスポンサーでしたが、何を隠そう弊社社員の牧がbuildersconの主催です(個人的には、buildersconのスポンサーと聞く度にYAPC::Asia Tokyo 2015の時の社長とのやりとりが思い出されます。 :-) )。
Photo by builderscon / CC-BY-NC 4.0
今回、その主催が諸事情で当日参加できない可能性があったため、海外からのゲストスピーカー対応要員を探していました。そこで、たまたま自分が体験入社記事に少し関わったこともあり、Shihanと共に当日スタッフに誘っていただきました。
普段はMTSという社内勉強会の運営を行なっているのですが、3日開催のテックカンファレンスに運営スタッフとして参加するのは初めてでした。
Photo by builderscon / CC-BY-NC 4.0
受付をやったり、
Photo by builderscon / CC-BY-NC 4.0
ノベルティを配ったり、
Photo by builderscon / CC-BY-NC 4.0
懇親会で部門長のスピーチをスタッフの立場で聞いたり、
その他、当日スタッフ業をその場の状況に応じて臨機応変に行う3日間でした。一参加者として何気なく見ていたバックパネルやノベルティですが、スタッフとして参加することで、それぞれにコアスタッフの方々による準備と情熱や、各スポンサー企業の創意工夫を垣間見ることができました。
また、社内公用語英語化を宣言して久しい弊社ですが、個人的にはゲストスピーカーとのコミュニケーションは、社内で鍛えられた自分の英語力を社外で生かすチャンスでした。隙を伺って話をしてみたのですが、今回痛感したのは、話を掘り下げることができるだけの技術力や知識と、それを表現できるだけの英語力がないと、（特に技術的なトピックに関して）挨拶の域を超えた深いコミュニケーションは難しいということでした。社内では、一緒に仕事をしている分、事前にコンテキストを共有した上でコミュニケーションができるのですが、buildersconが掲げる"Discover Something New"のコンセプトの元で招待されたゲストスピーカーと話すのは、専門とする技術領域も様々だったこともあり、特に難しかった気がします。
Photo by builderscon / CC-BY-NC 4.0
以上、当日スタッフからの参加レポートでした！
懇親会
builderscon 2017の懇親会は、弊社HDEもスポンサーをさせて頂き、乾杯の挨拶も担当させて頂きました。
Photo by builderscon / CC-BY-NC 4.0
懇親会のフードは、🍖(肉)や🍣(寿司)や🍦(甘味)など充実したもので、参加者の皆様も満足して頂けたと思っています。
Photo by builderscon / CC-BY-NC 4.0
Photo by builderscon / CC-BY-NC 4.0
Photo by builderscon / CC-BY-NC 4.0
Photo by builderscon / CC-BY-NC 4.0
なぜスポンサーを検討したか？
単刀直入に言いますと
です。
Python, Go, 英語ができる優秀なエンジニアに懇親会で弊社の名前を覚えてもらいたかったのです。
We are hiring!
As we mentioned, we are hiring!
