Fe and Ni

rvm@mac で Ruby をアップグレードしようとしてエラー

ググったらトップ記事がちょっと古かったので。
公式サイトのDocumentation が充実しているので、そっちを見ればあまり問題なさそう。

rvm list #インストール済みRuby一覧もしくは
ruby -v #今のバージョンを確認
rvm list known #最新のバージョンを確認
rvm upgrade 1.9.3-p194 1.9.3-p448 #p194からp448へアップグレード

しかしやってみたらエラーotz
brewのところでこけたようです。
package_install_pkg-config_gcc46_libyaml_readline_libksba_openssl.log
にログが残されていたので、それに従って

brew tap --repair
brew doctor

Xcode の command line tools を入れてなかったのでインストール
(一回再起動したけど、不要だったかも)

予期せぬファイルがあるよ！みたいなWARNINGが出てたのでそれらを削除。
参考にさせていただきました > http://tech.nsymtks.jp/brew-doctor-get-errors/

brew doctor でOKになったら再実行…
…したらまだエラーotz
今度はrvmのエラーっぽい。ログにしたがって

rvm get stable

で、再度 rvm upgrade 〜を実行。

…ようやくできましたー('A`;)

通り魔？

なんか8/8深夜にだけ30件もアクセスが…なんかやったっけ…？

git rebase は怖くない…の？

branchA にコミットした変更を、branchAの元々の分岐元からじゃなくてbranchB（例えばmaster）のHEADから変更したようにみせるには

git checkout branchA

git rebase branchB

何事も無ければこれだけでおしまい。
「注意事項」は、

・　rebaseすると元々のコミットのリビジョン(commit xxxx...)ではなく新しいリビジョンが振られる
・　ゆえに、リモートリポジトリにpushしたbranchをrebaseすると、pushできなくなる

の2つ。
なんでそーなるの？っていうのはこのへんが詳しい。

で、「rebaseしたらコンフリクトしちゃった！」ってのが困る。超困る。

error: could not apply "リビジョン"... "コミットメッセージ"
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' and run 'git rebase --continue'

こんなこと言われる。

【対処法】
とりあえず、言われた通りにする。

error: ... っていうので、どのコミットでコンフリクトしたか分かるので、
そのコミットで変更したファイルの中身をチェック。
「ここでコンフリクトしてるよー！」っていうのがgitによって書かれているので、
「こんな感じにすればおk」って感じで自分で書き換える。
（gitに入れられた<<<<<<<みたいな行やなんかは消す。）

直したファイルを git add する。commit はしない。

git rebase --continue する。
ちゃんとコンフリクトが直っていれば、rebaseの続きをやってくれる。

余談その１：
コンフリクトの解消はまだよく分からないかも。
branchBのコミットとbranchAの自分のコミットの内容が両立できるようにしなきゃいけないんだと思うけど、超無理そうだったらどうするんだろう。
（今の所はそういうのはまだない）

余談その２：
記事投稿ツールを「見ながら編集」というのに変えてみた。
…？まだよくわからない。

攻殻機動隊あるいは

ウェアラブル・コンピュータ、感覚補助機械等、サイボーグが徐々に実現しつつあるわけですが、自分も機械化するとしたらどこをやりたいかなぁというところを妄想する。
まぁありきたりなところに落ち着いて、

1. 視覚
メガネとかコンタクトレンズでも可。
紫外線とか見えたらカコイイ。
現実の視界に地図とか時計とかメールとかを重ねて見るとかそういうの。

2. 聴覚
iPod(ローカル/リモート問わず)を思考だけで操作して、イヤフォン付けなくても即座に曲を聞けるようにしたい。
とはいえ話しかけられるとかクラクションとか、聞くべき音は届けて欲しい。

2. 記憶検索 or クリップ
攻殻機動隊でありますが、名言を引用したり引用元を調べたりする機能。

はー、はやく実現しないかなぁ。
子ども生んで、ある程度育った頃に実用的な価格だったらやりたいくらいのイメージ。

gem install で permission denied

ReVIEWってツールを使ってみようと思って gem install review したらpermission denied。

You don't have write permissions into the /Users/hoge/.rvm/gems/ruby-1.9.2-p318/bin directory.

rvmが原因ぽいけどググってもrvm使ってる人は普通にgem installでおｋとしか書いてなくてよく分からず。
(もうちょっと深く探せば何かあるかもしれない)

問題のディレクトリを見てみたら、binだけオーナーがrootになっていた。(他は自分のユーザ名)
なんでだろう？macportsとか関係あるのかしら？

とりあえず
sudo chmod a+w bin

して誤魔化した。
これをするとインストールはできるけど、gemコマンド実行時に警告が出る。
warning: Insecure world writable dir

うん、まぁそうだよね。
sudo chmod o-w bin

してリトライ。警告は出なくなり、（表面的には）解決。
うーん。
副作用がないといいんだけど。。

git tag まだまだ続く

慌てる時ー！（慌てる時ー！）
リモートリポジトリにpushしたtagが間違っていたとか必要なかったとかした時ー！

# git tag -d hoga //手元のhogaタグを削除
# git push origin :refs/tags/hoga //リモートのhogaタグを空のタグ(:)で上書き

…って削除したけどやっぱり必要だったotz

git merge する時に --squash オプションをつける

--squashをつけた方がいい、とチーム内では言われていますが、
今まではよく分かんなかったので怖くて使ってませんでした。(推奨であって強制ではなかったので)

[ --squash をつけた方がよい理由 ]
コミットする時は、「新しいメソッドを実装」「不要なメソッドを削除」「リファクタリング」のように、内容や目的毎に分けた方が良いらしいですね？
(diffが分かりやすくなったり、レビューがしやすくなったりするから？)

とはいえ、レビューやテストが終わってmasterにマージする時は、「XXXメソッドの代わりにYYYメソッドを実装」とひとつにまとめた方が後で分かりやすいでしょう。

[ --squash の使い方 ]
ということで。

git merge --squash branch_name

こうすると、マージしたいブランチの変更全てがmasterにも適用され、かつまだcommitしていない状態にできます。

"git status" するとこんな感じで、変更されたファイル一覧が表示されます。

# On branch master

# Changes to be committed:

# (use "git reset HEAD <file>..." to unstage)

# modified: xxx.rb

# modified: yyy.rb

# ...

この状態で改めて "git commit" しなおせば、
別ブランチでの複数のコミットを、masterでは一つにまとめてしまえるわけですね。

以下、まとめ。
多分こうすればいいんだと思う。
----
(開発用のブランチを作成)
git checkout -b new_branch
↓
(開発してはコミットの繰り返し)
git add
git commit
git add
git commit
...
↓
(コミットとレビューが終わったらmasterにsquashマージしてcommitし直す)
git checkout master
git merge --squash new_branch
git commit
↓
(リモートリポジトリにpush)
git push origin master

みんな大好きsftp

リモートからファイルを取ってきたり、逆にローカルからファイルを送ったりってことは多いと思います。
ブラウザやGUI経由(自分の場合はjenkinsやFinder)だと色んな理由で遅い時がありますよね。。
それを解決する方法を知っていればベストなんでしょうが、残念ながら知識がないのでTerminalで取ってきちゃえーとなります。

そんな時に(どんな時だ)使うのがsftpです。本当かなぁ。。
scpでもいいんですが、pathが長くて思い出せなかったりファイル名が長くて思い出せなかったりってなるので、自分はpwdやらcdやらlsできるsftpの方が使いやすいです。

<参考にしたページ> http://cns-guide.sfc.keio.ac.jp/2004/2/6/3.html

基本はsshと同じで、

sftp user-name@server-address

.ssh/config に設定されたサーバなら

sftp host-name

で入れます。入った後は

リモート側の操作はsshの時と同様に cd,pwd,ls などを使い、
ローカル側の操作は"l"をつけて lcd,lpwd,lls ...のように行います。

肝心のファイル転送は、
リモートからローカルへ：
get remote/file/name local/path

get hoge.txt . ... hoge.txtをローカルのカレントディレクトリへコピー

ローカルからリモートへ：
put local/file/name remote/path

put foo.txt . ...foo.txtをリモートのカレントディレクトリへコピー

ディレクトリごと転送したい時は、"mget"/"mput"という複数ファイル用のコマンドがあるらしいですが、
"-r"オプションを使って
get -r remote/directory/name local/path

get -r remote/directory/name/*.txt local/path

とかでも十分かなと思いました。

タブキーでの入力補完とヒストリー機能がないので、そこはちょっと不便に感じています。
なんとかする方法があるのかしらん？

新世界よりを買うか躊躇するなど

本屋さんで見かける→アニメの制服が可愛い→まさかの上中下巻→会社の同期にアニメの様子を訊く(微妙)→別の同期が買う→感想を聞く(中々)→黒い家(黒い)の著者と判明→鍵のかかった部屋(大野君)の著者と判明[今ココ]

黒い家とかマジ黒かったのでまたあんな怖かったらやだなーとびびってるんですが、
しかし借りられそう(金銭的ハードルが無い)ので読むかも。
問題はその同期と会うチャンスがないこと。

さて、今年ももう終盤ですね。。。

去年の読書リストは74。
今年の読書リストは47(10/22付)。

ファントム・ブレイブやらProject Divaやらゲームばっかりやってたので少ないですね。
とりあえず、目標の年50はいけそうなので、まぁよしとする。

境ホラは年3冊読んでもリスト1で、物語シリーズは1冊/1リストなあたりちょっと変な気もするが、そこらへんがこだわり。
段々場所をとるラノベを買わなくなり、周囲の影響を受けてSFに傾倒しつつあります。

git tag はじめの一歩

便利なので付けすぎて氾濫し過ぎな気もするタグ。
短いと意味分かんないし、あんまり長い名前も使いづらいし。。

一覧表示： git tag

タグ付け： git tag hoge  ... 今いるところ(HEAD)に対してタグを打てる。

タグ付け(2)： git tag hoge commit  ...commitを指定してタグを打てる。

コメント付きタグ付け： git tag hoge -m "hoge-hoge"

タグ削除： git tag -d hoge

タグだけpull： git fetch origin -t  もしくは git fetch origin --tags
(git pull --tags でできるかと思ったけど、できないみたい？)

タグだけpush： git push --tags

タグ打ってpushしようと思ったら、「"zzz"というtagはrejectだよ！どこからも繋がってないよ！」的なメッセージが出たことがあって、そのときはそのタグを一回削除してからfetchして取り直してからpushしたらできた。

tagsとtagとがあって、ちょっとややこしいですの。
tagだけpushするときはbranchとかremoteとか気にしなくてよくて気楽―。

最後に。
タグが多すぎると目的のタグが見つけられなくて、いつも" | grep xxx"とかやってたのですが、
git tag -l "xxx*"
で探せるとな！何これ超便利。