Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな

調べてみた。動作確認用のサーバは plackup で立てている。 app.psgi の中身は一番最後に。 --data (-d, --data-ascii) application/x-www-form-urlencoded 形式で POST する。 @/path/to/file のように value の先頭が @ ではじまっているとファイルを読み込んで改行文字を取り除く。パラメータや @ つきで指定したファイルの中身はすべて URL エンコードされていることが期待される。つまり curl(1) は URL エンコードしてくれない。 -d を複数回指定するとすべてのパラメータが & で連結される。 @ でファイルを指定する場合、 -d 'file=@sale.txt' のようにすると中身が展開されないので注意 (file=@sale.txt という文字列が渡される) $ curl -d '

rbenv 環境下で実行された Ruby プログラムの中から他の Ruby プログラムを起動するときに、 rbenv 環境をリセットしたい―要するに別のバージョンの Ruby で外部プログラムを実行したい―という事情があったので rbenv のメカニズムについて調べた。 rbenv 環境下で ruby コマンドを実行するとき、実際にコンパイルされた ruby バイナリが直接実行されているわけではない。 rbenv 環境をお膳立てした上で ruby バイナリを exec するラッパーのシェルスクリプトが実行される。こういうものを binstub と呼ぶ。 binstub である ruby という名前のシェルスクリプトの中身をみてみると、最終的に rbenv exec というサブコマンドを呼び出している。 rbenv のサブコマンドはリポジトリでいうと libexec ディレクトリ以下にある。

ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属

今年から始まったペパボの新しい人事評価制度で、技術者 (エンジニア) にはシニアエンジニア・アドバンスドシニアエンジニアといういわゆるスペシャリスト枠ができたのですが、最初の評価プロセスが終了したこの四月から、シニアエンジニアとして働いています。 ペパボの技術者向け評価制度については Paperboy's engineer evaluation system - Gosuke Miyashita と paperboy is hiring - Gosuke Miyashita に詳しいので、ご存じない方はぜひご覧ください。 スペシャリスト枠については、毎年恒例の社内プレゼン大会 P-1 グランプリでのアイデア発表があったあと、個別にヒアリングをしていただき、他社も含めてエンジニア職の待遇がどのようになっているかを踏まえて、どういう制度・運用が望ましいか意見を述べたこともありました。自分が評価

High Scalability - High Scalability - Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter を読んだ。すごく面白かった。 Kindle で引用したところを中心にメモ。 Tumblr のソーシャルグラフの特徴 The graph for Tumblr users has hundreds of followers. This is different than any other social network and is what makes Tumblr so challenging to scale. Tumblr だと follower が数百人いるユーザーはザラにいる。 follower の多いユーザーの post は多くのユーザ

fluentd のソースを読み始めました。単なる趣味です。 経緯: fluentd の exec buffered output plugin を試してみたらflush_interval を短くしても USR1 シグナルを送ってもバッファが flush されず command が実行されなくて悩んでいたらTimeSlicedOutput はスライスの時間が経過しないとバッファから出てこないと教えてもらい、ソースを読んでちゃんと理解したいと思ったため、です。 とはいえ plugin/out_exec.rb をいきなり読んでもさっぱりわからなかったので、順を追って読んでみることにします。 まずは bin/fluentd を実行すると fluend が起動するところまで。 bin/fluend は fluend/command/fluentd.rb を実行してるだけ fluent/command

Apache でプロキシサーバをたてて、デバッグ用に独自のリクエストヘッダを追加してみる: httpd.conf にこんなふうに書く。 <Proxy> ProxyRequests On RequestHeader set X-Foo 1 </Proxy>このヘッダの値を Apache (proxy) -> Perlbal (reverse_proxy) -> Apache (Passenger) -> Rails という構成のもとで動いてる Rails アプリケーションから取得したかったのだけど、 X-Foo ではなくて HTTP_X_FOO という名前に変わっていた HTTP_ という prefix がついている ハイフンがアンダースコアに変わっている 全部大文字になっている これらの違いについて、経験的にそういう風になることはなんとなく知っていたけど根拠を理解していなかった。 RFC3

YAPC::Asia Tokyo 2011 で Rubyist のための Perl ウェブアプリケーション開発入門 (Perl web development guide for Rubyist ) という内容で話します。 今回はトークの応募がとても多かったので RejectConf 行きかなーと思ってましたが、採択されて嬉しいです。話すからには聞いてよかったと思ってもらえるようにしっかり内容を充実させたいと思います。 去年は「他人の褌で相撲をとる」ような面もあって、ラッキーだったけど実力でもぎ取ったわけじゃないからなーという気持ちも若干ありました。今年は自分で考えた内容で応募してちゃんと採択されたので、機会を得るところまでは実力でやりましたと自信をもって言えそうな気がします。発表して自信喪失しないように、しっかりやるぞ。

いままでリバースプロキシの設定がよくわかっていなくて、すでに動いているサーバの設定を見よう見まねで使い回してきた。ちゃんと理解しようと思って、マニュアルを読み直したらやっとわかった。設定の方法 (How) がわかったこと以上に、なぜそう書く必要があるかという理由 (Why) を理解できたのが嬉しい。久しぶりに「わかった！」と叫びたくなった。感動を忘れないうちに、思い出せるように、書いておく。 mod_proxy - Apache HTTP サーバ バージョン 2.2 が Apache のプロキシ関連のマニュアル。 mod_proxy を使うことになる。 大事なディレクティブは、 ProxyPass と ProxyPassReverse のふたつ。 ProxyPass これがリバースプロキシをする上でのほとんどすべてのことをやってくれる。実は見慣れた (コピペし慣れた) 設定ではこのディレク

MySQL Casual Talks vol.1 に参加しました。[twitter:@myfinder] さんをはじめとした主催の皆様、素晴らしい会場を提供してくださった日本オラクル様、ありがとうございました。 http://mysql-casual.org/ は、「もっと深く浅く、広く狭くMySQLを使っていこう」というコンセプトにもとづいて立ち上げられたコミュニティです。 MySQL といえばいまやウェブ開発者御用達といっても過言ではないくらい様々なウェブサイトで採用されているリレーショナルデータベースで、利用者の多さに比例してこのイベントにも多くのひとが注目していたようです。もちろん、ウェブ開発者のなかでは名の知られたスピーカー陣の顔ぶれも注目を集めた大きな要因だったと思います。 トーク内容の詳しいレポートは 「MySQL Casual Talks vol.1」に参加してきたよ、のメ