Gitで数個前のcommitを遡って分割する

Git

数個前のcommitを遡って、それを分解して2つのcommitに分けたいとか、たまにある。

例えば、git logで上から遡って5つ目のcommitを2つに分けたい場合



$ git rebase -i HEAD~5
git-rebase -i で5個目のcommitをeditに変える


pick xxxxxx Add JS files                                                                                                                 

pick xxxxxx Move Vendors CSS files

pick xxxxxx Add jquery.powertip

pick xxxxxx Add font

edit xxxxxx Design for tasks#index  ← 分割したいcommitの 'pick' を 'edit'に変える
で、git-rebase -i した状態で、HEADの位置をさらに一つ手前のcommitに移動する


$ git reset HEAD~
すると、分割したいcommitの中のファイルがUnstageされる


Unstaged changes after reset:

M	app/assets/stylesheets/screen.css.sass

M	app/views/tasks/index.html.haml
分けたい部分を別々にaddしてcommitし直す


$ git add app/assets/stylesheets/screen.css.sass

$ git commit -m 'Sass for tasks#index'

$ git add app/views/tasks/index.html.haml

$ git commit -m 'Markup for tasks#index'
とかやって、2つのcommitができたら、普通に


$ git rebase --continue
すると、普通にrebaseが成功して、commitが遡って分割できる。めでたいヾ(*'ω'*)ﾉﾞ

第24回 デザイナー向けプログラム部 #p4d に行ってきた

Ruby on Rails

http://connpass.com/event/2748/

やったこと

前回の続き
何とかタルトラッカーのような、アレをもっと簡素化した、気軽にポイント管理ができる感じのタスク管理サービスをRailsで作ってて、それの続き。

TaskをIterationに条件付き has_many するのをやめて、task の status が変更された時だけIterationに紐付けることにした

/app/models/iteration.rb



has_many :tasks, :conditions => { :status => 'done' }
としていたのをやめて


has_many :tasks
だけにする

Iteration にデータをどうやって入れるか？

Iteration は以下の2カラムをもってる

  • start_date 毎週月曜日はじまり
  • end_date 毎週日曜日おわり

→どうやってデータを入れておくか？ cronで毎月未来1ヶ月ぶんまで作るのがいいのではということになった。Heroku、cronお金かかるのかと思ってたらタダらしい。今回は間に合わなかったので次回以降に

今週の（今日を含む）Iterationを作ってみる

start_date は今日を含む週の最初の日
end_date は今日を含む週の最後の日
これが、こう書ける。



i = Iteration.new

i.start_date =  Time.now.in_time_zone.beginning_of_week.to_date

i.end_date = Time.now.in_time_zone.end_of_week.to_date

今日doneになったTaskが紐づくIteration = 今週の始まりの日が start_date と 一致するIteration



Iteration.where(start_date: Time.now.in_time_zone.beginning_of_week.to_date).first

tasks#index に 今週の始まりの日がstart_dateと一致しているIterationをTaskに紐付ける @this_iteration メソッドを追加する

参考）
http://guides.rubyonrails.org/active_record_querying.html
2.3.1 Equality Conditions

app/controllers/tasks_controller.rb の def index に @this_iteration を追加



   def index

     ・

     ・

     ・

     @this_iteration = Iteration.where(start_date: Time.now.in_time_zone.beginning_of_week.to_date).first

task の status を 'doing' にするボタンにhidden_field で Iteration を紐付ける処理を追加する

app/view/tasks.html.haml



       - if task.status == 'doing'

         %span.status<>

           = form_for(task) do |f|

             ・

             ・

             = f.hidden_field :iteration_id, value: @this_iteration.id

             = f.button "#{content_tag(:i, '', class: 'icon-ok-sign')}DONE".html_safe, type: :submit

doing 以外の status 変更ボタンには iteration を nil にリセットする処理を追加する



       - if task.status == 'done'

         %span.status<>

           = form_for(task) do |f|

             ・

             ・

             = f.hidden_field :iteration_id, value: nil

             = f.button "#{content_tag(:i, '', class: 'icon-ok-sign')}DONE".html_safe, type: :submit

Routingにdone のアクションを追加する

参考）
http://guides.rubyonrails.org/routing.html
10.2 Adding More RESTful Actions

/photos/2/preview/ みたいな処理のときには 'member'



resources :photos do

  member do

    get 'preview'

  end

end

/photos/search/ みたいな時は 'collection'



resources :photos do

  collection do

    get 'search'

  end

end

今回の、this_iterationメソッドは前者に該当

config/routes.rb にこんな感じで追加する
'done' オブジェクトが新規に生成されるイメージなので post で 



  resources :tasks do

    member do

      post 'done'

    end

  end

で、done とかを メソッドにしちゃったほうがもっとカッコイイよということで

