前から何回か興味を持ってるんだけど、ちょっとまとめて調べながら思ったことをザクザク吐き出しておくよ。

今のところ考えるちょうどいい使い方

いろんな使い方ができると思うんだけど、リリースサイクルの都合ではなく

• どんな機能が現在のプロダクトで切り替え対象となっているのかの可視化 ( admin panel )
• サーキットブレイカー

の意味で使うのを前提にしつつ、

• カナリアリリース
• A/Bテスト

にも導入していく、くらいの感じだとよさそう。

大げさな感じがするかもしれないけど、ちゃんと考えて入れないとややこしくなるだけだなと感じているので。

雑な言い方すると feature toggle って global な状態分けの if ブロックなわけで、実際、特別な記法なんかなくたって環境変数と if だけで実現可能なわけですよ。でもそれって実装側からもプロダクトオーナー側からも実態が見えにくくなるだけでいいことないので、なぜそれが有用なのか？を説明できる状態、機能を実現してなきゃダメだよな、と思うわけです。

基本的には避けられるものなら避けるべき

全体的に feature toggle でリリース管理していくのは危険な感じがする。クライアントサイドやアプリでは、時限リリースなど、マーケットが挟まることで uncontrollable になってしまう部分には使わざるを得ない場合があると思うけど。

普通は 追加するより消す方が怖い ので、消されないで放置されるフラグが増え続けることは容易に想像できる。リリースサイクルのコントロールよりも duration や user segmentation などのメリットを重視してやった方がよさそう。

また、サーキットブレイカーのような、消したらダメな機能もある。そういう違いが admin panel 上で可視化できるとよさそう。

※ 小さいプロダクトの立ち上げ期で次々 feature toggle で出し入れしなきゃいけない状況はあり得るっちゃああり得るけど、それは技術的に解決するものではなく WHY に立ち向かっていない状況のように見える。実装は同時並行で行なって短時間で検証をくり返す、言葉で言うとかっこいいけど、聞いただけで事故る可能性が高い（同時並行のくだりのあたり）し、本当にスモールな時って、そもそも多人数で同時並行開発できないので、feature toggle とか考えようがなくね？という気もする。まぁ、もしかしたら自分の知らない魔法の世界があるのかもしれない。

SaaS

https://launchdarkly.com/pricing/

75 USD/mo

ちょっと高いかなー。でも機能がすごい。これ全部実装するのは確かに大変。user の segmentation も webhook もみんなある。ユーザーベースの拡大がビジネスチャンスの拡大に繋がるプロダクトにはよさそう。

Admin Panelとスピードと履歴が重要

Admin Panel はかなり重要な要素になると思うんだけど、真面目に作るとそこそこ重たいので、複数のサービスをまたいで使えるとよさそう。というかイマドキはまたげないときつそう。サービスをまたいで feature toggle を実現するには CDN でスピードを稼ぎやすい仕組みが重要な気がする。例えばサーバが JP にあったり US にあったりするはず。¹

そして admin panel 上の操作は履歴を残すことが重要。なんなら同時に通知を飛ばすなどがあってもよいかもしれない。（PubSub でいいか？）

feature の追加、削除はどこで？

• admin panel で追加、削除すると実態（実装）と乖離する可能性がある
• 各サービス（アプリ）側で追加、削除の order が出せるのが理想的？
  • 追加、削除の履歴はコードの VCS 側に残る形か

調べてみた

http://featureflags.io/ より。先の LaunchDarkly 提供。

気になっているのは、

• backend storage はどうするのか？
• admin panel はどうするのか？
• frontend ではどうしているのか？

frontend で feature toggle はー、いるんだろうか？ Node.js でバックエンドならまだしも。JSアプリケーションを初期化する cell をバックエンドで rendering するかしないかで切り替える方が素直な気がするなぁ。

flip gem

参考になる。

https://github.com/pda/flip

Admin Panel までコミで、ちょうどいい感じがする。

feature gem

DSL 部分の実装がよさげ。

https://github.com/mgsnova/feature

• separeted repository
  • in-memory or redis or static YAML or ActiveRecord
• cache されるし force refresh! もできる

