you have done something wrong. No, the computer is not wrong.
今のURLが hoge.dev だとして、これを hogehoge.dev にしたいときは、
$ powder unlink hoge
$ powder link hogehoge
これで変更できた。
ちなみに unlink hoge せずに link hogehoge すると、どちらのURL（hoge.dev,hogehoge.dev）でもアクセスできた。
さらに powder link hogehoge したあとに、powder link mogemoge すると、hogehoge.dev も mogemoge.dev でもアクセスできなくなったりして混乱した。
現在の状況を見るときは powder -l で。
~/.pow 以下に、消したアプリケーションのリンク？が残ってるので気持ち悪いなあ、思って調べたら powder cleanupすればいいことがわかった。
解決したよかった。
Pow をもっと便利に使うためのツール比較 – Powder / Powify Comparison – m.igrs.jp
powder の他にも powify ってのもあるんですね。
powder でググったらスノボと美容室ばっかりでてきて困る。
バージョンを指定してRailsアプリケーションを作る場合は、引数にバージョンを指定するとできる。
今、こんな状態。railsは、3.2.3と3.0.10が入ってる。
$ gem list rails
*** LOCAL GEMS ***
rails (3.2.3, 3.0.10)
んで、rails -vすると、3.2.3 と表示される。
$ rails -v
Rails 3.2.3
ここで3.0.10でrails news したい場合は、
$ rails _3.0.10_ new hogehoge
_でバージョン番号を囲ってあげればOK。
hogehogeはアプリケーション名。
ruby-buildをアップデートしようとして、brew update するとエラー出た。
pplog@pplog ~ $ brew update
error: The following untracked working tree files would be overwritten by merge:
Library/Formula/autojump.rb
Please move or remove them before you can merge.
Updating f6442dc..4d66bf8
Aborting
Error: Failed while executing git pull origin refs/heads/master:refs/remotes/origin/master
とかいうエラーが出てアップデートできないときは、
$ cd `brew --prefix`
$ git remote add origin https://github.com/mxcl/homebrew.git
$ git fetch origin
$ git reset --hard origin/master
$ brew update
これで解決した。
ちょっと前にインストールしたrbenv+ruby-buildの環境で、
$ rbenv install
しても、1.9.3-p125 が出てこない場合は、
$ brew update ruby-build
するとインストール可能なリストが更新される。
brew update でエラー出る場合の対処も合わせて書いた。
brew updateでエラーが出る
自分の稼働率をあげようと思って、数日前からDay Oneを使い始めた。
仕事中、1つのタスクをどれくらいの時間でやってるか、という記録のため。
evernoteでもよかったんだけど記録専用のアプリが欲しいなと思ってたので、前から気になってたDay Oneにしてみた。
何かのタスクにとりかかるときに、こんな感じで追加しておく。
markdownに対応してるのが嬉しい。
追加した時間（ここだと2:20）が記録されているので、そのタスクが終わったときに何分かかったのかが分かる。
これをタスクごとに登録していくだけ。簡単。
やってみてわかったのは、
手間は少ない割に、効果が見えてよい感じです。
おまけ）markdown使えるので、手順をまとめるときにも使える。
ようやく読み終えた（最近読書に時間をさけてない）。
短編なんだけど、他の作品に出てきた人たちのサイドストーリーっぽい感じ。
ちょうどラッシュライフを読み終えたあとだったので、河原崎くんのお父さんとか、黒澤さんとか出てきたから楽しめた。
ハイジャックの話、かっこよかったなー。
$ brew install git-flow
==> Cloning https://github.com/nvie/gitflow.git
Cloning into /Users/pplog/Library/Caches/Homebrew/git-flow--git...
remote: Counting objects: 324, done.
remote: Compressing objects: 100% (244/244), done.
remote: Total 324 (delta 100), reused 233 (delta 42)
Receiving objects: 100% (324/324), 225.48 KiB | 160 KiB/s, done.
Resolving deltas: 100% (100/100), done.
==> Checking out tag 0.4.1
Submodule 'shFlags' (git://github.com/nvie/shFlags.git) registered for path 'shFlags'
Cloning into shFlags...
remote: Counting objects: 454, done.
remote: Compressing objects: 100% (55/55), done.
remote: Total 454 (delta 389), reused 454 (delta 389)
Receiving objects: 100% (454/454), 101.30 KiB | 99 KiB/s, done.
Resolving deltas: 100% (389/389), done.
Submodule path 'shFlags': checked out '2fb06af13de884e9680f14a00c82e52a67c867f1'
==> make prefix=/usr/local/Cellar/git-flow/0.4.1 install
==> Cloning https://github.com/bobthecow/git-flow-completion.git
Cloning into /Users/pplog/Library/Caches/Homebrew/git-flow-completion--git...
remote: Counting objects: 63, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 63 (delta 22), reused 39 (delta 10)
Unpacking objects: 100% (63/63), done.
==> Checking out tag 0.4.1.0
/usr/local/Cellar/git-flow/0.4.1: 13 files, 132K, built in 11 seconds
$ git flow init
Which branch should be used for bringing forth production releases?
- master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git flow feature start modify-layout-css(ブランチ名)
Branches 'develop' and 'origin/develop' have diverged.
And local branch 'develop' is ahead of 'origin/develop'.
Switched to a new branch 'feature/modify-layout-css'
気軽にブランチきれるっていいな。
非常に淡々とした内容だった。
非日常的な事態も続けば適応してそれが日常になって、それぞれのやり方で生きていくんだなあ。
伊坂作品おもしろいなー。
今はフィッシュストーリーを読んでる。
EC2のインスタンスはスタバのメニューに置き換えて考えると分かりやすかった。
EC2のインスタンスは
ってタイプがある。
このタイプがスタバでいうところの飲み物にあたる（本日のコーヒー、フラペチーノ等）。
EC2を使うときはまず、このインスタンスのタイプを決める。
で各タイプの中にそれぞれスペックの違うメニューが用意されている。
これがスタバで言うところの「ショート」「トール」「ベンティ」といったサイズにあたる。
スタバで「カフェラテのトールで」と注文するのと、
EC2で「ハイCPUのミディアムで」と注文するのは同じようなものなのだ。
そう思ってれば多分いいのだ。
けど、スタバと違って全タイプにこのメニュー（サイズ）があるわけではないあたりが最初混乱した。
「オーダー入りまーす。ハイメモリ クアドラプル エクストララージー」
「ハイメモリ クアドラプル エクストララージー（復唱）」
EC2は、スタバのメニューで考えたら理解できました。
m1.xlargeとかc1.xlargeとか記載されてる、m1とかc1ってのは
という意味。
c1、m1の[1]は何なんだろう。
ちなみに、インスタンスのタイプをスペックを弱い順で並べ替えると
になる。