テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場
Webサービスのようなプロダクトについての議論について教えて下さい - Kentaro Kuribayashi's blog で呼ばれたような気がしてたけど放置してた。でも今日、express という node.js 上で動作するメジャーなウェブアプリケーションフレームワークを作っているチームが、次世代の製品に取り組み始めたと聞いたので、メモを以下に貼ります。 ------------------------------ ✂ ------------------------------ ソフトウェア技術の配布手法のトレンドは以下のように推移してきた。 プロプライエタリ（仕様も実装もベンダー固有） オープンシステム（仕様は共通、実装はベンダー固有） オープンソース（実装を皆で共有） ハードウェアにしても、プロプライエタリから業界標準主導なアプローチにかわってきている。 つまり、時代とともに、
30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので３分で書く。 オープンソースライセンスは、以下の３種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い（そしてどちらを選んでも問題ない）。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ： ライセンスの解釈については、
alarmをネストする方法 - kazuhoのメモ置き場
だいたいこんな感じ。結局使わないコードだけど。alarm(0) を呼んでからセットしてるのは、$SIG{ALRM} の差し替え中にシグナルが飛んでくる可能性を考えて。このあたりは自分がセットするシグナルハンドラの仕様によっては、高速化の余地があるはず。 sub create_nested_alarm_guard { my $old_alarm_after = Time::HiRes::alarm(0); my $old_alarm_at = $old_alarm_after ? Time::HiRes::time + $old_alarm_after : 0; my $old_alarm_handler = $SIG{ALRM}; Scope::Guard->new(sub { my $now = Time::HiRes::time; Time::HiRes::ualarm(0); $SI
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
mysql と drizzle の負荷テストツール「skyload」が凄い！ - kazuhoのメモ置き場
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
Re 分散ストレージの収束する方向 (のうち Pacific 関連の話) - kazuhoのメモ置き場
id:frsyuki さん & id:hirose31 さん、クラウドコン優勝おめでとうございます！ (参考: Interop Tokyo 2009のクラウドコンでグランプリいただきました！！ - （ひ）メモ) Pacific はリゾルバがボトルネックになるが、Consistent Hashing + double-hash-space で分散できるのではないか。データの再配置を悲観的ロックではなく楽観的ロックでやるあたりが問題になりそうか…そこはまだ考えてない。 ※2009-06-14追記：データの再分配が起こらなければ問題ないので、最初は小さく始めて動的に増やす（動的な運用）を考えなければ、台数固定で分割してやってもリゾルバは分散できそう。 分散ストレージの収束する方向 - sdyuki-devel リゾルバ自体をある程度増やすのは簡単だったりします。リーダやライターは、リゾルバクラス
Tokyo Cloud Developers Meetup #02 に参加して - kazuhoのメモ置き場
講演は ustream で見て、懇親会だけ参加してきた。かな〜り勉強になった。GAE Data Store 関連でよくわからないことがあったので、２点質問をした。 Q. entity を更新してから index を更新していると言うが、それだと unique secondary index はサポートできないと思うのだが、どうか。 A. unique secondary index については、別途テーブルを作って管理してください。 感想. 複数の、ノードを跨がる unique secondary index があると 2-phase commit 的な話になるので、その割り切りはアリなのかなー。 Q. range query をサポートしていないというが、sharded, sorted array なのに何故？ A. 上下の両界をサポートしていないだけで、片方を指定した ascendin
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
Re はやいTCPサーバの書き方 - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ について、いくつか気になった点があったので。 Nagleアルゴリズムは、相手側のACK送信をまとめてくれるものです。これは、下記の様にアプリケーション側でパケットを意識した処理を行っている場合、邪魔になることがあります。 違うと思います。自分の理解では、Nagle アルゴリズムは、ACK を受信していないデータがある場合に、次のパケットを送信しない、というものです。RFC896 から引用すると、 The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unackn
memcached を SSD で動かす方法 - id:kazuhookuのメモ置き場
Re memcachedのストレージにSSDを使うアイディア - sdyuki-devel とりあえず、新たにサーバを開発しなくても、 SSD 全体をスワップに指定 memcached を CPU + SSDドライブ数 * 4 とかに指定 SSD の I/O ってどの程度多重化するといいんだろう (NCQ まわりとか?) 10/29 追記: 手元の環境では多重化によるパフォーマンス向上は観測できなかった (Kazuho at Work: Benchmarking SSD for MySQL) memcached の使用するメモリ合計をスワップーαに設定 ってやれば、ある程度の目算はたつんじゃないかなぁと思った。というのを書こうと思って忘れてた。 個人的には、あまり実メモリ:SSD容量の比率を極端にできない→それほどおいしくない、んじゃないかと思ってるけど、そんなのは机上の空論にすぎないわけ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Thrift のインストール - kazuhoのメモ置き場