「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが

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

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

6月の頭から3ヶ月ほどかけて、 Rails + 一部 jQuery 的なよくある構成のウェブアプリケーションのフロントエンド部分を Marionette.js をベースに作りなおした。メンバーはいわゆるウェブ系のスキルセットを持つ開発者3名。 Marionette.js の経験者は一人もいなかったが、別プロジェクトが先行して Marionette.js を採用して同様のリニューアルを終えたタイミングで、ある程度のノウハウと「なんとかなりそう」という手応えはあった。 せっかく新しくはじめるのだからちゃんとテストを書きたい、そしてカバレッジも計測したいと思い、先行していたプロジェクトで利用していた konacha ではなく、カバレッジ計測機能をもつ teaspoon を採用した。どちらも Rails アプリの assets に置かれる JavaScript/CoffeeScript に対するテ

TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を

きっかけは些細なことだった。 Emacs で RSpec のテストケースを書いていて、全体的に動作がのろくてイライラさせられた。どうやら ruby-mode だか ruby-electric だかが悪さをしているらしいが、何年も前に .emacs.d に放り込んだもので、どんな風に設定するのかも覚えていない。最新バージョンに入れ替えてみたら、手元でちょろっとカスタマイズしていた改行時のオートインデントだか何かの挙動が変わってしまい、気になってコーディングどころではなくなった。 もともと Emacs Lisp は読むのも書くのも苦手で嫌々ながらも騙し騙し付き合ってきたが、このときばかりは心底うんざりして、もうこんな古代のツールに頼るのはやめにしよう、自分の仕事は高度に知的な作業であるはずのプログラミングであって多彩で変態的なキーボード操作を駆使してテキストを編集しまくることではない、ならばも

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

OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み

isucon 2013 予選通過した。チーム名は :ok_woman: 選んだ実装は Ruby (Sinatra) ISUCON 本戦出場者決定のお知らせ : ISUCON公式Blog 予選二日前に @banyan から誘われ急遽参戦を決めた。予選当日までは十分な準備期間はとれなかったが、三回連続参加と場数だけは踏んでいるので振り返りという名の反省文を private repo の issue に書いて共有したりした。 当日の流れ。なんとなく役割分担したほうがいいねと事前に打ち合わせていたのもあり、チームリーダーの @m4i がデータベースを中心にパフォーマンス計測とチューニングの方針決定担当、 @banyan がデプロイ、開発環境整備、フロントエンドなどの足回り担当、残った僕がアプリケーション担当でひたすらコードを書く、という感じだった。 はやい段階で git pull によるデプロイ、

Quipper では日本オフィスの開発者を中心に、 Qiita::Team を導入して社内のドキュメント共有を行なっている。書かれる内容は日報が多いが、技術 Tips の共有やチャットでは適切でない込み入った技術的問題を解決する議論の場としても活用している。 なぜわざわざドキュメント共有？ていうか日報書くなんてダサすぎじゃね？そう思ったあなた、日報を見くびっちゃいけません。上手に運用すればナレッジシェアやコラボレーションのみならず、チームビルディングにも役立つんです。 上手に運用された日報には前例がある。ペパボの社内 SNS であるタンパクがそれだ。毎日スタッフ全員が日報を書くきまりなのだが、本来の目的である業務内容の記録以外に一言コメントを書く欄がある。定型文で済ます人もいればブログ並の長文を書く人もおり（それはわたしです！）、これがそこらの SNS なんかよりよっぽど面白いコンテンツな

五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい