Re: 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - @kyanny's blog
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト
二要素認証（TOTP）のトークンをどこに保存するか問題 - @kyanny's blog
2 要素認証に 1Password を使うのはよく考えてから | はったりエンジニアの備忘録 AWSの多要素認証に1passwordが使えたけど使っちゃダメだと思った話 - Qiita TOTP のトークンを 1Password に保存するのはセキュリティ強度を弱めるので良くない、という話は知ってたので避けてたのだけど、ちょっとよくわからなくなってきた。 Windows（具体的には社有のSurface Pro）上の1passwordとiPhone上の1passwordの両方でMFAの二段階目をクリアできたということは、もうこの2段階目は特定のデバイスを持っていることに依存しないということだ。僕のIDで他のデバイスに1passwordをインストールすることができれば、さらにそのデバイスでも2段階目をクリアできる。「AWSのパスワード」と「特定のスマホ（デバイス）」ではなく、「AWSのパスワー
VP of Engineering やめた - @kyanny's blog
2018年4月から務めた Quipper Limited の Vice President of Engineering を、2020年3月末日付で退任*1した。 なぜやめるのか 一言でいうと、 VPoE として担っていたミッションを完遂したため。 二年前に VPoE 就任を打診されたとき、自分が所属していた開発組織の課題は明白だった。人が辞める。定着しない。人が増えない（むしろ減る）ので現場の負荷が上がる。ムードも悪くなる。お世辞にもおすすめできる職場とはいえなかった。 そこで、「二年で開発組織を立て直す」をミッションに掲げ、上司と約束した。 結果、二年間でエンジニア組織は 25 名から 54 名へと倍増。かつ、ミスマッチを防ぐ採用方針を徹底したことで離職者を低く抑えることに成功。開発組織を安定化させた。 2017年3月 2018年3月 2019年3月 2020年3月 エンジニアの人数
採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな
私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
なぜ Quipper のエンジニア採用面接には必ず候補者の同僚となる人が参加するのか - @kyanny's blog
ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を
Terminal.app でプロダクション環境へ ssh するとき背景色を変える - @kyanny's blog
iTerm2で、sshしたら背景画像なり背景色切り替えとか出来ないのかな。プロファイルの設定とかでも可。Windowsではputtyでプロファイル切り替えて、本番つなぐ時は赤っぽい背景色とかにしてる。— songmu (@songmu) July 24, 2012 ssh したときセッション別にターミナルのテーマかえるやつ、 Terminal.app でもやりたいなぁ。むかし @nabokov7 さんが Mac でやってた記憶があるけど、あれはいったいどうやってたんだろ。— Kensuke Nagae (@kyanny) July 24, 2012 設定をまるごと.Terminalファイルに書き出してショートカットにしてた。ショートカットごとに別の背景色や起動コマンド(ssh)割り当てたりして。RT @kyanny: ssh したときセッション別にターミナルのテーマかえるやつ…— nabo
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
MySQLのインデックスを学ぶ (2) - @kyanny's blog
Linux-DBシステム構築運用入門をさらに読んでいる。前回は主に Chapter 8 を読んだ内容をメモったが今回は Chapter 9 の内容。 INSERT とインデックス インデックスが多いと INSERT の性能が落ちる、という話題はなんとなく見聞きしていたが、何故性能が落ちるのかについてはわかっていなかった。詳しくは Linux-DBシステム構築運用入門 P210 の図を見てもらうとして*1、ランダム INSERT よりも昇順 INSERT のほうがインデックスのリーフブロックの仕様効率が良い == インデックスのサイズが小さくなる == バッファキャッシュに載りやすくなる == I/O が減る、というのは知らなかったしとても勉強になった。インデックスを更新するために INSERT でもディスクから読み込みが発生する、というのも知らなかった。 クラスタインデックスとランダム I
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
