paselaのブックマーク - はてなブックマーク

テストファーストなGitワークフローについて - kazuhoのメモ置き場

Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます変更の主題を常に明確にする前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ

pasela 2014/02/04

git

リンク

サーバサイドからクライアントサイドのJavaScriptを呼び出す際のベストプラクティス - kazuhoのメモ置き場

JavaScript文字列のエスケープ – yohgaki's blog に対して、最近だと id="hoge" data-foo="<% bar %>" しておいて $("#hoge").data('foo') でとりだすのが主流かと思います。はてなブックマーク - JavaScript文字列のエスケープ – yohgaki's blog のように、そもそもJavaScriptコードを動的生成すべきでない JavaScriptコードに渡す変数はHTMLノードを経由すべきだというような反論がついています。が、はたしてそうでしょうか。僕には、元の記事の手法も、HTMLノードを経由する手法もあまり好ましくない*1ように思えます。そもそも、HTML生成時にXSS脆弱性が発生しがちなのは、タグや静的な文字列と動的に生成される文字列が混在し埋め込まれる多数の文字列を正しくエスケープ

pasela 2013/11/06

リンク

2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場

HTTP の持続的接続の功罪についてはじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。一方、持続的接続のデメリットは、接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション

pasela 2010/03/29

web
server

リンク

Apache を daemontools で管理する - kazuhoのメモ置き場

自作のサーバプログラムに、いちいち setuid とか setsid とかログローテート機能とか実装するのめんどくさいわけで。だから daemontools を使って管理してるわけですが、だったら、いっそ全部のデーモンを daemontools で一括管理したい。ちょうど、reverse proxy をセットアップする機会があったので、apache を daemontools で管理する方法を備忘録をかねてメモ。 % cat /service/httpd/run #!/bin/sh APACHE_ROOT=/usr/local/apache-2.2.14 exec 2>&1 exec pgrphack $APACHE_ROOT/bin/httpd -DNO_DETACH -DFOREGROUND -c "ErrorLog /dev/fd/1" -c "Include /var/httpd

pasela 2009/11/27

リンク

(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場

InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。他のパラメータも含めて書いておくと、データベー