コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles

う○こしづらすぎて和式が嫌いだ。 中腰は疲れるし、ち○この位置が定まらないと惨事が起きるからだ。 またう○こが射出される位置もう○この状態で変化するため（たとえばゲ○状態だと定まらず便器にぶっかけられてしまう）とてもじゃないが利用する気が起きない。 とにかく和式便所はとっとと滅びて欲しい。

おじさんになると、自分が社会人だから、社会人を主体とした話をしがちになる。社会に出てからが人生の本番であって学生時代はその準備期間にすぎないとでも言いたげになる。学生時代にそんなふうだと社会に出てから苦労する〜みたいな論調になる。 そういうロジックの人は、幼稚園児には小学校が本番だっていうし、小学生には中学校で勉強に遅れるぞみたいにいうし、高校では大学受験を正当化するためにいろんな不合理を押し付けると思う。 東大に入るのを人生のゴールにしないで、そこで何をしたいかを目標にしろみたいにも言いがちだと思う。 東大に入るのが夢でも問題ないとおもう、その先に何をするのかを目標にしろつっても、早かれ遅かれ目標達成したら次の目標立てなきゃならんだけだし、人生は連続していていつか死ぬ— Issei Naruta (@mirakui) August 19, 2011 東大、行ったことないけど、東大に入るの

用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ

ついにiPhone卒業→「Nothing Phone (2a)」へ。この乗換えが大正解だった!【今日のライフハックツール】

ruby のアプリを動かす時にいちいち bundle exec って書くのがダルい。書きたくない。でもシステムに入ってたり違うバージョンの物が動いて変な動作をされても困る。 どうにかしてこのダルさを解消できないかと考えてみた。 まず rbenv を使ってるなら gem でインストールされるコマンドは必ずシェルのラッパとして生成され、そこから本物が起動する様になっている。例えば rails であれば以下の様なシェルになっている。 #!/usr/bin/env bash set -e [ -n "$RBENV_DEBUG" ] && set -x program="${0##*/}" if [ "$program" = "ruby" ]; then for arg; do case "$arg" in -e* | -- ) break ;; */* ) if [ -f "$arg" ]; th