2007-04-22
昨日のエントリに、事前に設計を固めるなんてことはユーザーの意見を無視しかねず、危険であるという話に絡むことで、プログラミングに関しては、そもそも設計とコーディングを分けること自体が何かおかしいという話。 まずは、前川徹の「日本のソフトウェアに未来はあるか」 連載第2回 ソフトウェア開発におけるパラダイムシフトの、「「計画を立てそれを実行する」方式は正しいか」を読むと、下のような図がある。 Hotwired Japan 前川徹の「日本のソフトウェアに未来はあるか」より引用 この記事ではこの図が間違っていることが説かれているのだが、この図にもその先の説明にも、どうも違和感を覚える。 私がプログラムを作るときの感覚は、次の図のようなものである。 ウォーターフォールモデルの図と比べると、全然違う。 「要件定義」と「つくりたい」を、「使う」と「保守」を同じ地点だとすれば（そこのところは今回の話題では
MessagePack for Java ついに 0.6 リリース！ - Blog by Sadayuki Furuhashi
先日の fluent に引き続き、新しいソフトウェアのリリースです。 満を持して、MessagePack for Java 0.6 をリリースしました！ 9ヶ月ぶりのメジャーバージョンアップです。 以前のバージョン 0.5 の API をすべて見直し、互換性を維持しながらも、数多くの機能を新たに搭載しました。動的オブジェクトAPI や リフレクション機能の強化、JRubyとの連携、JSONサポート などなど。もちろん、性能も大きく向上しています。 このバージョン 0.6 のリリースによって、MessagePack の応用範囲は大きく広がります。MessagePackは、クラウドシステムからモバイルデバイスデバイスまで、多種多様なシステムの連携と統合をサポートする、新しいデータ表現形式です。 さて、新機能の詳細をご覧下さい： JSONシリアライザ･デシリアライザを統合 MessagePack
Protocol Buffersは遅い - Blog by Sadayuki Furuhashi
Google の Protocol Buffers は、同技術と競合するバイナリシリアライズ形式である MessagePack と比べて、場合によっては 19倍 以上遅く、シリアライズ後のデータサイズは 7倍 以上になることがあります。平均的に見ると MessagePack の方が高速であり、高い性能が必要とされるなら Protocol Buffers より MessagePack を選択するべきです。 …とはいえどちらも非常に高速なので、実際にはそのAPIの違いで選んだ方が良い。Protocol Buffers と MessagePack は重視している点が異なり、使い勝手は大きく異なる。 Protocol Buffers とは何か Protocol BuffersはGoogleが開発したバイナリエンコード手法で、以下のような要素が提供されます： データフォーマットを記述するための言語（
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
