2010-05-23

娘が一歳になりました

生まれてから早一年。無事大きな病気や怪我もなく、一歳の日を迎える事が出来ました。

両親から「準備して親になれる親なんかあらへん、子供に親にしてもらうんや」と言われて、そんなもかいねー、とぼけっと思っていたが早一年、怒濤のように過ぎ去りましたが、ふと思い返すと、そういうもんやなー、と思う一年でした。

生まれてから奥さんは実家に帰り、一月ほどは実感なかったのですが、戻ってきてから数ヶ月が、まず最初の大変。夜はなかなか寝ないし、深夜にも起きるし。母乳の事やら体重の事やらもあわせて奥さんも色々悩みながらも、頑張ってました。僕は、というと、この頃の父親って本当に具体的に役に立つ事はほとんどできなくって、せめてお風呂に入れる事ぐらいは、と思ってお風呂入れ担当に就任した事を覚えてます。

半年前後くらいから、目で追ったり、笑ったり、と少し「表情」が出て来て、この時期くらいからは、僕の中で、「娘にウケたい欲」がムクムクと出て来たり。あの手この手で笑わせようとしてみるも、同じ手が何度も通じなかったり。うざがられない程度に大きくなるまで続けてみようっと。

冬に奥さんが風邪でダウンした時に、たった半日だけだったのですが、娘を片手に掃除、洗濯、ご飯作りを (出来る範囲でしたが) した時は本当に家事、育児は超重労働と思いました。元同僚の二児のママが言っていたのですが「(自分が風邪になって) 仕事を休めたとしても、労力の三割が楽になる位だよ」というのを実感。

なかなかハイハイしないねー、とちょっと心配気味だったのが数ヶ月前。今やつかまり立ちもマスターし、そこここを行き来してます。今は目が離せなくて大変。

そんな感じの毎日、曰く「育児、待った無し」な毎日が続いてて、ぶっちゃけゆっくり本読んだり、映画観に行ったり、ライブ行ったり、ラーメン食べにいったり、など出来なくなった事 (これは奥さんのほうが滅法多いけど) もあるけれど、その分、沢山の言葉に出来ない感情をもらってるように思います。

一年振り返ってラッキーだったなー、と思うのは、知り合いに先輩ママがいたり、同じ位の月齢の子供のいるご家庭と知り合いになったり、そういう知り合いがいたり、と、色々と相談出来る環境にあったことや、僕らの両親とも近い場所にいて、いざとなった時に助けてもらえたことも大きかったです。

何はともあれ、皆様のおかげですくすく育ってます。これからもよろしくお願いします。

2010-04-29

UNIQUE 制約が付与された値の入れ替え方法

PostgreSQL

お題はタイトルの通り、UNIQUE 制約がついた行の値を 1 トランザクションで入れ替えたい、と。PostgreSQL のバージョンは 8.4 。例えばこんなテーブルを作り

CREATE TABLE sample (id PRIMARY KEY, value INT UNIQUE);

以下のような状態で、10 と 20 の値を入れ替えたい。

id	value
1	10
2	20

結論からいうと、あまりスマートな方法が思いつかず、一旦値を制約に違反しない値 (max(value) + 1 とか、勿論 LOCK かけてから) に事前更新してから、入れ替えるといった泥臭い方法をとらざるを得ない模様。(上手くいかなかった) 対応方法ですが、調べたのは二点。

CASE 文使う方法

ここにある CASE 文を使う方法は、少なくとも PostgreSQL 8.4 環境では以下の通り怒られ。

=> update sample set value = (case id when 1 then 20 when 2 then 10 else value end) where id in (1,2);
ERROR:  duplicate key value violates unique constraint "sample_value_key"

SET CONSTRAINTS DEFFERED

SET CONSTRAINTS 文で制約チェックを遅延させる方法。ただ、これ PostgreSQL 8.4 では FK 制約にしか使えないようで。ここにある通り、PostgreSQL 9.0 から UNIQUE 制約でも DEFFERED 出来るようなのですが。。。

他に良いアイディアないかな。。。

2010-04-21

QCon Tokyo 2010 に行ってきました (二日目)

技術全般

昨日に引き続き、二日目のレポート。

Scaling Memcache at Facebook

二日目、会場入り。ちょっと早く一番乗り。今日は朝から Facebook の memcache のお話。カサンドラは鬼の哭く街。 #QConTokyo
http://twitter.com/tksmd/status/12486857553

と、やる気満々な感じで一番乗りしつぶやいてみるも、カサンドラの話は一切なく。ま、それはそれでよかったのですが。。。

