ある 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日 それを受け

15年暮らした東京都杉並区久我山から、妻の実家がある石川県金沢市に引っ越した。 いずれは金沢に移住しよう、という話はしていたが、定年退職後とか、何十年も先になると思っていた。ところがここ数年で状況が変わった。妻が仕事を辞め、おれはフルリモートの仕事に就いた（コロナ前からフルリモートだったポジションなので、コロナ移住ではない）。通勤が不要になり、東京都内はおろか首都圏に住む必要もなくなった。ならば予定を大幅に早めてすぐ移住してもいいのでは？去年くらいからそう思い始めた。 仕事による生活圏の縛りが無くなった以外にも、移住したかった理由がいくつかある。金沢には妻の母が一人で、いや猫一匹と同居していて、妻とはとても仲が良いこともあり、やはり寂しそうで気掛かりだった。自分達が飼っている二匹の猫にも、もっと広くて快適な住処を与えたかった。杉並区の部屋は猫二匹と人間二人が暮らすには狭く、特に上の猫は二匹

Plan https://getplan.co/ というサービスを試して、止めた話。 ToDo 管理について調べていると「ToDo リストは使うな」という意見をたまに見かける。曰く、締め切りのないタスクは終わらないので、カレンダーに予定を入れて締め切りを設定せよ、という。このアイデアに魅力を感じつつも試してこなかったのは、カレンダーの予定はスヌーズしづらいからだった。今日やる予定だったけど終わらなかった、というとき、予定の日付を変更するか新しい予定を作るかを手動でやらないといけない。 ToDo リストなら未完了のタスクが残ってるだけだ。 ToDo リストとカレンダーを融合させるアイデアをうまく実装していそうな Sudachi - timetable editor for daily personal scheduling というアプリがある。 [Sudachi]超シンプルに1日のタスクとス

特に何かに困ったわけではないけどメモ。 とあるサイトでこんなレスポンスヘッダをみつけた。 HTTP/1.1 200 OK Date: Wed, 21 Oct 2009 02:31:27 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Wed, 14 Oct 2009 12:11:11 GMT ETag: "119565d-13ae0-475e40ef875c0" Accept-Ranges: bytes Content-Length: 80608 Connection: close Content-Type: text/html X-Pad: avoid browser bugX-Pad ってなんぞや？と疑問に思ったのでぐぐってみたら PHP-users の過去ログに書いてあった。 [PHP-users 19224]X-Pad: avoid

半年以上経って、またいろいろ環境が変わった。 7月に会社で大きな組織変更があった。直属の上司が変わった（上司の肩書も変わった）。それと並行して組織の体制もガラリと変わった。詳しいことは Quipper組織変更と41歳CTOの今後 - Masatomo Nakano Blog に書いてある。 新しい上司は開発体制だけではなくマネジメントの体制もいろいろ整備してくれて、自分に関わる部分でいうと、自分が Engineering Manager としてマネジメントする人数が 19 人から 7 人に減った（新しく Engineering Managers が増えて、減った分はそちらにスライドした）。その上 Engineering Manager に求められる役割もより限定されたものになった。要するにマネジメント業務はずいぶん楽になった。 毎日ミーティングするために会社へ行き仕事のプログラムを一行も読

Net::HTTP で通信してる内容をのぞくには set_debug_output に io を渡す。ヘッダもボディも全部出るので外部 API の呼び出しをするコードのデバッグとかに便利。 http = Net::HTTP.new('example.com', 80) http.set_debug_output($stderr) http.get('/') あんまし見やすくはない。 StringIO とか使ってうまく改行を整形した状態で出力できないかなと思ったけどうまくいかなかった。 ぐぐってもあまり出てこないけど undocumented というわけではないみたいだし知ってる人は知ってるみたい。 net/http - 詳細なログを出力させる - 技術メモ帳 Rubyのnet/http でHTTPリクエスト/レスポンスをdumpする方法 - ( ꒪⌓꒪) ゆるよろ日記 Class: Net

blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき

