GitHub の実用的な新規リポジトリ画面は偶然から生まれた - @kyanny's blog
ある 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日 それを受け
■ - @kyanny's blog
ここ何週間、メールの既読アーカイブをしていないこと ここ数ヶ月、iPhone のホーム画面を整理していないこと 数週間前に読んだ、とても良かった本の感想文をまだ書けてないこと こういう小さなことの積み重ねで、生活の乱れを感じる。人生に余裕がなくなっているともいえる。 なぜそうなっているのか理由は明白で、毎日の仕事に相当のエネルギーを費やしているから。英語とか韓国語とかストレッチとか、習慣化しようとしているいくつかのルーチンをこなしたら、あとは本を少し読む程度のエネルギーしか残らない。 仕事に精を出しているのは悪いことではないし（長時間労働気味でもない）、コンフォートゾーンよりはストレッチゾーンにいるほうが良いことなのだが、もう少し余裕を作りたいとも思う。 困ったことに、だらだらとネットのニュースや Twitter を眺めるのはエネルギーがなくてもできてしまうので、時間は浪費しがちだ。時間は
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月 エンジニアの人数
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
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 の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
master ブランチにマージ済みのリモートブランチをまとめて削除する git-prune-remote-branch というスクリプトを作った - @kyanny's blog
必要になったのでそういうものを作りました。 https://github.com/kyanny/git-prune-remote-branch パスの通ったところに置いて Git のワーキングディレクトリで実行すると master と develop にすでにマージ済みのリモートブランチを全部削除します。 --noop で dry-run モードになるので実際に消す前に確認もできます。なんで master だけじゃなく develop も？というと、僕のチームで gitflow を使っているからです。 $ git clone git://github.com/kyanny/git-prune-remote-branch.git $ git-prune-remote-branch --noop $ git-prune-remote-branchgit push --mirror じゃダメなの
第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
次の5年のロールモデルが見つからない - @kyanny's blog
自分にできる範囲の努力では「注目されない凡人」から脱却することはできないのだ、ということをようやく渋々認める気になり数ヶ月経ったが、ではこの先自分はどういう風になっていくのか？を考えたとき、ロールモデルと呼べるような存在が見つからず少し困っている。 「カッティングエッジなことをやっていて際立つ存在」を目指したいと思っていたときは前例に事欠かなかったが、平凡だがすごいと思える存在、というのは想像することすらちょっと難しい。自分のいままでの価値観では、すごいと思える部分があったらすでに平凡ではないからだ。 いまさら「スクラムおじさん」みたいな方向性に行くのも気が進まない。そういうことが好きでやりたいと思っているわけではないのに、技能だけで勝負できなくなったから長年の経験みたいなものを活かせるロールに立場を変える、というのは天下りみたいで格好悪く感じ、少なくとも自分はそうなりたくはない。 当面
ルーク、 MongoLab を使え！ - @kyanny's blog
五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい
Sapporo RubyKaigi 2012 (札幌Ruby会議2012) #sprk2012 - @kyanny's blog
Sapporo RubyKaigi 2012 (札幌Ruby会議2012) に参加してきました。充実した三日間を過ごしました。スタッフの皆様、ありがとうございました。札幌でお会いした皆様も、ありがとうございました。 30days Album の裏側 - レガシー Rails 編 というテーマで発表させていただきました。三日目の遅い時間にも関わらず多くの方にお聞きいただきありがとうございました。「共感した」というご意見をいただけて嬉しかったです。 スライドは言葉少なめなので、何を話したか書き起こそうと思ったのですが、文章にするのって難しいですね。うまく書けたらあとで追記します。 会期中はいろいろな方とお話させていただきました。懇親の場がたくさん設けられていたにもかかわらず、まだまだ話し足りないですね。次またどこかでお会いしたらもっとお話しましょう。 カンファレンスに参加するたびに、海外からの
Rails と時刻 - @kyanny's blog
時刻の扱いは難しい。タイムゾーンを跨ぐと格別に難しい。 Rails を使っていても難しさに変わりはない。むしろ時刻のやっかいな部分を隠蔽してくれるが故に余計にややこしくなることもある。 config.time_zone と config.active_record.default_timezone Rails アプリケーションで時刻を司る代表的な設定値は config.time_zone と config.active_record.default_timezone だ。いずれも config/application.rb で設定できる。詳細は Ruby on Rails Guides: Configuring Rails Applications 参照。 config.time_zone でアプリケーションのタイムゾーンを設定する。デフォルトでは UTC になる。日本向けのウェブサイトで
highscalability.com の Tumblr のアーキテクチャについての記事を読んだ - @kyanny's blog
High Scalability - High Scalability - Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter を読んだ。すごく面白かった。 Kindle で引用したところを中心にメモ。 Tumblr のソーシャルグラフの特徴 The graph for Tumblr users has hundreds of followers. This is different than any other social network and is what makes Tumblr so challenging to scale. Tumblr だと follower が数百人いるユーザーはザラにいる。 follower の多いユーザーの post は多くのユーザ
RubyKaigi2011 に参加した - @kyanny's blog
日本Ruby会議2011(7月16日〜18日)に参加しました。去年は惜しくも行きそびれたので、最初で最後の RubyKaigi でした。関係者の皆さん、ありがとうございました！ closing の動画、置いときますね。 以下、 Ruby とも RubyKaigi ともあまり関係ない個人的な感想しか書いてないので、 RubyKaigi の話が読みたいひとは http://b.hatena.ne.jp/t/rubykaigi2011 をクリックしてみよう！ ちゃんとやってるひとたちと、口先ばっかでやらないおれ RubyKaigi の会期中にいろんな方とお会いして話をしていろいろ刺激を受けたのだけど、ちゃんとやってるひとたちと、口先ばっかでやらないおれの差を見せつけられてハッとした。英語だったり発表だったり、口先だけで「やりたい、やろうと思ってる、やろうと思ってたけど・・・」なんて言い続けて結果
大江戸Ruby会議01に行ってきた - @kyanny's blog
大江戸Ruby会議01 - Regional RubyKaigiに行ってきた。 Asakusa.rb の皆様、発表者の皆様、ありがとうございました。とても楽しかった。以下、例によって感想をつらつらと。 100.times { Asakusa.rb.meetup! }, @a_matsuda コミュニティとは、みたいな話が聞けたのがよかった。自分が勉強してスキルアップしたい、ではなくて、 Ruby や Ruby を取り巻くもの（もちろん人も）に関心があるひとたちの集まり、という。 Asakusa.rb のような「コミュニティ」にはもともと憧れがあって、いいなーでも家からも職場からも遠いし・・・とか思っていたんだけど、一度行ってみたいと思ったし、それ以上に「じゃあ自分が近場で仲間を集めて何かすればいい」と強く思った。で、懇親会や帰り道で @mori_dev さんと @1syo さんにそれぞれ別
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
■ - @kyanny's blog
tig でいま見ているコミットをブラウザで開く - @kyanny's blog