テストにコケる度にシーザーが死ぬ仕組みを作りました - その手の平は尻もつかめるさ
タイトルは釣りです。 App::WithSound をリリース致しました。 https://github.com/moznion/App--WithSound https://metacpan.org/module/MOZNION/App-WithSound-v1.0.2/with-sound (2013.03.06 追記) App::WithSound はv1.1.0 にバージョンアップしました。 コマンドの成功・失敗時だけでなく、コマンドの実行中にも音声を再生出来るようになっています。 https://metacpan.org/module/MOZNION/App-WithSound-v1.1.0/with-sound (追記ここまで) App::WithSound? コマンドが成功するか失敗するかによって、その結果に対応した音声が流れるアプリケーションです。 まず、このモジュールはm
Plack Performance Tips - mount() and query_parameters() : D-7 <altijd in beweging>
すごいヘビーな負荷を受けているPSGIアプリケーションで「なんでこれで負荷があがるの？」的な現象があったので二つほどTipを。ちなみにこれは 2013/03/06時点での話なので、もしこれをあなたが大分将来に読んでいるのなら、状況に変更がないかちゃんと確認すること！ まずこのお話の前提：mod_perlなアプリをPSGIに移行したかった。アプリはmod_perlハンドラで書かれているので、Apache::RequestをPlack::Requestに書き換えたり、ハンドラ部分をオブジェクトにしてキレイにするくらいで、基本的な構造は何も変えてない（←ここポイント）。あとはApache側とか設定をもりもりいじって、PSGIファイルを書いて、Starletでデプロイして、パフォーマンスが30%くらい悪くなった。さて、犯人は誰でしょう？ まずアプリケーションを組む側が「やっちまったなぁ？」な件：P
DOMを高速に操作するための skin.js というライブラリを作った - mizchi log
(タイトル修正 DOMを高速に操作 => DOMの値を高速に更新 at Sat Mar 09 2013 15:30:09 GMT+0900 (JST)) (Skin#inject実装したのでタイトル元に戻した at Mar 09 2013 18:10:04 GMT+0900 (JST)) 若手の会で、JavaScript Hell on Earth というテーマで話してきました。 js_hell_on_earth http://www.rvl.io/mizchi/js_hell_on_earth というわけでDOM抽象ラッパーつくりました。 mizchi/skin.js · GitHub https://github.com/mizchi/skin.js 目的 クライアントサイドJSでは一回書いたら終わり、ではありません。ゲームなどのリッチなユーザー体験を提供する際、高頻度でDOMを書き換
おそらくはそれさえも平凡な日々: App::Xaicron構想
タスクの定期実行としてcronが使われ続けていることに問題意識を抱えている人は数多く居れども、多くは惰性で使い続けている。何を隠そう私もその1人である。 そんな中、近年ではcronの代替としてjenkinsを使うという斜め上の発想が蔓延りつつあるが、 そんなことをすると「cronに500Mもメモリ使ってられるかー」と椅子が飛ぶこと請け合いなので非常に難儀するものである。 斯くの如く問題意識を抱えていたものの、やはり惰性でcronを使い続けていたのだが、 昨日、代替cronのネーミングとして “xaicron” という非常に格好良い名前を思いついてしまったので、 この際代替cronについて考えてみることにする。 懸念事項としては、将来RPMパッケージ化などされた時に、実行ユーザーとしてxaicronが作られてしまって、 万が一xaicronというユーザー名を使っている人がいた場合に困るという
社内勉強会を居酒屋でやってみたら - HOW TO GO
ITエンジニアなので、社内で勉強会とかやってます。 ちょっと変わっているのは居酒屋で飲みながら勉強会をやっていることです。 勉強会を始めたきっかけ、やり方、その他もろもろを書いてみます。 きっかけは部署内のバラバラ感をなんとかしたかったから 昔は社内での受託開発はそこそこあったのですが、２年くらい前から激減し、今ではほぼゼロです。 今は主に客先に常駐して開発してたり、IT便利屋やってたりしてます。 そんな部署なので、 同僚が何やってるかわからない どんな技術を使ってるか知らない わからないの困った時に助けてもらうこともできないし、逆に助けることもできない。 といった感じです。こんな現状で、いい仕事ができるわけない、とモヤモヤしてました。 みんなそれなりに頑張ってる モヤモヤしてる中で同僚に愚痴ってると、 他のプロジェクトでも、それなりに新しい技術を使っていたり、 効率的な開発をする仕組みが
【絶対】PC の時計を 2099 年 12 月 31 日にしてはいけない【ダメ】 - satosystemsの日記
下手すると PC が起動しなくなります。 コンピュータには 2036 年問題というのがあって、簡単に言うと、2036 年のある時刻以降、内部時計が 1900 年に戻ってしまうというもの。まあこれぐらいならかわいらしい現象です。 僕は実際に 2099 年 12 月 31 日 23 時 59 分ちょうどに設定してみました。そこからの 1 分はまさにカタストロフィでした。 まず、常駐しているアプリが不正終了したりエラーダイアログを出したりして、1 分後の大惨事を知らない僕はこの状況を少し楽しんでいました。エラーダイアログのキャプチャなんかを撮ったりして。 Cygwin で date コマンドを打つと、196x 年ぐらいだったので、まさに 2036 年問題が発生していました。 出てきたエラーダイアログのひとつは .NET Framework のスタックトレースが出ていたので、なんだろうな、と眺めて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
