10もないかも、と思いながら項目を書き出してみたら10以上余裕であってキリがないので10で収めた。いやあ、あるなあ。 仕事柄よくベンチマークを実行したりしてて色々と思うところが溜まっていたところ、以下のような記事を見掛けたのでなんか書こうと思った。ところでこの記事はベンチマークを実行するための準備作業がループを回して2時間かかるところの待ち時間に書かれている。 sfujiwara.hatenablog.com ISUCONといえば多少縁があるコンテストで、文中でISUCON5のことについても言及されているので、それも含めて。 自分が業務でいじっているのは "Webアプリケーション" というとちょっと違うんじゃないのというものばかりだが、いやー、最近なんでもHTTPで外部APIを作るからベンチマークのコツとしては大体変わんなかったりするよね。 なおこの記事でベンチマークはどのようなものかとか

でっかい主語で入ったが、要するに2月にあちこち会社巡りをしたときに感じたことについてつらつら書こう、というのが目的。 特定の会社について書いてもしょうがないので、あれこれ*1回ったうちから少なくとも2〜3ケースで該当するなあ、と思ったことについて書く。特定の1社のみに該当する事項はこのエントリにはひとつも出てきません。 またエントリの主旨からして超上から目線になりますが、どうかご容赦ください。 これから成長が本格化するのでインフラを支えられる人材がほしい 正直に言ってこれが一番多かったパターン。スタートアップ的にサービスを作ってきたがその一方でデプロイや監視などの運用まわりが後手後手になっており、そのあたりを支えられる人物がほしい。 話としてはわかるのだが、気になったのは、これを聞くとき、詳しい内容を突っ込んでみると、どうも実際にはそう困ってはいない、というケースがほとんどだったように思え

Node.jsでWebアプリを書いてるんだけど別に大量のリクエストをさばくわけでもないしWebSocketも使ってないし、じゃあなんでそんなことしてんの、という話。 まず結論だけ書くと、 並列度が低くてよいが長時間かかることが確定的な処理を非同期的に走らせる必要がある場合、普通はそのような用途でもJobQueue/Workerを使って構成するがそういうのは管理も面倒だしインストールも面倒くさくなるのであんまりやりたくない。Node.jsなら普通のWebアプリケーションフレームワークだけでラクに書けていいんじゃね？ というひとつの提案です。 同期実行のケース 普通Webアプリケーションフレームワークというのは、一連の処理はクライアントにレスポンスを返すことで完了する。そしてひとつのプロセス/スレッドはリクエストをディスパッチされてからレスポンスを返すまでがそのリクエストに占有される。 ここで

先日書いたエントリでも触れたけど、日本OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、本当にありがとうございます。 「第9回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を

先にまとめ 現在の勤務先を退職することにしました。本日が最終出社日です。 次はまだ決まっていません。というか、どことも具体的な話はまだしていない、という段階です。面白そうな職場はどこにあるかなと探している段階ですので、魅力的なところに心当たりがある方はぜひご連絡ください。色々な人と話ができるといいなあと思っています。 現職について 11月半ばくらいまでは転職はまったく考えていませんでした。が、その頃の世間の技術的な流れなどを見ていて、ちょっと技術的に異なることをやろうかなあ、と考えたのが直接的な理由です。今後どうするかを考えたとき、せっかくなら働く環境なども変えてしまった方がこれからの人生が刺激の多いものになりそうだということで、現職を退職することを決めました。 やりたいことを変えるだけなら社内でやればいいだろう、という話を会社側からはされましたし、もっともなことでもあるのですが、同時に前

ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら

みんな大好きFluentdはプラグインも自由に書けて好き放題にリアルタイム集計を行うことが可能なわけですが、やりたい処理にあわせて無限にプラグインを書き続けてるとプラグインの数が爆発し何がどんな処理をしているのかもよくわからず混乱の海に呑まれて消えるという未来がみなさんの脳裏にもおそらく想像されていることと思います。 で、世の中にはCEPエンジンというものがあってストリーム状に流れてくるイベントデータに対して処理を行う仕組みがあるわけですね。これ使いたい！ しかもあれだ、簡単に処理が書けるものがいい！ 何が言いたいかと言うとWE NEEEED xQL!!!!!!!!!!!!!!! そんなようなことをこちらのエントリを書いたときに思ったわけです。 http://tagomoris.hatenablog.com/entry/2013/02/19/142017 で、RubyKaigiにも通っちゃ

結論を先に書くと「trunk使え」か？(ぇー まあ2.2.4でもなんとかなるかも。2.2.3以前だとかなり注意しないと、道を踏み外した瞬間に穴にハマりそう。 で、以下リスト。 trunkで修正されているもの Critical: リクエストが間違ったワーカーに配送される Bugzilla 40910 ポート番号に限らずホスト名(/IPアドレス)の部分一致でも発生する はてなの中の人が発見 追試済み 配送先が ajp:// の場合は正常に動作する？　らしいという情報がある(未確認) stickysession/routeによるルーティングが有効でもこのバグにひっかかる 部分一致するホスト名のうち長いものを設定ファイル上で先に書いておくと回避できる 2.2.4で修正済みのもの Critical: 一度エラーになったセッションがTimeoutを過ぎてもエラーから復帰しない Bugzilla 389

今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、