Dan McKinley :: Choose Boring Technology Digg Deeper より。新しいテクノロジーになんでもかんでもすぐ飛びつくのはやめて、退屈だが手堅いテクノロジーを選ぼう、みたいな話。 全般的に納得できるのだが、イケイケな人から見るとこういう意見は老害っぽく見えるのだろうなというのもわかる（そして自分が年齢的にもう老害側なのでバイアスがかかっていることも否定しない） スタートアップ的な小さい組織の場合、ベテランばっかりで手堅いチョイスしかしないと開発ペースも運用も安定しそうだがいきのいい開発者には魅力的に映らないので採用で伸び悩み、いずれスローダウンしてしまうのが問題だ（その前に大成功して風向きが変わったりすれば別だが）なので MEAN スタックみたいなのがスタートアップ中心に流行るのはある種合理的なのだろう（技術的負債で身動き取れなくなるより前に寿命を

ある Vercel ユーザーが「空っぽの状態」の画面に適切な導線が表示されているのを褒めたら、 Check out this delightful empty state by @Vercel! pic.twitter.com/qFkhFcUlwq— usrnk1 (@usrnk1) 2023年6月14日 Vercel の CEO が GitHub の new repo screen を参考にして意図的にやっているのだといい、 My love language is thoughtfully designed empty states See: @github's timeless new repo screen with `git` copypasta. https://t.co/ADFg52G7Ba— Guillermo Rauch (@rauchg) 2023年6月14日 それを受け

YAPC::Kyoto 2023 に参加した。久しぶりの京都、久しぶりのオフラインカンファレンス、久しぶりの発表で大いに充実した 2+1 日間だった。花粉症がひどくて体調がとても悪く、日中も夜もせっかくの交流の機会を満喫しきれなかったのは残念だった。 今回は特に Perl ハッカーたちのキャリアの話が印象深かった。 一つ目は @ar_tama さんの、あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで。「ハッカー」を再定義したうえで、技術・事業・組織の三軸を「ありたい自分 = will / いまある自分 = can / 自分への期待 = must」に応じてバランスよく伸ばしていくことの重要さを説いたスピーチで、狭い意味での、あるいは古典的な定義の「ハッカー」になれなかった多くの人々を救う、ベストトーク賞にふさわしい内容だった。 が、おれ自身はというと、まさに救われる一人で

toya.hatenablog.com id:toya といえば「年ごとにブックマークしたページでよかったもの集めた」の人という認識で、とにかくたくさんブログを読んで・ブクマしている人だなあと思っていた。おれのブログも読んでもらえていることは把握していて、「年ごとに〜」に自分のエントリが選ばれていると嬉しかったりスターがつくと嬉しかったりして、これがまた、ブクマ・スター数的には冴えないけど自分的には気持ちを入れて書いたものがよく選ばれていて、なんとなく親近感を持っていた。けど直接の関わりはないし、そもそもなぜ読まれているのかもわからない、謎の存在だった。 ので、YAPC::Kyoto 2023 のクロージング後の会場で Twitter の #yapcjapan ハッシュタグを見ていてこのツイートを発見したときはびっくりした。 スタッフの皆さまお疲れ様でした！！ありがとうございました！ #y

技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト

cakesサービス終了のお知らせ｜cakesからのお知らせ｜cakes編集部｜cakes（ケイクス） エクスポート機能くらい言われなくても作れよnote株式会社のソフトウェア開発者たち。エンドユーザー向けに提供する品質で作るのが厳しくても、テキストと画像をぶっこ抜いて s3 あたりに置くスクリプトくらい書けるでしょ。事業判断として人的リソースも投入しない、という以外にも「古いシステムなので把握してる人がいない」みたいな理由もあるのかもと邪推するが、だとしても難しい仕事ではない。 やはりエクスポート機能もないサービスに大事なテキストを預けるのはリスキーだ、という意見もちらほら見かける。noteが選ぶに値しないプラットフォームであることには同意するが、それはエクスポート機能がないからでもクリエイターへのリスペクトが感じられないからでもない。クリエイター？クソくらえだ。Twitter でちょっと