app/controllers/tasks_controller.rb に def done を追加



  def done do

    member do

      post @this_iteration

    end

  end

とすると、done 以外の status 変更 もメソッド化する必要がある



def start do

  member do

     delete @this_iteration

  end

end
とかやっとく。（ここでタイムアップ・・・次回につづく）
以下、他にも色々教わった。

コンソールにデータをリロード



reload!

タイムゾーンで日時をパースする



i.start_date = Time.zone.parse('2013-07-01')

データベースをリセットして作りなおす



rake db:reset

rake db:setup

rake db:migrate

データベースを全部表示



Iteration.all

Iterationの1件目を削除



Iteration.find(1).destroy

DBを直接見る



$ rails db

SQLite version 3.7.12 2012-04-03 19:43:07

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite> SELECT "iterations".* FROM "iterations" WHERE "iterations"."start_date" = '2013-07-01' LIMIT 1;

sqlite> SELECT "iterations".* FROM "iterations" WHERE "iterations"."start_date" = '2013-07-01';

sqlite> SELECT "iterations".* FROM "iterations" ;

2|2013-07-01 00:00:00.000000|2013-07-07 23:59:59.999999|2013-07-04 11:30:13.748625|2013-07-04 11:30:13.748625

日付以外の時間とかもDBに入ってしまっていたので、日付だけに直す



i.start_date = i.start_date.to_date

例えば、Date.today のmethodsはこんな感じで確認することができる



Date.today.methods.grep /beginning/

=> [:beginning_of_day, :at_beginning_of_day, :beginning_of_week, :at_beginning_of_week, :beginning_of_month, :at_beginning_of_month, :beginning_of_quarter, :at_beginning_of_quarter, :beginning_of_year, :at_beginning_of_year]

 

Date.today.methods.grep /end/

=> [:end_of_day, :end_of_week, :at_end_of_week, :end_of_month, :at_end_of_month, :end_of_quarter, :at_end_of_quarter, :end_of_year, :at_end_of_year, :require_dependency, :load_dependency, :send, :public_send, :extend, :__send__]
なんか色々できる。クォーターとかもあるのかー。すごいなー。

Railsのデバッグ方法



p @this_iteration
とか書いておくとログに this_iteration の中身が出る


    puts "========================"

    p @this_iteration

    puts "========================"
とかやっておくとどこにデバッグ出てるか見やすくなって便利(ΦωΦ)

Routes の確認



$ rake routes
とやると


done_task POST   /tasks/:id/done(.:format) tasks#done

         tasks GET    /tasks(.:format)          tasks#index

                 POST   /tasks(.:format)          tasks#create

  new_task GET    /tasks/new(.:format)      tasks#new

  edit_task GET    /tasks/:id/edit(.:format) tasks#edit

         task GET    /tasks/:id(.:format)      tasks#show

                PUT    /tasks/:id(.:format)      tasks#update

              DELETE /tasks/:id(.:format)      tasks#destroy

            root        /                         tasks#index
これが見れる

感想

  • またもや、@satococoaさんにすごくわかりやすく教えていただき、ありがとうございました。また教えてもらうだけになってしまった。。また@satococoaさんが何かを作る時にはお手伝いしなければならない感じある(ΦωΦ)
  • 色々教えていただいたけど、Blogに書こうと思ってひと通り復習したら結構忘れてたりあやふやだったりして調べなおしたり考えなおしたり。。とりあえずざっくりでもBlogに書くのは有効だ。こんなの誰が見ても役に立たないかもしれないが、少なくとも自分にとっては書くだけで役に立つのだ。
  • ソースがひと通りGitHubに挙げてあるので、教えて下さる方の@satococoaさんもご自分のMacにcloneして、手元のものを見ながら、色々素振りなどをしながら教えていただくことができた。あの方法は良い。
  • 教えていただく際に、@satococoaさんにサービス使ってもらったら、UIのわかりづらい場所がわかったのでこう直したらもっと良いというアイデアを思いついた。人に使ってもらうのは良いな。
  • いつもForkwellの方にしか行ってなかったが、初めて万葉さんの方におじゃました。一度行ってみたいと思ってて、やっとおじゃますることができたヾ(*'ω'*)ﾉﾞ
  • ちょうど @a_matsuda さんが @machida さんに会いたがってた（何かを頼みたがってた）ので、飛び入りでお連れした。P4Dに@a_matsudaさんがいる絵はなんか新鮮でよい。
  • 連れて行っていただいた中華屋さんが美味しかった。杏仁豆腐がうまい。そしてみんなずっとファミコンの話してた。
  • そんなわけで、やっぱりRailsは楽しい…のだが、やっぱりたまりにたまったタスクを片付けるまで or 次回のP4Dまで封印しておこう・・・(ΦωΦ)