Kindle Unlimited で読んだ。 まずプロトタイプを作る、というのはすでにやっていたが、二割の時間を見積もりのためと称して八割の仕事を終わらせる、というのはなるほどと思った。ある程度見通しが立つまでは正確な見積もりなんてできない、と常々感じてはいて、だからこそプロトタイプを作って見通しが立つかやってみるべき、と考えてはいたものの、ここまで明快に意識してはいなかった。 仕事を終わらせるための考え方については、自分の考え方が間違っていなかったと答え合わせできたような部分もあるし、まだまだ足りないところがあったと気付かされる部分もあったが、朝早起きするのだけは大嫌いなので絶対にやりたくないなと思った。そのせいで人生変わらないならそれでもいいからずって寝てるわ、って感じ。 あとやっぱり、「学生時代に作ったソフトで一億も稼いだり、MicrosoftでWindows95のアーキテクトをやっ

著者の id:tomoya さんから本をいただきました。ありがとうございます。 d.hatena.ne.jp 宣伝に偽りなし。 Atom の操作方法から内部構造まで丁寧かつ徹底的に解説した一冊だ。 Chrome DevTools しかり、 Web Components しかり、 2016 年に書籍で読む価値のある Web 技術の話であり、それぞれ単体で一冊の本になってもおかしくないトピックだ。それをテキストエディタの解説書でカバーしてしまう発想には脱帽する。 本題のテキストエディタの解説部分も抜かりない。まず目次からしてひと味違う。操作の名前（日本語）と対応するコマンド名（英語）が併記されているので、目当ての操作を見つけたらコマンドパレットにコマンド名を入力してすぐに使うことができる。さらに各項目の解説ページにはそのコマンドを呼び出すデフォルトのキーバインドも掲載されているので、メニューか

自分は十数年前からクローン病を患っており、現在も治療中の身なのだけど、以前から「遺伝子検査を受けたらクローン病の発症リスクはどのくらいと出るんだろう」とずっと気になっていた。先日 MYCODE が 40% オフキャンペーンをやっていたので、申し込んで検査を受けてみた。 なお、 MYCODE の説明事項において、 本検査結果に示される病気の発症リスクや体質の情報は、個人のリスクを示すものではなく、特定の塩基配列に関する統計的な確率を相対的な数字として表したものであり、特定の塩基配列を持つ集団の平均的な傾向及びリスクです。さらに、環境要因や生活習慣等、他の要因によっても大きく左右され得ます。お客様ご自身の健康状態・体質そのものを示すものではありません。 と説明されており、自分はこれを読んで内容について理解・同意しているので、自分の遺伝子に対するクローン病の発症リスクが高いとでようが低いとでよう

これもちょろちょろと試した結果、「自分宛にメールする、終わったらアーカイブ」という非常に原始的な方法に落ち着いている。 まず、「ツールを出来るだけ増やさない」という制約を課した。いろいろ試したいんだけどどうせ使いこなせないし、すぐ飽きるし、というのが目に見えている。暇で仕方なかったら喜んで暇つぶしをしたいところだが、本当に忘れちゃいけない・やらなきゃいけないことができなくなってしまうのは困るので、新しい TODO 管理サービスにサインアップしたりするのはやめにした。 普段から毎日必ず使うものをベースに考えると、結局 Gmail (Inbox) と Google Calendar くらいしか（自分が毎日確認すると）信用できないな、と思い、 Inbox のリマインダーでいいじゃんと思ったのだが、 iOS だとこれがけっこう追加するまで面倒くさい。 ホーム画面で Inbox アプリをタップ ->

なんなのかあまり深く考えたことがなく、雰囲気でつけたりしてたが、 Rspecの文法の基礎 - Qiita rspec-rails/model_example_group.rb at master · rspec/rspec-rails · GitHub ということで、 spec/models とか規定のディレクトリ以外の場所にファイルがあるとき rspec-rails の用意するヘルパーを example の中で使えるようにするための tag 記法、だったと知った。なので、 < ActiveRecord::Base でないただのクラスのテストなどの場合はこの tag は不要。

以下の HTML があるとき、 <!doctype html> <html> <head> <meta charset="utf-8"> </head> <body> <form action="http://localhost:9292" method="post" accept-charset="shift_jis"> <input type="text" name="key1" value="ほげ"> <button>submit</button> </form> </body> </html> このフォームを提出すると、ユーザエージェントはサーバに対し "ほげ" を Shift_JIS エンコーディングで送信するはずであり、実際そのようになる。 この挙動が、どの仕様のどの箇所に基づいてそうなっているのか、いまいちよくわからない。 accept-charset 属性の仕様は http

