ポータブルなWebアプリケーション

140文字で書ききれなかったのでブログに殴り書き。

Heroku のアプリケーションを人に渡す

昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。

対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。

対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかはすべてプログラマブルに構成されていて･･･大袈裟に言ってるけど要するに Bundler に gem 一覧を書いて Procfile にコマンド引数が書いてるってこと (実際は Node.js だけど) になっている。だから、そのソフトウェアを動かすのに「これこれこういう手順で〜」と説明しなくても、"git push heroku master" すれば OK ですよ、で済む。

Heroku を使ったことがある人なら分かる通り、Heroku は git push するだけでアプリケーションのデプロイが可能だが、その都度、内部では新しい環境･･･ コンテナを立ち上げてアプリケーションを構成し直し、準備が整ったら古いコンテナは廃棄され、新しいものがトラフィックを受け取る、という仕組みになっている。

従って、Heroku で動かす Web アプリケーションはこの仕組みで廃棄されたり、新しく立ち上げ直すことができる前提で作る必要がある。必要があるというか、Heroku のアーキテクチャ側から Web アプリケーションをどう構成すべきかということが自動的に決まる。すなわち、アプリケーションがポータブルになるよう構成させられることになる。ただし、Heroku は特にこの辺りで独自仕様を要求してくることはなく、Ruby であれば Bundler や Foreman を、Node.js であれば npm をと行った形で各プラットフォームでデファクトスタンダードな道具を使って構成すればよい。

結果的に、Heroku のアーキテクチャが Webアプリケーションのポータビリティを要求し、それによって、冒頭のケースのように、他人に Webアプリケーションをそっくりそのまま渡すという副次的な利益が得られている。この Webアプリケーションのポータビリティは、そっくりそのまま同じ物がすぐ構成できるということで、例えばサーバーを自動でスケールアウトしたいとか、そういうときに威力を発揮するし、同じ Web アプリケーションを Heroku で動かすのではなく Test as a Service、例えば Travis とか Circle CI のようなクラウドサービスに放り込んでテストしてもらう時の前提にもなっている。

Immutable/Disposable Infrastructure

Immutable Infrastructure、あるいは Disposable Infrastructure という考え方が昨今話題だ。

Webアプリケーションサーバーのように状態を持つ必要がないサーバーは、それが状態を持たないということを制約にし、いつでも廃棄可能であるという前提で扱うと運用コストが下がり、いろんな可能性が見えてくるよという議論。昨今のプロビジョニングフレームワークや DevOps への注目の集まりとか、そういうものの集大成としての概念、ということもあって盛り上がっている。

いま Immutable Infrastructure について議論したり、何かを作ったりしている人たちというのは基本的にクラウドサービスの裏側、あるいは多数のサーバー運用をしている大規模 Web サービスの裏側の人たちが主だったところである。(自分も含め) 彼らには、彼らが日々管理しなければならない大量のサーバーあるいはインスタンスの運用コストを下げることにとても強いモチベーションや経済合理性がある。

一方、単に自分の Web アプリケーションを動かすサーバーがあればそれでいい、というようなもう少しエンドよりのデベロッパーにとってはどうか。まだ、いまいちピンと来ていないかもしれない。そういう人は Immutable Infrastructure 的なインフラが実現された後の世界のイメージとして、Heroku を想像しておけばいい。

Heroku に git push するデベロッパーから見た場合、Heroku で動かしているアプリケーション環境はデプロイの度に廃棄されるし、紛れもなく Disposable Infrastructure である。Heroku のインフラストラクチャが廃棄される前提という制約が、そこで動かす Web アプリケーションにどういう副次的利益を及ぼすかということは先に見た通りである。

Docker