モリサワ タイプデザインコンペティション特別セミナー「タイプデザイナーの視点」に行ってきた

design

タイプデザインコンペティション特別セミナー「タイプデザイナーの視点」開催のお知らせ
最近は、P4D関連とかRuby関連とか、技術寄りのイベント参加が多くて、デザイナー向けのイベント（しかも偉大なタイプデザイナー様…自分にとっては神様みたいな雲の上の存在…）というのは緊張したが、とてもとてもおもしろくて、本当に行ってよかったです。興奮がさめないうちにメモを整理(ΦωΦ)

講演内容

  • マシュー・カーター氏「欧文のテキスト書体とディスプレイ書体」
  • 岡野邦彦氏「和蘭（わらん）ができるまで。」（和蘭：モリサワタイプデザインコンペティション 2012 和文部門 金賞）
  • 小塚昌彦氏「ひらがなを考えよう」

の豪華布陣
以下、内容のメモ（ところどころ聴き逃して内容が不正確だったりします。あと遅刻したのでマシュー・カーター氏の序盤を聴き逃してしまった…ﾓｯﾀｲﾅｲ…）

マシュー・カーター氏「欧文のテキスト書体とディスプレイ書体」

Millar daily Roman
  • 本文用、タイトル用、それぞれに合わせて数々のパターンを作った
  • Millarのディスプレイ用に作った書体は横線が極細、縦線が極太にして、コントラストを極端に強めたセリフ（これすっごいカッコイイ！）
  • 女性誌は何故だかわからないが、こういったコントラストが強い書体を好む傾向がある
Vincent for Newsweek
  • 新聞のために作った書体
  • 題字や本文テキスト、黒字に白抜きで利用する用などいくつものパターンを作った
Monotype Bembo Roman
Verdana
  • スクリーンで読まれる事に最適化して作った
  • IKEAのパンフレットに採用された
  • スクリーン用のフォントを紙媒体に使うなんて！…とデザイナー達にDISられた
  • が、私は良いと思う
  • 書体の出自が何であろうと、かっこ良ければそれでいいんだよ
Yale typeface
  • イエール大学のための書体
  • 大きいサイズで表示したり、スクリーンで使われる事を考慮
  • 構内のゴミ箱にも使われててうれしい
monticello（モンティチェロ）
  • 活版用タイプフェイス
  • ミラー（左右反転）でスケッチを作る
  • 活版のタイプフェイスは直線的すぎる
  • イタリックfとかの曲線が不恰好
  • 写植になって改善
  • 3Dから2Dになり技術の進歩で精密なフォルムが作りやすくなった
  • デジタル時代になってから知らない人にものすごい雑にコピーデジタル化された
  • 手書きの味わいをだすために自らリデザイン
  • 縦と横のラインの接合部を盛る
  • 横のラインにボリューム出し
  • 書体をチョコレートに漬けた感じのボリュームを付加（これは逆、説もあり。自分は正と解釈した…が記憶に自信がない）
  • 活版用のタイプフェイスをそのままデジタルに変換しても同じパフォーマンスは出ない

岡野邦彦氏「和蘭（わらん）ができるまで。」

フォントデザイナーを志すきっかけ
  • 93年、マシュー・カーター氏のワークショップ
  • sophiaを使って作られたパンフの美しさに感動
  • フォントにもデザイナーがいる！という意識の目覚め
オランダ ハーグに留学 書体デザイン学ぶ
  • オランダは美術館が専用の制定書体を持っていることが多い
  • エッシャー美術館とか
  • マウリッツハウス
  • 専用のフォントは8カ国分用意される
  • 日本語用のフォントはないのでパンフがすごく残念な感じに！
和文書体について
  • 従属欧文という考え方が大嫌い
  • たまには和文が歩み寄ってもよいでしょ
  • 本文用のテキスト書体が大別して明朝とゴシックしかない傾向に疑問
  • 欧文書体はもっと色々あってユニークなのに。。
  • 欧文書体に合わせた和文書体が欲しいという海外からの問い合わせも多い
和蘭では和文と欧文をトータルにデザイン
  • （気持ち）従属和文 な考え方に
  • 横組の親和性
  • 重心の位置を和欧あわせる
  • 和文の重心を下げた末広がり
  • アセンダとディセンダを長めにとった欧文のスタイルにあわせて、和文のフトコロ小さく、中心にぎゅっと集中させる
  • 明朝でもゴシックでもない書体が作りたい
  • 手書きの勢い、抑揚
  • 横画は水平、縦画は角度自由
  • 左側の三角、付けるとどうしても明朝になる…明朝にならないように左にアクセントをつける工夫をした
  • 左➡右に読む流れを促進
