Gitでブランチ切らないで作業をしてしまった時
ステージングされているものが全て新しいbranchに移行したいものであれば、これで新しいbranchに移行完了
RailsのHamlでbuttonタグの中にFont Awesome入れる
Gist: font-awesome-in-button-tag.haml
文字列の中にHTMLタグを含める場合は、.html_safeというのをつけて、「このHTMLは安全だから表示して大丈夫！」と明示してあげないと、安全のために自動的にエスケープされてしまうのだそうだ。Railsって賢いのねえ。
Gitで不要なcommitをリモートにPushしてしまった時の黒魔術
わー、branchに関係ないcommitが入ってる状態でうっかりPushしてしまった！しかもPull Requestまでしてしまった！
ありますよね。ないですか。そんな時。
黒魔術なのであまり使ってはいけません…|ωΦ)ｸｸｸ
Gist: いらんcommitをpushしてしまった時の黒魔術
完全にGit入門日記になってきた。
#（追記）git push -f 覚えてから、悪いことを覚えたての中学生のようにやたら使いたい気持ちになるのだけども、先日masterブランチでこれをやろうとしたら怒られました。masterでやるとＡ級戦犯扱いらしい。あとgit-rebase-i でHEADから遡りすぎて操作しようとするとこれまた収集つかなくなる。用法と用量を守る必要があります。ありました。
git-stash を使わないで stash的なことをやる
$ git stash今の作業を、ちょっと脇においといて…別branchに移動したりなんやりする時に便利なのでよく使います。が、忙しい時のstashは特に、stashしたことをついつい忘れてしまいがちで危険なので、あんまり使わない方がよいと聞きました。言われてみれば、おもむろに
git stash popした時に、全く記憶のないstashが出てきて、なんじゃこりゃー！となったことがあります。もう一回stashして見なかったことにしたりします。そんなわけで、git-stashを使わないで、stash的なことをやる方法をメモ
まず、今作業中の内容を全部add
$ git add .
で、作業中であることを示すコメントを入れてcommit
$ git commit -m "Work in progress"とかなんとか。これが、
git stashに相当する一連の作業。「なんちゃってstash」と勝手に呼ぼう。で、本来stashしてからやりたかった作業を完了後、
先ほど仮のcommitでおいといた、なんちゃってstashの作業内容に戻る。
なんちゃってstash中に、新たにcommitを追加して、"work in progress" がHEADじゃない可能性もあるので何番目のcommitなのか確認
$ git log↓
遡って2番目のcommitが "Work in progress" だった
git-resetで2番目のなんちゃってstashのcommitをリセットする
$ git reset HEAD~~元の作業内容に戻ってきたーヾ(*’ω’*)ﾉﾞ これが
git stash popに相当する。$ git statusで、ステージの内容が元にもどったことが確認できる。
$ git logすれば、なんちゃってstash中に作業した最新のcommitもそのまま残って無事なのが確認できるよ。
Gitって便利ねえ。実生活もGit管理したくなってきた。
git add -p をさらに分割する
という、ひとつのファイルから分割して部分的にcommitできる便利なオプションがあって、最近commitをもうちょっとこまめに分けようと心がけるようになってからたびたび使うのだけど、そうすると欲が出てきて、もう少し細かく分割してくれたらなあと思うことがたまにある。
$ git add -p
git add -p もうちょっと細かくわけてくれたらいいのにとたまに思う
— TAE ✅ (@ken_c_lo) February 16, 2013
@ken_c_lo 確か「git add -p」した後に「y」とか「n」で取り込むところを選ぶ時に「s」をやると、さらに小さい単位に分割してくれた気がします。最近やってないので若干怪しいですが。。
— 松本 瞬／Shun Matsumoto (@shu_0115) February 16, 2013
@ken_c_lo だいたいこんな感じだったと思います。→ bit.ly/XePByj 頑張ってくださいー。
— 松本 瞬／Shun Matsumoto (@shu_0115) February 16, 2013
あっ、そうか…いつもy / nしか使ってなくてあんまり意識になかったけど、そういえばなんか他にも色々文字がでてきてたわ…これで分割できたのだね。。というわけで、@shu_0115 さんが書いてくださったGistを貼っておきます。こんなに色々できたのか…(ΦωΦ)
git_add.md
なお、git add -pの使い方はこのエントリがとても詳しかった…ので、詳しくはこちらを参照のこと。
横着で神経質な私とあなたに贈るgit add -p #git #AdventCalendar - Qiita
git add -p → " s " でさらに分割
git add -p で分割された一つのコードの固まり（hunkというらしい）をさらに分割するには " s " をタイプする。すると、当初出てきたhunkをさらに半分くらいのサイズに分割してくれる。
しかし、もっと細かく分割したい！というケースもある。そんなときは " e " をつかって、hunkの内容を手で編集できる。
git add -p → " e " で編集。今回のcommitに入れたくない行を削除
" e " をタイプするとエディタが立ち上がって、hunkの内容を編集できる。えっ、ここで編集しちゃっていいの？消しちゃっていいの？と不安になるけれど、消した行はステージングされずに残るので、今回のcommitに入れたくない行は思い切って削除してOK。
なお、git add -p は、変更した行が連続していると一つの固まりの変更として認識してしまい、" s " してもうまく分割してくれないらしい。
また、" e " の編集機能でも、一つのhunkから連続していない2つの部分を削除したら、それは受け入れられない的なことを言われてしまってダメだった。
あまり込み入った変更をgit add -pでわけるのは無茶なんかもしれない。
教えていただいたこれを使ってみよかな。
GitX(L)@ken_c_lo GitX(L) などを使うと行単位でステージするしないを指定できるので便利です〜
— Uchio KONDO (@udzura) February 16, 2013
ちなみに、git add -p は変更した内容をいちいち確認しながらステージングできるので、うっかりミスの多め自分にとってはちょうどいい見直しの機会になるので、そこもよくて、最近は git add . をあんまりしなくなった。
git-cherry-pick で master の Sass を最新に
私の作り方にも問題があるのかもですが、CSSやSassはプログラムと違ってその変更がサイト全体に影響することが多いため、機能ごとにきれいに分割するのが難しく、トピックブランチ制で作業していると、そのブランチがmasterブランチにマージされるのを待つ間、masterのSassが古い状態のままになってしまい、masterブランチから続きのデザイン作業が進めづらくなる状況が頻繁に発生するのをずっと悩んでいました。
masterのSassだけでも最新の状態になってると、続きの作業が進めやすいのに…と思っていたところ、git-cherry-pickという他のブランチのcommitを取り込む方法を覚えたら、その悩みが解消されました。
複数人でデザインやマークアップ作業をしてる場合は、この方法だと問題あるのかもしれないですが、私のようにデザイン周りをいじる人がチーム内に他にいない場合はこの方法が便利だと思いました。
デザイナーはgit-cherry-pickを覚えると幸せになれる…かもしれないヾ(*’ω’*)ﾉﾞ
Gist: git-cherry-pickでmasterのSassを最新に
cherry-pickマジ便利…
cherry-pickのおかげで、Gitがなんだかすごく好きになってきました。git-cherry-pick最高ヾ(*’ω’*)ﾉﾞ
東京Ruby会議10で、Rubyistのためのデザイン講座ワークショップやらせていただきました #p4d #tkrk10
#p4d Rubyistのためのデザイン講座
- 12:30 - 13:30 発表1: @machida さん / 「RailsエンジニアのためのTwitter Bootstrapカスタマイズ例」
- 13:50 - 14:50 発表2: @ken_c_lo さん / 「少ない手間と知識で "それなり" に見せる、ズルいデザインテクニック」
- 15:10 - 16:10 発表3: @saucerjp さん / 「ノンデザイナーのための配色理論」
- 16:30 - 17:45 実習: オトナの塗り絵で学ぶデザイン
発表内容は、前回の「第一回 プログラマ向けデザイン勉強会 #design4p」の再演で、前回1画面に詰めすぎて喋りにくかったという反省から、きちんとスライドを分割して臨もう…と思っていたのですが、前の晩にさあ作業をしようと思ったらいつの間にか寝てしまい当日の朝になっていたという失態をやらかし、ほぼほぼ前回のまま、（少しだけ拡大画面等追加を入れて）臨むこととなってしまいました…（すみません。。。あぁ、次こそは、もっとうまくしゃべれるように…精進します…。。聞いてくださった方、ありがとうございました。
少ない手間と知識でそれなりに見せる、ズルいデザインテクニック// Speaker Deck（前回のスライドです）
@machidaさんの発表は、前回からさらにかなりグレードアップしており、新ネタも盛り込まれ、より役に立つ素晴らしいスライドになってました。（まだスライドUPされてないのかな。前回のやつを貼っておきます。）
RailsエンジニアのためのTwitter Bootstrapカスタマイズ例// Speaker Deck
@saucerjpさんの発表は、前回と同じく教授っぽい落ち着きで、知的好奇心も満足でき、かつアプリは実用的という、相変わらず素晴らしい内容でした。
[ HUE / 360 ] The Color Scheme Application
@saucerjpさんは[http://www.codegrid.net/:title=フロントエンドエンジニアのためのWebマガジンとして名高い「CodeGrid」]で、2月からデザイン講座の新連載が始まるそうで、CodeGrid愛読者の私も大変楽しみにしております！
前回は、寝不足で臨んだため、ウツラウツラしながらお二方の発表を聞いてたのですが、今回は図らずもよく寝てしまったために、発表も集中して聞くことができ、改めていい内容だなあと感動しながら聞いておりました。
今回の新ネタ、「大人の塗り絵で学ぶデザイン」の実習
これも盛況でよかったです。むしろこれはデザイナーの方が楽しんでしまった感ありますが…。
prog4designer/tkrk10-hands-on · GitHub
事前に上記のリポジトリをCloneしておいていただき、このような画面で、ヘッダや背景や本文の色を用意した色の中から選択し、できあがった配色を私どもデザイナーが講評するという内容でした。サンプルの画面は、エンジニアの皆さんがGemやライブラリを公開するときの画面を作るときを想定したものです。
これ、配色のインターフェイスをあっという間に組んでくださったのが、今回のスタッフであるバリバリjsも書けるデザイナーさんの @kkotaro0110さんで、今回の最も功労賞と言ってよいかと思います！（最近フリーランスになられたそうです。お仕事依頼のチャンス！）
ダメな配色を作るコツ
ダメな配色の例
ダメな配色のBlog
ダメな配色で作ったまずそうなあのサイト（す、すみません…(Φω|
良い物を作るには、まず何がダメなのかを知ることから…ということで、、ダメ配色を作るコツというのが最初の話題に上がりましたが、ダメな配色を作るコツを列挙してみると以下のようになるかと思います。
- 近い明度同士の色を並べる
- 中間色同士の組み合わせ
- 特に背景色（専有面積の大きい色）に中間色を選んでしまうと、その他は黒っぽい色か白っぽい色かの極端な色しか選べなくなってしまうので、選択の幅が大変狭くなります。
- 人間はあいまいなものの組み合わせを気持ち悪いと思う心理がある（by @saucerjp）
- 近いけどすこーしだけ違う色相の色同士の組み合わせ（@saucerjpさんの資料のM&S理論でいうところの「第一不明瞭」にあたる色）
- これけっこうやりがちです。近い色相で濃淡をつけているはずなのになぜかちょっと気持ち悪い…みたいなときは大体これをやってしまっています。
- 実は本職のミュージシャンである（！）@machidaさんが言ってたんですが、これ音楽でも不思議と同じなんですよね。音階で隣同士の音って（ドとレとか）綺麗な和音にならない。
- ちょっと色相が離れてるんだけど合わない色同士を選んでいる（@saucerjpさんの資料のM&S理論でいうところの「第二不明瞭」に当たる色）
- これ具体的な例でいうと、「赤と黄色っぽい黄緑」とかですよね…合わない。
- これ音階でいうと、「ドとファ」とかですよね…合わない。
- 正反対の色相の色同士を並べる（色どうしが喧嘩して、端っこがチカチカ光る現象（ハレーション）が起こります）
- 彩度が高い色を選んでいる
- 彩度が高いとそれだけで他の色とは仲良くしづらくなってしまいます。
- 例外として、黒に近い地色や白に近い地色に高彩度色はわりとかっこ良くキマリます。
- 他の色は低彩度で落ち着いているのに、一色だけ高彩度の色を選んでしまっている場合、ちょっと気持ち悪い感じになります。（見てるとこれ結構皆さんやりがちでした）
では、よい配色を作るポイントは？
上記を踏まえて、よい配色を作るポイントはこれかなあと思います。
- 背景色（専有面積の大きい色）を最初に決める
- 上記で言及したように、背景色に中間色を選んでしまうとその後に選べる色の幅が少なくなります。
- 背景色の他にも、色んな色をカラフルに使いたいのであれば、白に近いすごく薄い色（薄いグレーやアイボリー等含む）か、黒に近いすごく濃い色（濃いグレーや濃紺、濃い茶色含む）を選んでおく必要があります。
- 逆に中間色を背景に使うのであれば、文字等他のオブジェクトの色は、白に近い色か、黒に近い色を選ぶ必要があります。
- ごく近い色相の色同士を並べない（第一不明瞭）
- ブロック同士のトーンの調和にも気をつける
- これ割りとみなさんやりがちな落とし穴でした。ヘッダ、メインのスペース、それぞれの内部では色合いが合っているのに、ヘッダとメインのトーンがそれぞれちぐはぐな感じになりがち。全体でもトーンがあっているかどうか気をつける。
- 結論としてすごい乱暴に言ってしまうとWebサービスの色合いは、ちょっとさびしいくらいがちょうどいいです。
- 主役はコンテンツなので、コンテンツが読みやすい状態がベストで、かつ色で個性を主張できるギリギリのバランスの模索が必要。
- @saucerjpさんのアプリ、HUE360を使って色を選ぶ（これ間違いないｗ）
そんなこんなで、私自身もあまり配色について理屈立ててあまり普段考えることが少なかったので、、、本当によい勉強になりました。
デザインは絶対値がなくて、全てが相対的である
最近、@saucerjpさんと私の間でちょいちょい挙がる話題なんですが、結局のところコレよなあと思いました。全ては組み合わせと比較なのですよね。
@saucerjpさんの発表にあったようにRGBの16進で色を選ぶと人間にとって気持ち悪い色になってしまうことや、@machidaさんの発表にあった「スクリーンショットを取って比較すればわかりやすい」というのもおそらくこれで、人間の認知というのは、相対的に物事を判断するのには向いているけど、何かを絶対値で規定するのに向いていない（それは機械の方が向いている）ということに、色々収斂してきそうな感じがしてます。
恥ずかしながら実はかなり最近知って、感動したんですが、アジャイル開発なんかもまさにこれで、あのイテレーションなんかも人間は相対的な判断の方が向いているという前提のもとに編み出された手法っぽい感じがします。
このトピックが自分の中で最近だいぶアツいので、この手の事例を色々集めてみるとおもろいのかなあと思ってたりします。
プログラミングが、人間の感覚を機械の文法に置き換える手段なら、デザインとはその人間の感覚を徹底的に追求するお仕事なのかなあと、改めて認識させられた次第です。あー、精進せねば……(Φω|
さて、そんなこんなで、初のRuby会議の参加でしたが、非常に楽しく、勉強になりました。たくさんのRubyistの方々にお会いできたのもよかった！あと、黒Ruby会議すごいおもしろかった！ｗｗ
皆様、ありがとうございました。
あと、#p4d関連、告知です
#p4d デザイナー向けプログラム部（@satococoa さん主催）では、月1回、表参道のForkwellさんの会議室をお借りして、平日夜にWebサービスを作りたいデザイナーとプログラマが集まってプログラミングやデザインを教えあったり、もくもくと個々のWebサービスを作っていたりしています。（2月から月2回開催になるようです！）
Railsの環境を構築したり、最近旬のGitやSassなどをはじめてみたいデザイナーさん、プログラマにデザイン教えたいデザイナーさん、またデザイナにプログラミングを教えたいプログラマさん、デザイナにデザイン教わりたいプログラマさんなど、お気軽に参加お待ちしてます！
また、前回好評だったプログラマ向けデザイン勉強会の第二弾も、おそらく3月くらいに開催予定です。
あと、たまにデザイナとプログラマが組んでハッカソンなどもやっておりますので、ご参加お待ちしてますー！
