OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場
「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な食事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート（1, 2）を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か？ 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
WebSocket(RFC 6455)上で使用するプロトコル設計についての備忘録 - kazuhoのメモ置き場
一般論として、全二重の通信プロトコルを実装するにあたっては、いくつか注意すべき点があって、具体的には、到達確認と切断シーケンスについて定めておかないと、送達されたはずのメッセージがロストしていたり、切断タイミングによってエラーが発生*1したりする。 具体例をあげると、たとえばTCP/IPにおいてshutdown(2)を用いずに、いきなりclose(2)を呼んでいると、read(2)やwrite(2)がエラー(ECONNRESET)を返す場合がある。 翻って、WebSocket (RFC6455)の場合はどうなってるか？ だいたい以下のような感じっぽい。 ws.close()が呼び出されるとWebSocketをCLOSING状態に変更し、Closeフレームを送信する ws.onmessageはWebCosketがCLOSING状態にある間も呼ばれるかもしれない*2 相手からCloseフレーム
「今日使われているプログラミング言語の多くは、なぜ1990年前後に誕生したものなのか」に関する一考察 - kazuhoのメモ置き場
若い人たちは、「文字列型」があるプログラミング言語しか知らないかもしれない。だが、汎用的な文字列型が一般的になったのは、プログラミング言語の歴史の中でも比較的最近のことである。 たとえば、1972年に誕生したC言語には文字列型がない。1980年代に良く使われていたPascalの文字列型は最大255文字しか格納できなかった。 なぜか？ それはメモリが貴重なリソースだったから。 1980年代のPCの搭載メモリは多くて数メガバイト。これに対し、長編小説の長さは1MB程度に達する*1。 当時、メモリはとても貴重な資源であり、テキストを処理するプログラムを開発するにあたっては、文字列をどのようにメモリ内に展開するかプログラマが細かくコーディングする必要があった。 だから、汎用的な「文字列型」というのは「夢」にすぎなかった。CあるいはPascalにおける文字列（CのASCIIZ文字列あるいはPasca
GCとかロケット科学すぎてウェブサービス屋さんには似合わない - kazuhoのメモ置き場
※タイトルは釣りです。 先のエントリで、 採るべき技術的アプローチに関しては、ソフトウェアの修正コストによってかわるという議論があって、ウェブサービスの場合にはソフトウェア製品（やSI)と比べて圧倒的に修正コストが安い。ウェブサービスの場合にロケット科学的な「正しいけど大げさ」なアプローチよりも、小さく作って動かしながら修正していく手法が好まれるのにはそういう背景もある ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場 と書いた件、GCを例にあげて説明します。 ソフトウェアを製品として出荷するビジネスは、修正コストが高いです*1。企業向けソフトウェアなら、管理者がアップデートをインストールしなけりゃいけないし、それによって不具合が発生していないか結合試験が必要になるかもしれないし、場合によって南極まで出張して…ごにょごにょ。 こういう
オレオレ認証局の適切な運用とName Constraints - kazuhoのメモ置き場
オレオレ認証局が忌避されるべきものとされてきた理由は、X.509 PKIが保証する安全性は、最も信頼性が低い認証局（trusted root）のそれに等しいからです。 しかし、X.509 v3以降ではName Constraintsが導入され、「特定のドメインに対してのみ証明書を発行可能な認証局」を定義できるようになっており、同constraintをcritical key usage extension*1として宣言したルート証明書を安全な経路で配布、インストールすることができれば、上記のようなX.509 PKIの系全体に対する影響は発生しないことになります*2。 ここで問題になるのは、どの程度のウェブブラウザがName Constraintsに対応しているのか、という点になりますがhttps://news.ycombinator.com/item?id=5194103によると、Chro
mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので３分で書く。 オープンソースライセンスは、以下の３種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い（そしてどちらを選んでも問題ない）。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ： ライセンスの解釈については、
同時にwrite(2)すると混ざるかどうか - kazuhoのメモ置き場
Linux のシステムコールである write(2) の ドキュメントを読むと Atomic/non-atomic: A write is atomic if the whole amount written in one operation is not interleaved with data from any other process. This is useful when there are multiple writers sending data to a single reader. Applications need to know how large a write request can be expected to be performed atomically. This maximum is called {PIPE_BUF}. This volume of
サービスごとに異なるパスワードを使い分ける方法 - kazuhoのメモ置き場
最近、パスワードの使い回しをしているユーザーに対する攻撃が出回るようになってきています (参照: パスワード攻撃に対抗するWebサイト側セキュリティ強化策 | 徳丸浩の日記) が、マスタパスワードからサービスごとに異なるパスワードを自動生成するのが簡単な対策ですよね。 プログラマなら（もしくはコマンドライン操作に慣れているのなら）、こんな感じでできるかなーと思います。 $ perl -MDigest::HMAC_SHA1 -wle 'print Digest::HMAC_SHA1->new($ARGV[0])->add($ARGV[1])->b64digest' "my-master-password" example.com Mau83v+ml6dRViOZhcRdHM0NXzY $HMAC 関数にマスターパスワードとサービスのドメイン名を食わせて、その出力をサービス専用のパスワードにす
巨大な bookmarklet を信頼できる形で配布する方法 - kazuhoのメモ置き場
Twitter で聞いてみたところ @hasegawayosuke さんいわく、Bookmarklet の文字数制限は最短だと約2,000文字らしいです。 でも、その長さで bookmarklet を書くのって難しいですよね。かといって、別のサーバから JavaScript をダウンロードして実行するとなると、そのダウンロードされたスクリプトが安全か、という問題が出てきます。 ならば、暗号学的ハッシュ関数を2,000文字以下で実装し、ダウンロードしたスクリプトの改ざん検証を行った上で実行すればいいのではないか。そうすれば、文字数の制限に悩むことなく Bookmarklet の開発に勤しめるのではないでしょうか。 ジャジャーン！というわけで、とても短い SHA-1 の JavaScript 実装を作りました*1。 GitHub - kazuho/sha1.min.js: SHA-1 impl
Test::mysqld 0.17 でテストがもっと簡単になる話 - kazuhoのメモ置き場
Test::mysqldというモジュールがあって、MySQLを使うテストを簡単に書けるので好評なわけですが、今回これに copy_data_from って、既存のデータディレクトリをコピーして mysqld を起動するオプションを足しました。 このオプションを使うことで、以下のように MySQL データベースからコピーしたデータを使うテストを書くことができるようになっています。 use Test::mysqld; my $mysqld = Test::mysqld->new({ my_cnf => { 'skip-networking' => '', }, copy_data_from => 't/mysql.data', # mysqld の data ディレクトリをコピーしたやつ }) or die $Test::mysqld::errstr; my $dbh = DBI->conne
なぜPHPでrequire("http://...")したらセキュリティホールなのに、Goならいいのか - kazuhoのメモ置き場
go言語なんか import "http://github.com/mattn/xxx " だったりする。rubyもそういうの面白いかもしれない。require "http://github.com/mattn/xxx "みたいな。 mattn on Twitter: "go言語なんか import "http://t.co/9qiwho7OMZ" だったりする。rubyもそういうの面白いかもしれない。require "http://t.co/9qiwho7OMZ"みたいな。" @mattn_jp それコンパイル型言語なら許されるけどスクリプト型だとセキュリティホールとされるものでは？ (e.g. PHP) Kazuho Oku on Twitter: "@mattn_jp それコンパイル型言語なら許されるけどスクリプト型だとセキュリティホールとされるものでは？ (e.g. PHP)" と
なぜ動的型付けの言語が流行ったのか (Re 静的型付けと動的型付けのどちらが優れているかという話) - kazuhoのメモ置き場
静的型付けと動的型付けのどっちが優れているか。どのようなプログラムを書いているかによって答えはかわるんじゃないの？ たとえば、自社で開発・運用しているウェブサービスなら「問題が出たら修正」すればいいんだし、バグがないことを保証するよりも迅速に開発できるプログラミング言語（つまり動的型付けの言語）がいい。 逆に、客先への納品が発生するソフトウェア製品なら「バグがない形で出荷する（様々な状況・環境下でちゃんと動作する）」ことが重要だから、静的型付けの言語を使うことで品質を高めるというのは合理的な選択*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
Mac OS Xで、再起動せずにスワップを解放する方法 - kazuhoのメモ置き場
Mac を使っていて、だんだん動きがもっさりしてきたなー*1と思って /private/var/vm/ 下を見ると、案の定スワップファイルが溜まっていることがある。 こういうケースでの対策としては、・スワップ禁止にする、・/usr/sbin/purgeする、・再起動する、といった手があるけど、スワップ禁止にするのは本当にメモリ不足になる可能性を考えると怖いし、purgeはスワップアウトしたデータを回収してくれないので効果は一時的だし、再起動はめんどい。 そんな場合は、処理が落ち着いたタイミングで以下のようにして、スワップを実メモリに書き戻せばよい*2。スワップファイルも全部消える。 $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist $ sudo launchctl load
Xcode を使わずに iOS 向けのコードをコンパイルする方法 - kazuhoのメモ置き場
# armv7 clang -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk -c mattn.c ar mattn-armv7.a mattn.o ranlib mattn-armv7.a # i386 clang -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk -c mattn.c ar mattn-i386.a mattn.o ranlib mattn-i386.a
JavaScript(V8)で避けるべき(だった?)クロージャの使い方 - kazuhoのメモ置き場
Grokking V8 closures for fun (and profit?) に、ほんの少しだけ触れられている話なんですが。 ごく最近まで V8 には、オブジェクトリテラルの中で関数リテラルを使った場合に非常に遅くなる(というかGCが多発する)問題があった。 たとえば、 function doit() { for (var i = 0; i < 1000; ++i) { for (var j = 0; j < 1000; ++j) { var o = { f: function () { return i + j; } }; } } } doit(); というコードを node-0.6.19 で実行すると、以下のように mark-sweep GC が大量に発生して処理に時間がかかっていることが分かる。 $ time /usr/local/node-0.6.19/bin/node -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gzipされたcore-fileをスパースファイルとして展開する方法 - kazuhoのメモ置き場