スケッチ
フォント制作の過程
  • 200-300dpiでスケッチをスキャン
  • Illustratorでトレースし作りこむ
  • Glyphsでフォント化
  • OTFに
  • Illustratorで実際に打ってみて、またフォントから直してをくりかえす
  • 出力チェックは未アウトライン状態でずっとやっていたがアウトライン化すると出力でフォントが太くなる事を思い出してアウトライン化した状態に合わせて全部直した
  • アウトライン化してから出力チェックした方がいい
  • 最近はリガチャーの要望も多いので、OpenTypeFeature のあるフォント作成ソフトがおすすめ（Glyphsはついてる）
クルマのデザインが書体デザインのヒントになった
  • 横方向の流れ
  • 下半身の重心
和蘭という書体名に込めた思い
  • オランダでの経験
  • オランダの低地と、書体の重心の低さをかける
  • 蘭の小振りな花びらのイメージ
  • 江戸時代の出島（唯一オランダとのみ貿易)
  • 日本と世界をつなぐ架け橋になってほしい
和蘭の今後
  • 文字塾で和文かなの作り方基礎習ってる
  • 和蘭見直したい
  • 縦組みを洗練
  • スケッチは現在は筆で描いてる 楽しい
  • 和蘭修正版 よりコントラスト増えた形に
  • このままタイプフェイスの洗練に2〜3年かかる
  • 10年後には製品化したい

小塚昌彦氏「ひらがなを考えよう」

縦書きの草書
  • 傾きに注目する
  • かな文字は1字1字は独立して見ない
  • 1ワードが一続きでつながっている
  • 「わ」右下がり
かな文字のスケッチ
  • かな文字は筆を使って水彩のビリジアンを薄く溶いてスケッチ
  • 鉛筆はつかわない
戦後の話
  • カタカナ小さいのが多い
  • いかにカタカナを大きくするかの流れが昭和20-30年代
  • タイポス37 昭和34年
  • 新書体ブームへ
  • FrutigerやHelveticaのようなファミリーつくりたい
  • かなを分解してそれぞれのエレメントをパターン化するという考え方
  • 写植の時代へ
かな文字作りについての認識
  • ひらがなの「は」は 「波」の草書体から生まれた
  • 左側の縦棒はさんずいを象形化したもの
  • ひらがなも漢字もエレメントのパターンを組み合わせて作ると認識してるかもしれないが、かなはその発想でいいのか？
  • 漢字は表意文字だが、ひらがなは音声そのもの
  • 日本語は表意と表音が混じり合ってる特殊な言語
日本語の組版で占める割合（数字聞き逃し箇所ありあいまい…すいません）
  • 漢字は約 50％
  • ひらがな 30-35%
  • カタカナ 7-10%
  • 役物（記号等） 3%
『新書体』という本、 桑山弥三郎氏編集
  • デザイナー30人が参加
  • ほとんどがパターン化の発想で作られてる
例えば機械の読み上げ音声を例に考える
  • あきはばらは「あ」、「き」、「は」、「ば」、「ら」
  • ではなく 「あきはばら」と1ワード一続きで発音しないと変
  • カナをパターンの組み合わせで考えることは、読み上げ音声の違和感と同じ感じがある
  • ひらがなは出自から縦組み用に作られてる
書体における線
  • のっぺりした単調な線ははじまりと終わりがない
  • セリフの発生→線にはじめとおわりの区切りが欲しい
  • ディスプレイ体は面の発想
  • 横線を宙に指で書いてみて下さい
  • 左から右に書くよね？右から左に書いた人いないよね？
  • 漢字は右手でかかれたもの
  • 石に文字を掘っていた時代、線のはじめとおわりは意識されなかった
  • 紙と筆記具が使われるようになってはじめて、線のはじめとおわりが意識されるようになった
書体に制作において考慮するデザイン要素
  • ウエイト
  • 重心
  • ふところ
  • 地球に重力があるから、重心は下よりのほうがカッコイイ
  • 宇宙に行って無重力状態になれば、上重心の書体がカッコよくなるかも？
かなのエレメントの出自
  • 「に」「ほ」の左の縦棒は にんべんを象形化したもの
  • 「は」 さんずいを象形化したもの
  • 似ているが出自が全く違う物を同じように表現していいのか？
  • 似たようなものは単純化パターン化するのがタイポスの考え方だがそれでいいのか？
かなは発音すると全部違う音であるように、現代において当たり前になったパターン化、画一化に対してもっと懐疑的になっていい
  • 竹久夢二のポスター、感動的な美しさがある
  • 書き文字はどんな筆を使っても、芯と紙の一点の接触のみで表現される
  • 書体デザイナーはそれを鉛筆デッサンで無理やり袋文字にしてるがそれでいいのか？
