TONY0922のブログ

学んだことを適当に記録していくブログです。主にRuby, Java, PHPで仕事してます。更新頻度はそんなに高くないので、ご了承下さい。

Gitポケットリファレンスを読んだ

Gitポケットリファレンス

Gitポケットリファレンス

プロジェクトでGitを使う機会が増えてきて、 通常の業務で困ることがなくなったけど、 もうワンランク使いこなせるようになりたいなーと思ったので、 読んでみた。

以下、勉強になったコマンドを張り付けていく。

git config

Git の各種設定を表示、変更する。

以下、興味をもった設定のみ記載。

commit.template

コミットメッセージのテンプレートをファイルで指定する。

core.whitespace

git diffなどで不正な空白文字を検出して通知する。

push.default

引数なしでgit pushされた際に、どのブランチにプッシュするか指定する。

git commit

インデックスに登録した変更内容をローカルリポジトリに反映する。

-a

バージョン管理している全変更をコミットする。

-c

コミットメッセージを以前のコミットやタグから読み込む

--dry-run

コミット結果を表示。実行はしない

git add

変更内容をインデックスに登録して、コミット対象にする。

-p

パッチ形式で確認しながら１つずつインデックスに登録する。

-A

バージョン管理対象になっていないファイルも含め、すべてをインデックスに登録する。

-n

addコマンドの実行結果を確認する。

-i

変更内容をファイルずつ確認しながら、インデックスるに登録する。

git rm

バージョン管理しているファイルを削除して、バージョン管理の対象外とする。

-- cached ファイルを残したまま、バージョン管理対象からファイルを削除する。

git reset

インデックスに登録したファイルをコミット対象から外します。

-p

インデックスに登録された変更箇所をバッチ形式で１つずつ選択して、インデックスから取り除きます。

--hard HEAD^

直前のコミットの一つ前の状態にソースを戻す。

--hardを間違えて実行した場合

reflogを使う。

git revert

コミットした内容を取り消すコミットを実行する。

-m parent-number

マージコミットを取り消す際にどのブランチをメインラインとして残すかを指定する。

--no-edit

revert用に自動生成されるコミットメッセージをそのまま採用する場合に指定する。

-n（--no-commit）

revert内容のコミットを自動で行わない。

git pull

共有リポジトリ（リモートリポジトリ）から変更を取得し、現在のブランチにマージします。

--rebase

変更を取得した後、rebaseを行う。

--no-ff

必ず、マージコミットを行う。明示的にマージしたコミットを残す際に利用する。

--squash

リモートブランチの複数のコミットを一つのコミットにまとめてブランチに取り込む。

git fetch

共有リポジトリ上のリモートブランチの変更を取得する。

-p

取得後に存在しなかったリモート追跡ブランチを削除する。

--dry-run

取得結果を確認する。取得結果の反映はしない。

git push

ローカルブランチへの変更を共有リポジトリへ送信します。

-u

新規に作成したリポジトリやブランチをプッシュする際に、ローカルリポジトリのブランチとプッシュ先リポジトリのブランチの対応付けを行う。

--mirror

リモートリポジトリにローカルリポジトリの内容をそのまま複製したいときに使用する。

git remote

リモートリポジトリを一覧表示、追加、削除、変更をします。

-t branch

pullコマンドで更新内容を取得するリモートリポジトリを限定できる。

remote prune

リモート名からリモートリポジトリで削除済のブランチをローカルリポジトリから削除します。

git branch

--no-merged

カレントブランチにマージされていないブランチを表示する。

--merged

マージ済みブランチを表示

デフォルトでは共有リポジトリのタグやブランチをどのユーザでも消せてしまうので、共有リポジトリにフックを設定することでそれを防ぐことが可能。

git checkout

-b

ブランチを作成して、切り替える。

-t

リモート追跡ブランチからブランチ作成をする前に、作成するブランチにアップストリーム設定をする。 ※ アップストリーム設定とはpushやpull時の指定を省略できる。

-p

