Testing JavaScript with node.js - tokuhirom's blog
http://d.hatena.ne.jp/gfx/20110206/1296979666 JavaScript のライブラリやアプリケーションなどを JE でテストしたりするのは、筋が悪いとかんじます。創りかけのものを創りかけのものでテストするのは、時間の無駄になりやすいからです。 最近では v8(の一ラッパーとしての node.js)やSpiderMonkey などが用意に手にはいるので、これを利用すればよろしい。CommonJS などというものもでてきており、最近ではサーバーサイドでのテストもかんたんになりつつあるだろうし ということで、mustache.js をテストするスクリプトを以下にあげる。これは node.js でテストする場合です。JavaScript で簡易的な TAP Producer を実装してみたけども、これよりちゃんとしたものを誰か node-test-simp
web application 開発における git のブランチ運用ルール - tokuhirom's blog
俺は普段こういう運用でやっているが、君はどうか。 社内の trac にドキュメントをかいたので、コピペしておく。git についてはカジュアルにつかってるだけなので、もっとこうしたほうがいいんじゃねえのというのがあればおしえてください。 ブランチ命名規則master 本番の deploy 用。誰かに deploy されてこまるものはいれない。stg ステージングの deploy 用iss(\d+) チケット$1 用の topic branch。master から分岐させるその他、キャンペーン関係など、おいやすくしたい者は別途名前つけてもよし。 stg の運用基本的に、開発はチケットにひもづく topic branch でおこなうので、以下のような作業フローとなる git co master git co -b issXXX # トピックブランチをきる ... # development gi
HTTP/1.1 における Keep-Alive と HEAD の関係性について - tokuhirom's blog
HTTP/1.1 においては、HEAD リクエストの場合には Message Body を送信してはならないということにはなっているのですが、現実的には、Message Body をおくりかえしてくるアホなサーバーがおおい。たとえば Plack では Plack::Middleware::Head を明示的に使用していない場合、普通にやると HEAD でも message body をかえしてしまうだろう。 というわけで、HEAD で Message Body をかえしてくれるサーバーがおおいのだが、Message Body をかえされてしまうと、Keep-Alive しているときにこまる。次のリクエストとまじる。 この問題にたいするよい解決策はないので、HEAD リクエストを送信した後には connection を close してしまうのが、現実的な解決策だとおもった。 現実的には、現
LL脳な人でもこれぐらいは覚えておくとうれしいgdbのつかいかた。または猫でもわかるgdb講座 - tokuhirom's blog
LLつかってても「ばすえらーになるー」っていう状況ってたまにあるわけですが、LL しか普段つかわないゆとりは、ここでお手あげになってしまったりすることがままあります。 で、「ばすえらーになるんですが」ってときの最低限これだけはやってみたらどうか、という話。「えー、わたし gdb とかわかんないしー」とかいってる人でもこれぐらいならできるんじゃないかなーっと。 perl t/00_load.tというコマンドで segv するという場合、gdb をつかって % gdb --args perl t/00_load.tとうつ。 すると、以下のようにプロンプトがでるので、"run" とうつ。これでスクリプトがはしりはじめる。 % gdb --args perl t/00_load.t GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
TokuLog 改め だまってコードを書けよハゲ - ケータイシミュレータなんて使ってないで Moxy 使えばいいのに
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
