Protocol Buffersのソースを読んでみる
2008-07-12 近況 新刊が多く慌しい. 谷川史子の "草の上星の下", 岩本ナオの "町でうわさの天狗の子", あとは Google の "Protocol Buffers". 谷川史子の洗練を綴るには余白が狭過ぎる. かわりに Protocol Buffers の話をすこし. Protocol Buffers (以下 protobuf) は Google 製のオブジェクトシリアライザ. 名前からは RPC を連想しそうだけれど, RPC そのものではない. もっともオブジェクトを直列化して送受信するのが RPC だから, あとは送受信だけあればいい. 実装は含まれないものの, protobuf にも RPC を前提としたインターフェイスがいくつか含まれている. ...といった細かい話は ドキュメント や インタビュー を見ればわかる. 今日はコードを見てみることに. なお, 例の
steps to phantasien t(2007-07-06)
昔の同僚が退社してベンチャー仕事をやるという. 門出を祝う宴会に, 昔のよしみで呼んでもらった. ついでに古巣の近況を聞く. ひとつ嬉しい知らせがあった. 以下その自慢話. ある夏, 私は社内ライブラリのチュートリアルを書いた. そのチュートリアルが, 今でも改訂されながら参照されているという. のみならず新人プログラマの研修教材として広くとりいれられつつあるそうだ. 私はとても嬉しくなった. もちろん手柄は改訂を続け, 様々な改善を続けた彼らのものだ. それでもなお私は喜びを隠せない. 自分が去った今も文章だけが生き続けている. 私は平凡なプログラマだから, 自分のコードが生き残れるとは思えない. 一方ボランティアで仕事の合間に書いた文章は読み継がれている. 価値のあるものが生き残るのなら, 私のなした価値は(コードではなく)文書にあったことにある. プログラマとしては悲しいけれど, 会
steps to phantasien t(2007-06-01) ChangeLog の作法 つづき
Subversion の開発者が ChangeLog について面白い記事を書いている. 記事の要旨はこうだ: ChangeLog (Subversion なので commit log) を書くのは面倒だよ, メーリングリストもあることだし書かなきゃダメ? ってよく訊かれる. 書きましょう. バグトラックもあるけど, 書きましょう.これらのツールは補完しあっている. メーリングリストはノイズが多いし, 変更を特定するには情報が足りない. バグトラックはバグの記録がメインだからコードの話を細々書くのは邪魔になる. 変更については ChangeLog に書くのがいい. プログラマは ChangeLog を読む. 記録を検索して, どの関数に何が起きたかを調べるものだ. この類の記録は ChangeLog を読まないとわからない. 逆に ChangeLog を書く時は, それを特定できるように省略
ChangeLog の作法 steps to phantasien t(2005-10-13)
ソースコードなどの変更履歴を ChangeLog と呼ぶ. オープンソースのソフトウェアで変更履歴を "ChangeLog" というファイルに書いたのが ChangeLog のおこりだと思う. 最近は Subversion などに登録された変更履歴も change log, あるいは commit log などと呼ぶ. 以下ではそれらを ChangeLog と総称する. 最近わけあってこの ChangeLog をどう書いたものかと考えている. コーディング規約には山ほど資料がある. コメントの書き方もよく議論される. しかし ChangeLog についての読み物は少い. GNU コーディング規約 は数少ないそうした文書である. この説明はよくかけている: ChangeLog は将来のメンテナがバグの原因を探るのに使うものだ. コメントに書くべきものはコメントに書け. 関数名を並べろ...
steps to phantasien t(2006-10-31) To BLOB or Not To BLOB
なんとなく Jim Gray のページ を見ていたら, "To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?" という記事があった. データベース業界には "ちまいデータは BLOB に入れろ, でかいデータはファイルに置け" という口伝があるらしい. (業界ビトでない私はしらなかった...) でも "でかい" って具体的にどのくらいなんだろう. 実験/ベンチマークをして BLOB とファイルシステムを比較, 疑問に答えましたよというのがこの記事. このごろはビデオや写真をウェブに置くのもふつうになりつつある. そういうメディアなデータを保存する世相を知っておくのはいいかもしれない. 読んでみた. この実験では BLOB の実装に MS SQLServer, ファイルシステムに NTFS を
RDB の FTS 拡張
2006-10-02 近況 sqlite を眺めていたとき私がもともと何をしていたかというと, RDB への全文検索(Fulltext Search: FTS)をつなぎ方を探していた. flino で使った HSQL は FTS に対応していない. 以前 Lucene あたりを繋げないものかとコードを覗いたけれど, 敷居は高そうだった. (Java のくせに sqlite より modular でない気がする.) よく見ると HSQL は BLOB にも対応していない. 結局ファイルと Lucene をアプリケーション側で管理している. いまいち. で, 今回はそのリベンジを目論んでいたのだった. (結局 sqlite をいじっているうちにストレス解消は完了.) 世の中を眺めてみると, RDB に FTS を繋ごうとする試みは多い. MySQL や PostgreSQL は FTS に対応
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