パッチ形式で確認しながら1つずつコミット時点のものに戻す。

git tag

-a

注釈付きのタグを作成する。

-s

署名付きのタグを作成する。

git archive

配布用のファイルを作成する。

git merge

対象ブランチの変更を現在のブランチに取り込む

--no-ff

マージコミットを必ず生成する。

--log

マージコミットのコミットメッセージにマージされるコミット郡の一行目のコミットメッセージを含める。

--no-commit

マージ後、自動的に行われるコミットを行わない。

競合発生時でファイル単位で解決を行う場合

git checkout MERGE_HEAD XXXX.txt git checkout ORIG_HEAD XXXX.txt で解決できる。

Merge時にFast-forwardマージとコミットマージのどちらを採用すればよいか？

ウォータフォール的にかっちりとした開発モデルのプロジェクトの場合はどのブランチで作業して、いつマージしたかを分かりやすく把握するためにコミットマージを使用する。開発者が分散していて、自由度の高いOSSプロジェクトの場合は、「履歴を一直線に保って見やすくする」方針を取ることが多い。

git rebase

コミット履歴を変更して、ブランチの分岐元を置き換えることができる。また、コミットの順番の入れ替え等、コミット履歴を編集できる。

--onto []

ブランチが「どこのブランチから分岐したか」を修正します。実行後は、から分岐してからののコミット郡が、--onto で指定したブランチから分岐したように修正される。

rebase | --continue | --skip | --abort

rebase実行中に、競合が発生した場合、競合を解決してrebaseを続けるか、競合が発生したコミットをスキップしてrebaseを続けるか、rebaseを取りやめて、rebase実行前の状態に戻るか選択する。

--continue

競合解決中にリベースを再開したい場合に使用する。

--skip

競合解決中にそのコミットをスキップしたいときに使う。スキップしたコミットは適用されない。

--abort

競合解決中にリベースを中止し、リベース開始前の状態に戻りたい場合に使用する。

--squash

複数のコミットを一つにまとめる。

git log

現在のブランチのコミットメッセージを表示します。

--graph

コミットの履歴をグラフで表示する。

--color

出力を色付けする。

--left--right

2つのブランチ間のコミットの差を表示する場合に使用する。

--reverse

逆順に表示する。（古いコミットから順に表示する。）

git diff

インデックスに未登録の内容や次のコミットで反映される内容を表示します。

--cached

特定のコミットとインデックス間の差分を表示する。

-w

行同士を比較するときに、すべての空白文字を無視して比較する。

-b

行末の差分を無視して、差分を表示する。

git show

コミットの差分、もしくはファイルの内容を表示する。

--oneline

コミットメッセージを1行で表示する。

git blame

ファイルの特定の場所がどのコミットで変更されたかを参照できる。

-L

表示する行の範囲を指定する。

-M

同じファイル内でコピー&ペーストした行を検出し、元となるコミットを表示する。

git reflog

リポジトリの操作履歴を確認できる。

git svn

SubversionのリポジトリをGitで操作する。
Subversionを共有リポジトリに使用していても、ローカルではGitを使用できる。

パーフェクトRuby を読んだ。

パーフェクトRuby (PERFECT SERIES 6)

パーフェクトRuby (PERFECT SERIES 6)

Ruby歴3年ですが、ここで初心に戻って、 パーフェクトRubyを読んだので、興味のあるところを 備忘録で示す。

例外処理

rescue 引数なしは Standard Error を補足

begin
    error_method # 例外発生を含むメソッド
rescue => e # standard Error とそのサブクラスを補足。

end

rescue後のraiseで同様のエラーを発生させられる。

begin
    error_method # 例外発生を含むメソッド
rescue => e
    raise # eと同じ内容の例外が発生
end

後置rescueはStandard Errorのみ補足

（例１）
raise rescue puts('error') # error (例外を補足する)

（例２）
raise Exception rescue puts('error') # これはエラーを補足しない。

メソッドで例外を補足する。

def
    error_method
rescue
    ## メソッド呼び出し時に例外発生した場合に補足
