GitHubのcommitのURLの末尾に ?w=1 とつけると差分がわかりやすい（時がある）

Git

各commitのURL

https://github.com/hoge/fuga/commit/xxxxxxxxxxxxxxxxxxx
の末尾に "?w=1" をつけて
https://github.com/hoge/fuga/commit/xxxxxxxxxxxxxxxxxxx?w=1
とすると、差分がホワイトスペースのみの行を省いて、文字の変更があった行だけを差分表示してくれるので、何を変更したかがピンポイントですごくわかりやすくなる場合があります。


例えば下記の例。CoffeeScript内である部分をコールバックにして、コールバックした部分のインデントをごっそり下げてるのですが、インデントを変えただけの行も全部差分に表示されてて、何を変えたのかひと目でわかりづらい。


普通のcommit表示

↓
これがURLに"?w=1"をつけるとこうなる！！！
↓

単にインデントを変えただけの行が省かれて、文字の変更があった行だけを差分表示してくれるので、何を変更したのかひと目ですごくわかりやすい。
これは感動的だ！ヾ(*'ω'*)ﾉﾞ



#（追記）
id:efcl さんのブックマークコメントから知ったのですが（ありがとうございます！）、GitHub公式にも載ってました。
GitHub Secrets - GitHub
GitHubのヒミツ、なんですね(Φω|


#（追記2）
@gantawriter さんがBookmarkletにしてくださいました。べんり！ ＆ 仕事はや！

Rubyコマンドにつけるおまじない "bundle exec"

ruby

rake なんとかとか、Ruby系のコマンドを実行してどうもうまく動かないとき、bundle execというおまじないをコマンドの頭につけるとうまくいくことがある。
どこに入ってるライブラリが呼び出されるのかがそのマシン環境によってかわるので、現在実行中のプロジェクトのものを指定して呼び出されるようにするためのものらしい。（多分）
例えば

$ rake db:migrate
↓
$ bundle exec rake db:migrate
とかやる。
よく使うので、.zshrcとか.bashrcとかにエイリアスを作っておくと幸せ。
alias bx='bundle exec'
"bx"派と"be"派がいるっぽいけど、bxの方がなんかかっこいい。

RVMからrbenvに乗り換えてRuby2.0.0-p0を入れる

ruby Ruby on Rails

RVMとか使ってていいのは中学生までだよねって言われたので、はっ、そうだったのか、と焦って乗り換えました。この記事が大変わかりやすく参考になりました。Gistには手順だけ書きましたが、詳しくはこの記事見た方がいいです。
OS X で rbenv を使って ruby 1.9.3 の環境を作る #Ruby #開発環境 #AdventCalendar - Qiita




# 追記
@satococoa さんと @shu_0115 さんから助言いただいたので追記しました。ありがとうございます！そうかー、普通に全部brewでも入るんですねー。

ズルいデザインを振り返る

design

ズルいデザインのことを振り返ってみたいと思った。
書いた本人がびっくりするほどのヒットになってしまい、今も使ってくれてる人がたくさんいてすごくうれしいのですが、一体アレの何がよかったのか。
「ズルい」というタイトル（©machida）もさることながら、そこに、自分のデザイナーとしての自己主張をあまり盛り込まず、割と純粋にP4Dに来るエンジニアさんがデザインをするときに何を求めているかだけを考えて作れたことが、良かったんじゃないかという気がしている。
そのおかげで、フォロワーさんは増え、執筆や講演の依頼は頂いても、デザインそのものの依頼は来なかったという、デザイナーのセルフブランディングとしては正直割と失敗だったんでは…と思わなくもない。でも一方で、たくさんの人達に参考にしてもらえて、実際使ってもらえているというのは何よりの喜びだ。
しかし、「ズルい〜」を書いた時のように、作り手の功名心や自己主張を差し置いて、ユーザー本位にものを書いたり作ったりできるような精神状態を獲得するのは案外難しくて、どうしても自分の作るもの書くもののそこかしこに、ユーザーが必要としない主張が顔を出してしまうのが常だ。ちなみに今これを書いてる精神状態は、もちろん自己主張超丸出しです。
Design4Pで「ズルい〜」の発表の機会を頂いた時は割と状況が特殊で、正直人前で話すのもすごく苦手だし実は気が進まなかったのだけど、それまでP4Dのエンジニアさんにタダですごく親切に色々教えていただきながら、何一つお返しできていないのでヤバい…、というそれだけがお受けした動機だった。恩を返さねばいけなかったのだ。
恩返しだけが動機であり目的だったので、P4Dに来るようなWebサービスを作りたいエンジニアさん達にすぐに役に立ちそうなコンテンツを提供することがミッションという、自分の中ではすごくシンプルな話になった。ポイントさえつかんで、コードさえ書ければ、誰にでもすぐに真似できることだけを話そうと思った。
自分自身は、デザインするときにもうちっと色々考えてるし、単にSassやCSS、PhotoshopやIllustratorが操れることがデザインであるとも決して思わない。でもその自分の思いは、少なくともあの発表の場では割とどうでも良い事だと思った。私の発表を聞いてくれる人達は、限りある時間の中で、今すぐに、今手元にあるリソースの範囲内で、もうちょっと良い物を作れるようになりたいだけなのだ。そう思ったので、それにそぐわなそうなものは、自分の中で思い入れやこだわりが強いトピックでも、草案の段階で全部省いた。多分、それがよかったのだと思う。
もっとも、作り手の功名心や自己主張やこだわりを、もちろん自分は全く否定しないです。それこそが、やはり何かを作ったり書いたりするときの源泉になる事は確かだし、こうやって今書いている文章だってそういう気持ちがあるから書いてる。作り手の自己主張や表現、技巧、技術そのものがユーザーを魅了し、心を打つことだってあるし、そういうもの作りが出来る人を私はすごく尊敬する。
けども、自分はそういう趣向とは少し違ってて、やはりユーザーが何を必要としているのかということに寄り添って何かを作ったりしたい。その最適化の結果、例え、多少デザインがダサくなろうが、技術的な作りがイケてない感じになろうが、デザイナーとしてのプライドを多少挫かれることになろうが、いいんだと思う。（もちろん、作り手のやりたい事とユーザーの喜びがトレードオフだとは決して思わないし、本来はそれらは両立して、うまく止揚できるものだと信じているし、そのための最大限の努力はしたいと思う。）
まず、ユーザーに喜んで使ってもらえないとやっぱり意味が無いし、自分が作ったものが使ってもらえるということは何よりも勝る喜びだと思う。作り手都合や作り手感情を（尊重しつつも）優先させる事がないように、きちんと裏方に徹したい。


という、日々の反省と所信表明のような何かでした。（何のだ？

翻訳：Railsを学んだことで私はより良いデザイナーになった（by 37signalsのデザイナー）

Ruby on Rails design

Getting Real や Basecampなどで有名な37signals、そこのデザイナーである@jonasdowney さんがよいことを書いてらして、そうだよなーと思ったので訳してみました。英語あまり得意でないので割と勢いで適当に意訳しました。誤訳あったらすいません。

原文：Learning Rails made me a better designer by Jonas of 37signals - Signal vs. Noise




（以下、翻訳）---

Railsを学んだことで私はより良いデザイナーになった

Jonas Downey wrote this on Feb 22
37signalsのデザイナーはコードを書く。HTMLやCSSだけではなく、RubyやJavaScriptも書く。私たちはプログラマの手助けなしで、当然のごとく自分のアイデアを実装することができる。
新しいBesecampの開発が佳境を迎えた時、私がRailsの集中講座の授業を受けられることになったのはラッキーではあったが、1年経っても光が見えず、私は自分の選択が正しかったのかどうか自信がもてなかった。そこで、昨年の秋、The Starter LeagueのRails for Designerという授業を受けた。それは見事に私のプログラミング能力を開花させてくれた。そのことがこんなにも自分のデザインプロセスに変化をもたらしてくれるだなんて、全く期待以上だった。

歩けるようになるにはまず、自分自身の足で立たなければ。

インターフェイスは、動かない画面に貼り付けられた書類の束では決してなく、それは、インプットとアウトプットのフローなのだ。それが本当によいインターフェイスなのかどうかは、自分で使ってみるまで評価は下せないし、使ってみるにはまず作ってみないといけない。正確な評価・判断をしたかったら、実物に勝るものはない。
プログラマが開発にジョインした時、デザイナーが自分のデザインが素晴らしいものだと自信を持ってるならいいけど、そうでなかったら？他人の大切な時間と精神力をゴミに費やすことになるかもしれない。そうなったらひどい話だ。
デザインプロセスが一変したのは、先日、新しいアプリ制作が始まったときだった。それまで私たちデザイナーは、動かないモックアップと、いくつかの動く部品を作って、それからプログラマの助けを呼んでいたが、この時の私達は、およそ2ヶ月もの長い期間を、プログラマの手を煩わせることなく、コンセプトの検証や新しいアイデアを実験するためのプロトタイプフェーズに費やすことができた。プログラミングの基礎知識は、私達デザイナーに dance without a partner のための手段を授けてくれる。
「コードマスター」になる必要はない。私だって全然そこまでじゃない。機能的に動くものを作れるようになりさえすれば、自分のデザインを評価・判断するには十分だし、それは本職のプログラマが自分のデザインを素晴らしいプロダクトに仕上げてくれる際の大きなアドバンテージになる。
あなたはプログラミングを学んだデザイナーですか？それはあなたのデザインプロセスを変えましたか？コメント欄でぜひ聞かせてください。

（翻訳おわり）---

37signalsのデザイナーはやっぱりすごいなあ。精進します。


#後日談
翻訳させてもらったことを報告したら、ご本人から返信いただいた！Awesomeヾ(*'ω'*)ﾉﾞ

インターネットって素晴らしい！


小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
posted with amazlet at 13.03.02
ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン
早川書房
売り上げランキング: 7,521
Amazon.co.jpで詳細を見る