Repository が分離しているのは非常によい。refresh! もできるので、例えば Central Repository を分離しておいて Central Repository に Admin Panel を設置、Central Repository から必要な情報を取得して Repository に保存しつつ、Central Repository が更新されたら PubSub で Repository を更新する、といったことが可能なはず。

Unleash npm

こりゃすごい。

https://unleash.github.io/

• Admin Panel ( Server ) と Client SDK を持つ
  • Java / Node.js / Go / Ruby / Python / .NET
• Heroku-ready
• storage は PostgreSQL 固定？
• userId とカナリアリリースっぽいものに対応

これすごいな。 LaunchDarkly の OSS 版ぽい感じ。ただ、都度アクセスが必要になりそうなので、cache がないとサーバの位置によってはちょっとつらそう。

bandiera gem

監視体制が参考になる。

https://github.com/springernature/bandiera

• サーバサイドは Ruby
• Client SDK は Ruby / PHP / Node.js / Scala

これ自体が中央のサーバになるので監視ものがいろいろ最初から考慮されている。

chanko

https://github.com/cookpad/chanko

Rails アプリの中で toggle する機能に関するコードの置き場所を安全に分離する DSL. user segmentation 対応。

確かにねぇ、View 以外も分けたいとなった時にコードの置き場所に困るのは事実。

rollout gem

https://github.com/FetLife/rollout