end

クラスやモジュールで例外を補足する。

class
    ## 何らかの処理
rescue
    ## クラス定義時に例外発生した場合に補足
end

例外のリトライ

rescueの中でリトライをするとbeginからやり直す。

その他

  • 例外が発生しなかった時のみ処理するelseが使用できる。

大域脱出

任意処理からの脱出

  • ネストしたループなどで一気にループを抜け出したいときはcatch,throwを使う。
  • throw時にループを抜ける箇所を指定するシンボルを指定することができる。

メソッド定義と呼び出し

メソッドのカッコ（）の付け所

括弧がいらないケース

  • 戻り値が必要ない。
set_current member
  • メソッド引数がない。
member = find_menber_first

メソッド呼び出しとローカル変数

  • メソッド呼び出し（括弧なし）とローカル変数はかぶるので、注意する。 そういう時は明示的に（）をつける。

ブロック

  • yealdを含むメソッドはブロックを必ず渡すこと。でないと、エラーになる。
    • 仮引数に＆blockとすると、Procオブジェクトとしてブロックにアクセスできる。
  • ブロック内でnext,breakが使用できる。戻り値の返し方がそれぞれ違うので注意。
  • ブロック内の変数はスコープ外の変数にアクセスすることができる。
  • メソッド呼び出し時、実引数の先頭に「&」をつけると、Procオブジェクトをブロックとして渡せる。
people = %w(Alice Bob Charlie)
block = Proc.new{|name| puts name}

people.each %block # Alice Bob Charlie
  • ブロック引数に引数なしのメソッドを使う場合は下記の用に書ける。
container.map(&:method_name)

  • ブロックは準備 → 本質的な処理 → 後片付け といった前後の処理を共通化する際に役立つ。

    • ファイルのOpen/Close、DBへの接続/切断

  • ブロックにはブロック外の同名変数に影響を受けないブロックローカル変数が存在する。

someone = 'Dave'
    
%w(Alice Bob).each do |person; someone| # ;のあとに定義する。
    someone = person
end

someone # => 'Dave'

外部ファイルの読み込み

  • require や load は $: , $LOAD_PATH に格納されているファイル・ディレクトリを探す。

モジュール

  • クラスがモジュールを取り込んだ際、インスタンスメソッドを取り込み事ができる。
  • 特徴」と取り込むことができる。
  • extend でオブジェクトに特異メソッドを取り込むことができる。
  • クラス内でextend モジュールでクラスメソッドを定義する。
  • モジュール関数 ... サブルーチンとして利用されることを目的としたメソッド
  • autoload 必要時に読み込みする。

オブジェクト

オブジェクトのコピー

  • dup, clone でも参照先の配列の要素はコピーしない。したがって、コピー元の要素を変えた場合、コピー先の要素も変わってしまう。

Enumerable

Hash

  • Ruby1.9ではHashは順序を保持する。

  • 外部イテレータを用いると、柔軟な繰り返しが行えて、複数の配列を一度に使用したいことができる。

    • Enumerator#rewind, Enumerator#next を使う。

      IO・File

  • ファイルのオープン・クローズはブロックを使用した方が手軽に書ける。

  • 各１行の取り出しはeach_line を使う。
  • エンコーディング情報は外部と内部で所持しているため、適切に指定すること。

スレッド

あとで試す。

Struct

  • 構造体を示すクラス。
    • 使いドコロがいまいちわからん。

クラスオブジェクト

  • Class.new でクラスの定義が可能
  • Class XXX end との違いは？
    • Class.new でクラス定義するメリットはブロックでメソッドを定義するため外部スコープの変数を参照できる。
  • Class.newを定数に代入するか、変数で代入するかで挙動が変わる。
    • 定数の場合 … クラス名を持ったClassオブジェクト
    • 変数の場合 … 無名クラスができる。
  • selfがクラス自身を表す部分で定義するインスタンス変数をクラスインスタンス変数と呼ぶ。
    • selfがクラス自身を表す場所で参照可能。
    • クラス変数とは異なる。
      • クラスインスタンス変数はそのクラスのインスタンスメソッドから直接参照したり、変更したりできない。
      • クラスが継承された際に、継承したクラスから参照、変更ができない。
  • クラスメソッドはクラスオブジェクトに定義された特異メソッドである。
    • クラスの定義外でもクラスメソッドを定義することが可能。
  • インスタンスメソッドもメソッド定義式を使わずに定義可能。
    • Module#define_methodを使えば可能