memcache が支えている、facebook の規模のお話から始まったのですが、トラフィックが Google を越えただけあって、秒間 4 億超の get や、2800 万超の set など、想像を絶する世界。その中でも memcache が果たしている役割は、その規模感からみても相当大きいようです。

まず、memcache の利用の前提条件は以下の通り。

基本的な GET はまず memcache から
更新時には DB 情報を変更し、memcache の値を invalidate
DB の行に対して memcache を対応づける

これらを元に様々な工夫をしたとのことで、興味深かった点を抜粋。

ネットワークトラフィックのオーバヘッドが大きく、(この辺りは昨日の Coherence にも通ずるのですが) 、TCP の輻輳を避ける為 UDP に実装を変えた
オブジェクトのシリアライズを Thrift のフォーマットに変更したら、3 倍早くなり 30% ほどサイズが小さくなった
複数データセンター間での memcache の同期の為に memcache proxy を利用している、また MySQL のレプリケーションをした後、更新情報を同期する用途にも memcache proxy を利用している
HotKey に対応するために、Key 自体もレプリケーション (alias と言っておられました) し、負荷分散。また、他にもアプリケーションのアップデート時に、複数のアプリバージョンからのアクセスがある可能性もあるので、アプリケーションのバージョンを Key に入れるなど、Key 自体の値の持たせ方にも色々工夫をしている
構成変更のテストは、python と ctypes を使ってやっている、一台のマシンでも複数の memcache インスタンスを立ち上げたり、構成を作るのが簡単だから、簡単なものなら、数十分で回帰テストを回せる

Twitter と同様、Facebook でも、トラフィックの増大にあわせて、色々とその形態を変えていっているとのこと、「ゲームのルールは刻々と変わる」という点も、Twitter の Nick さんの「全ての対応は transient なものなんだ」と言っていた事に通ずるように思いました。

終わった後に、Twitter の Nick さんと話しているのを見かけたのですが、こういった形での交流を自然に出来るようになりたい。。。がんがれ > 自分

Javaにおけるモジュラリティ元年

id:kompiro さんによる、OSGi と Project Jigsaw を材料に、モジュラリティについて、その有用性を説いたお話でした。こちらで資料も公開。

現在、自動車で利用されているコード総数はなんと 1 億ステップもあるとのことで、また、全世界で保守されているソフトウェアのコード数も、7 年毎に倍になっていっているそう。その観点でいっても、モジュール分割し、適切な規模に問題領域を限定し、保守性を高めていくことは重要との話には、まったくもって同感でした。

Java では、そのモジュラリティを実現するために、既に Eclipse などで実績もある OSGi と、Java7 から搭載される Project Jigsaw が選択肢になるのですが、その各々について現在の立ち位置なども含めてお話されていました。

「再利用」の考え方には「機能軸」と「時間軸」がある。時間軸というのは、あるモジュールを未来にも安全に使い続ける事が出来る、ということ。
開発にかかるコストは三倍くらいかかるので、適用する規模の見極め重要
OSGi と Project Jigsaw は歩み寄ったらしい (OSGi Bundle が Jigsaw でも利用可能)
Linked in は OSGi でシステム構成を刷新 (資料発見)

規模にもよりますが、ウェブの場合だと、Control 層 - Service 層 - Dao 層といった形の層軸で、分割するケースが結構多いと思うのですが、OSGi の場合は機能軸でのアーキテクチャ分割をするようになるので、その点アーキテクチャ設計のイメージ変えていかないといけないですね。

私としては、モジュール分割もそうですが、何より OSGi はその動的構成の部分がすごく気になる所ではあります。ここが上手く動けば、稼働中のシステムの一部のみを、更新したりといった事がより柔軟に出来そうなので。メリットとデメリットよく把握した上で、使える所では使っていきたいな、と思いました。すごく勉強になりました。

「ビューティフルコード」とRubyの思想

Tuigwaa の時以来 (?!) の久しぶりのまつもとさんのお話。タイトルにもある通り、コードの美醜についてのまつもとさんの考えや、その視点からみたときの「Ruby の思想」といったお話。一番印象に残ったのは、Ruby には

プログラマに対する信頼 = 自分で作ったものは自分で責任をもつ
プログラマに対する自由 = その信頼のもとに、最大限の自由を与える

という思想がある、と。これだけで十分良い話が聞けたように思います。

「ビューティフルコード」は積み読み状態になっているので、今読んでいるガベージコレクションのアルゴリズムと実装を終えたらこれを読もう。

デザインパターンの "本当の" 使いこなし