pyvenv.el が使える。 Spacemacs の Python layer にも同梱されている。 SPC m V a (M-x pyvenv-activate) SPC m V d (M-x pyvenv-deactivate) SPC m V キーバインドは python-mode がメジャーモードでないと使えないが、 M-x で直接呼び出しても普通に動作する。 動作原理としては、単純に exec-path やら外部プロセス実行時の PATH 環境変数やらの先頭に venv 環境の python へのパスを追加している感じ。

OM-D Webcam Beta は Windows にしか対応していないが、 macOS でもソフトを組み合わせれば OM-D E-M1 Mark II を Web カメラ化できるという記事を読んで自分もやってみた。 E-M1 Mark II はバッテリーホルダーを装着しないと AC アダプターで給電できないので常用には向かないが、やはり MacBook シリーズ内蔵の FaceTime HD カメラとは格が違う写り。真正面ではないアングルも良い。卓上用のミニ三脚が欲しくなる。 必要なもの OM-D E-M1 Mark II OLYMPUS Capture に対応しているカメラならなんでも良い OLYMPUS Capture CamTwist 手順 OM-D E-M1 Mark II OM-D E-M1 Mark II を USB-C ケーブルで MacBook に接続する。接続モードは

今日付で退職する。入社日は2013年5月28日だった。「入社して○年」も書き納めだ。去年は書けずじまいだったので、この2年を振り返りつつ、7年を総括する。 これまでの「入社して○年」エントリまとめ 丸2年 丸3年 丸4年 丸5年 丸6年（欠番） 失われた2年 一言でいうと「失われた2年」だった。2018年4月から VP of Engineering になり、ほとんど全ての時間をエンジニア組織のマネジメントに費やした。ソフトウェア開発者として技術を磨き経験を積むという当たり前のことができず、大きなブランクが空いた。ストレスに苛まれ、身体を壊して二度も入院した（一回目・二回目）。自分にはマネジメントの仕事は向いていないと改めて痛感した。不得意なことで勝負すべきではない。 機会が与えられたのは、ありがたいことだったと思う。これまでの社会人人生で最も出世したし、年収も高くなった。ソフトウェア開発者

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

会社がスタートアップだった頃に「この人いざってときに頼りになるなぁ…」と思った人たちには、共通する特徴があると思う。 プロフェッショナルだけど、サラリーマンではないのだ。 仕事に対する責任感が人一倍強く、締め切りを守る。そのためならオーバーワークを厭わない。基本的に物事を他責にせず、周りがどうだろうが自分の責任として仕事を完遂する。無茶な要求にはきっぱりノーと言うが、現実的な代案を提示して着地させるし、そもそも「無茶」と判断する基準が高すぎるので、並の人ならとっくにサジを投げるような仕事も涼しい顔で片付ける。 それほど自分の仕事を終わらせることにこだわるのに、「仕事だから」を逃げる理由にしない。自分の仕事はここまで、とか、この仕事は他の人・チーム・部署の仕事だろう、とか、残業することになってしまうので、とか、基本的にそういう言い訳をしない。また休出しちゃったよ、などと軽口を叩くこともあるが

2018年4月から務めた Quipper Limited の Vice President of Engineering を、2020年3月末日付で退任*1した。 なぜやめるのか 一言でいうと、 VPoE として担っていたミッションを完遂したため。 二年前に VPoE 就任を打診されたとき、自分が所属していた開発組織の課題は明白だった。人が辞める。定着しない。人が増えない（むしろ減る）ので現場の負荷が上がる。ムードも悪くなる。お世辞にもおすすめできる職場とはいえなかった。 そこで、「二年で開発組織を立て直す」をミッションに掲げ、上司と約束した。 結果、二年間でエンジニア組織は 25 名から 54 名へと倍増。かつ、ミスマッチを防ぐ採用方針を徹底したことで離職者を低く抑えることに成功。開発組織を安定化させた。 2017年3月 2018年3月 2019年3月 2020年3月 エンジニアの人数

ようやく自宅用マシンを数年ぶりに買った。色はスペースグレイ。ストレージは迷ったけど一番小さい 128GB にした（安いので）。 iCloud Drive とか使えばなんとかやりくりできるだろう。 オプションは何も買わず。外装に傷がつくのが気になりそうなのでソフトケースは買うつもりだけど、アマゾンか楽天で安物を買えばいい。デジカメの写真を取り込むために USB-C の SD カードアダプタは必要かと思ったけど、 OM-D E-M1 Mark II に付属してた USB-C ケーブル経由でデジカメをストレージモードにすると SD カードから写真データを取り込めたのでやはり買う必要なし。 AppleCare も、私物の物持ちはとても良いのでいままでそういう保証の世話になったことはほとんどなく、無しでいいかなと判断してつけなかった。