メソッド探索方法

  • include module でインクルードしたクラスの一つ上の階層に無名クラスが定義される。
    • 連続でmoduleをincludeした場合は、後のmoduleが近くなる。

Module#prepend

  • メソッド実行前に処理をはさみたいときはModule#prependを使用する。
    • prependにて同名のメソッド内にsuperを組み込むことによって、prependしたクラスの前処理を挟むことが可能。

7-2 BasicObject#method_missing

  • method_missing内で存在しないメソッドを呼ぶと無限ループになってします。

7-3 eval

  • evalで文字列をそのプログラミング言語の式として評価できる。
    • 実行コンテキストを共有するために、実行中のコンテキスト内の変数を共有できる。
    • evalにてメソッド定義が可能。
      • メソッド名が違うけど、ほとんど同じような処理を行っているものの定義に有効。
      • 動的なメソッドの追加も可能。
    • あるコンテキストで定義された変数やメソッドなどをまとめたオブジェクトをBindingオブジェクトと呼ぶ。
      • コンテキストの内容を様々な場所で持ち回すことが可能。
      • eval の第2引数 もしくは Binding#evalで呼び出し可能。
    • module_eval, class_eval, instance_evalで式を評価するコンテキストとなるモジュール、クラス、オブジェクトを指定してevalすることが可能。

8-1 Procクラス

  • Proc#===でProcオブジェクトで定義したブロックを呼び出す。
    • when式ではcase式で評価したい値と\=\=\=でマッチさせたい式を書くため、Procを渡すと\=\=\=でブロックが実行されるため、ブロック内の返り値と評価させることができ、柔軟な評価式を記述することが可能。

8-2 Proc#new以外のProcオブジェクトの作り方

  • Kernel#lambda で Proc を生成可能。
    • -> が lambda のシンタックスシュガー
    • Proc#new, Kernel#proc, Kernel.lambdaでreturnやbreakの挙動が異なるので注意。
    • Kernel#lambdaは引数の数が一致していないとエラーになる。

10-1 オブジェクトについて調べる

  • インスタンス変数名の確認や更新をアクセサを無視して、行えるメソッドがある。
    • オブジェクトのインスタンス変数を確認。
      • Object#instance_variables
      • Object#instance_variable_defined?
    • オブジェクト変数の値を更新
      • Object#instance_variable_get
  • オブジェクトが持つメソッドの調べ方
    • メソッドの可視性によって、使うメソッドが異なる。
メソッド スコープ
Object#methods プライベートメソッド以外のメソッド
Object#public_methods パブリックメソッド
Object#private_methods プライベートメソッド
Object#protected_methods プロテクテッドメソッド
Object#singleton_methods 特異メソッド
  • オブジェクトが持つメソッドの調べ方 その2
    • Object#respond_to?
  • メソッドの可視性に関わらず、Object#sendでメソッド呼び出し。
    • sendは他の場所で使われている可能性があるメソッド名のため、sendがエイリアスとして、使用できる。

10-2 クラスについて調べる

  • Module#ancestors で継承しているモジュールやクラスがわかる。
  • Module#included_modules でインクルードしているモジュールのみわかる。
  • Module#nesting でモジュールの階層が判明する。
  • クラスメソッドは未定義にしたり、新しく定義したりすることが可能。
  • ActiveSupport::Concern をextendしたモジュールはClassMethodsをモジュールとして定義することで、そのモジュールをincludeしたクラスにクラスメソッドを提供する。

