DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場
「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な食事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート（1, 2）を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か？ 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複
コモンネームの位置づけ The (soon to be) not-so Common Name
※こちらの記事は2013年8月14日に投稿されたものを、GMOグローバルサインスタッフが翻訳したものです。 この記事を読んでくれている読者の中には、SSLデジタル証明書の使用方法については詳しい人もいるかもしれませんがSSLの歴史についてはあまり詳しくない人もいるかもしれません。今回はデジタル証明書の使い方の前に、デジタル証明書の核の部分について、あまり踏み込まないところを伝えていきたいと思います。 デジタル証明書とは鍵に資格情報(エンティティの ID に関する情報および識別を裏付ける他の情報)と制約情報を結合したもので、例として、”この証明書に関連した秘密鍵の所有者(エンティティ)はEmailに対して(制約情報)、ライアン・ハーストと署名する権利がある(資格情報)”と言い換えることができます。デジタル証明書の構想段階では、人やリソースといった主体（サブジェクト）と、ディレクトリ内の表示と
2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