デザインパターンを適用する意味や、その扱いについての注意事項、各パターン間の関係などといった、デザパタ全般に関わるお話でした。要約すると、デザパタの「解決」の部分を鵜呑みにして、そのままのモノで使うのではなく、そのトレードオフや考え方の根本を理解した上で、さらにその開発に置ける「フォース」に従い、採用のするしない、適用の仕方などを考えましょう、といった所。

で、お話の内容はまったくもって同意出来る話でしたが、デザパタを使ったり、試行錯誤した事ある人にとったら、ある意味当たり前の事が多かったように思いました。勿論それを整理し、抽象度 (デザパタから、別のデザパタへの参照数と被参照数の差) を利用して構造化してとらえたり、といった部分は面白かったのですが。。。

どうしても一般論に落ち着いてしまうのはしょうがないとは思うのですが、例えば典型的なソフトウェア (ウェブとか GUI とか、ミドルウェアとか、フレームワークとか、なんでもよいのですが) でよく使われるパターンであるとか、最近のアプリケーションアーキテクチャにおける新しいパターンであるとか、何がしか、そういった具象の話ももっと交えた形でお話聞きたかったなぁ、と思いました。

Failure Comes in Flavors

運用後のシステムのトラブルシューティングから、共通のアンチパターンを見いだし、開発時点で気をつけないといけない所を「やってはいけないこと」な視点からお話されていました。「障害は発生するもの」として、アーキテクチャや設計を考える、という基本スタンスは肝に命じておこうと思いました。

結合点 (Integration Point と言っておられました、ネットワーク、DB、ファイアーウォールなど) は最も障害が発生する可能性が高いので、それらを利用する部分では、タイムアウト処理を入れ、「永遠に待つ」事だけはしないように。
CircuitBreaker (ブレーカ) のような仕組みを、結合点毎に入れておくと良い事もある。ブログでも幾つか紹介してるよ、とのこと。
ある層 (ex. アプリケーションサーバ) を負荷分散している場合、あるノードが落ちた場合、相対的に他のノードの負荷が高まり、結局芋づる式に全ノードが落ちてしまう事がある。そういった場合には縮退したり、またその層のサービスが全部落ちたとしても、全体が止らないような作りにしておくこと
本番環境との差異を認識しておくこと、特にスケールについて、2 台のテスト環境では起こらない事が起こる可能性がある。またテストを刷る際のデータは本番環境を不要な個人情報などをスクラブしたものを利用するのが良い

最後になったので、僕が息切れしていた感は否めず、少し聞き違えてる所もあるかもです。。。ともあれRelease It! 本番用ソフトウェア製品の設計とデプロイのためには読んでおこう、というのが感想。。。

余談

もう少しちゃんと英語を聞き取れるようになりたい。
帰り道に相方とお茶した時に教えてもらったライブラリ、Apache Camel: Index は結構よさげ。
参考 : http://qcon.jp/

2010-04-20

QCon Tokyo 2010 に行ってきました (一日目)

技術全般

タイトル通り、昨日、一昨日の二日間、東京はミッドタウンで開催された QCon Tokyo 2010 に行ってきました。

久々の東京である事と、場所が東京みったーんという超オシャレゾーンでアウェー感満載でした。また、火山の影響で Erich Gamma が来れなくなる、という残念なニュースもありましたが、充実した二日を過ごす事が出来ました。200名の参加者だったようです。(場所とスピーカからすると、この値段でもペイしないのでは、とか思ったり) お小遣い以外の予算で行く事を許してくれた奥様に感謝。まずは一日目の内容を。

Data Architecture at Twitter Scale

Twitter がいわゆる「リアルタイム」( < 100ms や low latency という事を何度も言っていました) を如何に実現しているかについて、主な四つの機能の観点から、その取り組みを話していました。内容については、「秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT」のレポートが素晴らしいので略。。。資料もこちらに。

まず興味深かったのが、Twitter が初期は RDBMS (+ RoR) といったいわゆる「通常の」構成でサービスは開始され、ユーザの増加、トラフィックの増加に伴ってそれにコツコツ対応し、今の高トラフィック、低レイテンシを支えるインフラやソフトウェアアーキテクチャに育てたという「過程」。常に正しくあり続ける回答は無いし、逆に「見えない未来の事を心配しすぎない、今ある問題に正しくアプローチする」という事も改めて大事な事だと思った次第。