Immutable/Disposable Infrastructure を実現するミドルウェアとして注目が集まっているのが Docker (https://www.docker.io)。Docker は LXC と AUFS を組み合わせて Heroku のような PaaS バックエンド、すなわちコンテナ型の仮想環境をカジュアルに運用維持できるようにするソフトウェアだけれども、最近 RHEL に搭載されたかと思いきや、つい昨日、Google Compute Engine が一般公開とともに Docker サポートを発表 したりして、非常に勢いがある。Docker 面白いなと思っていた自分も、まさかこんな勢いで普及するとは思っていなかった。

Docker の重要な特徴に、Docker コンテナとして構築したアプリケーションは、そのままイメージとしてエクスポートして別のホストに持っていって、Docker コンテナとしてそっくりそのまま再度立ち上げることができる、というものがある。これも Immutable/Disposable Infrastructure の文脈で語られる機能というか、その辺の制約が前提となって実現された機能である。

Google Compute Engine のような大規模クラウドプラットフォームが Docker をサポートしたということは、例えば自分の手元の OSX 内の Vagrant で立ち上げた VM で動いていた Docker コンテナを、ある日大規模計算リソースが必要になったからとかそういう理由で、Google のクラウドに移して動かすなんてことが、デベロッパから見た場合にほぼノーコストで実現できる、ということである。これもアプリケーションのポータビリティという文脈で考察すると色々と面白い。単に自分のアプリケーションの動作環境をスケールアップということに留まらず、他人にアプリケーションを配布するとか、Test as a Service その他よりレイヤの高いクラウドサービスに放り込むとか、いろんなユースケースが考えられる。

Webアプリケーションを配布する ･･･ Movable Type

ところで、Webアプリケーションを配布するというと自分が思い出してしまうのは、10年前のブログブームの火付け役になった Movable Type というブログツールである。Movable Type は Perl で書かれたサーバーインストール型のソフトウェアで、ダウンロードして自分のサーバーに自ら設置して動作させる必要があった。当時は周囲のブログツールに比較してずっと高機能かつ洗練されていたので、Movable Type を動かしたいがために、慣れない Linux サーバーと悪戦苦闘するエンドユーザーが大勢いた。

Movable Type よりもずっと前から、例えば掲示板やアクセスカウンターのようなスクリプトなんかをインターネット上で配布して、「プログラムは配布するから自分で設置設定して自分の計算機リソースで使ってね」という形でアプリケーションを配布するという形態は良くあった。良くあったけれども、Movable Type はそれらのプログラムの配布が簡単であろう一枚岩のスクリプトに比較するとずっと複雑且つ高機能で、中にはデータベース関連、テンプレートエンジンその他多種多様なライブラリなんかも含まれており、最初にみた印象としては「こんなに大きなプログラムを配布してもいいのか」と驚いたくらいで、その他の類のものとは一線を画していた。Movable Type は高度なアプリケーションにも関わらずダウンロード配布型のソフトウェアであることを維持するのにそれなりの開発コストを支払って、それを実現していた。

ただ、当然の流れだけれども、設置にはサーバーは必要だし実際動かすまでに色んな苦労があるしで、多くのユーザーはその後あちこちで立ち上がったブログサービス、つまり SaaS 系のサービスに移っていった。

この時自分が思ったのは、配布型の Movable Type をそれぞれ自分の計算機リソースで動かすというのは責務や負荷の分散という意味ではよりWeb的な分散の考え方だけれども、エンドユーザーが支払うコストが大きすぎるので、そのコストを一手に引き受けましょうというのがブログサービスだということだった。多数のユーザーそれぞれが支払っていた小さなコストをまとめて一手に引き受けるわけだから、そのコストもそれなりに大きなものになるのは当然で、それがサーバーリソースに過負荷をもたらして、サーバーが落ちたり、ストレージが壊れたりで大障害になるという話も後を絶たなかった。分散から集中を行った結果のトレードオフである。

分散から集中、集中から分散へ

分散から集中とくれば、次は集中から分散である、というのはこの分野のセオリーで、じゃあいつどういう契機でこれがまた分散型の考え方に移行していくのかなとこの10年生暖かくみてきたのだが、ここでようやく冒頭の話と繋がって、いままさに盛んに議論されている Immutable/Disposable Infrastructure が、集中から分散へのきっかけになっていくのではないかと思った、というのが本エントリで言いたいことであった。やっとここまで辿り着いた。

もちろん、Immutable/Disposable Infrastructure は、前述のとおりクラウドプロバイダ、大規模Webサービスプロバイダのような集中側の世界で議論されているしその達成主眼がそこにあるのは間違いない。一方で、Heroku が Webアプリケーションのポータビリティを強制することによって、それが副次的に第三者とのアプリケーションの交換を可能にしたのと同じように、廃棄可能なインフラストラクチャを追求していった結果、まるでデスクトップやスマートフォンのアプリケーションを配布するかのように、Webアプリケーションを第三者に配布し、エンドユーザーはそれを自分の好みの好きなクラウドプラットフォームにデプロイして使う･･･というような世界がいずれ実現されるかもしれないな、ということを妄想したりしている昨今で、例えばこのまま色んなクラウドプロバイダが Dokcer をサポートしていったら･･･そういうことは容易に想像できるのであります。

･･･どうやら、140文字で書こうとして書き始めたら 5,000 文字になっていたようです。

iPhoneで今みてるページのはてなブックマークコメントを見たい、でも見られない。そんなときありませんか。私はあります ─ HBFav 2.5 をリリース

HBFav をバージョンアップ、2.5 をリリースしました。既に App Store でダウンロード可能です。iOS 7 なら放っておいても新しくなるはず。

今回のアップデートは二点

  • ペーストボード (クリップボード) にコピーしたURLを HBFav で開く機能の追加
  • タイムラインで追加の新着取得時にうまくいかない不具合の修正

です。主には前者ですね。

こんな感じで、HBFav を開いたときにペーストボードに URL があると、それを開くかどうか聞いてくるようになりました。

どんなシチュエーションで使う機能なの?

想定ユースケースを再現してみましょう。

ある日 Twitter なんかで拡散されてきたページを Safari で開いてみました。

なにこれウケるんですけど。

ブコメ (はてなブックマークのコメント) では何て言われてるのかな〜。と気になってきます。ウズウズ。こんなときは、おもむろにコンテキストメニューから URL をコピー。

右下の「コピー」ですね。

そして、HBFav を立ち上げる。ホームのアイコンから開いてもいいし、アプリの切り替えでも良いでしょう。

すわっ

HBFav が開くと、上部にいまコピーした URL を開くかどうかの案内が出てきます。これをタップ!

あら不思議。HBFav 内のブラウザが立ち上がって、さっきのウケるページが表示されたのでした。287 users。

コメントワロタ。

こんな感じです。もちろん、コメントを確認するだけでなく、はてなブックマークに保存したり、Pocket に保存したり、あるいはブックマークついでに Twitter や Facebook に拡散したり、ということも可能です。

自分の場合主に Twitter を見てて開いたページを HBFav で開きたい、と思ったことが頻繁にあってそのたび苦痛だったので、本機能を実装するにいたりました。

次のバージョンなど

もう一点の不具合修正は、ただのバグフィックスなのではありますが、タイムラインで追加のエントリを取得する際「ブックマークをもっと見る」をタップしても想定通りに動かないという頻出バグの修正でした。ずっと直さなきゃなあと思ってたものだったので、スッキリしました。

続くバージョン 2.6 の開発も行っていまして、8割方完成してます。次のバージョンではタイムラインを自動でひっぱって更新しなくても適当なタイミングで新着ブックマークを取得してくるようになります。自画自賛ですが、かなり良い感じです、乞うご期待。

12月は中旬くらいから iOS アプリの審査等々がお休みになるため 12 月の間にリリースできるかどうか、というところです。なるべく出せるよう頑張ります。

では引き続き HBFav をご贔屓に。

「書く」のは特別な道具

This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。

コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。

今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが全体を通して言いたいことです。

〈書き言葉〉は自分の心の中に降りていくための道具

また吉本隆明から引用する。

〈書き言葉〉は自分の心の中に降りていくための道具

ふだんはまったく意識してないと思うけれど、書くことと、話して相手にそれを通じさせようとすることはまったく別のことなんですよ。〈書き言葉〉っていうのは、何か得体の知れないところがある。書いてみると、自分でも気がついていなかった自分自身の気持ちがわかることがあるし、それをもっと深く掘り下げていくこともできる。〈話し言葉〉が相手に何かを伝えるための道具だとしたら、〈書き言葉〉は自分の心の中に降りていくための道具だといってもいい。

『ひとり 15歳の寺子屋』より。

もうこれだけで自分の言いたいことを言い切った感じもあるけれども、この手のことを言っているのは何も御大だけではなくいろんな作家のエッセイ、あるいは知的編集がどうこうという本でも似たような記述を良く見る。

よく自分が何をしなければいけないかを整理するのに、とにかく自分のやるべきことを文章にして書き出せみたいな話があるけれどもその手の How To の有効性も、ここに通じるのだと思う。

なぜ書くということがそういう性質を持っているのか、というのはいろいろな要因があると思うけれども、ひとつには、書く行為には今自分で考えたことを文章という形で外部化し、それを足がかりに次の思考のステップへ進むということを強制する側面がありそれが大きいと思っている。つまり、書く行為は思考過程の不確実性みたいなものを最小限に留めながら物事を考えるフレームワークになっている。

コードを書いている最中に解決策が思い浮かぶ

プログラミングをしていると、コードを書くまでは全く思いつかなかったようなアイデアや解決策が次々と思い浮かぶ、なんてことが本当に頻繁にある。これはプログラマなら誰もがそういう体験をしたことがあるはずだ。

コードを書きながら考えるということが創造的なソフトウェアを作るということとどういう関係があるかなんてのはあの『ハッカーと画家』にも書かれていて、それに感化されて自分も昔 http://d.hatena.ne.jp/naoya/20050518/1116425594 なんてエントリを書いた。(そして若気の至りで dis を加えたためにちょっと炎上した)

この、コードを書きながら初めて解決策が思い浮かぶ･･･みたいなことと、先の文章を書くことで新しい発見があるということは良くにている ─ と思っている。プログラミングにおいてはコードという形で思考を外部化し、文章の場合は自然言語というかたちで外部化する。プログラミングにしても自然言語にしても「言語」には本来的にそういう機能がある、ということなのかもしれない。

メモ魔

冒頭の話に戻ると、そんなことから自分も、少し時間のかかりそうな作業だとか手間のかかる問題解決をするときはエディタを立ち上げて、そこに自分の思考過程みたいなのをメモしながら進めていく。それが、自分の場合は割り込まれたときに作業を再開したいためというよりは、自分自身の思考の整理のためにそれをしているという側面が強い。

例えばちょうど最近また Docker を触っていたのだけど、そのときのメモの一部はこんな感じになっていた。

% docker export cbe3fe76c418 > files.tar
% cat files.tar | docker import - naoya:test
　
・そもそも commit ではファイルシステムだけが commit されるんだっけ?
　- プロセスの実行状態も含めて commit できたと思ったんだが･･･
　
・さすがにそれは思い込みっぽいか
　- http://d.hatena.ne.jp/naoya/20130620/1371729625
　- Dockerfile で CMD ["/usr/sbin/sshd", "-D"] とかしてるし
　
・Q. Docker の中のコンテナって最低限のサービスも動いてないんだけどこれで
　- 長時間運用できるのけ?
　
・とりあえずファイルシステムを export して import すれば virtualbox <=> AWS の交換は可能なのは分かった
　- OS 違ってていいのか、は謎

...

後から読み返すとバカみたいなのだけれども、思考の「過程」なので、これでよいのである。

ちなみに自分は会議の際も、自分がファシリテーター役になるようなときはモニタにエディタを映し出して発言を書いて整理しながらミーティングを進める。こうしておけば、後々議事録を書き起こす手間も必要ないし、なにより会議の話題が発散しなくていい。言ってみれば、普段自分がデスクトップ上でやっていることを、会議という場で実践しているだけでもある。

Google の DesignDoc

最近あまり話題にならなくなったけれども、Google には、エンジニアが何かの設計や実装に取り掛かるにあたって書くべき DesignDoc と呼ばれるドキュメントフォーマットがある (あった?) そうだ。詳しくは Google の Design Doc について - フリーフォーム フリークアウト のエントリなどに書かれている。

ソフトウェアの変更の背景だとか設計や変更の概要、セキュリティ的な懸念点などをペライチのドキュメントにまとめましょうみたいな話なのだけれども、面白いのはこの文書は他人と共有するのももちろんその目的の一つだけれども、より大きな目的として、作業するエンジニアの思考整理のための道具として活用されている (いた?) ということだ。

書いてみて初めてわかることがある。いきなりコードを書くんじゃなくて、それを事前に文章として書いて整理することで、自分でも気づいていなかった懸念点、課題、解決策を整理してから作業に取り掛かりましょう･･･ そのためのドキュメントである、ということらしい。

DesignDoc の仕組みは必ずしも万能薬ではないというか、うまく回ってない箇所もあったという話を聞いたことがあるのだけれども、少なくとも過去に自分が会った Googler の人は DesignDoc は非常に重要だと語っていて、エンジニアがドキュメントを書かされてしんどいみたいな話ではなく、自分の仕事を助けるためのツールとして DesignDoc という仕組みはとても良いと思うと評価していた。ただ、その良さがどういう良さなのかはなかなか外の世界には伝わらないみたいで、WebKit プロジェクトで Googler が DesignDoc を書くことをさも当然のようにしていたら他陣営からツッコミが入ったとかそんな話もあったらしいが。

過去に自分の仕事でも DesignDoc を真似てプロジェクト開始時に必ず似たようなドキュメントを書くようにしてみたが、その仕組みはとてもうまく回っていた。プロジェクト内容を本人が整理するためにも良かったし、プロジェクトのレビューを依頼される側としてもやりやすかったし、他チームに各プロジェクトの概要を伝えるのにも良かった。良いアイデアとは複数の問題を一度に解決するアイデアだ、なんていう話を思いすところである。

テストを「書く」という行為

自分の思考を先にアウトプットする、という観点でいくとテスト駆動開発なんかもこの文脈で考察できるところがあると思う。

テストを先に書いた方がインタフェースが綺麗になるとか、モジューラビリティが高まるとか、いろいろ。最近、ソフトウェアの自動テストといえば BDD スタイル (RSpec みたいなの) が主流だけれども、先に自分がエディタにメモしている･･･みたいな行為が、そもそも spec ファイルに書くことがそれに相当しているなんていうプログラマも結構いそうだ。

自分はそこまでテストエンジニア力がないので、いきなりテストでやりたいことを表現するというレベルにはなかなか到達できそうにない。

何にしてもテストを書くというのもまた、思考を整理するためのフレームワークになっているところがあると思われる。

チームでの共有

作業記録、DesignDoc、テスト、なんでもそうなのだがそうやって思考の整理のために書いた文書を、そのまま自分の引き出しにしまっておくだけというのはちょっと勿体ない。

You、せっかく書いたのだから共有しちゃいなよ、というわけだ。

先日 Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー の中でも触れたのだが、自分はそういう文書をなるべくチームや組織で共有するということが、組織を運営していく上で長期的にとても重要なことだと思っている。そのための道具として、自分がはてなにいたときははてなグループがあったし、最近は(まあいろいろ不足してるところもあるのだが今後の期待も込めて) Qiita Team を使っている。クックパッド社には元技術部長が作ったグルーパッドというのがある、というのは今月の Web+DB PRESS に書かれている。

後からの検索性、ナレッジシェア、透明性の確保などいろいろな効果があるけれども、それを当たり前にやれている組織とそうでない組織というのを幾つか見てきて、やっぱり、当たり前にやれているチームほどチーム内の暗黙知は少なくそれでいてストロングカルチャーを持っているような、健康状態の良いチームを維持できているように感じた。

そんなわけで、自分が理想とするチームでは、みんなが自分の思考の整理のためにドキュメントや振る舞いベースのテストを書いていて、それが共有されていて、共有されているといっても単に Wiki に置かれているとかではなくフィードのような形で自分の手元に配信されてくる、そういうことが当たり前に行われていて欲しいと思っている。これ、やってみるとわかるのだが、当たり前の状態にするまでには結構苦労が要るのでチームが小さなうちから実践しておくということが非常に重要だ、とも思っている。

以上、すこしとりとめのない話になってきたが、何にしても、「忘れないために書く」ではなく「考えるために書く」ということ。そして書いたからにはできれば共有する。そういうことを続けて習慣化していくと良いだろう･･･と常々思っていて、ここまで長々と書いているとおり、それはちょっとやればいいんじゃないかな程度のものではなく、自分はそういうことに強くこだわりを持っている派であります。なかなか口頭でこれを伝えるのは難しいので、これから先に一緒に仕事をする人が運良くこれを読んでくれることも期待しつつ、ここに書き残しておく。

そしてこのエントリを書く、ということを通じて、自分の中でもこんな風に考えていたのだなと整理されたというオチがついてくるのである。

HBFav を 2.4 にアップデート : iOS 7 対応

HBFav を 2.4 にバージョンアップしました。今回のバージョンアップは新機能はなくて、iOS 7 への対応が主です。

これまでも iOS 7 でも特に問題なく使えていましたが、インタフェースは iOS 6.1 互換のものでした。今回から iOS 7 を使っている場合は、フラットデザインになり iOS 7 前提のインタフェースになります。やっぱり、OS 側と歩調があっていたほうがいいですね。




その他、細かな調整事項などは以下の ChangeLog を参照してください。

引き続き HBFav をどうぞよろしくお願いします。

Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー

先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。

自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。

KAIZEN platform

KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう時に使うもの。

システム構成は大きく

  • A/Bテストの設定をしたり結果を受け取ったりするための Webアプリケーション
  • JavaScript のビーコンからログを受け取って格納して計算したりするログシステム

の二つに分けられる。

Webアプリケーションは Rails + JavaScript で、ログ周りも基本 Ruby で書かれている。インフラはすべて AWS に置いていて、社内には開発用のサーバーも含め、物理サーバーは一台もない。ビーコンはクライアントの Webサイトに貼り付けられて、その1HTTPリクエスト毎に planBCD のシステムにもアクセスが来るので、バックエンドはそれなりにスケーラブルに構成される必要がある。

Github と Pull Request ベース開発、テスト自動化

この辺をどうやって開発しているか、というのをざっくり一言でいえば「Github を使って Pull Request ベースでスクラム」みたいな感じだ。Rails のコードも JS のコードもすべて Github のプライベートレポジトリに置いている。

Pull Request ベースの開発は、最近クックパッドの id:secondlife の発表なんかでもあった。これとほぼ同じやり方である。


ソースコードへの変更は基本的に、Pull Request を通して行う。リモートブランチに直接コミットしたり、ということはしない。そして、本体にマージする前にかならずその Pull Request のコードレビューを行う。コードレビューってどうやったら続くんですか? みたいな話がよくあるけれども Pull Request はレビューが間に挟まることが前提になっているので、Pull Request ベースで開発すると自然とレビューするような流れになる。

コードの変更に対してはすべてテストを書いていて継続的インテグレーション (CI) している。CI には Jenkins ではなく、CI as a Service な Circle CI を使っている。これは、プライシングその他の理由でビジネス用にも使い易い Travis CI みたいなものだと思えばいい。git push の度に Circle CI が Rails 用のコンテナを立ち上げてインテグレーションテストを実行し、何かあったら通知が飛んでくる。

このテストを書いて CI して、Pull Request でコードレビューして･･･というやり方は、前回の YAPC::Asia の感想エントリでも書いたとおり、Web開発のベストプラクティスとして現場に根付きつつあるやり方だ。ただ、トレンドだからこういうやり方をしているというよりは立ち上がったばかりのスタートアップで、スピード感は必要なのに人はいないと、そういう中でどうするべきかというときに必然的に辿り着いたのがこのやり方だった･･･というのが実感として面白い。

テストを自動化しておけば何かのリリースの度に人手でテストをする手間を省けるし、コードレビューをすることでバグを未然に防いだり設計がおかしなものがそのままマージされるリスクを減らせる。サーバーを自前で運用するのにも人的リソースが要るし･･･というので AWS や Circle CI のようなクラウドサービスを積極的に使う。たぶん、昨今のスタートアップでエンジニアリングを真面目にやろうとしている企業は、どこも同じような結論に達しているのではないかと思う。

この開発フローで、エンジニア数名で開発していっている。

エンジニアのコミュニケーション

KAIZEN platform が少しユニークなのは、リモート環境で関わっている人が結構多いというところだ。社員のエンジニアはもちろん、一緒に開発している協力会社 (ハートレイルズさん) もいるのだが、そのあたりも基本リモートでやっている。このとき彼らも Github と Pull Request とコードレビューのサイクルの中にいて、協力会社というよりほぼ同じチームという感覚で開発できているのがちょっと面白い。

そしてリモートワークとはいえ、スクラム的な、ある程度短い期間を切ってのイテレーションをちゃんと回そう･･･ということでJIRA と Greenhopper を使ってカンバン形式でタスクとストーリーの見える化を行っている。この辺はいろんなツールがあって激戦区だけど、社員の坂田さんこと @sakatam が JIRA を使い慣れていたということで、彼がスクラムマスター的な役割も担いつつでの導入となった。

写真はエンジニアのスタンドアップミーティング･･･って座ってるのでスタンドアップじゃないけど、それに相当するミーティング。こんな感じで Google Hangout で顔を写して会話して、画面共有で JIRA のカンバンを見ながらスプリントを進める。モニタには Apple TV が繋がっていて、画面に何かを映したいときは AirPlay で飛ばす。

普段のエンジニア同士のコミュニケーションは HipChat を使ってチャットで行い、チャットで流れて困るようなドキュメントは今のところ Github Issue にまとめたりしている。

なんとなく、スタートアップ的なスピード感が伝わってるだろうか。

これからの課題は、基本的な開発プロセスは回っているのをどうより効率化していくか、一方で速いスピードに対して中長期ロードマップをどのように組み立てていくか、DevOps 的な部分や手元の開発環境の整備みたいな後手に回りがちなところ、あたりである。その辺を一緒にやってくのが自分の仕事だったりする。

Qiita (インクリメンツ)

次は Qiita や Qiita Team を作っているインクリメンツ社。インクリメンツ、というよりも Qiita という名前の方が馴染みが深いのではないかと思う。サービス内容については、まあこの blog を見てくれる人たちには説明不要だと思う。

インクリメンツもやはり、まだ人数数名のスタートアップというところ。Qiita はもともと CEO の yaotti (･･･ 彼は元々ぼくがはてなにいた頃にインターンに来て知り合ったので、呼び捨てである) が一人で立ち上げたサービスだったが、徐々に大きくなって社員数名を雇用するまでになった。立派だなと思う。

こちらオフィスの様子。ここは元々、今は mixi で COO をやっている id:kawasaki の kamado 社のオフィスだった場所。

Qiita も、Rails で書かれていてサーバーはすべて AWS にある。またランディングページそのほかの Qiita 本体ではないところのサイトを動かすのに Heroku も利用していると言っていた。オフィスの中にはやはりサーバー類はない。

Github、Circle CI、Pivotal Tracker …

Qiita の開発も、Github を使った Pull Request ベースの開発によって行われている。緊急の修正とかそういうのでない限り、基本は Pull Request を飛ばして、誰かがレビューしてその上でマージするそうだ。コードレビューの担当は誰というのは特に決まっておらず、誰かが自発的にレビューを行うというのでいまのところは回っている。ただ、場合によっては各々自分のタスクに集中して未レビューのパッチが溜まってしまうことが時々あるそうで、その辺は今後の課題ということだった。

Pull Request ベースで開発している、ということもありテストはしっかり書いている。特に Rails アプリケーションのモデル周り。決済など、バグ混入が怖い部分はコントローラも含めより念入りにテストしている。最近は capybara-webkit を使っての E2E テストも書くようになった。

テストの CI はインクリメンツもやはり Circle CI を使っている。Jenkins を動かすとそのために運用するサーバーが最低一台は増えてしまうので、やはり小さなスタートアップでは極力それを避けたいというのもあるだろう。同じような理由で、* as a Service 系のサービスをいろいろと積極的に使っていて、Rails アプリケーションの監視と数値化には NewRelic を、例外発生時のバグレポートには Sentry、ユーザーサポートには zendesk を･･･という具合だ。

タスク管理はストーリーベースの Pivotal Tracker。最近の Web 開発によくある「ゆるいスクラム」的なものをこれを使って回している。ミーティングはスクラム的な文脈の短い朝会を毎朝 10:00 からやって、週一回の定例にあとは金曜夜に振り返り的なゆるいミーティングだけで済ませているそうだ。自社サービスを開発運用し続けていく SaaS サービスの開発現場では、こんな風にスプリントミーティング的なきっちりとした感じではなくゆるく繋がるミーティングを続ける、というのもよくある風景だと思う。

Qiita Team

社員同士のコミュニケーションは HipChat によるチャット、それから自分たちで作っているサービス Qiita Team。チャットだけでは流れがちなストック寄りのコミュニケーションは、仲間内だけで使える Qiita 的なこの Qiita Team に書き込む。日報とかも。いわゆる、自分たちのサービスを自分たちで使ってという Eating our own dog food というやつですばらしいと思う。

ちなみに、自分ははてな在籍中は Qiita Team がカバーするのとよく似たツールのはてなグループ を使ってこの辺の情報共有や連絡そのほかを行っていたけど、これはエンジニアの仕事ととても相性がよい。作業記録とか、アイデアとか、この処理はこう書いた的なことを何でもいいからどんどん書き込んでいくと周囲のエンジニアからスターがついたり、コメントがあったりでフィードバックが返ってきたり、後から検索できたり云々。まもなく発売の Web+DB PRESS Vol.77 にはクックパッドの開発現場での情報共有についての特集記事があるらしいが、クックパッドでも同じようなツールを内製して･･･というか、はてなから転職したエンジニアがはてなグループがないのを苦にしてオリジナルのそれを開発したと言っていたし、その辺の話も載っていると思う。

そして同カテゴリのサービスになる Qiita Team に関しては Increments は和製 GitHub の夢を見るか？ この辺りのエントリも詳しい。

話がそれた、インクリメンツの話。

Boxen

最近エンジニアが増えてきたこともあって、各エンジニアの手元の開発環境をどう整えるかというのが課題になってきたそうだが、最近 Boxen を導入して解決したそうだ。Boxen は Github の中の人が作った、ローカルマシン用のプロビジョニングツールみたいなもので、これを使うと各開発者の OSX のソフトウェアセットアップを (内部では Puppet が動いて) 自動化且つ共通化できるので、各種ミドルウェアのバージョンを統一できる。

KAIZEN もそうだしインクリメンツもそうだけど、人も少ない、お金もまだ無駄遣いはできない、あれもないこれもないというスタートアップでは日々の仕事で無駄なことが発生するとその分会社全体のパフォーマンスが目に見えて落ちるので、やらなくていいことはやらないように色んな工夫をする･･･というかせざるを得ない状況にある。そういう状況が、こんな感じのやり方、開発プロセスに行き着く理由のひとつだと思う。

じげん

最後に紹介するのはじげん の例。

先の二つは立ち上がって間もない、その名のとおりスタートアップなベンチャー企業だったが、こちらのじげんは設立は 2006 年で社員も結構いるしで、ベンチャー的な雰囲気は残しつつもスタートアップのフェーズは追えて拡大期に移行しつつある。事業は求人系や賃貸系の複数の情報サービスを、Webサービスとして提供するのが主なところ。

KAIZEN やインクリメンツは最近起業したばかりでまだ人数も少ないということで、いろんなプロセス、ツールが新しい。一方のこちらは、すべてのアプリケーションを Rails で書いているとはいえ、一番古いサービスの Ruby のバージョンは 1.8 で、Rails に至っては 1.2 とかそんな具合だ。本当はこれらを Ruby/Rails のバージョンアップに合わせてバーンアップさせていくべきだったのだろうが、テストも書いていなければ、その作業に割り当てるエンジニアもいなかった･･･ということで気づけば「レガシーな Rails アプリケーション」を抱えることになってしまった。

これまでの文脈から一転して、じゃあなんでこの会社の例を紹介しようというのか。そういう状況から色々プロセスに手を入れていって、良いやり方に移行していっているという例だからである。今は Rails 4 を使って、ユニットテスト/E2Eテストを書いて Jenkins で CI し、Github 上でコードレビューを行ってデプロイ。それからサーバーのプロビジョニングは Chef で･･･など DevOps も含めて、開発フローが確立されつつある。ほんの半年ちょっと前まではこのどれも行われていなかった。

多分、スタートアップが新しいやり方、新しいツール、建前より本音を優先するスタイルみたいなことを実践できるのはスタートアップだからであり、そうでない立場にいる人からは別世界の話のように聞こえると思うが、一方のこのじげんに関しては、そうではない、比較的よくありそうな課題群から出発しているという例に見えるだろう。

エンジニアは今は十数名。だいたい一つのサービスにつき 2〜3人くらいのエンジニアがアサインされて、開発を行っている。開発プロセスの改善に手をつけるまでは、各サービスのエンジニアがそれぞれ独立して自分のサービスを開発していて横串でそれらのやり方を標準化したりといったことはあまり行われていなかった。また、自分のサービスのインフラは基本そのサービスのエンジニアが片手間で運用していて、専門の運用部隊はいない。だから、どのサービスでどういうサーバー設定が行われているか全体を把握している人はいない･･･みたいなそんな状況だった。「あ〜、あるある」なんて声が聞こえてきそうだ。

そういえば先日 DevOps Day Tokyo でクックパッドの mirakui さんが発表されていて (発表の内容は http://www.publickey1.jp/blog/13/devopsdevops_day_tokyo_2013_2.html この記事なんかにある。必読)、その途中のスライドにこんな画面があった。

じげんが置かれている状況というのは、だいたいこの、mirakui さんが入った前後のクックパッドの当時の状況によく似ているのではないかなと思う。つまり、ここから開発標準や体制を整えていき、今後の事業の拡大や開発の複雑性増大に対して備えていきたい･･･そういうフェーズ。

Github の導入から

そんなわけで、横串での開発プロセスやインフラ運用方法を新しくしていきましょうと手を付け始めたのが半年とちょっと前。

最初は課題整理をして、現状把握をし、それをどんなやり方にしていきたいかというディスカッションをした。そのゴールイメージを作るのはそんなに難しくない。昨今では同じような事業をやっている他者の開発体制の情報が、このクックパッドのスライドのように公開されているから、なんとなく、こういうのが今どきのやり方だろうねという共通理解が最初からみんなの中にあった。

で、まずはどこから手をつけましょうかということで Github を導入した。少し前に開催したはじめるDevOps という勉強会でじげんのエンジニアリーダーの浅沼さんが当時の様子を話していたけれども、期末か何かの全社ミーティングで新しい開発プロセスのロードマップと、それに伴ってまずは Github を使い始めます･･･という話をしたら嬉しくなった現場のメンバーから握手を求められたとかそんな話をしていたのが印象的だった。

テストとコードレビューの習慣化

次はやはりテストを書く習慣を作りましょう、という話になっていく。当然、最初はどういうところをどのぐらいテストすればいいのか分からないという状態が続く。ただ、コツコツとやっていきつつ「カバレッジ 100%は目指さない」とか「モデル周りを重点的に書いて」とか「とりあえず最初は書きやすいところ、すぐに書けそうなところから」みたいなベストプラクティスを吸収していくうちに、なんとなくコミット毎にテストを添付するみたいなことができるようになってきた。

そして、コードレビュー。

インクリメンツもそうだし、id:secondlife のクックパッドのプレゼンでもそう言っていたが、この両社なんかはレビューが各チーム内で自発的に回るような空気作りができている。でも、まったくコードレビューをやったことがないチームでは、Github を渡したからといっていきなりレビューし始めるなんてことは当然おこらない。この辺は、YAPC::Asia での HIROCASTER さんの発表 GitHubでつくる、たのしい開発現場 なんかを見てても、それが根付くまでの段階があるというのがよく分かる。

ところで、コードレビュー、というとだいたい品質を保証するとかバグをなくすとか、そういう実利的な部分にばかり目が行きがちなので、ついつい、ベテランのエンジニアや要件をよく知っている人がレビュワーを担当するのかな? と考えてしまう。そういう忙しそうな人にレビューをしてもらうとか、そういうフローを回して貰うコストをどうやって考えたらいいのか、云々･･･。

だがしかし、実際にはコードレビューは「自分が書いたコードを誰か他の人に見てもらえる/見られる」という状況そのものが一番重要だったりする。つまりレビューをしてくれる相手はベテランでなくても構わない。

よくよく考えてみれば、コードレビューというフローがなければ、自分が書いたコードなんて有事の際以外にはなかなか他人が見るなんてことはない。それがそうでなくなるというのは、それだけで大きな変化だし、そこから「人が見るなら綺麗に書いておこう」とか「新人が見るのにひどいコードのまま push するわけには」とか「こんなコピペしてたら絶対指摘されるよなあ」みたいな心理が生まれる。その心理を生み出すことが大切で、品質保証やバグ解消なんかを主目的にするのはその次の段階でもいいと、個人的には思っている。

そんなわけで、じげんではどうしたかというと、コードレビューの担当を日替わり交代制にした。これは自分が以前にいた会社で、ユーザーサポートから依頼のあった対応案件をどのエンジニアが対応するかというのを日替わりで回すのでとてもうまく回っているのを思い出して、レビューもそうしてみたらどうか、という話から出たアイデアだった。これは思いの他うまく機能したそうだ。

習慣化のための道具

せっかくテストを書いてコードレビューをするというフローを始めたのだから、やるのであればそれもなるべく正しい方法でやりましょう。ということで Github で Pull Request を基本にし、Jenkins で CI が回るようにあらかじめプロジェクトをセットアップして各開発者の端末には Jenkins Notifier なんかを入れて、とかとか、周辺環境も整えていった。

いや、むしろテストやコードレビューを習慣化させるために Github + Pull Request や Jenkins があるというのが実際のところだ。やり方だけみんな知っていても、それがワークフローとして確立していなければ長く継続するのは難しい。コードレビューだって、レビューをすることにはこんなに良い効果があるって、Google とかの話が聞こえてきたのはもう何年も前だったけど、最近になってようやく巷の Webサービスの開発現場でそれが無理なく定着してきているのは Github というそのワークフローを実現するための道具が手に入ったからだと思う。

結果として、この半年間で見違えるほど開発の中身が見える化されて、最近では浅沼さんをして「Pull Request / レビューなしの開発はあり得ない」といわしめるほどになった、とのことです。

この開発フロー、新しいサービスでは Rails を含め新しいからやりやすいのだけど、後ろのシステムがレガシーだとなかなか適用が難しかったりする。そこをどう解決していくか、一部の取り組みを全体に拡大していくまでみたいなところが今後の課題。とはいえ、ちゃんと正しいやり方で開発を進めるんだというカルチャーの火種はできあがったので、いろいろ困難はあると思うけど、それが全体に浸透していくのは時間の問題だと思う。

まとめ

長くなってしまったけれども、KAIZEN platform Inc.、インクリメンツ、じげん三社のWebサービス開発現場からでした。自分でも書いてみて良く分かったけど、やっぱり Github + Pull Request + コードレビューというのがどの会社にも共通して、開発プロセスのデザインの根幹になっているなと思いました。

Github といえば、前回 YAPC の感想に合わせて

事実、かつて当たり前のようにスタートアップが Rails を採用することがニュースになった時と同じように、昨今のスタートアップは当たり前のように Github でコードをホストして、テストを書いて、Pull Request をして CI をするようになってきている。これはサービス開発の現場に定着していくやり方になると思います。

てなことを書いたけれども、具体的にそれがどういうことなのか、というのを知って貰うのにちょうど良い例というのが、そもそもこのエントリを書くきっかけではあったわけです。(もちろん、自分の携わっている2社、それから個人的にがんばってほしいと応援しているインクリメンツの知名度向上に貢献したいというのも理由の半分以上ですけどね。)

そのほかの事例も知りたいなあという人は、エントリ中で紹介したクックパッドの例とかあとは最近自分が見た中では

この辺もいいと思う。これらを通してみると、共通して使って要る道具とか、あるいはその根底にある共通の考え方や哲学っぽいものが発見できるんじゃないかなと思います。

ちなみに今回紹介した三社はいずれもエンジニアを積極採用しているそうなので、自分もこういう開発プロセスとかやり方の開発を経験してみたいとか、おれにもやらせろ! という人は履歴書を送ってみるといいかもですね。文章に書き起こすの大変だったんで、これくらいしっかり宣伝させてもらって締めとします。

おわり。

YAPC::Asia 2013 / Github によりバザールモデルへ

ブログを書くまでが YAPC、ということなので、書きます。

初日「モダンPerlリファクタリング」

自分は20分枠で 「モダンPerlリファクタリング」という題で話しました。スライドは以下で公開してます。

今回、思いの他 CI やテストに関する発表が他に多くてそれらに比べると基礎的な内容に終始しちゃいましたが

と @t_wada 御大よりお褒めに与ったので個人的には満足です。

リファクタリングはテストさえ書ければその半分以上は終わったことになる、ただしテストはテストを書くことそのものが主目的になりすぎないように。そして書いたテストはとにかく計算機を利用して頻繁に実行しましょうということが言いたかったのですが、意図通りに伝えられたんじゃないかなと思う。

2日目「Ruby の良いところ語ってください」

2日目は、@hotchpoch、@shyouhei、@masuidrive + @tokuhirom によるパネルディスカッション「Rubyの良いところ語ってください 〜そんなPerlで大丈夫か？」の司会も務めました。しかしなんだこのメンツ。最初 @lestrrat さんから依頼を受けたときは全然違うメンツ案で、一ヶ月後に「決まりました！」と連絡が来たらこのメンバーになっていた。聞いてない。

Ruby 陣営から猛者が集まったわけだししっちゃかめっちゃかな会になる･･･かと思いきや、みなさんここ数年で流石に丸くなったのか、予想外にスムーズな進行でこっちが逆にびっくりしました。とはいえ、おとなしくしてもらったというよりは

と、言いたいことはちゃんと言ってもらったし、投票結果は3位だったりとで聴衆のみなさんにはそれなりに満足いただけたのではないかなと思います。実は @miyagawa さんをはじめパネルを聴いていた面々がその後の HUB でビール片手に自分にも言わせろ的にいろんな議論をしはじめて非常に面白かったのですが、熱量的にそっちの方が本番じゃないかという感じでその勢いや本音を壇上で引き出せなかったのが反省点ではあります。

内容的には、結局パネルディスカッションの最後のテーマである「Perlリスク」に関してがやはり一番の感心どころでしょうが結論は以前に @shyouhei さんが書いていた http://shyouhei.tumblr.com/post/44451702850/1 のポストにある論旨がすべてだったと思います。壇上にいた4人、それに関しては同意していたし。

だからまあ、こう言ってしまうと身も蓋もないかもしれないけど、リスクはPerlじゃない、Perlに固執することにあるのです。

「Perl って今どうなの」という問いに対してどう答えるべきかというのは難しいところなのだけど、個人的には、ライブラリの更新数であったり何か新しいパラダイムやアーキテクチャが生まれてくる土壌を他言語と比較された場合には、かつての勢いが無くなっている (というかそんな勢いあっただろうか云々) という所は認めざるを得ないのかなと思うし、それはもう大前提とした上で、なぜ今 Perl コミュニティに自分が帰属しているか、どうコミットしていくかとか、どう Perl と関わっていくかということを考えたいと思っている。

Perl でも同じことができる、あの言語にあるこれはこうやればできる･･･ということを言っていくのも、ググラビリティその他の意味で必要だとは思うのだけど「Perl って今どうなの?」と疑問に思っている人が期待してる回答は多分そこではないだろうし、まずは他言語との差分をちゃんと受け入れるところから、かなと思います。そういう意味で今回のパネルでは、Ruby のコミュニティやエコシステムと Perl のそれの考え方の違いをそれぞれの識者から話してもらうことができたのが、自分の思うところを代弁してもらう形に誘導した形ですこしずるかったかもしれないとは言え、良かったと思ってます。

テスト、CI、Github ─ 伽藍方式からバザールモデルへ

毎年の YAPC ではときどき、誰がいうわけでもなく、その年のテーマがはっきり見える会、というのがたまにあります。

Audrey が来たときは Perl 6 ･･･というか Pugs 絡みで Haskell の話が盛り上がった年だったし、あちこちで Moose が話題になった年、AnyEvent が、Plack/PSGI が、みたいなときもあった。必ずしも毎年そういうテーマみたいなのが浮かび上がるわけではないのだけど、一方でそういうテーマが浮かび上がるときというのは、つまりその話題について同時多発的にみんなが感心を持ったということでありその年のトレンドを表しているといって間違いないと思います。

今年はどうだったかというと、テスト、Continuous Integration、Github あたりが話題に上ることがとても多かった。テストに関しては、CPAN モジュールのテストの仕方というよりは大規模アプリケーションでの分散テストの仕方であったり、アプリケーションにまつわるテストの書きにくい場所をこう書こうという話であったりとより業務寄りの話が多く、CI や Github の文脈もそうだった。たぶんこれが、今年のトレンド。

たとえばこのへん。

前者に関して、古巣の資料を紹介するのも変な感じだけど自分がいた頃の開発フローとは大きく変わっていたということも併せて述べたいということで、敢えて紹介します。後者は、やはり Github を使った Pull Request ベースの開発についての発表。とてもおもしろい。中にはこれを読んだり聴いたりでカルチャーショックを受ける人もいるのではないかと思う。

YAPC とは関係なく、このところ、Pull Request ベースで開発してテストを CI して Social Coding ですよ、というのを軸にした各社の開発フローみたいな話をよく聞く。そういうトレンドが、Webサービス開発なんかを手がける人が多く参加しているであろう YAPC でも表面化したということではないかなと思ってみていました。

ところで、今日こんなツイートをした。

Github/Github Enterprse あるいはその同種のツールを用いて Pull Request ベースの開発･･･つまり OSS 開発で培われてきたワークフローで自分たちのソフトウェアを開発する、というやり方が現在進行形で拡大していて、またその拡大度合いも勢いづいてきている印象を受けます。

これまでも Webサービス開発に関して言えば、アジャイル的であったり軽量な開発だったりするのはごくごく普通に行われてきたけれども、現場の実感としては Github によってコードレビューやテストや CI が当たり前のように根付くというのはそれなりに･･･というか、かなり大きな変化に感じているのでないかと思う。1年やそこらのスパンでそういう大きな変化が起こっていて、その中に身を置いている人が多いからこそ敢えてその話を YAPC でしようと思うモチベーションが沸くわけで、今年のそれはそれが同時にあちこちで起こっているということの証左じゃないかと自分は思いました。小さな変化でたいしたことのない話であれば誰も発表しようという気にすら、ならないわけですしね。

より大袈裟にいうとこれはつまり「Github はコンピュータ・プログラミングの民主化だ」という話があるけれども、それが Webサービス、クラウドサービス、アドテクそのほかいろんな分野の開発現場で起こっている、ということ。Github を使った開発、つまり OSS のような開発プロセス ─ ソフトウェア開発の方法論が伽藍方式からバザールモデルへと移行していくという大きな流れがおそらくあって、その流れがこの一年の間に一気に速くなった。自分はそんな風に捉えています。いつか恥ずかしげもなく、あれがソフトウェア開発革命のターニングポイントのひとつだったよ、という風に言えるときがくるんじゃないでしょうか。

事実、かつて当たり前のようにスタートアップが Rails を採用することがニュースになった時と同じように、昨今のスタートアップは当たり前のように Github でコードをホストして、テストを書いて、Pull Request をして CI をするようになってきている。これはサービス開発の現場に定着していくやり方になると思います。

ただ、その現場で起こっている大きな変化はその外からはかなり見えにくい。それがもどかしい。･･･もどかしいけれどもこうして YAPC でそれが話題になって表面化したということは、やがてより広範な分野に知られるようになって、そのもどかしさはどこかに行くでしょうし、それはもう時間の問題だろう･･･ということを強く感じました。

えーと、なんか最後は YAPC に絡めて自分の言いたいことを言ってるだけになってしまいましたが、今年の感想は以上です。他にも PerlMotion とか、LT とか、その後の打ち上げで Shibuya.pm 同窓会みたいになったとか、いろいろ面白い話はあったのだけどこの辺で。

@941 さん、@lestrrat をはじめとするスタッフのみなさん、おつかれさまでした & ありがとうございました。(今年も) 楽しかったです!

･･･さてさて、来年以降どうしましょうかねー。

HBFav を 2.3 にアップデート。プッシュ通知ほか機能追加

iOS 7 が間もなく出そうという頃合いですが、HBFav をアップデートしました。前回の 2.1 から飛んでバージョン 2.3 になります。8月末にはほぼできてたのですがレビューだ何だでちょっと時間がかかってしまいました。その分、新機能多め。

となっております。若干やり過ぎ感があるきもするが、今は反省していない。

プッシュ通知

プッシュ通知に対応しました。これが今回の目玉機能です。

フォローしているユーザーが新しいブックマークを追加した、自分のブックマークにスターがついた、あるいはIDコールが飛んできたなどの通知を受け取ることができます。自分がブックマークした、という通知も受け取ることができるので PC で見ている URL を通知で飛ばしたいというケースなんかにも利用できます。

ブックマーク系の通知はサウンドとバイブレーションは切ってありますので、普段はニュースヘッドライン的にプッシュ通知を長しっぱなしにしておき気になったときに通知センターから開いてみる、なんて使い方がオススメです。

プッシュ通知の実現にははてなブックマーク本体の Web Hook 機能を利用しているため、アプリ側だけでなく本体側での設定も必要になります。ちょっと面倒ですみません。設定方法については本エントリの末尾で解説します。

はてなブックマーク iOS SDK統合

目玉機能その2。先日リリースされたはてなブックマークiOS SDK を取り込みました。これによって、ブックマーク追加画面がリッチになりました。

タグのサジェストはもちろん、Twitter や Facebook 連携にアプリからシェアすることもできるようになってます。便利!

これに伴い、2.1 までのブックマーク追加インタフェースは削除しています。また、これによってアプリ側でパスワードを保持する必要がなくなったのでパスワード設定も削除しました。

ちなみに、SDK の制限で複数端末で使った場合にいずれか一つの端末ではてなにログインすると他端末でログアウトしてしまいます。現時点では仕様とさせてください。

人気エントリー

人気エントリーのリストを、サムネイルを表示するなどして見やすくしました。これまでは hatenabookmark さんのブックマークという形で適当に表示していましたが、専用のビューを用意しました。

人気コメントに対応

エントリに人気コメントがある場合に、HBFav でも見られるようにしました。個人的には、今回つけた機能の中でプッシュ通知に次いでこれがかなり気に入ってます。


iOS 7 対応

2.1 までは iOS 7 で起動しませんでしたが、@watson1978 さんの尽力により iOS 7 でも普通に動くようになりました。(Pixate への依存をなくした) パッチ感謝、です。ぎりぎり間に合いました。

パフォーマンス改善

パフォーマンス、特にHTTP通信時のパフォーマンスを改善しました。タイムラインやブックマーク一覧、それからWebブラウザでコンテンツを閲覧している際のスクロール速度なども改善していますし、これにより電池の消費も抑えられているかと思います。

ブックマーク画面の改善

地味なところですが、ブックマーク画面に概要とサムネイルが表示されるようになりました。

そのほか

他改善項目は以下のような感じです。

  • Google Analytics 組み込み
    • アプリの利用状況を調査して今後の改善に利用します
  • キャッシュ周りの制御を改善
    • 本体側でキャッシュが効きすぎてデータのずれが起こる状況をできる限り回避しました
    • まだ完璧ではないです
  • 「Chrome で開く」追加
  • 24時間表記オフ設定でのクラッシュ対応
  • 長押しでルートまで戻る機能改善
    • 閉じるボタンも長押しでルールに戻るようになりました

あと、アプリについて画面にすこしコンテンツを追加してるので良かったらみてください。

その他バグ修正などは ChangeLog を参照してください。

プッシュ通知の設定方法

プッシュ通知の設定方法について解説します。

まず、サイドメニューのアカウント名をタップし、設定メニューを開きます。

そこからプッシュ通知設定を開きます。

画面の案内に従い、プッシュ通知設定で Webhook キーに任意の文字列を設定してください。このキーは、いたずらで第三者が自分の端末に自分に無関係な Webhook を送ってくるのを回避するための項目で、このキーがなければプッシュ通知機能は動作しないようになっています。

アプリの設定はここまでで完了です。

次に、はてなブックマーク本体の「外部サイト連携」設定の「Web Hook」設定を設定します。

  • イベント通知を受け取るURLに「http://push.hbfav.com/<ユーザー名>」
  • キーに先ほど設定したキー

を入れてください。<ユーザ名> は HBFav で設定したはてなID です。図に載ってるキーはもちろんダミーです。

上図のように受け取りたい通知項目ははてなブックマーク本体側で細かく設定できます。フォローのブックマークは通知せず、スターだけ通知する･･･などの設定も可能です。

なお、Webhook のキーはアプリとサーバー間で暗号化されず平文でやりとりされます。通信路はセキュアでないので、ほかでパスワード文字列に使っているような文字列は設定しないで、新規に適当な文字列を割り当ててください。

･･･というわけで、HBFav 2.3 でした。ぜひご利用ください。

蛇足

ちなみに明日 9/18 は iOS 7 のリリースであると共に、ぼくの誕生日です。FF14 用に EIZO の 2560 x 1440 モニタが欲しいです。