OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場
Webサービスのようなプロダクトについての議論について教えて下さい - Kentaro Kuribayashi's blog で呼ばれたような気がしてたけど放置してた。でも今日、express という node.js 上で動作するメジャーなウェブアプリケーションフレームワークを作っているチームが、次世代の製品に取り組み始めたと聞いたので、メモを以下に貼ります。 ------------------------------ ✂ ------------------------------ ソフトウェア技術の配布手法のトレンドは以下のように推移してきた。 プロプライエタリ（仕様も実装もベンダー固有） オープンシステム（仕様は共通、実装はベンダー固有） オープンソース（実装を皆で共有） ハードウェアにしても、プロプライエタリから業界標準主導なアプローチにかわってきている。 つまり、時代とともに、
GCとかロケット科学すぎてウェブサービス屋さんには似合わない - kazuhoのメモ置き場
※タイトルは釣りです。 先のエントリで、 採るべき技術的アプローチに関しては、ソフトウェアの修正コストによってかわるという議論があって、ウェブサービスの場合にはソフトウェア製品（やSI)と比べて圧倒的に修正コストが安い。ウェブサービスの場合にロケット科学的な「正しいけど大げさ」なアプローチよりも、小さく作って動かしながら修正していく手法が好まれるのにはそういう背景もある ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場 と書いた件、GCを例にあげて説明します。 ソフトウェアを製品として出荷するビジネスは、修正コストが高いです*1。企業向けソフトウェアなら、管理者がアップデートをインストールしなけりゃいけないし、それによって不具合が発生していないか結合試験が必要になるかもしれないし、場合によって南極まで出張して…ごにょごにょ。 こういう
LTSV のもうひとつのメリット、あるいは、プログラムでログを出力する際に気をつけるべきこと - kazuhoのメモ置き場
Labeled Tab-separated Values (LTSV) がブームのようです。 LTSV については、ラベルをつけることで柔軟に拡張できるという点が、その特徴として取り上げられますが、もう一点、タブをセパレータに使うことでログのパースが簡単になった、という点を忘れるべきではないでしょう。 特に httpd のログは NCSA httpd という HTTP/0.9 時代のWebサーバのログフォーマットがベースに拡張されてきたため、以下のようにセパレータとして空白、[]、ダブルクォート ("")*1が混在するという、とても処理しづらいものになっていました。どれほど複雑かは「404 Blog Not Found:perl - Apache Combined Log を LTSV に」の実装を見れば明らかでしょう。 127.0.0.1 - - [08/Feb/2012:23:52:4
perl から任意の C ライブラリを呼び出す方法 - kazuhoのメモ置き場
syscall って組込関数でシステムコールはできますけど、libc やその他ライブラリの関数を呼びたい、ってこともありますよね。i386 かつ dlopen な環境なら、こんな風に書けます。 use DynaLoader; use ops; sub ccall { my $r = '1111'; my $s = "\x68" . pack("L", $_[5]) . "\x68" . pack("L", $_[4]) . "\x68" . pack("L", $_[3]) . "\x68" . pack("L", $_[2]) . "\x68" . pack("L", $_[1]) . "\xb8" . pack("L", ("Dyna"."Loader")->can("dl_find_symbol")->(("Dyna"."Loader")->can("dl_load_file")->
MySQL on SSD に二の足を踏んでいる理由 - kazuhoのメモ置き場
やってもいいかなとは思っているんだけど、複数の SSD で冗長構成を組んだとして、故障までの期間がポアソン分布するとされる HDD と異なり、ほぼ同時に書込回数制限を突破してエラーになりそうで怖いんだよなー。memcached みたいな使い方なら、隣接するアクセスパターンの異なるノードに failover することになるから、同時故障は気にしなくていいんだろうけど。 追記: 結局はメモリセルの不良だから同時になることはないんじゃないかと言われた。なるほど。あとは SSD 内部のエラー訂正レートが S.M.A.R.T. 等で観測できれば、なんとかなるのかなぁ。(なんて言ってたら、手渡された日経エレクトロニクスの特集にちゃんと書いてあったww) Support for Intel® SSD X25-E Series Intel のサーバ向け SSD だと、S.M.A.R.T. に加えて「add
ストレージエンジンを書くにあたって知っているといいかもな知識 - kazuhoのメモ置き場
ってどのあたりなんだろ。マインドマップ的に。 たとえば memcached のストレージ書くなら、 I/O API p?(read|write)v, fsync async API? Memory Mapping API mmap, msync Multithreading pthread API various locks: mutex, rwlock, etc. あたりかなぁ。耐障害性が必要になってくるなら、 Block Device HDD, SSD block size, random vs. sequential access, etc. Journalling Replication あたりも必要？ より本格的なストレージを書くなら MVCC Transaction Data Arrangement logging, indexing, cluster index, row-b
MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場
集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに１回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に
ウェブアプリケーションと動的再構成と djbdns - kazuhoのメモ置き場
Pathtraq の (少なくとも一部) は設定ファイルにテストコードがついている。あと、動的再構成をサポートしている。でも今日あらためてその辺を見ていると optimal じゃない。 やっぱり djbdns のやり方が最高やね。 設定ファイル本体は高速にアクセス可能なバイナリファイル (cdb) 設定ファイルのソースはテキストで書く make コマンドを実行すると以下が行われる 設定ファイルの文法確認 cdb へ変換してテンポラリファイルに保存 設定ファイル本体を新しいものにアトミックに差し替え デーモンは設定ファイルの mtime? を見ていて、ファイル更新されたら再読み込み 厳密にはちょっと違うところもあるけど設計としてはこのとおりのはず。速度と保守性に優れ、かつ単純で美しい。 perl ベースのウェブアプリなら、バイナリファイルの設定形式を Storable とかにしとくといいのか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