もう一つ、Timeline のデータを作るための Fanout の話で、こういった「先払い」型の設計というのは、話で聞くと簡単そうに思うけれど、中々出来ない所。というのも、どちらかというと、RDBMS では「one fact in one place」的な考え方に従って正規化し、データの入力は一つで、見る時に種々の加工 (ex. 集約やジョイン) をするという「後払い」的なアプリケーション設計にする事が多いので、「慣れ」という側面でもなかなかとりにくい。その観点で、Twitter の規模で、この Fanout 的なアプローチが上手くいっているという事は参考になるなー、と。(と、思っていたら naoya さんのこんなつぶやきも)

振り返るとこの二日間で、一番面白いお話でした。きけてよかった。

The JSON Saga

JSON の生みの親 (ご本人曰く「発明したのではなく、自然にあるものを見つけた」と) Douglas Crockford さんのお話。

曰く、「私は、JSON の為に 1) サイトをたて 2) ドキュメント (簡単な BNF/鉄道ダイアグラム/説明) をかき、3) Java の JSON Parser の参照実装を書いた、以上」と。それ以外は特に何もせず広がっていったとのこと。

広まった要因は、その「シンプルさ」。各プログラミング言語がもっているデータ構造の和集合ではなく、共通部分に仕様を「絞った」おかげで、沢山の言語実装もあり、沢山の人がそのデータフォーマットの恩恵を受けれるようになったそうです。また、偶然にも、JavaScript だけでなく、Python や NewtonScript にも同様の考え方のフォーマットがあり、他にも (一部仕様を削除する事によって) JSON は YAML のサブセットになった、といった事実からも、ある意味「必然的」なデータフォーマットではないのか、という所は印象的でした。

id:agt さんに教えて頂き JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティスを読んだのですが、この本から受ける印象と同じく、ハッカー的「変わり者」な語り口でした。(この本は面白かったです。勉強になりましたし、JS 書きたくなる一冊だと思います。)

Connected Clouds: A Platform for Globally Distributed Service - サービス基盤としての分散KVS、そのグローバルへの広がり -

タイトルはやや「釣り」気味で、実際の内容は、ヨドバシなどで使われている Coherence の worldwide での事例紹介。

cache は置かれたタイミングで自動的にパーティショニング及びレプリケーションされる
worldwide のシステムでも、キャッシュクラスタは拠点内で設計する。拠点間の遅延 (ex, uk <-> au で < 300ms) が無視出来なくなる
レプリケーション (自動) において、ネットワークスループットは超重要。仮想環境でも動かせるが、最悪 1G Ether でも仮想ドライバ経由で 5MB/s くらいしか出ない時もあるので、物理 H/W に構築しておく方が今はよい
Push Replication というアプローチで、複数のクラスタの同期を取る。最終的にデータを受け取った後に、conflict があれば、それを解決する。eventually consistent な考え方
JVM 1 インスタンス辺り 1GB くらいが大体上限。(Java6 でもう少しいける) これを数百台くらい並べる

もっとまっすぐ「Coherence」のテクニカルな話を聞きたかったなー、というのが正直なところでした。後、物理 H/W を推奨する辺りに Sun を買収した影響か ?! みたいな邪推をしてみたり。(笑)

有機的なユーザーインターフェイス実装における課題とアプローチ

Site4D さんでこの10年で取り組まれた事例紹介を下敷きにしながら、そこで培った、チームの構成、プロセス、仕様のポイントと仕様書、といったまさに現場のノウハウてんこ盛り、な内容でした。

まず、チーム構成が「UIデザイナ」「開発者」そして「テストエンジニア」の中心に「IA」を置き、皆がプロジェクト開始からほぼ同時に動き出す、という所がプロセスの中で興味をひいた点。実際に、こうした方が結果的にはコストは下がるんです、と言い切っておられました。私もチームの中でテスト仕様を作ってもらった人からのフィードバックで、随分仕様の抜け・漏れを指摘し助けてもらった事があり、「テストの事を考えるのは仕様の事を考える事に近い」といった事を話していたので、それを実際にうまく回されているのだなぁ、と感じました。

また、UI の考え方で、

例えば「右からスライドしてウィンドウが入ってくる」という操作に対しては、「ひょっとして、つまんで右に払ったら、画面から消えるのでは」といった、「やってくれるかもしれない、出来るかもしれない」というラインを作り込んでおくと、非常に印象が良い
ただし、それをメインのオペレーションにするのではなく、メインはボタンなどのあくまで正統派なものにしておき、セカンドオペレーションとして、そういった作り込みをしておくと良い

といった当りは、よく考えられているなぁ、と。