文字とは
  • 文字は目で見る言葉である
  • 文字の形は右手の軌跡である
  • タイポグラフィは民族のもの
陸隷書という書体（モリサワ）
  • 中国の作者にかな文字を追加で作ってもらった
  • かなの来歴を説明
  • 作者納得しない
  • 「あ」隷書にテールをくるっとはらうパターンはないと抵抗
  • 外国の方に無理言って作ってもらって申し訳なかった・・・
活版の種字
  • 正確な作り込み難しい
  • 活字の母型の深さが不揃いだと刷りの太さにむらが出る
活版書体を縦組みで美しくみせるために傾きを調整
  • 「ね」「な 」前のめりに傾かせる
  • 「る」 中心より左寄りに置く
  • こうした調整ができないのが鉛の活字の限界だった
欧文はラインシステムがあってきれいだが、和文は…
  • 和文は「やきとり組版」と海外に説明
  • 小さい肉、縦長のねぎ、中心で串刺し
  • いい焼き加減でウマい
横組を意識して運筆方向を決める
  • 50音中14字は左下方向のはらい （一番多い）
  • 終筆のハネはじゃまなときがある
  • 横組には横組の作り方がある
タイプフェイスの機能
  • 一列にならぶこと: alignment
  • 情報を正確に伝達する: text
  • 視覚的イメージを表現: display

質疑応答

Q: 文字デザインのデジタル化の影響についてどう思われますか？
カーター氏
  • 仕事作業の仕方が変わった
  • デザイナーはレーザープリンタによりリアルタイムで仕上がりイメージが見ることができるように
  • これが実現するまでに500年かかった
  • より多くのデザイナーが書体作りに参加できるようになった
  • これはいいこと
  • しかし、フルタイムの専門のタイプデザイナーは増えてない
  • 書体を作ったことがある人は増えた
  • ディスプレイ用の書体は増えた
  • テキストタイプ（本文用の書体）はあまり増えてない
  • テキストタイプのデザインは、活版でもデジタルでも手法、考え方は（テクノロジーの影響がないことはないが）大体同じ
小塚氏
  • 原点はかわらない
  • 読者が気づかないように旧来のものを現代の技術で再現し、技術を生かして今までにできなかった事を表現するのが現状
  • 写植もデジタルも転換期は重鎮にDISられる
  • これから画期的にタイポグラフィは変わる
  • 日本語にはプロポーショナルな書体がない
  • 欧文のハイフネーションのような発想も必要
岡野氏
  • 自分が新しいんじゃないかと思ったアイデアが、金属活字の時代にも行われていたりする
  • 古いものに学びつつ、新しい事にチャレンジ
  • 使い方によって文字の形も動的に変化していいのでは
Q （カーター氏へ）かな文字はワードごとの固まりでとらえるという小塚氏の話をうけて、欧文書体の組版ではどうお考えですか？
  • 欧文では、文字は組み合わせる事でしか意味をもたない
  • 可読性が最重要
  • それぞれの文字を単体で見せるのに注力するのは本末転倒
  • 文字そのものには意味がないから
  • 文字同士のスペーシングが最大の意味を持つ
Q 文字に興味をもったきっかけは？
カーター氏
  • 父がタイポグラファーだった
  • オランダのタイプ鋳造所で働いた
  • デザインより前に活版作りから学んだ
  • 見習いからデザインをはじめた
小塚氏
  • 私の若いころは何もなかった時代
  • タイポグラフィ=活版作りを意味した
  • レタリングという単語もなかった
  • 絵が好きだった
  • 飛行機の絵好きで、描いて友達に送ってた
  • 憲兵隊の検閲を受けて酷い目にあった
  • それでも絵や図案が好きだからやめなかった
  • でもほんとは新聞記者になりたかった！
  • 続きは長くなるので…
岡野氏
  • 学校の課題で毎週ポスターを作る
  • 文字を使うには見本帳を繰って選ぶ→イメージにあうものがない！
  • 写真は自分で撮り、イラストも自分で書くのに…文字だけは他人の作ったものを使うのに疑問
  • 自分で作ろう
Q カッコよさとユニバーサルデザイン・視認性への配慮の両立にジレンマ。乗り越えるこつは？
小塚氏
  • 大きくすれば見える。大きくすれば情報は減る
  • 専用のフォントを作るには資本がいる。デザインだけの問題ではなく社会のバックアップが必要。
Q: テキスト書体とディスプレイ書体、具体的にどのへんに着目してなおしてますか？
  • ウエイト
  • プロポーション
  • スペーシング
  • サンセリフは大体どんな大きさでも使える事が多い
  • セリフのコントラストが激しい書体は調整が大変
  • タイプスタイルによっても方法は様々で複雑
  • 一つの答えはない