先週のレビュー うまくいっていない。 Plan (getplan.co) 試した→止めた - @kyanny's blog Plan を試して止めたあと、 Google カレンダーのみで同じことをやろうと試みたけど、うまくいかなかった。 タスク管理と時間管理で感じている課題は、緊急度が低く重要度が高いタスクを着実に進められないことで、一日の空き時間にやればいいんだけど、取り組む計画をうまく立てられない。空き時間に、割り込みタスクの処理に追われたりしがちで、それは仕方ないのだけど、いざ割り込みタスクが無いときに、 ToDo リストの真ん中から下の方にあるようなタスクにちゃんと取り組めていない。 カレンダーの空き枠にタスク作業の予定を入れるのは、その時間になったらこれをやる、と自分に促す点で有用だけど、そういう時間管理方法に不慣れなので全然カレンダー通りに行動できない。チャット起点の割り込みタ

というか、（かなり偏見を含む）空想。 blog.kyanny.me 「技術力が衰えつつあるおじさんエンジニアのキャリアパスをどうするか」という命題に対して業界は「経営がわかるCTO」「技術顧問」などの回答を示してきた しかしCTOも技術顧問も椅子に限りがあるため、業界は新たな受け皿を必要としていた 業界の平均年齢が上がり、他の業種と同様におじさんエンジニアたちは「管理職」になることを受け入れなければならなくなったが、この業界は「マネージャー（管理職） = 悪」という価値観が根強いため、業界人たちの意識変革が必要だった そういうもろもろの問題意識やら個々人の思惑やらが交錯した結果、どこかの誰かが「エンジニアのマネージャーは無能な管理職なんかじゃない！『髪の尖った上司』なんかじゃないんだよ！」といいだし、キャリアに不安を抱えていたおじさんエンジニアたち（と、そんなおじさんの背中をみてぼんやりと

blog.kyanny.me blog.kyanny.me 3月？4月？から VP of Engineering というのになった。スタディサプリを開発する Quipper 日本オフィスのプロダクト開発部門の責任者という位置づけ。一年前の予定では、いち Software Engineer に戻っているはずだったのに。 自分も会社もいろいろあった。良い一年だったとは言えない。そうしてしまった責任は自分にもある。最悪の時期は脱したという感触もある。 昨年度までは「必要悪」という意識で悩みながらやっていた。自分のかわりに誰かがやってくれるなら任せたい、とも思っていた。実際にそうしてみたら、自分の望むようにはならなかった。当たり前といえば当たり前のことではある。 自分は opinionated だという自覚がある。 Quipper のエンジニア組織はどういう風であるべきか、ということについて、他の

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

最近入社した同僚から「（Quipper では）ペアプログラミングはやっていないの？」と聞かれ、正式な形では実施していないが必要に応じて相手の席に行って議論しながらコーディングしたりすることはふつうにやっているよ、いい機会だから連休明けにでもトライしてみよう、と答えてみたものの、正式なペアプログラミングってどういうものだろう？と疑問に思ったので、そういうものがあれば学んでおこうと思い、 Amazon で「ペアプログラミング」で検索して一番それっぽい本を買った。ペアプログラミングというプラクティスはだいぶ多く言及されているものの、専門に扱っている書籍が（和書では）ほとんどなくて驚いた。 おおまかに分類すると、 ペアプログラミングの良い点を挙げる ペアプログラミングを導入するにあたり障害になり得るもの（一人で仕事をしたいプログラマによる抵抗、マネージャの理解を得られない、など）への対処法 ペアプ

(defun my-js-mode-hook () (setq-local electric-layout-rules '((?\{ . after) (?\} . before)))) (add-hook 'js-mode-hook 'my-js-mode-hook) この挙動がどうしても我慢ならなくて js2-mode が機能豊富すぎるせいだろうと思い javascript-mode に鞍替えしても同じ挙動だったので怒りと絶望で Emacs を投げ捨てたくなったが気を取り直して調べてようやく解決した。https://github.com/emacs-jp/issues/issues/24#issuecomment-77167968 js-mode-hook については javascript - Adding Common Hook to js-mode - Stack Overflow