考えてみるとほとんどパスワードを保存するコードを書いたことがない。現状のベストプラクティスを知らなかったのでメモ書き。 現状では bcrypt 使うのがいいみたい。b は Blowfish の b。 Modular Crypt Format というフォーマットとコンパチの出力をする。crypt (3) はもともと DES の短いフォーマットだが、弱すぎたため md5 拡張なりSHA512 拡張などが存在している。(htpasswd でも使われているので見たことある人は多いだろう) これの Blowflish を使ったものが bcrypt で、prefix に $2$, $2a$, $2x$, $2y$ $2b$ がついている。prefix の違いはバージョンの違いであり、現在は 2b を使うのが良い。ストレッチング回数も出力に含まれるので、あるとき急にストレッチング回数を増やしても特に問題

リバースプロキシとして使っている h2o で proxy.reverse.url: http://localhost:5001/ みたいに書いていたら確率的に connection failure がでて悩んだ。結局 proxy.reverse.url: http://127.0.0.1:5001/ で解決 なぜこうなったか /etc/hosts に ::1 localhost のエントリ(IPv6)があり、h2o は解決したアドレスのうちからランダムに1つ選択するため。プロキシ先のバックエンドサーバは IPv6 を bind しておらず、::1 が選択された場合に接続に失敗していた。 メモ h2o がホストを選択するところ (rand している) nginx でも同様の設定をしていたが、nginx はランダムにしないみたい 最初の1つを使ってそう、IPv4を優先して配列にいれてそう トッ

http://www.sqlite.org/withoutrowid.html WITHOUT ROWID 最適化について SQLite は常に暗黙的な rowid カラムを持っていることになっている。これはカラムとして明示することもできるし、interger primary key として定義されたフィールドは暗黙的な rowid の代わりにすることができる。SQLite ではこの rowid が基本のプライマリキーになっている。 適当な数値をプライマリキーにしたい場合はこれで全く問題ないが、複合キーだったり文字列をプライマリキーにしたい場合、その表面上のプライマリキーとは別に rowid カラムができる。このケースでは表面上のプライマリキーを使って SELECT しようとすると、表面上のプライマリキーのインデックスを探したうえで、さらに rowid のインデックスを探すことになる。つま

このサーバはVPS 1台で動いていて、メモリは1GBしかありません。常時メモリ上限まで使いきっており、スワップファイルもそこそこあります。そういうわけで、できるだけメモリ消費をケチりたいのです。 稼働率の低い複数のサービスを1つのプロセスにまとめる このサーバ上で動いているサービスがいくつかあるのですが、実際のところどれも殆どアクセスはありません。一番アクセスされていてこの日記システムぐらいです。 それらのサービスをそれぞれ別プロセスで起動させておくと、たいへん無駄なので、できるだけプロセス自体を同居させています。 psgi の vhost 化 Plack::Builder が提供している mount() を使うと、vhost を実現できます。 builder { mount 'http://lowreal.net' => do { my $guard = cwd_guard("lowre

JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも

h2o の casper (cache-aware server-push) を有効にしていると、force reload したときでも push されなくなってしまって、だんだん混乱してきます。YAML を一時的に変えて再起動したりしていたのですが、自分以外にも影響が及ぶのでちょっとなんとかしました。 JS で h2o_casper クッキーを削除してからリロードする 最初に思いつく方法で手軽なやつです。以下のようなブックマークレットでリロードすると cookie がない状態からのリロードになります。 javascript:document.cookie="h2o_casper=; max-age=-1; path=/";location.reload(true); h2o へパッチをあてて、force reload 時は常に h2o_casper を無視してプッシュさせる force

すこし昔書いたGoogle Keepのメモを発掘してきました。 NASの維持コスト 電気料金 を30円/kWh、NAS の消費電力を 20W で計算すると、446円/月。24時間動かすので思いのほか電気料金がかかっていることになり、初期コストも含めて考えると、オンラインサービスと案外競合する。 NAS の特徴は 良：データが手元にある安心感 良：LANで完結するので速度が早い 悪：災害によってデータ消失が起こる 悪：自分でメンテする必要があり、故障が起こると思いがけずコストがかかる オンラインサービスの維持コスト オンラインサービスの特徴 良：災害があってもデータが失われない 良：自分でメンテナンスする必要がない 悪：大量のデータの取り出しが難しいことがある 悪：ネットワーク経由でしか入出力できないことがあるので速度が遅い 悪：サービスが終了することがある Google Drive エンド

HTTP2 化に伴なって、サイト全体の最適化を行ないました 依存の整理 もはや jQuery なしでも簡単に書けそうなスクリプト部分から jQuery 依存を抜きました。また、JSDeferred を Promise で置き換えました。 script 要素の async / defer script 要素については必要に応じて async や defer をつけるようにし、基本的に外部スクリプトでブロックする可能性を排除しました。 async は script 要素同士で独立している場合無条件につけられます (非シーケンシャル)。defer はページのDOMが構築されたあとに実行されるように遅延されます (シーケンシャル) defer は DOMContentLoaded 直前にまとめて呼ばれるようです。 外部ライブラリを自分でホスト 外部ライブラリをCDN経由でロードしている部分がありま

細い回線で Chrome のダウンローダだとうまくレジュームできないことが多々あって厳しい。キャンセルするとダウンロード途中のファイルが消えたりするし (余計なお世話だ)、大きなファイルはダウンロードしにくい。 ということで、curl でダウンロードすることにする。特にログインセッションが必要でなければ普通にやればいいが、ログインセッションが必要な場合、いちいちヘッダを全部書くのはだるいので、一度 Chrome 上で開発者ツールを開き、リクエストを発生させてすぐキャンセルし、Network ペインで該当リクエストを右クリックして Copy as cURL すると早い。 そのうえでお尻に -o filename -C - をつけてやる、つまり $ noglob curl... -o filename -C - curl... の部分はペースト。noglob は念のためつけておく。-o fil

Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え 別に SQL::Maker に限らないから気をつけろ という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな… strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。 Teng での対応 Teng を使っているとデフォルトで SQL::Maker がクエリビ