感想

  • タイプデザイナーはやっぱり偉大だった…！
  • 自分にはとてもなれそうにない…
  • でも作ってみたいのでGlyphs買おう(ΦωΦ)
  • かっこ良ければいいんだよ、っていうのがいいよね！（IKEAの話とか）
  • マシュー・カーター氏のセリフ、ホント美しい！
  • 岡野氏、初めての和文書体製作であのクオリティすごい！そして直し続ける執念、情熱、ただひたすら頭が下がる。自分には真似できそうにない。
  • 和蘭のビジョンもすごく良いと思った。従属欧文に対する問題意識。普段のデザインワークの中でのモヤモヤを解決するために生まれたものっていうのもいい。
  • 小塚氏のお話はすごく本質に迫ってて、モダニズム以降の流れに今一度懐疑的になって新しい価値を生み出せという、現代のデザイナーへの応援メッセージに思えた。今は歴史の転換期なのだなと改めて感じて胸熱。
  • 遅刻して一番端っこの後ろの席だったせいで、前の席に岡野氏、隣にマシュー・カーター氏…というおいしいポジションに…(ΦωΦ) ファーー！となった
  • 当然なんだけど、タイプデザイナーの方々はみんな「フォント」って呼ばずに、「書体」「タイプフェイス」って呼ぶ。それがいいよね。
  • あと、岡野さんの話でも10年かけて作るって、和文書体ってやっぱり大変だよなあ…我々は使う側だからそれを気軽に選んだり、上から目線で褒めたりDISったり…ホント気楽なもんですよ…（すいません…

雑談 with @machida, @saucerjp

このあと、一緒に来てたデザイナー友達と、デザインについてすごい話してすごい楽しかった。デザイナーどうしでデザインについてまじめにこんなに話すのはすごく久しぶりで（プログラマとシステムについて話すことは多いのに…）、やっぱり自分はデザインが好きだなあと思った。
色んな話をしたのだけど、この2つが特に自分的に印象的。

デザイナーのコアスキルは何だろうね？
  • イラストも写真も専業じゃないし、文字は基本人が作ったものを使うし、Webで言うとコーディングだって別に必ずしも出来る必要はない
  • 装飾 = デザインだと思っている人も多いけど、それも本質ではないよね
  • 色んな要素を組み合わせて、分類して、重要度を咀嚼して、一連のストーリーを作り、審美的な側面と合わせて最適な見せ方を提示するといった、一種の編集スキルなのではないか？
  • （そういえば、書籍や紙メディアの編集者の方なんかは、Adobeスキルさえあればデザイナーなれるだろうな…って思える人が多い（というかAdobeスキルある人多いし、実際デザインできそう））
理屈は後付けだよね？
  • デザイナーは感覚的なものが先に来て、後でその理由を言語化して納得して確信を得る（もしくは人に説明するための手段を得る）
  • というか、感覚的にモヤっときてるものの背後には必ず、確固とした理由があるので、それを後から言語化するのはそんなに困難ではない。
  • ところが人に説明するときには、理屈で説明するしかないので、まず理屈から入ってデザインしたんだなと思われがちなんだけど、割とそれ、実態とは違うよね。。
  • 結局、自分で作る中で、感覚と審美眼を磨くしかないんだよなー。

的な話をしてて、書いてたらこんな時間だ…！！
仕事中に抜け出させてもらって行ってきたので、これから仕事します・・・・すみません。。。
いやー、デザインって（つらいけど）楽しいですね。いいものですね。

追記

読んだ方からフィードバックいただきました。ところどころ間違ってたみたいだ。すいません・・・
ご指摘、ありがとうございました。

「デジタルになってから知らない人にものすごい雑にコピーされた」

→　これって、おそらく、許可のない「コピー」ではなく、マシューさん自身が最初のデジタル化に関与しなかっただけではないかと思います。そのデジタル化はあまり良くなかった。
→Monticelloを出すことのできる正当な会社によるデジタル化が、例に出されてあれだったのか100%確かではないので、「コピー」ではなく、「デジタル化」とかに変えれば問題ないかと。

「書体をチョコレートに漬けた感じのボリュームを付加」

→　これは逆です。「そうではない」と言っていました。チョコレートを付けたように全体を太くするのではなく、例えば、ステム（縦画）はやや太くするくらいに、セリフ（横画）の太さはそれよりももっとウェイトを強めた、という感じだったはず。
→ もちろん、「ステム=縦画」、「セリフ=横画」の意味ではありません。あの例のなかで、縦画のうち、例えばステム、太くした横画のうち、例えばセリフ、という意味です。

「活版のタイプフェイスは直線的すぎる」

