blog.kyanny.me 使い物にならない、とは言わないが、おすすめしない。 遅い もっぱら毎日 GitHub や Google Drive にアクセスしているが、どこも Chrome に比べて体感で明らかにわかるほど表示も動作も遅い 速度がウリって、いったいどこのウェブサイトなら速いわけ？ 一番困ったのが Cmd+W に対する反応が遅くて（処理落ちしてる感じ）気持ち長く押してしまうのか、閉じたくないタブまで閉じる操作ミスが頻発した 開発者ツールが使いづらい 慣れの問題もあるけど、機能の少なさはこなれてなさは否めない minify された .js ファイルを prettify してブレークポイントを設定しても、そこで止まってくれない。デバッグが致命的にやりづらい 拡張がめっちゃ少ない Quantum で過去の拡張を捨て去ったので、拡張を探しても軒並み未対応 Trello の公式拡張が未

New Relic をこまめにチェックすべきだが怠惰かつ忘れっぽいせいでチェックできないので、グラフ画像が毎時チャットにつぶやかれるようにしてみた。 やり方はけっこう込み入っている。 New Relic の Embedded Charts 機能を使って埋め込み用のグラフを作る。 Amazon S3 にバケットポリシーでデフォルト公開設定にしたバケットを作る。 適当なサーバーに Jenkins と phantomjs と s3cmd をインストールし、 s3cmd は 2. で用意したバケットに書き込める Access Key Secret Key で --configure しておく。 capture_put.sh というスクリプトを使い、 phantomjs で embedded chart のスクリーンショットを撮って s3 に put し、画像の URL を HipChat に投稿す

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

笹塚に創価学会の施設がある。Ingress をやっていて何気なく Hack したポータルがそうだったのだが、ポータル名に悪意を感じた。 特定の新興宗教を邪教と呼ぶのは個人の自由だが、不特定多数の目に触れるある種パブリックな場所にあるものに対して偏った主観に基づくラベルをつけるのは感心しない。自分はさほど熱心なエージェントではないのでゲームにもコミュニティにも強い思い入れはないが、こういうつまらないイタズラで Ingress の評判に傷がついたら残念に思う人も少なくないと思う。 ポータル名の編集をリクエストすることができたので、看板に書いてあった「創価学会 渋谷平和会館」という正式名称に変更要請しておいた。気がついてよかったと思う反面、日本中にこんなのがあるのかと思うと気が滅入る。 2015年4月9日更新 Accepted. https://www.ingress.com/intel?ll=

昨年末から SNS を見るのをやめた。目的は精神の平穏を保つため。誰が退職しただの、誰が本を書いただの、誰と誰が寿司を食っただの、そういう業界ゴシップで心惑わされるのに疲れ果てた。知る価値のある情報もたくさんあるが、 S/N 比が悪くなりすぎた。 また、 SNS に愚痴や攻撃的なことを書いたりしてしまうのもやめたかった。傍目に悪いし、書いてスカッとするわけでもない。いつか炎上するかもと内心びくびくしながらやめられない様はまさに中毒だった。 具体的にやったことは以下。 iPhone から Twitter と Facebook その他 SNS のアプリを削除した。隙間時間についつい見てしまう・書いてしまうのはこれで克服できた。 SNS からの通知メールをできるだけオフにした。特に効き目があったのははてなブックマークのマイホットエントリーお知らせメールで、自分にとって最大のゴシップ情報源になって

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

新人さんの JavaScript のコードレビューをしていて、 if 文の本体部分を波括弧で囲っていないコードを見つけた。 おれは本体が一行しかなくても必ず波括弧で囲うようにしており（そのほうがわかりやすいと思っているから）、できればそうして欲しいけど個人の好みを押し付けるのはよくないので、広く支持されているコーディングスタイルガイドの類いで同様の主張をしているものが無いか探した。 Google とか Mozilla とか GitHub あたりのドキュメントを眺めてみたが if 文の波括弧についてはっきり言及している箇所を見つけられずにいたら、該当するドキュメントをいくつか教えてもらった。 http://contribute.jquery.org/style-guide/js/#spacing if/else/for/while/try always have braces and alw

ざっと流し読みしたけど、いまいちだった。深く読み込めばもっと得るものもあるのかもしれないが、この本を精読するよりは他の本を読みたい。 JavaScript によるクライアントサイドアプリケーションはステートフルなオブジェクトで構成されるので、状態を持つがゆえにテストもデバッグもしづらいらしい、ならばステートフルを飼いならすためにそれが一体どういうものなのかちゃんと学ぼう、と思い、タイトルにひかれて買ってみた。が、実際にステートについて触れている箇所はあまり多くなく、期待はずれだった。 この本の原題は「JavaScript Web Applications - jQuery Developers' Guide to Moving State to the Client」で、これなら jQuery の話が中心でも仕方ないかな、という気はする。ただ、最初からこういう書籍名だと知っていたらたぶん読

ペパボに入社して七ヶ月経ちました。特に区切りがいい日ではないけど、ここ何日か退職とか転職の話題を多くみかけて、そういえば入社したその後のことをあまり書いてないなと思ったので書きます。 僕はホスティング事業本部 30days Album チームというところに所属しています。名刺の肩書きはプログラマで、もちろん 30days Album の開発にあたるのが主な仕事です。開発、とひとくちにいっても内訳はいろいろで、文字通り新しい機能を開発するためにコーディングすることもあれば、データベースのチューニングのようなインフラ・運用寄りのこともするし、ユーザーサポートもやっています。 入社前は Perl と Ruby のコードを 50% ずつくらいの割合で書くことになるのかなーと思ってましたが、いまは Perl はぜんぜん書いていなくて Ruby と JavaScript を 50% ずつくらいの割合で