Web 日記は止まらない - @kyanny's blog
↓を読んで、タイトルで脊髄反射したくなっただけ。 トラックバックがあった時代のブログ作法ってこういう感じだったな、と懐かしくなった。タイトル含めて他人のブログ記事にお返事するというか、アンサーソングというか。もちろん元記事はお前に向けて書かれたものではないので返事もクソもないだろ、という話なのだが。 おれはインターネットにテキストを書かずにはいられない人間で、これを禁じられたら精神に失調をきたすこと間違いなしと思う。なので逆に書かずにいられる人たちのことが正直いうと信じられない。しかし世の中の大半の人はウェブ日記を書き続けたりしない、ということに十年くらい前から徐々に気づき始めて、いまでは確信に至った。これはおれの才能だ。インターネットにテキストを書き続けられる才能。なんの役に立つんだと言われれば特になんの役にも立たないとしかいいようがない、しょぼい才能だけど、それでも稀有な才能には違いな
Nagoya.Testing in Tokyo -テストを強いられている人達の話- に参加した - @kyanny's blog
ソフトウェアのテストに関心があるので、Nagoya.Testing in Tokyo -テストを強いられている人達の話- - connpassという勉強会に参加した。 テストというよりもアジャイル開発、とくにスクラムと、チームのマネジメント・コーチングの話で、とても参考になる内容だったものの、自分が求めていたものとは少し違っていた。求めているもののほうが間違っているのかもしれない、という気づきがあった。 特に印象に残った部分 バグの根源には何かしら「無理」がある。無理からくるバグをテストで取り除こう、という考え方が間違い。無理をやめよう。 いかに普段からテストして、テストを減らすかを常に考える。 残業をしない。 ソフトウェア工学の知見を活かす。先人に学ぶ。 チームメンバーに、わかるまで800回くらい、同じことを表現を変えて言い続ける。伝え続ける（人間とはそういうもの） いかにして、アイデア
Quipper に入社して丸5年が経った - @kyanny's blog
blog.kyanny.me blog.kyanny.me 3月？4月？から VP of Engineering というのになった。スタディサプリを開発する Quipper 日本オフィスのプロダクト開発部門の責任者という位置づけ。一年前の予定では、いち Software Engineer に戻っているはずだったのに。 自分も会社もいろいろあった。良い一年だったとは言えない。そうしてしまった責任は自分にもある。最悪の時期は脱したという感触もある。 昨年度までは「必要悪」という意識で悩みながらやっていた。自分のかわりに誰かがやってくれるなら任せたい、とも思っていた。実際にそうしてみたら、自分の望むようにはならなかった。当たり前といえば当たり前のことではある。 自分は opinionated だという自覚がある。 Quipper のエンジニア組織はどういう風であるべきか、ということについて、他の
Quipper に入社して丸4年が経った - @kyanny's blog
blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき
なぜ Quipper のエンジニア採用面接には必ず候補者の同僚となる人が参加するのか - @kyanny's blog
ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を
イシューからはじめよ - @kyanny's blog
ものすごく良かった。とても面白かった。もっと早く読むべきだった。 「答えを出すだけの価値がある問題を見極める」「取り組むべき問題を絞り込んでから解き始める」これが大事なんだ、という論点をいきなり冒頭で述べている。言われてみれば（言われてからなら）その通りだと思えるが、初めて読んだときはけっこうな衝撃を覚えた。自分がこれまでいかに無駄なことをしてきたか気付かされた。 本書では「イシューの見極め」「大胆な仮説」「仮説に基づくストーリー」「仮説を検証する分析」「明快な結論」という順序で物事を進めていくのだ、と説明されている。その各項目の説明の仕方それ自体が、著者の提唱する「イシュードリブン」の考え方に基いて構成されている。つまりこの本は、本を読み進めるにつれて「考え方」そのものが例を変えながら繰り返しでてくるので、読めば読むほど考え方への理解が深まる、というつくりになっている。これに気づいたとき
第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
autodoc その後 - @kyanny's blog
二年前に autodoc を導入したが、現在はもはや誰も見てないし使ってないね、という話を社内でしたら、「使い始めた話だけじゃなくて、やめちゃった話もブログに書くべき」と指摘され、確かに誠実な姿勢とはいえないなと反省したのでこの記事を書いています。 恥を忍んで現状を明かすと、 master ブランチに push されたタイミングで実行される Jenkins のジョブが半年ずっと fail していた、ということに昨日気づいた体たらく。そもそも生成された markdown ドキュメントを push していたリポジトリがとっくの昔に削除されていたと思っていた。 うまくいかなかった原因の分析: Quipper の Internal API は非常に込み入ったデータ構造を返すものがほとんどで、お世辞にも「きれいな RESTful API」とは言えない。なので request spec を書く際に、完
リモートで働く開発者が行うとよいたった二つの習慣 - @kyanny's blog
チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で返事をはやく返す チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で自分の状況をこまめに報告する 目安としては、 1 on 1 チャットは 30 秒以内・パブリックチャットのグループ mention （@here みたいなやつ）は 1 分以内・パブリックチャットの mention なし不特定多数向けメッセージは 3 分以内・それ以外のものは 24 時間以内に返事をするとよい。これより遅いと、「自分が返事をしないせいで相手を待たせてしまい、ストレスを与えたり仕事が進まない原因を作っている」ということになってしまう、と思っておくのがよい。 1は第一には「相手を待たせない」ためだが、まめに返事をしてあげていれば逆の立場になったとき自分もまめに返事をしてもらえることがあるので、自分自身
WIP (Work in Progress) な Pull Request を目立たなくする Chrome 拡張をリリース - @kyanny's blog
Pull Request ベースの開発手法（いわゆる "GitHub Flow" というやつ）では、未完成のブランチに "WIP" という件名をつけて作業中である旨を示しつつ途中経過もレビューしてもらう、というのをよくやります。 Quipper ではそれに加えて "DONT MERGE" とか "DO NOT MERGE" というのもよく使っています。 WIP と同じ意味で使うこともあれば、レビューの過程で発生した議論にまだ決着がついていないのでマージしないでね、という意思表明として使うこともあります。 僕は一日にだいたい十個弱の Pull Request をレビュー・マージしています（個人差はありますが Quipper のデベロッパーの多くは似たようなものです）レビュー・マージのタイミングははやいほうが良いので、一日に少なくとも二回か三回は Organization の Pull Req
Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな
破れ紙の片割れのようなMixinができてしまうワケ - @kyanny's blog
最近「Mixin は避けられれば避けたほうがよいのではないか」と思い始めている。扱いに困るダメ実装の Mixin を簡単に作れすぎてしまうからだ。 Wikipedia の定義によると、 mixin とはオブジェクト指向プログラミング言語において、サブクラスによって継承されることにより機能を提供し、単体で動作することを意図しないクラスである。 とのことなので、そもそも Mixin される側の実装と結びつきが強くなるのは仕方ないのだろう。しかし、まれにだが破れ紙の片割れのような実装を持つ Mixin ができてしまうことがある。 一枚の紙を適当に手で破って二枚にする。断面はギザギザだが、破った二枚の紙の断面はぴったり一致する。もともと繋がっていたものを切り離したのだから当然だ。だが破れ紙の断面にぴったり合うような別の紙を用意するのは簡単ではない。別の紙を合わせる必要があるのならば、紙を破るときに
New Relic のグラフを毎時チャットに貼り付ける - @kyanny's blog
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 に投稿す
例えば OSFA な API をやめる - @kyanny's blog
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 がある、み
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Wantedly Open API を試してみた - @kyanny's blog