→　これって言ってましたっけ？　機械の制約のせいで、イタリックのfが途中で切れた感じで、しかもほかの文字よりも角度が直角に近くなってしまったというようなことは言っていたと思いますけど。
Vincentのところに、「新聞のために作った書体」って書いてありますけど、「雑誌」ですよね。
Verdanaの綴り、間違ってる。

第23回 デザイナー向けプログラム部 #p4d に参加しました

design Git Ruby on Rails

http://connpass.com/event/2639/
前々回のP4Dから作り始めたRailsアプリがあるので、それを進めたく参加。
既存のModelをhas_manyしてるModelを作りたかったのだけど、Rails Guides とか見て1人でやってみたんだけど詰んだので、教えていただいた。

色々わかったこととかやったこととか
  • イチからやり方聞いてどうしたらいいんですかー、ってなりがちなんだけどそれよくない。やってみてわからなかったことをはっきりさせて、わからない部分だけきくのがよいと思った。
  • 自分がわからないこと聞くだけで、デザイン知りたくて来てるエンジニアさんもいるのにあまりフィードバックできず申し訳なかった。ので、せめてわしが答えられる事を…と思い帰ってから急いで駄エントリ書いたらまさかの800ブクマ超えでびびった。
  • モデリング、色んなやり方が考えられるが、今回のケースの場合は中間テーブルをもたせず、特定のカラムが特定の値だったものだけ紐付けるという条件付きhas_manyをやるのがいいと教わった。ググってみたらなんかわかったような気がしたので今度やってみよう。
  • データベース設計は難しい。。
  • Rails3 レシピブック便利。何か具体的な方法を知りたくなったら見るべし。
  • 毎週月曜日始まり日曜終わりでstart_dateとend_dateを持つテーブルがあるのだけど、どうやってデータを作るべきか。（そのデータはある程度未来のぶんまで必要である）
    • 何か別のユーザーアクションをトリガにしてデータを作るのも良いけどおそらく色んな矛盾が出る。
    • crontab回すほどのことでもない
    • イケてないけど、カレンダー見ながら最初にある程度の未来まで手入力でデータを入れておけば、とりあえずそれで良さげということになった。動くのが正義だ！
  • わからないことググってコピペ駆動でやってると、やはり限界が生じる。どうしたらいいか。
    • Rails Tutorial をやるのがよい。MVCの基本的なことも結構書いてある。日本語版も作ってくださっているし、英語の勉強がてら英語でやってみてもいいかも。
    • Ruby on Rails Guides をちゃんとイチから読むのもよさそげ
    • （Rails 頻繁に色々変わるので、本とかよりも公式に近いドキュメントを見る方が良さそう）
  • 何かどこかで変なことやってるらしくて、Herokuにpushする前に、なぜかいちいちassets:precompile しないとassetsの変更がHerokuに反映されない問題がありめんどい
    • ローカルのprecompile されたassets を一度クリーンするとHerokuが勝手にコンパイルするようになるっぽい
  • Gitでデザインのcommit、どのくらい分けてる？って聞かれたので以下のように答えた
    • デザインは割とページ単位（というか一つのviewファイル単位）で考えていて、1view内のデザインをイチからガッツリ作ったときは特に細かく分けない傾向にある。
    • Viewのマークアップと、SassとかのCSSは、"Markup for hoge#index" "Sass for hoge#index" みたいにしてcommitを分けてる。（後でSassだけ別branchにcherry-pickとかすることが多いので）
    • あと、commitわけても、デザイン部分は誰もコードレビューしてくれない・・・
    • 逆にViewにロジック入れてたり、Controllerを少しいじったり、JSやCoffeeScriptでなんかした場合は、レビューする人が見やすそうな範囲でcommit分けるようにしてる
    • 後から部分的にデザイン修正した場合は、できるだけ分割して、後から何を変えたかわかるようにしている…（が、細かすぎる変更をちょこちょこ色々やった場合は Fix detail of design みたいなので済ませてる）
  • （書き忘れた）デザイナーがプログラミング覚えるのって、デザイナーっぽいやり方をどうしてもしちゃうよね。抽象的な思考がやはり苦手だ、って話が面白かった。ホントそう。

みなさま、今回もありがとうございました。
Rails アプリ作るのが楽しくてしょうがないのだが、仕事の合間に気分転換、気分転換…と自分に言い訳しながらやってついつい夢中になってしまい本業に支障をきたすため、しばらく封印してる。。

Rails3レシピブック 190の技
Rails3レシピブック 190の技
posted with amazlet at 13.06.23
高橋 征義 松田 明 諸橋 恭介
ソフトバンククリエイティブ
売り上げランキング: 169,162
Amazon.co.jpで詳細を見る

フラットデザインのコツ的なアレ

design

