OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので３分で書く。 オープンソースライセンスは、以下の３種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い（そしてどちらを選んでも問題ない）。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ： ライセンスの解釈については、
node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理) - kazuhoのメモ置き場
node.js を代表とする JavaScript を用いた非同期プログラミング環境においては、コーディングパターンのベストプラクティスが共有されておらず、結果として品質の低いコードが多くなるという問題があるように思います。そこで、特にエラー処理をどう書くべきか、既存のライブラリを使う方法を紹介してみることにしました。 いきなりですが、ファイルの文字数を返す関数を作ることを考えてみます。Java だと以下のような感じになるでしょうか。countChars メソッドに注目すると、エラーを例外として扱っていて、モジュラーかつ簡潔になっていることがわかります。 class FileCounter { static long countChars(String filename) throws IOException { FileInputStream is = new FileInputStre
HTTP/1.1 の chunked encoding を使った POST / PUT を避けるべき理由 - kazuhoのメモ置き場
通信相手のサーバが HTTP/1.1 対応と確認できるまでは 1.0 と互換性のない chunked encoding は使えないし でも確認が取れた接続を使い回す = HTTP/1.1 の持続的接続を使い回して POST / PUT するってことだけど、持続的接続のタイムアウト条件は、TCP 接続確立後初回のリクエストより厳しいし 従って、POST / PUT は、べき等性がないリクエストだから持続的接続には投げるのは避けた方が無難だし ということで、基本使うべきじゃない。という話をした (http://github.com/tokuhirom/p5-Furl/commit/67c3ea52a23542a44e58869d0bcebcb53becd34a)。
SSD定点観測 - kazuhoのメモ置き場
前回の続き。９ヶ月経過。現在のヒットポイントは83/100。 あと、データセットが大きくなってきた分I/O負荷が上がってる。一見まだ余裕ありそうだけどSSDなので、書き込みが増えると読み込みがサチる点注意が必要。 $ sudo smartctl -d ata -a /dev/sdc smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: INTEL SSDSA2M160G2GC Serial Number: CVPO9404019D160AGN Firmware Version: 2
TwitterやFacebookのURLには、なぜ#!が含まれるのか (SEOとAjaxのおいしい関係) - kazuhoのメモ置き場
Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1 hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない 特にサーチエンジンのクローラ等で問題になる*2 そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。 TwitterやFacebookはこの仕様に従うことで、Ajax な UI と SEO を同時に実現している、というわけ。ということを調べたなう。 参照: Getting Started |
はてなのサーバ運用は教科書的なスケールアウト手法? - kazuhoのメモ置き場
はてなにおける SSD の実績 - mura日記 (halfrack) の感想。木を見て森を語るような話ですが、この iostat を見ていて興味深かったのが、 ボトルネックは SSD この状態だと iostat -x の ioutil は 100% にかなり近い値40%-50% 前後だと思う*1 CPU がスカスカ メモリもそんなに積んでない*2 それでも SSD を複数台つながない、ってことは、ストレージの上限にあわせて CPU とメモリをスケールダウンする方針なんだろう。絵に描いたようなスケールアウトダウンアプローチ。 高可用性はレプリケーションで確保する、と割り切るなら、サーバ毎に RAID を組んでシステムを複雑化させる必要はないし*3、方針がはっきりしてて素晴らしいな、と思った。 酔っぱらってるようなエントリだけどまだ飲んでない 追記： うちのパストラックの新サーバの X25-
テンプレートエンジン作りたい - kazuhoのメモ置き場
いちおうまとめておきます。先週末の NanoA のテンプレートエンジン - kazuhoのメモ置き場 は妥協の産物で、本当は、 なぜ、いちいちエスケープを手動で指定しなければいけないのか 文脈によって、自動的にエスケープ手法は決定できるはず と思ってます。言うまでもないかもしれませんが。たとえば以下の例。 こんにちは、<?= username ?>さん <a href="/user?id=<?= userid ?>">マイページ</a>前者は、 HTML encode するのが正しく、後者は、URI escape した後に HTML encode するのが正しい。そして、どのようなエスケープ手法を組み合わせるべきかは、テンプレートエンジンレベルで判別できること。反論としては、「テンプレートエンジンが重たくなる」というものがあり得るが、それはテンプレートをパースして実行形式に変換する際の問題
linux サーバ上のメモリの ECC 訂正回数を確認する方法 - kazuhoのメモ置き場
メモリのエラー訂正はサーバでは必須だよという話もあるけど、じゃあ実際どのくらい訂正が発生しているのか。確認するには、/sys/devices/system/edac/mc/mc*/csrow*/edac_mode が S.?ECD.?ED になっていることを確認した上で /sys/devices/system/edac/mc/mc*/csrow*/ce_count を見ればいいっぽい。 $ cat /sys/devices/system/edac/mc/mc*/csrow*/edac_mode S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED $ cat /sys/devices/system/edac/mc/mc*/csrow*/ce_count 0 0 0 0 0 0 0 0 普段作業している
Linux で共有ライブラリをビルド＆配布する際に気をつけること - kazuhoのメモ置き場
Linux の共有ライブラリをリンクするためのハッシュテーブルは、従来、.hash というセクションに収められていたのが、CentOS 5.0 や Fedora Core 6 以降? といった新しい環境では、.gnu.hash という新しいセクションに収められるようになった。 で、後者の環境で何も考えずに共有ライブラリをビルドすると、.gnu.hash セクションのみをもつものができあがるんだけど、それを Debian Etch とかに持っていくと、dlopen した際に SIGFPE で落ちてしまう。 問題を回避するためには、リンカに --hash-style=both というオプションを渡してやれば、両方のセクションが作成されるので、この問題を回避できる。 Q4M もこの問題にはまって、0.8.2 をリリースすることになりました。幸い問題を発見した人が id:hirose31 さん (
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
メモリの消費電力 - kazuhoのメモ置き場