• DSL の部分はあまりイケてる感じがしない
• Redis固定
• Service あり ( https://github.com/fiverr/rollout_service )
• dashboard アリ ( https://github.com/fiverr/rollout_dashboard/ )

API サーバも Dashboard も作ってあって真面目にやってる感じがする反面、DSL や Redis 固定の部分はイマイチかなぁ。

flagship gem

https://github.com/yuya-takeyama/flagship

• dependency free
• flagset を DSL で定義できる
  • この中でもさらに条件分岐できる
  • ちょっと難し過ぎる気がする
• no storage

admin panel を別立てにできなさそうに見える。

少なくとも DSL での定義を通過する必要があるので、deploy / restart は必要な気がする。環境変数を参照する部分は反映し直しやすいけど、それでも restart は必要？ でもそれだと目的を達成できないような気がするので何かを見落としているかも。

feature-toggles gem

https://github.com/LouisSayers/feature-toggles

YAML storage 固定

まぁ YAML dump する script があれば admin panel を別立てにすることもできるけど、YAML storage ってことは deploy し直さないといけないので、そこはイマイチ。feature gem でいいかな。

参考

• システム障害のおわびとまなび - freee Developers Blog
• 「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
• フューチャブランチの発展は継続的インテグレーションの衰退である
• 第3回　ブランチvs.フラグ：Comparators—比べてみればわかること｜gihyo.jp … 技術評論社
• 開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記

ふと気づいたけどここ数日 Evo の画面ロックを解除していない。

え？

いやいやいや。

え？

とりあえず再起動。

直った。

こんなんでいいの？

ちょっと時間が取れるようになったので環境を変えることにした。¹

• PowerBook G4 12" 1GHz² + 768MB -> MacBook 13" 2.4GHz + 2GB
• MacOSX 10.3.9 -> 10.5.2

今の機械は中古で買って4年、HDD交換1回、バッテリ交換2回。まぁ頑張ったんじゃないか。

AppleStore なんてない田舎なので量販店で。特にオプションはなし。以下、気づいたこととか。

本体

• でかい。15" じゃなければまぁいいかと思ったけどいざ使い始めるとでかい。画面がでかいのはいいけどモノとしてでかい。
• 質感がよくない。やっぱ Pro の筐体の方が全体的に触っていて気持ちいい。特にキーボードとトラックパッドは確実に落ちる。15" なんて邪魔で使えないと思い込んで我慢しているが意外にストレス。全体的に入力の感度が悪いのかキーの戻りが悪い³のか、自分の思っている強さ、スピードで普通に入力すると漏れがいくつも出る。
• 上と関係して、細かいことだけど、打鍵時の音が少しうるさい。キーボードユニット自体へ伝わった振動であちこちのキートップから音が発生している。この安物め。
• もうちょっとだけ開いてくれないか。前から感じてるんだが、Mac のノートはもう少しだけ開くと扱いやすいんだよな。
• テカテカ液晶は思ったより悪くないかも。まぁ外で使う機会はほとんどないのでその辺は分からないんだけど、画面の明るさも上がってるし、全体的に見やすくなってるとは思う。
• 速い。さすがにこれだけ性能差があれば当たり前。feed消化がぐっと楽になった。⁴
• アダプタはほんの少し変わっている。今回買い替えたいちばんの理由は実は現行機の PowerBook のアダプタの断線なんだけど、断線した部分はほんの少し強度が上がっているようだった。でもやっぱ ThinkPad の方が断然よくできてるね、この辺は。MagSafe はいいんだけど、こういうところに気を配らないのはやはり Apple クオリティか。
• function キーの配置が変わって、頭を使わないと expose できない。慣れるまで時間が掛かりそう。

OSX 10.5

• 全体的にメタル縛りになったっぽくて、少しいかつい印象を覚える。
• Finder のサイドバーがちょっと邪魔くさくなった。検索フォルダ（スマートフォルダ？）は便利なのかなぁ。Thunderbird で使うことはあるけど。
• Ruby 1.8.6, Perl 5.8.8, zsh 4.3.4, screen 4.0.3, Emacs 22.1 ステキ
  • と思ったけど Ruby も PHP も入ってるのに対応する elisp が入ってないのは相変わらずかよ。
• AirMac のインジケータが全然役に立ってない

全体的に Terminal とブラウザ中心の生活なのであんまり変化がよく分からない。Carbon アプリの文字の描画がよくなったって話を読んだ記憶があるんだけど、モニタそのものが違うのでうまく比較できません。

移行

今回は有線で rsync + ssh で今までのデータを転送しておいて⁵、一つずつ使うアプリを入れて、Library 以下を必要な分だけ上書きするという方法で。昔からアレコレ試したりして無駄が多いので、最終的にそれを削るため。Mozilla アプリの移行は手慣れたものであっという間。拡張まで一気に復元できるのは楽だよなぁ。

入れたのは Camino, Thunderbird, Firefox, CarbonEmacs, CotEditor, LimeChat, EIJIRO Viewer, Flip4Mac, OmniGraffle⁶, Gimp, MacPorts, MacPorts で shttpd⁷, lv, nkf, gauche⁸ くらいか。VLC とか ffmpeg とか NeoOffice とかはあとでいいや。あ、PixelCat はあった方がいいのか？ Preview で複数の画像をまとめて閲覧できるね。じゃあ要らない。PowerBook バンドルアプリだった GraphicConverter をほぼ写真の回転のためだけに使っていたけど、Preview でできるようになったから問題なし。おっと忘れていた。ClamXav も。

簡単なもんだ。

実はランチャは sh の alias を使っていて Terminal は開きっぱなしなので QuickSilver とか必要なかったりする。新しく使い始めたのは今のところ SpotLight くらいかな？ Panther -> Leopard で結構差のでかい upgrade だと思うんだけど、違和感なく使えるのは OSX のいいところだよなぁ。XP -> Vista でかなり悩んだのとはえらい違いだ。

ハマったのは無線のパスワードをいつの間にか変更していたのを忘れていたことと、X-Chat Aqua を捨てる⁹に当たって代わりになる irc client がやっぱりなく、LimeChat に行き着いたがまだ納得できていない辺り¹⁰か。

しかしアレだね。十分速いと思っていた Fastladder はさらに速くなってちょっとした感動。言うなれば時間を金で買ったって感じか。自分の処理能力はそう簡単に速くならないけど、まだまだ削れる時間があった。

一段落ついたので最近自分とその周辺を振り返って感じたていたことをまとめてみる。

• Subversion 便利
• CLI 便利
• rsync 便利
• Emacs 便利

Subversion 便利

単純な話、CVS より Subversion の方がクライアント環境が充実している。CLI の人ばかりなら CVS でも Subversion でも使える機能に違いがあるだけで大きな問題はないが、そうでない人が居るなら CVS より Subversion の方がよい。Subversion より高機能なものもあるだろうが、クライアントの対応はやはり今のところ Subversion がイチバンだろう。また Subvserion は使えるプロトコルに http があり、ネットワークに乗せやすい。

ただし cvs2svn で何も考えずに既存のリポジトリを変換してしまうと svn:eol-style が native になっちゃって Windows の人の環境では CRLF になっちゃって、それがあとで影響する可能性があるので注意が必要。

やっぱ CLI 便利

扱うべきオブジェクト（ファイルだったりそうじゃなかったり）が大量にある場合は GUI より CLI の方が効率的に作業できることが多いなぁと思った。

1. 履歴によって同じ、あるいは似たような作業のくり返しがやりやすい
2. ファイルの書き換えに関しては、同じアクションで実際にファイルを書き換えるのか、結果の表示だけを行うのかなどのスイッチが行いやすく、テスト -> 本番という段取りを踏みやすい
   • sed 発祥の -i オプションが便利すぎ
3. パイプによって必要なデータだけを相手にしやすい
4. 必要なデータ、情報をテキストとして抜き出しやすい
5. 重くなって作業不能とかいう事態にまず陥らない

特に最後の二つは重要である。

重くなって作業できなくなっちゃうという現象は、立ち上げっぱなしにして使うアプリ¹なら基本的に必ず起きると見ていい。最近だとタブで大量にページを開きやすくなったブラウザなんかもそういうケースが多いような気がする。ま、とにかくそういうことがちょくちょく起きるというのはこれを読んでいるような人はよくお分かりのことと思う。特に大量のオブジェクトを扱うケースなんかでね。

しかし必要なときに立ち上げてフィルタ動作して慎ましく終了するような CLI のツールの場合、そういうことはない。いや実際には自分でやろうとしている処理が悪ければ全然結果が返ってこないとかいうことはもちろん発生するのだけれど、今まで普通に動いていたのに、別な作業をやろうとしたときにモタモタされて作業が進まないってことはほぼないと言っていいと思う。簡単な話、shell が重くなって全然作業できないなんてことは普通起きない。

「テキストとして抜き出しやすい」のも本当に大切なことで、作業のリストアップと作業ボリュームの検討をする人と実際に作業する人が違う、あるいは検証する人が違う、なんてケースではとても重宝する。作業リストを起こしやすく、「見える化」させやすいのだ。

GUI のエディタや IDE で何が不満て、検索した結果見つかったファイル群のリストをテキストとして落とせないことがほとんどである点だ。何もかも自分で作業するとかそのまま作業に移って結果さえあればいいって言うんならそれでもいいんだけど、中間の段階でチェックを掛けにくいのは「兵隊」の道具としては扱いにくいんだよなぁ。

※ 「戦士」の武器としてはいいかもしんないけど、自分で使っていないからそこら辺はよく分からない。

ついでに、ファイルのリストも内部でオブジェクトとして抱えちゃうタイプの（例えば eclipse などの）IDE は履歴管理していないファイルでもファイルが大量にあるだけで動作が重くなっちゃうのでとても不便だなと思った。（プロジェクトの管理方法をうまく設定すれば遅くならないのかな？）

便利だなと思う CLI の使い方サンプル

xargs をやっとつかめた。今まで知らずに済ませていたのが本当に恥ずかしくなった。数年前のときもこれ知ってればもっと速かったんだなぁ。

find . EXPRESSION | xargs grep -Hn PATTERN

で、修正の必要なファイル名と行番号と修正箇所を抜き出しておいて

find . EXPRESSION | xargs perl -i.bak -p -e 's/PATTERN//'

で、実行、なんて感じ。²あるいはその前に

find . EXPRESSION | xargs perl -p -e 's/PATTERN//' | less

で確認してもいいかな。動作が複雑になりそうならスクリプトを起こして使う、という具合に簡単に切り替えられる点も便利。（というか複雑なパターンはエディタや IDE の置換機能で乗り切れないよなぁ。もちろん不必要な変換が起きていないかどうか diff で確認しておくのもお忘れなく）

修正の状況も

svn status -v | awk '$1 =="M" {print $NF}'

とか

svn diff | awk '/^Index:/ {print $NF}'

とかでリストをすぐに作れる。便利便利。

diff も GUI のツールはファイル全体を対象にして開いちゃうことが多いと思う（もちろんそうなっている方が便利なケースも多々ある）んだけど、あれも複数のファイルの変更の全体像を確認するのには不便なんだよな。というか

svn diff | less

のように使えないと commit log 書くときや不必要な修正をし過ぎていないかどうかの確認のときに不便だと思うんだけど、そういうのは IDE 派な人はどうしてるんだろう？ 単純に疑問。変更したファイルが10個あったら一つずつ diff の作成を10回くり返すの？ マジでそうなら IDE 使うなんて信じられない。

CLI はキーボードから手を離さなくても使える

IDE 使いの人の作業を見ていると何かするたびにマウスに手が離れて、しかも目的のオブジェクトをポイントするのに時間が掛かるといったことがちょいちょい起きている。本人は疑問に感じていないのだろうが、どうもハタで見ているとイライラする。どうしてそんなに作業のテンポを悪くする要素ばかりなのだと。

もちろん習熟度によっても違うだろうし、マウスカーソルを合わせただけで情報を取得できるツールチップなど CLI や curses では逆立ちしても実現できない機能などはかなり便利だと思う。GUI 全般やマウスそのものを否定するようなアホな話がしたいのではない。

しかしやはりインターフェイスには向き不向きがある。すべての作業において Terminal さえあれば十分と言うつもりはない。ただ Terminal に否定的な人や嫌悪感を抱いている人にも、「あなたの作業スタイルはあなたが思っているほど便利でも速くもないのだよ」ということは知っておいたもらいたいのだ。決してオイラが old type だからとか新しい IDE が理解できないからこういうことを言ってるわけじゃないのよ。

※ どこかのブクマコメントかなんかでこの手の話題を見かけたような気がするんだけど、なんだったか忘れてしまった。ちなみに自分でもデータベースの中身をチェックしたり簡単な UML を書く際に eclipse は使っている。ただし Emacs ほど長い時間は使っていないし達人の技などは知らないので、勘違いはあるかもしれない。

rsync 便利

いろいろクセがあって個人的には意外とハマる rsync だけど、やはり使えると便利。まぁ単純に .svn などの特殊なディレクトリやファイルを除外してネットワーク越しにミラーリングできればなんでもいいんだけど、こういうツールを何か一つ押さえておくのは大事だなと思った。Explorer や Finder の機能だけしか使えないってんじゃ話にならない。

Emacs 便利

これは余談。今まで

• ediff-buffers
• vc-mode

など開発者なら使ってて当たり前だろと思われるようなものを使わずに全部コマンドだけで済ませていた。いやこれはかなり恥ずかしい。いや Emacs のような巨大なツールなんか使いこなせなくて当然だから恥ずかしくないと言えばちっとも恥ずかしくはないんだけど、使い始めたらどっちも手放せないな。（vc で log とか化けまくっちゃうのはなんか設定が足りないのか、そもそも UTF-8 で動作させていないとダメなのかな？）

Emacs 22 のカラーカスタマイズは以前 FreeBSD の Emacs で確認済みなので、近いうちに Emacs も入れ直して手元の環境をすべて UTF-8 に統一しちゃった方がいいかなーと思い始めている今日この頃。

なんて言ってたら Dan の中の人が CotEditor をベタ誉めしている³。おぉ、確かにこれはいい。今度薦めておこう。自分でも mi の代わりに入れておくつもり⁴。まだちょっと負荷テストが足りてなさげで、大量のファイルを開いたりすると途端に重たくなっちゃうのはご愛嬌かな。

これ、桁折り位置をウィンドウ幅以外でその場で指定できるといいなぁ。

cf. AYNiMac : 自作ソフト : CotEditor 0.9.2

mi はもっさりしていて、Smultron は日本語判別がタコなのと MDI なのがイヤだったんだけど、これはどちらもクリアしているので GUI なエディタはこれに落ち着きそうだ。

prototype.js をもう少し読もうと思って、とりあえずクラスとかちゃちゃっと分類して読みやすくならんかなと思って JSDoc に掛けてみた。

漏れまくり。

まぁ javadoc 形式のコメントなんか一切ないんだけどさ。それにしてもコードの概観を眺めるくらいには使えるんじゃないかと思ったわけですよ。

うーん。src/ ディレクトリで一つずつ読むしかないのか。

主に横スクロールが発生したときに思うんだけど、スクロールバーにマウスカーソル合わせるのも邪魔くさいし、カーソルキーを使うのも鬱陶しい。

そんなとき手のひらツールでガッと横スクロールできたらステキ。

もしかして Greasemonkey ?

[04-28 追記]Scrollbar Anywhere を教えていただいた。早速使っているんだけど、気づいた点を少し。（いずれもバージョン 0.8 の段階の話。）

• デフォルトではドラッグの際にマウスカーソルも変わらないし、スクロールバーというだけあって、マウスを動かした方向と反対に動く。これらはいずれも設定で変更可能。
• 通常の onmousedown で動作が始まるので、例えば右クリックに割り当ててしまうとコンテクストメニューが全然使えなくなる。
• だからと言って左クリックに割り当てると、こうして textarea 内で編集しているときにもドラッグして選択とかするときにスクロールしまくって困る。
• 中クリック…って、PowerBook のパッドでどうやって使うんだろ？
• マウスカーソルの動きとスクロールが合わない。
  • あくまでマウスの動きと連動するのは目に見えないスクロールバーであってウィンドウ内のオブジェクトではないってことかな？

キーコンビネーションがあればだいたい文句ないレベルなんだけどなぁー。便利だから使うけど、左クリックにそのまま割り当てちゃってるので、簡単に off にするボタンか何かあるともっとよさげ。

[2007-07-10 追記] Grab and Drag :: Firefox Add-ons なんてものも。

Mac OS X 用コンテキストメニュープラグイン

OS X の作る PDF がでかいので、リソースを削ったら小さくなるかなぁ、でも FileBuddy 買う気もないなぁと思って探していて見つけたもの。

結果、PDF は小さくならなかったんだけど。ブックマーク追い出し用メモ。

HUB が止まったりケーブルが切れ切れ（これは前からあやしかったけど）だったり。むーう。困ったな。対策取るの面倒だ。

脱 Illustrator への一歩として Sodipodi の利用を考えてみた。Gtk2 アプリなのでついでに Gimp も 2 を入れた。Gtk2 は Gtk のときにあったメニューの間抜けさがずいぶん減り、Win32 アプリと比べても遜色ないレベルに UI は洗練されてきている。（軽くなってくれることを期待していたが、それは無理だったようだ。）どちらもそれほど試したわけではないが、Gtk アプリの Dia なんかに比べて違和感はずいぶん少ない。

しかし問題は Sodipodi が SVG にしか対応していないこと。やはり素材としては eps である方が何かと有利なので、なんとか eps に変換できないかと悪戦苦闘してみた。

結論から言うと、現状では難しい。

まず、eps -> svg であるが、これは GSView の license key さえ買えばまともに変換可能である。GSView の他に pstoedit が必要。どちらも Win32 で問題なく動作する。license key がないと、変換に制限が掛かるのか、まともに見れる SVG にならない。微妙に見えるところがイライラするし、Sodipodi に読ませたら帰ってこなくなってしまった。（強制終了）

license key は持っていないのでこれ以上は試していないが、license key さえあれば既存の eps 素材（普通は既存の素材は SVG ってことないよね）を活かすことができる。この点は問題なさそうだ。

問題は svg -> eps の方で。これはフリーのアプリでは対応しているものはなさそうだ。誰かの日記にできそうなことが書いてあった が、試しに PostScript Printer を作って、そいつを使って出力した ps ファイルを開いてみたらベタ絵になっていた。これでは使いものにならない。

Gimp で SVG を開くことができるが、開いた瞬間にラスタデータにレンダリングされる。ImageMagick の変換でもやはりベタ絵になってしまう。

そんなこんなで完全に SVG に囲い込まれてしまう。まぁ将来的には SVG と既存のフォーマットの変換にも苦労しなくなるのかもしれないが、現状では難しいと言わざるを得ないんじゃないかなぁ。自分一人ですべて片付いているなら SVG に移行しちゃってもいいと思うけど。

参考

• ９．TIPS1　−GSのその他機能−

PDF目次生成

目視で確認しながらでなく、CSV でページ番号なんかを指定して一気にしおりを生成するソフト。イマイチ使い方が想像できないけど、フリーでできるのはありがたいのでメモ。

http://www.subway.co.jp/shops/index.html （注 いきなり FLASH です）

SUBWAY って、全然ないんですねぇ。

おれの「たまご」イタリア風（マイレシピ）返せ。あーもう。