P4Dで教えていただいたエンジニアさんに聞かれたので、なんか整理しきれてなくてざっくりなんですが、取り急ぎ、なんかそれっぽくなるコツみたいなのを独断と偏見でまとめてみました。

3色〜5色くらいの色を画面の中で均等に使うのおすすめ

作りたいサービスが何で色分けできるか考えます。ちょうどよく3〜5種類くらいのステータスやカテゴリなどがあったら、それに応じて色が変わるとかするとうまくハマる。かも。

Flat UI Colorで色選び

http://flatuicolors.com/
という便利なサイトがあって、ここから3〜5色くらい選ぶとよいです。クリックするとカラーコードがコピーされます。あら便利。赤は他の色と仲良くするのが難しめ。

Sassで彩度を抑えると落ち着いた色調になって、使いこなしの難易度が低くなります

上のサイトもそうなんですが、Flat UIによく使われている色は、鮮やかなが多くて、うまく使えるとかわいいんですが、使い方を間違えるとギラギラしてしまう可能性もあるので、彩度（鮮やかさ）を少し落としておくのが安牌でおすすめ。



$color-1: desaturate(#25b89a, 10%)

$color-2: desaturate(#efc319, 10%)

$color-3: desaturate(#e57d24, 10%)
こんなかんじで、上で選んだ3色をSassで彩度を10%落としてます。これで割とどのようなレイアウトでも調和がとりやすいトーンになったりします。

メインのテキストの色は真っ黒よりも、グレー or 濃紺が合います

グレー

#666 〜 #888 くらいの濃さ
#95A5A6, #7F8C8D （http://designmodo.github.io/Flat-UI/ 参考）

濃紺

#34495E, #2C3E50 （http://designmodo.github.io/Flat-UI/ 参考）

  • 上で選んだ3〜5色 + テキスト色（グレー or 濃紺）+ あと、ベースになる色（薄いグレーかベージュ等がおすすめ）+ 白 で構成。それ以外の色を使わない。
  • 色の上に白抜きで文字を載せる
  • 白の上に色で文字を載せる
  • rgba(0,0,0,0.1) -> 黒の透明度 0.1 / rgba(255,255,255,0.3) -> 白の透明度 0.3 等を色面の上に乗せて活用する


テキストエリアやボタンまわりにrgba(0,0,0,0.1)を使ってます

フォントづかい

Latoおすすめ

http://www.google.com/fonts/specimen/Lato

数字だけ違うフォントで、2〜3倍くらいの大きさで使う
  • 幾何学的に単純なスタイルの数字を持ったフォントがおすすめ
  • おすすめ DIN medium > http://fontzone.net/font-details/din-medium
  • 文字の大きさにメリハリをもたせるとそれっぽくなります。ポイントになる部分は大胆に大きく、それ以外の部分は小さく。

アイコンはFont Awesome で

これも数字くらいのサイズで文字の2倍くらいのサイズで使うとよい。
http://fortawesome.github.io/Font-Awesome/icons/

その他ポイント

  • マージンは大きめにとる。ボタンであれば、文字の高さと同等のマージンを上下に取る。
  • ボタンが認識されづらい。Submitボタンなど、押して欲しいボタンの周りにはマージンを大きめにとって、周りに何も置かないなどして目立たせる工夫必要。
  • 画面の半分以上が色ベタ面になるようにする（もしくは写真を敷いてもよいです）。画面の半分以上が白だとさびしくなりがち。
  • タイトル的な大きく使う文字要素は、フォントサイズを大きくして、フォントのウェイトをUltraLightなどの極細にするとそれっぽい。（やっぱり周りにマージンが大きく必要）
  • 日本語をなるべく使わないｗ （日本語使う場合、大きな文字はboldにせず細い文字で使う、文字の周りにはマージンを大目に取る等するとよいです。）
  • 写真とかボタンとかをマルにするとかわいい

思いつくの今のところこのくらいか。。。もうちょっと具体的なTIPSや色の組み合わせのパターン等をまとめて、類型化できると面白そう
しかし、図解がないのでわかりづらいな…（しかし図解をつけるのがめんどくさい・・・・いずれもうちょっとちゃんとした形に、どこかでまとめたいです。。

rmしたファイルを全部一気に git rm する → git add -u

Git

どういうことだかわかってないのだが、これでできた…すげええ・・・



$ git status | grep deleted: | awk '{print $3}'  | xargs git rm
git rmしないでrmした場合に一括git rm - x-iteの日記
こちらの記事より知りました。ありがとうございました。


# 追記：と、書いたところで上の記事のはてブコメントを見たら
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/x-ite/20110722/1311316116


$ git add -u
でもできるって書いてあって、やってみたらできた！こんなのあったのか…
しかし、この場合、modefied のファイルも 一緒にaddされてしまう（新規のファイルはaddされない）。