DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場
「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な食事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート（1, 2）を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か？ 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複
ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場
Webサービスのようなプロダクトについての議論について教えて下さい - Kentaro Kuribayashi's blog で呼ばれたような気がしてたけど放置してた。でも今日、express という node.js 上で動作するメジャーなウェブアプリケーションフレームワークを作っているチームが、次世代の製品に取り組み始めたと聞いたので、メモを以下に貼ります。 ------------------------------ ✂ ------------------------------ ソフトウェア技術の配布手法のトレンドは以下のように推移してきた。 プロプライエタリ（仕様も実装もベンダー固有） オープンシステム（仕様は共通、実装はベンダー固有） オープンソース（実装を皆で共有） ハードウェアにしても、プロプライエタリから業界標準主導なアプローチにかわってきている。 つまり、時代とともに、
パスワードをソルトつきハッシュ化してDBに保存するのがベストプラクティス…とは限らないという話 - kazuhoのメモ置き場
フレームワークの責務とセキュリティ - MugeSoの日記についての感想文です。 世の中にはたくさんの通信プロトコルが存在し、中には、特定の条件でパスワードを含む文字列をハッシュ化した値を検証しなければならないものも含まれています。 例えば、HTTP Digest認証の場合は、MD5("realm:user:password")を保存しておく必要がありますし、APOPの場合は生のパスワードを、CRAM-MD5の場合はMD5("password")を保存しておく必要があったはず。 で、こういった様々なプロトコルに対応可能な認証データベースを準備しようとすると、パスワードを復号可能な方式で保存しておく必要があります*1。 ただ、パスワードを復号可能な方式で保存するとか、開発者あるいは管理者としてやりたくないというのはもちろんそうなので。で、長期的には世の中どこへ向かってるかというと： 選択肢a
30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので３分で書く。 オープンソースライセンスは、以下の３種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い（そしてどちらを選んでも問題ない）。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ： ライセンスの解釈については、
MySQL用にランキング専用ストレージエンジンを作る話 - kazuhoのメモ置き場
前提: ゲームに限らずランキング機能が必要になるケースは多い つまり需要はある だが、MySQLで高速なランキング表示は難しい 具体的に言うと、以下の要件を満たすのが不可能 １行の更新コストが要素数Nに対して O(log N) 以下 任意のランキング位置周辺のSELECTコストが O(log N) 以下 ならば、専用のストレージエンジンを作ればいいのではないか いつやるか？ 今でしょ！ 以下理由 MySQL 5.5以降?だとストレージエンジンをまたぐトランザクションがまともになってるはず*1 ランキング専用でいいから、テーブル構造とか固定でいい（つまり実装が簡単！） ランキング専用だから、テーブル・ロックで十分（つまり実装が簡単！） 更新すると順位がずれる（つまりテーブルの大部分に影響がある）ので行ロック実装するメリットが小さい*2 ランキング専用でいいから、全データをメモリにもっても問題
JavaScriptのTyped Arrayのコピー - kazuhoのメモ置き場
JavaScriptのTyped Arrayにおいて、JavaのSystem.arraycopy相当の関数は以下のような形で実装することができる。 function arraycopy(src, srcPos, dest, destPos, length) { dest.set(src.subarray(srcPos, length), destPos); }
ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
JavaScript で任意の漢字にマッチする正規表現を書く - kazuhoのメモ置き場
重箱の隅で恐縮ですが。弾さんは (function(e){ e.innerHTML = e.innerHTML.replace( /東京都?([\u3200-\u4DBF\u4E00-\u9FFF\uF900-\uFAFF]+)/g, '首都$1東京' ) })(document.body)漢字を判定する正規表現が工夫のしどころでしょうか。[一-龠]はUnicode時代にはちょっと古い。grep CJK /usr/local/lib/perl5/5.10.0/unicore/Blocks.txtが参考資料代わりです。CJK Unified Ideographだけ欲しければ[\u4E00-\u9FFF]でも行けます。 404 Blog Not Found:javascript+regexp - ていうか首都最強東京bookmarklet とおっしゃってるけど、[\u4E00-\u9FFF]
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
