RuboCop リネーム騒動の所感 - @kyanny's blog
Is it time to change the name? · Issue #8091 · rubocop-hq/rubocop · GitHub Rubyists, we must do better | timriley-info The RuboCop Name Drama Redux | Meta Redux 件の騒動を知る前に「Black Lives Matter の流れに乗って名前変えたらいいんじゃねーの」とは思った 難癖をつけられて揉める前に済ませておくほうが楽そう、とか FactoryBot のことを当然思い出しながら 個人的に RuboCop は好きではなく愛着もないので、というのもある リネームしたら？という提案自体は、まぁ妥当な範囲内だと思う master ブランチやめます話もあることだし https://twitter.com/mislav/status/1270
スタートアップに向いてる人の特徴 - @kyanny's blog
会社がスタートアップだった頃に「この人いざってときに頼りになるなぁ…」と思った人たちには、共通する特徴があると思う。 プロフェッショナルだけど、サラリーマンではないのだ。 仕事に対する責任感が人一倍強く、締め切りを守る。そのためならオーバーワークを厭わない。基本的に物事を他責にせず、周りがどうだろうが自分の責任として仕事を完遂する。無茶な要求にはきっぱりノーと言うが、現実的な代案を提示して着地させるし、そもそも「無茶」と判断する基準が高すぎるので、並の人ならとっくにサジを投げるような仕事も涼しい顔で片付ける。 それほど自分の仕事を終わらせることにこだわるのに、「仕事だから」を逃げる理由にしない。自分の仕事はここまで、とか、この仕事は他の人・チーム・部署の仕事だろう、とか、残業することになってしまうので、とか、基本的にそういう言い訳をしない。また休出しちゃったよ、などと軽口を叩くこともあるが
連鎖退職 - @kyanny's blog
要約 感想 メモ ハイライト 優秀な人材の退職が組織に与える影響 マネジメント体制 ファーストランナーの退職が逆に良かったケース 信頼される管理職 連鎖退職の火消しをして燃え尽きた管理職 要約 これは「従業員が立て続けに辞める事象 = 連鎖退職」について分析した本である 連鎖退職には二種類ある ドミノ倒し型 蟻の一穴型 「ドミノ倒し型」は、退職による業務負荷の増大が原因 「蟻の一穴型」は、影響力がある人の退職で職場の問題が顕在化することが原因 「ドミノ倒し型」は人的余裕の少ない中小企業に多く、「蟻の一穴型」は大企業に多い（管理職や経営者が職場の問題を放置していたことが原因のため） 予防策 採用 採用前にネガティブな面も含めて詳細に情報提供する 採用基準を変更して合う人をとる 人事評価 報酬の分配方針（成果主義） 評価結果に対するフィードバック キャリア形成支援（メンター制度） 定期的な配置
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月 エンジニアの人数
Android 10 ファーストインプレッション - @kyanny's blog
Pixel シリーズからロールアウトされると聞いたらアップデートしないわけにはいかない。 トラブルっぽいもの スクリーンショットの保存に失敗するようになった、が、今もう一度試したらできてしまった。ダメだったときの挙動は、撮影はできるが、 9 の頃は撮影後数秒するとスクリーンショット画像の共有や編集を促す通知が出てきたところで保存に失敗しましたというエラー通知が通知エリアに出る、という感じ。予想としては、アップグレード処理の中でスクリーンショットを保存するストレージ領域のパーミッションが意図せず変更されて書き込み不可になった、とかかなと思っていたが違ったようだ。アップデート直後にシステムのバックグラウンドでいろいろ処理が走っていて、なにかリソース競合とかでも一時的に起きていたのかもしれない。 モバイルネットワークの名称？が Sprint になり、 plus.acs.jp.v6 という APN
「振り返り」が嫌い - @kyanny's blog
なぜ嫌いなのかわかった気がする。 「振り返りって、要は内省でしょ？そんなの言われなくても、他人からわざわざ指摘されなくても、もう何十年も毎日毎日、本当に毎日、スキマ時間があるたびにやってるよ、やりたくもないのに無意識に。十数年分のブログが証拠だ。俺がそれだけ時間をかけてやってる内省よりも効果的な「フィードバック」とやらを、たかだか数日、数週間、数ヶ月仕事をしたくらいの赤の他人ができるとでも思っているのか？思い上がりも甚だしい」 って思ってるからだろうな。 「フィードバック」には、確かに自覚してないことも含まれるのだろう、けど、それは自分にとって重要なことではないから内省して改善してないってことじゃないの？それをわざわざ大事なことだと指摘されても腹立つだけじゃん。だって大事じゃないんだもの。自分にとって何が大事かを他人が決めるんじゃねーよ。
Firefox やめた - @kyanny's blog
blog.kyanny.me 使い物にならない、とは言わないが、おすすめしない。 遅い もっぱら毎日 GitHub や Google Drive にアクセスしているが、どこも Chrome に比べて体感で明らかにわかるほど表示も動作も遅い 速度がウリって、いったいどこのウェブサイトなら速いわけ？ 一番困ったのが Cmd+W に対する反応が遅くて（処理落ちしてる感じ）気持ち長く押してしまうのか、閉じたくないタブまで閉じる操作ミスが頻発した 開発者ツールが使いづらい 慣れの問題もあるけど、機能の少なさはこなれてなさは否めない minify された .js ファイルを prettify してブレークポイントを設定しても、そこで止まってくれない。デバッグが致命的にやりづらい 拡張がめっちゃ少ない Quantum で過去の拡張を捨て去ったので、拡張を探しても軒並み未対応 Trello の公式拡張が未
Heroku の二段階認証を有効にしたあと heroku コマンドで 2FA ログインできなくなったときは新しい heroku-accounts プラグインをインストールする - @kyanny's blog
仕事用の Heroku アカウントで二段階認証を有効にしたら、 heroku コマンドでログインし直すときに Two-factor code を入力しても Authentication failed. エラーがでてログインに失敗するようになった。 WARNING: heroku-accounts plugin is installed. This plugin is known to have problems with HTTP Git. · Issue #76 · ddollar/heroku-accounts · GitHub これと同じ状況で、 WARNING メッセージも同じものが表示される。 Issue コメントに書いてあるように、 Heroku 自身が fork した heroku-accounts プラグインをインストールしなおせば直る。 github.com $ hero
ロングテール‐「売れない商品」を宝の山に変える新戦略 - @kyanny's blog
Kindle Unlimited でクリス・アンダーソンの「FREE」と「MAKERS」を見つけたので、何年か前にハードカバーで挑戦して読みきれなかった「FREE」から読み始めたところ、冒頭で「ロングテール」に触れていて、そういえば読んだことがないので読んでみた。 「FREE」は邦訳が出たときけっこう話題になって、数ヶ月は経っていたものの鮮度がある間に手に取った記憶があるけど、そのときですら「フリーミアムなんてそんなにうまくいかねーよ」と斜に構えた受け取り方をしたものだった。しかし「ロングテール」は原著と最初の邦訳が出版されてから十年も経つのにまだまだ現役で通じそうというか、さほど間違ってない感じがした。 十年前と比べて、電子書籍の普及は大きな変化だと思うので、電子版も含めた本の売れ方にロングテールの傾向が強まっているのか？は気になる。たぶんデジタルデータの流通コストおよび保管コストの低下
Quipper に入社して丸4年が経った - @kyanny's blog
blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき
ペアプログラミング―エンジニアとしての指南書 - @kyanny's blog
最近入社した同僚から「（Quipper では）ペアプログラミングはやっていないの？」と聞かれ、正式な形では実施していないが必要に応じて相手の席に行って議論しながらコーディングしたりすることはふつうにやっているよ、いい機会だから連休明けにでもトライしてみよう、と答えてみたものの、正式なペアプログラミングってどういうものだろう？と疑問に思ったので、そういうものがあれば学んでおこうと思い、 Amazon で「ペアプログラミング」で検索して一番それっぽい本を買った。ペアプログラミングというプラクティスはだいぶ多く言及されているものの、専門に扱っている書籍が（和書では）ほとんどなくて驚いた。 おおまかに分類すると、 ペアプログラミングの良い点を挙げる ペアプログラミングを導入するにあたり障害になり得るもの（一人で仕事をしたいプログラマによる抵抗、マネージャの理解を得られない、など）への対処法 ペアプ
理想的なコードレビュー - @kyanny's blog
理想的なコードレビューとはどういうものだろう。前提として、 Git のよくあるワークフローで常識的なサイズのトピックブランチを、 GitHub か似た何かの Pull Request 的なビューの単位でレビューする、とする。 無言、または LGTM や :+1: など、「ちゃんとレビューしたよ、オッケーだよ」というシンプルな意思表示のみでマージに至るものは理想的に思える。レビュアーの「自分だったらこう作る」という設計・実装イメージとレビュイーの「自分はこう作った」という設計・実装がほとんど違わない、もしくはレビュアーのイメージとは違うけども納得できる結果になっている、よってコメント不要、なのだといえるからだ。 これを理想だとすれば、なんであれコメントがつくのは理想的ではない、ということになる。レビュアーとレビュイーの見解・実力に差があり、それが設計や実装の欠陥を指摘するコメントや、逆にコー
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
エンジニア立ち居振舞い: 作業の進捗をチャットに逐一報告する - @kyanny's blog
お題「エンジニア立ち居振舞い」 同じく GitHub の通知はだいたい目を通してる。流量が多くてブラウザで開いてられないので Gmail で読み流して気になるやつだけ見に行くようにしてる。 GitHub の通知を見る専用のアプリを使っていないのは、 GitHub 以外のサービスからの通知とか、ごくわずかだけど外部の関係者とのメールとかもあってメールを一切見ないわけにはいかないので、だったらいっそ Gmail 一本にしたほうが楽だし見落としが無くて安心だと思ったからです（なので inbox zero を気合で実践してる） で、気をつけてることで、まだお題で書かれて無さそうだったのがこれです↓ 作業の進捗をチャットに逐一報告する production 環境のデータを修正するとかそういう運用系のタスクというのがけっこうあって、たいてい rake タスク + Jenkins job みたいなのを用
なぜ Quipper のエンジニア採用面接には必ず候補者の同僚となる人が参加するのか - @kyanny's blog
ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を
How Quipper tests software - @kyanny's blog
Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。 実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。 サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがとこ
Quipper に入社して丸3年が経った - @kyanny's blog
Quipper に入社して丸3年が経った。そんなことすっかり忘れていた。3年と言われてもピンとこない。体感的にはものすごく昔のことのように感じられる。それだけいろいろあって濃い日々を過ごせたということだと思っておこう。 せっかくなので、 Quipper 日本オフィスの変遷になぞらえながら振り返ってみる。 入社前夜 前職で担当していたサービスの事業展開がうまくいかず、英語を使う環境で仕事をしてみたいという希望もあり、海外スタートアップ企業への転職を考えはじめたのが2013年の3月だった。 3月上旬にWantedly で見つけた Engine Yard のソフトウェア開発者募集に応募して選考に進んだものの、合否がなかなか出ず、やきもきしていた頃に前職の同僚で同じサービスをペアで開発していた @banyan に「Quipper に転職するんだけど話聞いてみない？」と誘われたのが4月の半ば（たしか
最近思ったこと - @kyanny's blog
ここ数ヶ月、十数年のソフトウェア開発者人生で初めて、悪名高いExcel方眼紙に書かれた仕様書というものに触れる機会を得たのだが、悪評の理由が身を持ってわかった。 装飾過多。長過ぎるフローチャートや謎のテーブル風定義一覧の「見栄え」ばかりよくて肝心のデータの見方・読み方がわからない。 おそらく装飾にパワーを取られすぎているからだと思うが、仕様の説明に不足がある。フィールド文字列長が何バイトとか書いてあるが超過したとき何が起こるか明記されていない、など。 そのシステムが実現するビジネスにおける仕様について（仕様書なのに）触れられていない。ドキュメントの書き手が読み手に対して「機械のように指示に忠実に実装だけすればよい」と考えているのが見え透いている。 実装例・サンプルコードの類に乏しい。コードを見ればすぐ理解できる類のことを無理にコード無しで伝達しようとするので情報の劣化が激しく、資料として不
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
■ - @kyanny's blog
仁義なき宅配: ヤマトVS佐川VS日本郵便VSアマゾン - @kyanny's blog