一番感銘を受けたのは、開発前の段階で、プレビズ (pre-visualization、参考) といって、最終的なアプリイメージを動画として作りこんで、そこでお客さんとも、また開発チームとも最終イメージをぐっと共有してから、実際に作り出す、というプロセス。これを作るために、「そのソフトウェアの UI = 世界観」を徹底的に作り込むそうです。この「世界観」というのは UI に限らず大事な所ですよね。

Real Javascript

Erich Gamma さんの代わりの講演で、Douglas Crockford さんが再度登壇。JavaScript の未来の話。

ブロックスコープの問題は、let/const で解決するかも
number 型の問題は解決するかも
Thread はやらないでしょう (thread は必要悪で、アプリケーション言語には入れない方がよい)
compile 対象としての JavaScript
末尾再帰の最適化

などなどが、検討されたりするでしょう、とのこと。ただし、それより何より大きな関心事はセキュリティで、曰く「The Web is important to fix」。折に触れて、(MS スポンサーのイベントで)

IE6 Must Die

と (三回くらい) いってみたり、

HTML5 は間違った方向に進んでるから、一からやり直したほうがよい

とか、ずけずけ言ってしまう当りにも現れてました。 (笑。

ちなみに、HTML5 については、良い仕様も沢山あるのだけれども、各仕様が複雑になりすぎていて、その複雑さは必ずセキュリティ問題を引き起こす、というのが大きな理由とのことです。それよりは、ひとまず今のブラウザと JS のモデルのもつセキュリティの問題にしっかりと対応するために、ES5/Strict を推し進めていきたい、とのこと。

2010-03-30

一年を経てインストールしたソフトウェアを振り返る

iPhone

ここにあるように、3GS 発売間近の 3G 安売り期間に負けて iPhone を購入し早一年。一年間の試行錯誤の結果を簡単に振り返り。

よく使う、たまに使う

TweetDeck: PC でも使っているので。なのですが、結構重い。。。
foursquare: 最近 iPhone 使う時はほとんどこれ。
KeitaiEmu: 日本の携帯サイト見る時に。IP 制限かけてる所は駄目。
PhotoSpeak: 娘に「オッス」と言わせた動画が局所的にヒット。次回作つくらねば。
ホットペッパー FooMoo: 不慣れな土地で喫茶店探したり、とか
乗換案内: 定番

標準の Google Map やカレンダはよく使います。カレンダは NuevaSync で Google Calendar と同期とっていて、これがかなり便利。

いまいち使えていない

イマイチ自分にあっていないのか、使うシーンがあまりないのか、どっちかか、どっちもか。

baby rattle bab bab lite: 娘がまだ興味を示しません
Echofon: TweetDeck 使っているので
Fuzzyshot Photo Blog: Twitter に POST するだけなら、TweetDeck で事足りてしまい。
Galaga REMIX: ギャラガはあまり得意ではなかった事を思い出しました。
Google Earth: 舞空術を使えるので、あまり使いません。
Lightsaber Unleashed: ダースベーダーにまだ会ってないので
mixi: mixi に最近ログインしていない
ServersMan: shot6 さんの SeasarCon での発表みて入れるも、そうそうサーバにする機会がなく。。。
Shazam: CM みて入れるも、CM みたいなシチュエーションがなく
Skype: 普通に電話します
Ustream Viewing Application: UST は PC で見ることが多いです
Virtuoso Piano Free 2: Piano はスタジオで弾くことが多いです。applegirl にはなれないなぁ。
Yahoo!動画: WiFi 環境以外で見れないので、あんまり見るタイミングがありません
セカイカメラ: 動作が重い、からかなぁ。
はてな touch: 更新はやっぱり PC で。。。
駅探飛行機時刻表国内線: 飛行機のってない
産經新聞: 新聞読まない。。。

最近いれてまだ判断ついてない

Evernote: 日本法人設立されるとのことなので
Ustream Live Broadcaster: 近々に試してみる予定です。
FF: UI にようやく慣れた所で、ちょっと時間が空いてます

雑感

購入後からライフスタイルとして大きく変わったのが、電車通勤を辞めて移動の大半を自転車にした事。これにより、iPhone を触る時間が劇的に減り、用途がメール、電話、ウェブの閲覧に加え、専用クライアントを使ってツイッタしたり、とごくフツーの携帯とあまり変わりませんねー。

当たり前ですが、生活習慣に組み込まれないツールは興味がてら入れてみてもあまり使わなくなってます。ただ、foursquare はその中でもよく使っていて、初めて行く場所とか、チェックインされてなさそうな所にいくと、ついつい iPhone 取り出してチェックインしてしまいます。カメラで写真とるのに近い感覚。

あと、最近気になっているアプリは、Kindle for iPhone と、阿修羅でしょうか。