ISUCON5 で準優勝しました - 鳩舎
今年も @mirakui と @sora_h と一緒に ISUCON5 に出場して、準優勝しました。 やったこと 時間は投入した時間。 12:00 : API リクエストを送る先の services が DB に入ってるけど大した数でもない(7つ)ので、全部アプリケーションにハードコードした。 これはのちにリクエストにプロキシを挟む時にコード変更だけでよくなったので地味に効いた。なお、これによる高速化はあんまりしなかった(そりゃそうだ)。 13:16 : API リクエストへのパラメータを保存している subscriptions の保管先を DB から Redis へ変更。 DB 問い合わせへの高速化というより、 JSON 形式から MessagePack 形式での保存になったことの方が重要な気がしてる ま、これも大した効果は出てない。 initialize でバグったら話にならないから、
ISUCON5 予選でアニメ見た - 鳩舎
今年は参加者側として ISUCON5 に出てきました。チームは白金動物園。いつもの(@sora_h, @mirakui)メンツです。 何やってたかについては大体 sorahのエントリ に書いてあるので割愛。というか前頭葉破壊されて覚えてないです。 真剣な与太話 9:30 チームビルディングと称して アイカツ! #152 を見る 10:00 チームビルディングの一環でリアルタイムでプリパラ #64 を見て、前頭葉を破壊される 10:30 チームビルディング、そして緊張を解くために ゆるゆり なちゅやちゅみ!+ +2 を見る これを見てなにやってるんだと思われたかもしれませんが、あくまで僕に限った話(二人はどうだったか知らない)をすると、これは本当に助かった。 開始前の9:00時点だと、リラックスしてるつもりだったけど『前回の問題作ったヤツが予選敗退とか笑えない冗談だろ』みたいな感じで、めちゃ
ISUCON4 お疲れ様でした - 鳩舎
今回の ISUCON 、みんなはどうだったかな？楽しかったかな？ベンチマーカーについての文句？いいよ、こいよ、俺がベンチマーカー実装者だ。 ということで、まずはお詫びを。今回、過去の ISUCON に比べて本当にトラブルが多くて申し訳なかったです。次の出題者になれる機会があるならば、本当にもっとしっかりしたいと強く思っています。本当に、申し訳なかった。 あとは後悔を。正直当日まで実感なかったし、朝の方も徹夜明けであんまわかってなかったんだけど、昼飯が喉を通らないところでストレス過多で死にそうになってることに気づいた。いやーだって考えてみたら今まさに僕よりすごいエンジニアが僕のベンチマーカーを叩き潰すために全神経を注いでるわけですよ。そりゃ胃痛もするわ。もう二度と出題者になんてなりたくないね。 問題についての詳しい解説や、講評なんかは後日 ISUCON 公式ブログの方に乗せてもらえると思うの
speed_gun で Rails のパフォーマンスを測定する - 鳩舎
Web アプリケーションのパフォーマンスにうるさいみなさんこんにちは。 Rails アプリのパフォーマンスプロファイリングだと、 rack-mini-profiler が有名で、それ以外だと New Relic とかを使って測定していくのが普通のようですが、物足りない部分があったので、自前でプロファイラ gem を作りました。 Rubygems: http://rubygems.org/gems/speed_gun / Github: https://github.com/rosylilly/speed_gun 詳細は Github の README なんかを見ていただくとして、基本的には rack-mini-profiler 的な情報収集が出来ると思ってもらって差し支えないです。 ちなみに計測画面はこんな感じ。 大きなスクリーンショットはこちら 小さくて何も見えないかも……とりあえず3セ
golang を始めた時 - 鳩舎
そういやまだ新しい経験だから覚えてるし、 golang を勉強していった過程を書いておく。 正しさとかは気にせず、動くものが出来るまでがむしゃらに。 Hello, world まで 特にひねりはない。 homebrew は便利だ。 $ brew install go $ cd ~ $ mkdir -p go/src/hello_world $ export GOPATH=${HOME}/go $ cd go/src/hello_world $ cat main.go package main import "fmt" func main() { fmt.Println("hello, world") } $ go run main.go hello, world 手軽。 入門、そして組み込みパッケージを使う http://golang.org/pkg/ に組み込みパッケージの一覧があるので
Gondler という bundler for golang を作った - 鳩舎
2番煎じ乙。 Gondler という Bundler みたいなツールを go 向けに作りました。gom という先行実装があるのでもう作らんでもええかな感があったのですが、Ruby っぽいけど Ruby じゃない Gomfile とか、bundle exec 相当の機能がないとか、そういう理由でわざわざ自作しました。 基本的には bundler なので、バージョン、というよりコミットハッシュとかをロックするのに使います。 fork 元の gom との違いは インストール先ディレクトリがデフォルトでは .gondler になっている(変更可能(gom は変えられない)) Gondler 環境下の repl が起動できる(gondler repl) Gomfile を自動生成する機能はない Travis 用の yml を自動生成する機能はない bundle exec 相当の gondler ex
gofu is tofu clone implemented by golang - 鳩舎
go 言語かけるようになるとメス鳩のウケが良いと聞いたので頑張って勉強しました。リリースは大安か友引の日を選ぶタイプの鳩、ロージーです。 gofu(護符) という、弊社の id:mirakui さんが作ったイケてる画像リサイズサーバー、 tofu の go 実装です(tofu についてはこのへんを見ると良いです)。 もちろん全部機能が載ってるわけでもなく、ひみつのハッシュ値あたりとかはどう実装されてるのか知らんし今回必要ないのでつけてません。 護符が出来ることは以下で全てです。 S3 から画像をとってきて表示することが出来ます(/image/path.jpg にアクセスすると S3 の /image/path.jpg を取ってきます) 取ってきた画像からは自動的に Exif その他のメタ情報が消えています。 これらのパラメータでリサイズなどの処理を付与できます。 w : 画像の横幅を変更し
関連モデルの命名 - 鳩舎
今日は Rails での『関連モデル』の名前について考える。 構造としてはこんな感じ。 ・ルーム(Room)に所属するユーザー(User) ・ルーム(Room)での管理者権限を持つユーザー(User) どちらの関連も N:N の関連。いわゆる has_may な感じ。 で、こういう時の命名って Room モデルと User モデルだから RoomUser とか UserRoom とかっていうモデルやテーブルを作りがちなのだけれど、今回は同様の形態の関連が2つあるのでちょっと微妙な事になりそう。 っていうか、まずもって RoomUser モデルってなんだよ。なんのモデルだよそれ。って感じなので名前を考える。 ルーム(Room)に所属するユーザー(User) 関連モデルのデータは大抵2つのフィールドを持っている。 Migration あたりから抜き出すと t.references :room
適切な名前がつかないモデル - 鳩舎
ちょっと目についたので。Dis りたい訳じゃないです。 これ適切な名前が見つからないとき困るんだよなぁ。あとで思いついて変更なんて作業はしたくないし。割り切ってRoomUser式に統一した方が気が楽だと思う。 http://b.hatena.ne.jp/kensatou/20130512#bookmark-145186810 id:kensatou さんの言う『適切な名前が見つからない時』がわからないのでなんとも言いがたいのですが、割りきって RoomUser 式に統一は悪手だと僕は思っています。 大体からして何らかの案件なり要望なり青写真なりをモデルに落とし込んでいる時に『名前がつかないモデル』が出てくるということは、それは何かが噛み合っていない状況のアラートだと思っています。 ぱっと思いつく状況だと 英語力が足りない: 僕は大抵このパターンなので辞書を引きます。それでもわかんなかったら
プログラミングの話 - 鳩舎
この辺見て、いつも思ってること。 プログラミングはアプリを作ることの手段なのか - 銀の人のメモ帳 プログラミングはそれ自体が目的であっていい - mizchi log プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 プログラミングは手段です。僕にとっては。 「動けばいいコード」は糞コードだ でしょうね。としか言い様がないです。 あえて例え話にして、プログラミングを車の運転だとします。プログラマは運転手です。 でまぁ、アプリを作るってのが伊豆の旅館に行くことだとしましょう。この時、僕の運転する目的は伊豆に行くことです。間違っても運転することは目的じゃないです。なので別に運転に特に気を使うことはありません。 そこに突然 F1 ドライバーがやってきて、『お前のカーブの曲がり方は下手くそだ』とか『もっといいルート選択がある』とか『こんな運転の仕方じゃガソリン代がもったいな
repl がザコなので reel を作った - 鳩舎
昔 brew install repl 便利 - 鳩舎 で repl というのを紹介したけど、これの補完が貧弱すぎて git なんかだとオプションがわからなくて実用に耐えなくてクソザコだったので reel というのを風邪を直したリハビリがてら書いた。まだ rubygems にあげてない。 git の補完が書き終わったらあげる。 Github: rosylilly/reel 使い方は README に書いてある通り。オプションまわりがちょっとめんどくさいので治したい気分。補完を書くのが大変なので、このへんを誰かにやらせたい。Rakefile の補完とかキャッシュできるので高速に動いて便利だと思う。Rails も。 補完に甘やかされた今時のゆとりに補完のない環境を与えると死ぬ。
git-助けてというすごく便利なエイリアスを作った - 鳩舎
こんばんは！暑い！ ということで今日はgitのすごく便利なエイリアスを作りました。 Git-助けて https://github.com/rosylilly/git-tasukete という、超便利コマンド集です。 使い方はホームディレクトリあたりにクローンしてきて、パスを通しておくだけです。 するとあら不思議、ターミナルに $ git 助けて と打つだけで、助かりたい時の場合がリストで出てきます。 後はそのうち、目的の状況のモノをターミナルにコピペするだけです。ほらね $ git mergeを取り消したい はい、マージが取り消せました。よかったよかったー！ こんな困った場合にも対応してください！というのはGitHubのissueか、コメント欄にて受け付けてます！
リリース先輩というIRCボットを作った - 鳩舎
こんにちは、皆さんgit使いこなしてますか？僕は全然です。 ところでgit個人的に使う分にはいいですけど、会社の許可取るのとかは大変ですよね。できる限りSVNで管理したい。 ということでとあるチームではgitで基本的にソースコードを管理して、デプロイ時はsvnに置く、というようなことをしています。なんだか二度手間な感じもしますが、まぁやっておけばいいのであればやっておきましょう。 ところがどっこいgit-svnはとてもめんどくさい。めんどくさいしgitに慣れきった人間はsvnでコミットすることができない。できないなら機械に任せよう。 ということでどうせ毎回同じ事をするので「リリース先輩」というIRCボットを作って、先輩によろしくやってもらうことにしました。 リリース先輩 IRCで rosylilly: release_senpai: 先輩、リリースの準備お願いします！ release_se
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails 4.1.0.rc2 で AR オブジェクトその他の #to_json に Oj を使う - 鳩舎
DCI の話をした - 鳩舎