10-3 イベントをフックする

  • クラスの継承されたタイミングやモジュールがincludeされた際にフックが可能。
    • Module#included モジュールのinclude時
    • Module#extended モジュールのextend時
    • Class#inherited クラスの継承時
  • メソッドの追加、削除、禁止時にイベントをフックすることも可能

12-1 組み込みツール

  • irb
    • irbの初期設定は .irbrc にて定義可能。
      • SAVE_HISTORY irbのコマンドを履歴として残せる。
      • LOAD_MODULES 予め読み込むライブラリを指定できる。
  • RubyGems
    • gemのコマンドに対して、常にオプションを指定できるように .gemrc を定義可能。
    • 複数あるバージョンの古い方を削除する cleanup
      • -d でドライランが可能。
    • インストールしたgemパッケージを元に戻す prinstine

14-1 標準外のツール

Bundler

  • bundle outdated はインストール済みのバージョンと最新バージョンを比較する。
  • bundle open はGemをインストールしたディレクトリでエディタを開く。
    • Gemの動作を確認したい際に便利
  • bundle console はgemを読み込んだ状態でpryを呼び出す。
  • 開発ツール系のGemはアプリケーションに読み込ませる必要はない。
    • Gemfileでrequire => false とすると、アプリに読み込まないので、 メモリの使用量を抑えることが可能。
  • bundle package でキャッシュしたGemをインストール可能
    • デプロイの度にbundle installしている時間が膨大な場合はこちらを利用すると良い。

Capistrano

  • デフォルトのデプロイ先は /u/apps/#{app_name}
  • cap -v でログを表示制御　-vv, -vvv でより詳細
  • タスクの中にTrnsactionとRollbackを載せることが可能。
  • Capistranoのフック
    • 複数登録ができる。
    • フックする内容をブロックで渡せる。
  • パスワードを書くのはセキュリティ上問題になるので、コマンドラインインターフェースを使用する。
  • 実行結果を利用して、Capistranoの処理を分岐させることが可能。
    • capture
      • 指定した:roleの最初のサーバで実行した内容を取得できる。 -　サーバのディスク容量を確認して、なんらかの処理を行う等の確認ができる。
    • stream
      • 複数のサーバに継続的にアウトプットを得たいときに利用する。
        • tailを利用すると、複数のサーバのログを全部覗くことができる。

yard

  • yard diff
    • gemのバージョン間でのdiffを行ってくれる。
    • バージョンupのメソッドやクラスの増減をチェックしてくれる。

pry

  • binding.pry

    • 埋め込んだ部分のスコープでオブジェクトの内容を確認できる。
    • 変数の書き換えも可能。

  • show-source

    • gemのソースを見る。
  • show-doc
    • ドキュメントを見る。
  • edit
    • Pryからエディタを起動させて、評価することができる。
  • .pryrcで起動時にデフォルト設定をする。
    • 詳細はPryのwiki もしくは Pry::Configを参照。
  • pry-stack_explorer
    • 起動した時点での呼び出しスタックを表示して、スタックが示すコンテキストの選択と移動が可能。
      • さらにそのコンテキストのスコープで変数の確認も可能
      • デバッグや開発中のソースを追うことができる。
  • pry-debugger
    • ブレイクポイントを設定して、デバッグが可能。

capistrano の topメソッド

topメソッドが何してくれるのかわからなかったので、調査。

Definition

top()

Module

Capistrano::Configuration::Namespaces

使い方

namespace :cache do
  task :warm_up do
    # ...
  end
end

namespace :deploy do
  namespace :cache do
    task :restart do
      # ...
    end
  end

  task :default do
    update_code # (1) 同じネームスペースのupdate_codeが呼ばれる。
    cache.warm_up # (2) トップレベルの「cache」ネームスペースではなく、「deploy:cache」ネームスペースのwarm_upが呼ばれる。
  end

  task :update_code do
    # ...
  end
end

（２）でトップレベルの「cache」ネームスペースのwarm_upを呼びたい場合は下記の書く。

task :default do
  update_code # calls the task in the same scope
  top.cache.warm_up # uses the top-level cache namespace