コードレビューするときに考えること 開発チームもコードベースもプロジェクト規模も大きくなってきたので、もはや実装上の設計の細かい点まで指摘することが難しくなった。個人的な趣味で、自分が直接関わっていないプロジェクトの issues も全部眺めているが、それでも内容を把握しきるのは無理。なので、コードそのものに対する指摘は少なくなり、その代わりに「第三者があとでこのコードを見たとき、意味がわかるだろうか」と考えて、わからなそうだなと思ったらたとえ自分には意図が理解できたとしても「意図がわからないのでコメント書いてくれ」とか指摘するようになった。コードレビューをしているのに、コードレビューをしていない人の気持ちになる、みたいな感じ。ちょっと幽体離脱っぽい。違うかもしれない。 仕事のやり方について考えること 一般に、能力が高い人ほど仕事が増えがちだし、責任感の強い人ほど仕事を抱えてしまいがちだ。

The programming talent myth [LWN.net] 5月をふりかえる - Kazu's Soapbox でほめられていたので読んだ。長いのでまだ半分くらいしか読めておらず、 HN のほうは全く読めていないが、 kzys さんが感心していたのとは違う部分で良い気づきが得られた。 曰く、あなたが一緒に働いたことがないプログラマの実力を測る術はないのだから、確率分布的に見積もるしかない。世の中のたいていの物事は正規分布に従うのだから、プログラマの能力は山なりのグラフの中央付近に属するはずである。しかし我々はプログラマの能力をそのように見積もらず、逆U字形のグラフのように分布すると考えがちで、自分はU字の優れた人が集まる側に、知らない他人はその反対側に属すると思いたがる。だがそれは全然なんの根拠もない妄想なのでやめよう、みたいな話。 この話に感銘を受けたのは、まさに自分がそ

それでもRailsを選択する3つの理由 - pblog 興味深く読んだ。 ずっと気になっていることがある。フレームワークとアプリケーションの境目について。 アプリケーションとフレームワークははっきり区別されるべきなんだろうか。 Rails は「区別するべきだ」と要請しているように感じられる。アプリケーションはフレームワークが規定する「できること」の範囲内で書くべきであり、その範囲を外れる場合は相応の覚悟をしろ、領分を守る限り難しいが一般的な問題はフレームワークが正しく解決してやるぞ、と。 一方で、フレームワークもアプリケーションの一部である、とする考え方もあると思う。足場を支えるライブラリに過ぎない、という思想。両者の境界は曖昧になり、フレームワークが規定する「できること」だけでは物足りなくなったとき、アプリケーション側を「できること」の枠内に合わせるのではなく、フレームワーク側を拡張して

時刻の扱いは難しい。タイムゾーンを跨ぐと格別に難しい。 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 になる。日本向けのウェブサイトで

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 は多くのユーザ

#shibuyarblunch のサイトをアーカイブ化しました。Lokka (CMS) で運営されていましたが、現在は静的サイトとして配信しており、今後は更新されない予定です。 2020/11/10 更新: heroku の bamboo stack (!) を使っていて動かなくなっていた && ドメインも変わってリンク切れになっていたのでアプリを作り直しました。 大江戸Ruby会議01 で僕と @1syo さんが意気投合し始まった #shibuyarblunch でしたが、発起人の二人が渋谷を離れてしまったことや、途中から運営を取り仕切ってくださった @tyabe さんの主催する渋谷.rbが「渋谷近郊のRubyistのための地域Rubyistコミュニティ」という役割を担うようになった等の事情により、定期的な活動が途絶えていました。 大量のスパムコメントが投稿されているなど好ましい状態では

皆さん bundle update してますか？ぼくは忙しさにかまけてついサボりがちなのですが先日何ヶ月ぶりかにやってみたらけっこういろんな gem がアップデートしててヒヤリとしました。 bundle update 忘れは今後もまたやってしまいそうだと思い、なにかこれを解決する方法がないか考えたところ、 マメにやるのは無理。余裕があればやるけど忙しくなったら忘れる。自分の意識が低くなっても破綻しない仕組みを作るべき 差分が小さくても Pull Request を出すのは悪くない。というか Pull Request は毎日全員が見るし放置されにくい bundle outdated の結果をメールするのもお手軽そうだけど、メールなんてどうせ見ない (pendaxes がいい例で、毎朝メールがきても痛くも痒くもない) ということで「Jenkins に毎週 bundle update したブラン