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日 それを受け
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
ヤフーの1on1 - @kyanny's blog
Engineering Managerになって三ヶ月経ち、ぽつぽつと1on1をやりはじめたが、合ってるのかよくわからないので本を買って答え合わせすることにした。結局、本を読んでも自分の振る舞いに対するフィードバックは得られないので、答え合わせにはならなかったかもしれない。 アクティブリスニングはできてると思う。昔から、人に興味ない割に、一対一で話すときは不思議と会話にのめり込みながら聞く癖がある レコグニションは大事そうだと理解してたけど、実践はまだまだのような気がした ティーチングとコーチングの切り替え・使い分けをもっと強く意識すべきだと思った。コーチングの割合を増やした方が良い 相手のための時間であるということも、もっと強く意識すべきだと思った。つい自分が話しすぎてしまう コーチングに通ずるテクニック全般に言えることだが、綺麗事にみえて実際は「相手に悟らせず自分の意のままに操る、人を動
RubyKaigi 2015 - @kyanny's blog
二日目の夕方からと三日目の二コマ目から参加した。 この一年ほどは Ruby/Grape,Rails よりも CoffeeScript/Backbone,Marionette を書いてる時間の方が圧倒的に長く、仕事以外でも特に面白いものを作らなかったので、トークに応募しなかった。準備せず手ぶらで参加するだけのカンファレンスは、ラクだけどやっぱりどこか物足りないなと思った。もっとも、この冬の忙しさでは準備できたとも思えないが。 今年は「Ruby にこだわる」姿勢というものを感じるトークが多かった（自分が聴いたものの中では）特に mruby は、数年前に出てきたときは全然ピンとこなかったけど、今年はなぜか「Rubyist ならパフォーマンスが出ないからとかいって Go なんか選ぶんじゃなく Ruby でパフォーマンスを出す方法を考えるのが筋だろ？」と言われているような気がして身が引き締まる思いだ
第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
リモートで働く開発者が行うとよいたった二つの習慣 - @kyanny's blog
チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で返事をはやく返す チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で自分の状況をこまめに報告する 目安としては、 1 on 1 チャットは 30 秒以内・パブリックチャットのグループ mention （@here みたいなやつ）は 1 分以内・パブリックチャットの mention なし不特定多数向けメッセージは 3 分以内・それ以外のものは 24 時間以内に返事をするとよい。これより遅いと、「自分が返事をしないせいで相手を待たせてしまい、ストレスを与えたり仕事が進まない原因を作っている」ということになってしまう、と思っておくのがよい。 1は第一には「相手を待たせない」ためだが、まめに返事をしてあげていれば逆の立場になったとき自分もまめに返事をしてもらえることがあるので、自分自身
Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな
マナーの悪いIngress - @kyanny's blog
笹塚に創価学会の施設がある。Ingress をやっていて何気なく Hack したポータルがそうだったのだが、ポータル名に悪意を感じた。 特定の新興宗教を邪教と呼ぶのは個人の自由だが、不特定多数の目に触れるある種パブリックな場所にあるものに対して偏った主観に基づくラベルをつけるのは感心しない。自分はさほど熱心なエージェントではないのでゲームにもコミュニティにも強い思い入れはないが、こういうつまらないイタズラで Ingress の評判に傷がついたら残念に思う人も少なくないと思う。 ポータル名の編集をリクエストすることができたので、看板に書いてあった「創価学会 渋谷平和会館」という正式名称に変更要請しておいた。気がついてよかったと思う反面、日本中にこんなのがあるのかと思うと気が滅入る。 2015年4月9日更新 Accepted. https://www.ingress.com/intel?ll=
アナログ世界時計をチャットに貼れるサービス Tokei.link をリリース（Slack 対応） - @kyanny's blog
「現在時刻を知りたい国や都市をチャットでつぶやいたら時計が表示されると便利だな」と思ってそういうサービスを作りました。無料です。登録も不要です。 http://www.tokei.link/ アナログ時計なので文字を読まずにパッと見でだいたいの時刻を把握できます。一つの国や都市の現地時刻を表示する機能と、二つの国や都市の現地時刻を並べて表示する機能があります。「ロンドンとシンガポールの同僚とビデオ会議をしたいけど、いま何時かな？」みたいなときに便利です。 API があります http://www.tokei.link/doc http://www.tokei.link/png?destination_timezone=New+York&local_timezone=London のような URL に GET リクエストを送ると、指定したタイムゾーンの現在時刻を表す PNG 画像を返します。
英語で朝会 - @kyanny's blog
Quipper には約 20 名ほどの Developer がいる（Software Engineer + Designer をあわせて Developer と呼んでいる）。この夏から、おおまかなトピックごとにチームをわけて、毎月チーム間でメンバーをシャッフルしている。 GitHub flow に従うこと、のような基本的な決まりは Developer 全員に共通しているが、それより細かいレベルでどのような開発手法を取り入れるかはチームの裁量に任せられている。が、自然とどのチームも daily standup （スクラムでいう朝会）をやるようになった。 どのチームも複数拠点のメンバーからなるので朝会での公用語は英語だ。 Skype でビデオチャットをするチームもあれば、 HipChat でテキストチャットをするチームもある。朝会といいつつ、時差の関係で夕会になってしまうチームもある。 今月の
Increments は和製 GitHub の夢を見るか？ - @kyanny's blog
Quipper では日本オフィスの開発者を中心に、 Qiita::Team を導入して社内のドキュメント共有を行なっている。書かれる内容は日報が多いが、技術 Tips の共有やチャットでは適切でない込み入った技術的問題を解決する議論の場としても活用している。 なぜわざわざドキュメント共有？ていうか日報書くなんてダサすぎじゃね？そう思ったあなた、日報を見くびっちゃいけません。上手に運用すればナレッジシェアやコラボレーションのみならず、チームビルディングにも役立つんです。 上手に運用された日報には前例がある。ペパボの社内 SNS であるタンパクがそれだ。毎日スタッフ全員が日報を書くきまりなのだが、本来の目的である業務内容の記録以外に一言コメントを書く欄がある。定型文で済ます人もいればブログ並の長文を書く人もおり（それはわたしです！）、これがそこらの SNS なんかよりよっぽど面白いコンテンツな
rbenv のメカニズム - @kyanny's blog
rbenv 環境下で実行された Ruby プログラムの中から他の Ruby プログラムを起動するときに、 rbenv 環境をリセットしたい―要するに別のバージョンの Ruby で外部プログラムを実行したい―という事情があったので rbenv のメカニズムについて調べた。 rbenv 環境下で ruby コマンドを実行するとき、実際にコンパイルされた ruby バイナリが直接実行されているわけではない。 rbenv 環境をお膳立てした上で ruby バイナリを exec するラッパーのシェルスクリプトが実行される。こういうものを binstub と呼ぶ。 binstub である ruby という名前のシェルスクリプトの中身をみてみると、最終的に rbenv exec というサブコマンドを呼び出している。 rbenv のサブコマンドはリポジトリでいうと libexec ディレクトリ以下にある。
Jenkins に bundle update した上で Pull Request させる - @kyanny's blog
皆さん bundle update してますか？ぼくは忙しさにかまけてついサボりがちなのですが先日何ヶ月ぶりかにやってみたらけっこういろんな gem がアップデートしててヒヤリとしました。 bundle update 忘れは今後もまたやってしまいそうだと思い、なにかこれを解決する方法がないか考えたところ、 マメにやるのは無理。余裕があればやるけど忙しくなったら忘れる。自分の意識が低くなっても破綻しない仕組みを作るべき 差分が小さくても Pull Request を出すのは悪くない。というか Pull Request は毎日全員が見るし放置されにくい bundle outdated の結果をメールするのもお手軽そうだけど、メールなんてどうせ見ない (pendaxes がいい例で、毎朝メールがきても痛くも痒くもない) ということで「Jenkins に毎週 bundle update したブラン
「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog
rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動
Working with UNIX Processes を読んだ - @kyanny's blog
Working With Unix Processes という本を読んだ。 Thin の作者からの「時期バージョンを作るとき参考にする」というメッセージ*1が添えられていたのに惹かれて買った。著者のサイトで直販しているが、 Kindle Store からも購入できる。 この本は一言でいうと、 UNIX 系 OS のプロセスについての本だ。プロセスとは何か、という導入部から始まって、プロセス ID やプロセス名、終了コードへと言及し、 fork(2) やソンビプロセス、シグナル、そしてデーモンプロセスの説明あたりまで本編中で説明している。 UNIX プログラミングに関する類書は 1000 ページを超えるものが多いなかで、この本はわずか 100 ページほどしかなく容易く読める*2。しかしページ数が少ないぶん、あまり踏み込んだ内容とは言えず、全体的にやや浅い印象を受けた。すでに UNIX, Li
1章 ようこそ、Rubyのある生活へ - @kyanny's blog
object.object_id メソッドで、あるオブジェクトの一意な番号がとれる。 == と equal? は比較方法が違うので var1 == var2 と var1.equal?(var2) の結果は同じになるとは限らない。 object.class メソッドで、あるオブジェクトのクラスがわかる。 "string".class #=> String "string".class.class #=> Class "string".class.class.class #=> Class クラスもオブジェクトらしい。 String クラスというものは Class クラスのオブジェクトなので "string".class.class #=> Class になるということか。 "string".class.class.class も Class になったのは・・・なんでだろう？ 見慣れない文法
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tig でいま見ているコミットをブラウザで開く - @kyanny's blog