end

参考URL

KiwiをCocoaPodsからインストールしようとしたら、ハマった

使用環境
Xcode 5.1.1
iOS 7.1
CocoaPods 0.32.1

既存のプロジェクトにKiwiを導入したくて、 CocoaPodsにKiwiをインストールさせるために以下を書いた。

platform :ios

target "App_Kiwi", :exclusive => true do #テスト用プロジェクト
    pod 'Kiwi'
end

そんで、プロジェクトのルートディレクトリで下記を実行。

$ pod install
Analyzing dependencies
[!] The platform of the target `App_Kiwi` (iOS 4.3) is not compatible with `Kiwi (2.2.4)` which has a minimum requirement of iOS 5.0 - OS X 10.7.

色々調べた結果、platformでバージョンを指定していないのが、ダメっぽい。

platform :ios, '7.1' #ここで使用しているバージョンを書く。

target "App_Kiwi", :exclusive => true do
    pod 'Kiwi'
end

もう一回チャレンジ！

$ pod install
Analyzing dependencies
Downloading dependencies
Installing Kiwi (2.2.4)
Generating Pods project
Integrating client project

[!] From now on use `App.xcworkspace`.

うまくいった！

参考URL
http://stackoverflow.com/questions/18797180/platform-of-the-target-fubartests-ios-4-3-is-not-compatible-with-kiwi-2-2

CocoaPodsのインストールで色々ハマった。

iOS開発にてKiwiを使って、テストコードを書くために
まずはCocoaPodsをインストールしようとしたのだが、色々ハマったのでメモ。

OS X 10.9.2
XCODE Version 5.1.1

$ gem install Cocoapods

"/Users/user_name/.rvm/rubies/ruby-1.9.3-p362/bin/ruby" -rubygems /Users/user_name/.rvm/gems/ruby-1.9.3-p362/gems/rake-10.3.1/bin/rake RUBYARCHDIR=/Users/user_name/.rvm/gems/ruby-1.9.3-p362/gems/xcodeproj-0.16.1/ext RUBYLIBDIR=/Users/user_name/.rvm/gems/ruby-1.9.3-p362/gems/xcodeproj-0.16.1/ext
/Users/user_name/.rvm/rubies/ruby-1.9.3-p362/bin/ruby extconf.rb
checking for -std=c99 option to compiler... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/Users/user_name/.rvm/rubies/ruby-1.9.3-p362/bin/ruby
/Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:381:in `try_do': The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:491:in `block in try_compile'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:443:in `with_werror'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:491:in `try_compile'
        from extconf.rb:24:in `block in <main>'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:790:in `block in checking_for'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:284:in `block (2 levels) in postpone'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:254:in `open'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:284:in `block in postpone'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:254:in `open'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:280:in `postpone'
        from /Users/user_name/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/mkmf.rb:789:in `checking_for'
        from extconf.rb:23:in `<main>'
rake aborted!
Command failed with status (1): [/Users/user_name/.rvm/rubies/ruby-1.9.3-p3...]
/Users/user_name/.rvm/gems/ruby-1.9.3-p362/gems/xcodeproj-0.16.1/ext/xcodeproj/Rakefile:37:in `block in <top (required)>'
Tasks: TOP => default => ext
(See full trace by running task with --trace)

You have to install development tools first.
と言われるので、開発ツールが必要らしい。

ここを参考にコマンドを試してみる。

$ xcode-select --install

そこから下記にコマンドをもう一度、試してみる。

$ gem install cocoapods

ダメだ、さっきと同じエラーが起こった。

ここを参考に今度は下のコマンドを試してみる。

$ brew install apple-gcc42
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/apple-gcc42-4.2.1-5666.3.mavericks.bottle.2.tar.gz
######################################################################## 100.0%
==> Pouring apple-gcc42-4.2.1-5666.3.mavericks.bottle.2.tar.gz
==> Caveats
NOTE:
This formula provides components that were removed from XCode in the 4.2
release. There is no reason to install this formula if you are using a
version of XCode prior to 4.2.

This formula contains compilers built from Apple's GCC sources, build
5666.3, available from:

  http://opensource.apple.com/tarballs/gcc

All compilers have a `-4.2` suffix. A GFortran compiler is also included.
==> Summary
🍺  /usr/local/Cellar/apple-gcc42/4.2.1-5666.3: 104 files, 75M

もう一回チャレンジ。

$ gem install cocoapods

Building native extensions.  This could take a while...
Fetching: cocoapods-try-0.2.0.gem (100%)
Fetching: escape-0.0.4.gem (100%)
Fetching: open4-1.3.3.gem (100%)
Fetching: cocoapods-0.32.1.gem (100%)

CHANGELOG:

## 0.32.1

##### Bug Fixes

* Fixed the Podfile `default_subspec` attribute in nested subspecs.
  [Fabio Pelosin][irrationalfab]
  [#2050](https://github.com/CocoaPods/CocoaPods/issues/2050)


Successfully installed xcodeproj-0.16.1
Successfully installed cocoapods-try-0.2.0
Successfully installed escape-0.0.4
Successfully installed open4-1.3.3
Successfully installed cocoapods-0.32.1
5 gems installed
Installing ri documentation for xcodeproj-0.16.1...
Installing ri documentation for cocoapods-try-0.2.0...
Installing ri documentation for escape-0.0.4...
Installing ri documentation for open4-1.3.3...
Installing ri documentation for cocoapods-0.32.1...
Installing RDoc documentation for xcodeproj-0.16.1...
Installing RDoc documentation for cocoapods-try-0.2.0...
Installing RDoc documentation for escape-0.0.4...
Installing RDoc documentation for open4-1.3.3...
Installing RDoc documentation for cocoapods-0.32.1...

お、うまくいった。 ちゃんと、インストールされているのを確認した。

$ gem list | grep cocoapods
cocoapods (0.32.1)
cocoapods-core (0.32.1)
cocoapods-downloader (0.5.0)
cocoapods-try (0.2.0)

インターフェースデザインの心理学を読んだ。（その４）

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

9章　間違えない人はいない

人間にノーミスはありえないし問題ゼロの製品も存在しない 設計前にプロトタイプを作って、どのような誤りをするかを事前にテストしてもらうと良い。 ターゲットにしているユーザに実際に使ってみてもらうと良い。

人がどういうところでストレスを感じるかを調査する上で、非常に有効だと思われる。 アプリを設計する前に自前に使いやすさを図る場合はプロトタイプを作る重要性がやっと分かった。 人はアプリを使う上でファーストインプレッションでそのアプリが使えるかどうかを判断するため、 エラーに関する対応が不適切だとあっという間にユーザ離れを引きを越しかねない。

エラーの対処方法は様々。 間違いを修正する方法は人それぞれである。 年配者のほうが固定的探索（何回も同じ操作をしてしまう）や試行錯誤的探索（やみくもに操作を行う）を行い、ゴールまで時間が掛かるが、若者と同じ作業をこなせることはできる。

なるほど。

10章

人は自分の処理能力を超えた数の選択肢や情報を欲しがる。 しかし、その場合決定することが少ない。 人は選択肢が絞られたほうが決定を下すことが多い。 なので、多くの選択肢を提示しなくてはいけない場合、ある程度数を絞ってやると良い。

提示する選択肢は必ず絞ってやること。

選択肢が多いほど、思い通りになっていると感じる。 最速の方法があっても、ユーザはそれを選ぶとは限らない。 改良されたバージョンを提示するのと同時に前のバージョンも残しておくと良い。

これは判断が分かれるかな。

「お金」より「時間」 殆どのケースでユーザは「時間」や「体験」に共感をもつ。 ユーザリサーチを前提に何を欲しがるかを考える必要はあるものの、時間がない場合は「時間」や「体験」の路線をとったほうが無難。

ケースによると思うけど、「物語」が人の興味を惹きつけるのと同じで、 体験などをユーザにイメージさせたほうが良いかもしれない。

意思決定には気分も影響。 自分のいつものやり方で決断できるとき、製品の見積り額は実際より高くなる。 相手の決断の仕方が事前にわかっている時はそれに合わせて見ると良い。 楽しい気分の時は直感で素早く決断するように求めれば、製品をより高く評価してもらえる。

これは交渉術に非常に有効な手段だと思う。 相手をいい感じにのせて、一気に決断を迫れば、いいかもしれない。

人は支配的な人物に影響される。 グループディスカッションする際は、最初に提案された案に飛びつく場合が多いので注意。 したがって、それぞれの意見を書き出させてそれを事前に回覧できると良い。

これはほんとにそう思う。 グループの中で一つの意見をたたき台にすると起こってしまう弊害だよな。

確信が無いときは人任せにする。 ユーザの行動に影響を与えたいときは推薦文や評価、レビューを活用する。

なんとか高評価を付けてもらえるような仕組みを考えると良いかも。

目の前にある品物のほうが高値になる。 実際の店舗は品揃えさえ良ければ、ネットショップよりも優位に立てる（値段的には）

イメージさせやすいからかな。

インタフェースデザインの心理学 を読んだ。（その３）

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

7章 ～ 8章 までの感想をつらつらと

7章　人は社会的な動物である。

人には生来模倣と共感の能力が備わっている。
ある人にある行動を促したければ、その人に誰か他の人がその行動をしているところを見せる。
人に行動を起こさせたければ、物語を活用する。

そういえば、昔スノボー旅行に言った時、ちょうど冬のオリンピックでスノボジャンプ台を悠々と飛ぶ選手を見て、
真似しようとチャレンジしたら、見事に骨折した思い出があるけど、これは人間の生来の行動原理が原因だったのか。（違）
子供は親の背中を見て育つわけだから、子供に勉強させる習慣を付けたいなら、まず親からその姿勢を見せるべきだな。

オンラインでの交流においては社会的なルールの遵守を期待する。
ユーザビリティデザインの指針の多くは人間同士のやりとりに関する規定に基づいて設計すれば外れない。

インターフェースを対人と行う間隔でやると親しみやすくなるかも。

笑いは絆を生む。
相手に笑って欲しければ自分から笑うこと。笑いは伝染する。

10章で「相手が喜んでいるときは直感で物事を決定する」とのコンボで、
交渉などで場を和ませる時なので、使えると思う。

8章　人はどう感じるか。

人は忙しいほうが満足を感じる。
何かをしている方が良いが、それが「価値ある仕事」でない場合はなにもしないほうが良い。

待ち時間等で何か操作できるようにしておくことで暇つぶしの時間を与えて、ユーザの注意を引きつけられるかも。

人は「見た目」と「感じ」で信用するかを決める。
人は「信用できない」という判断をすぐに下す。拒絶すべきサイトを排除してから、残ったサイトについて信用するかどうかの検討に入る。
したがって、最初の「信用拒否」でふるい落とされないために、デザインをしっかり考える必要がある。

これ重要。あたりまえだけど、改めて指摘されないと意識が向かない。
人の印象の8割が第一印象で決まるのと同様で、ここはしっかりと時間をかけて取り組んでいきたい。

達成が難しいことほど、愛着を感じる。

Paizaとかある程度、プログラミングができないと良い求人を見ることができないサービスとかで利用されている。

将来の出来事に対する自分の反応を大げさに予測する傾向。
顧客からの反応はプラスでもマイナスでもおそらく本人が思っているほど強いものでない。

必要以上に相手の評価を鵜呑みにしないということ。

出来事の最中よりその前後の方が前向き。
目標で将来の計画をたてるためのインターフェースデザインを行う場合、計画を練る時間を長くしてやるほど、ユーザは楽しめるかもしれない。
ユーザの評価は使用している最中よりも2~3日後のほうが良くなりやすい。

旅行前の準備が楽しいという理屈と一緒かな。
また、人間は思い出を美化しやすいので、上記の内容は納得がいく。