2013-12-10

ブログを移行した

新ブログはこちら。

http://kumamidori.github.io/

jekyll bootstrap を使って Github Pages に立てました。無料でホスティングできるなんて嬉しい。

2013-10-27

Finderで検索できない（Lion）

Mac

対処方法は分かったのだけれど、たまに再発する・・・。

Spotlight reports “Indexing and searching disabled” in Lion

http://apple.stackexchange.com/questions/24401/spotlight-reports-indexing-and-searching-disabled-in-lion

対処した方法：ターミナルで下記を実行した（合ってるのかは不明。自己責任。）

  sudo mdutil -i off /
  sudo rm -rf /.Spotlight*
  sudo mdutil -i on /
  sudo mdutil -E /
  sudo vi /etc/hostconfig
  #この行を末尾に追加
  SPOTLIGHT=-YES- at the bottom (this line was missing)

  で、OS再起動

これで、虫眼鏡マークにカーソルをあててみると、Spotlightのインデックスが再構築中になっているのを確認できた。直ることは直るのだけれど、ふと気づくとまた再発していたりして、根本的な原因、解決方法は分からず。やり方を忘れるのでここにメモった。

別な話なのだけれど、Mac で今さら覚えたTipsがあって、ファイル選択のダイアログで、
Command + Shift + . (ドット)
をすると、ドットで始まるファイルを普通に選べるということ。今までずいぶん無駄なオペレーションをしていた！もっと早く知るべきだったな。

今日は入り用があってAWS学習。ドットインストールで解説されている程度までしかさわれず。AWS公式アカウントで公開されているPHPのSDKラッパって、ZF2/Silex/Laravel の３種類しか無いのかー、と思った。https://github.com/aws

2013-10-19

リモートの最新を取り込む（rebase、merge、push -f について）

Git

今の勤務先は、VCS は Github、開発フローは git-flow です。

※ちなみに、会社のみんなは、クライアントは source-tree で全部やっているのだけれど、私はGithub for Mac（Editボタンやsyncボタンが好き）、git-flow系のコマンドだけコマンドラインで手で打っている。

以前の職場がSubversionだったもので（個人ではGithubを愛用していたとはいえ）、Gitでのチーム開発、初心者・・・。案の定、下記問題で行き詰まって、時間を無駄にしたわ。っていうか、ジタバタする前に、よく考えれば良かったんだなー。

やりたいこと

バージョンの上がったdevelopのfeature への取り込み。

この stackoverflow がまさに私の求めていたぴったりの情報だったので、理解を深めるため、以下に勝手に翻訳する。

http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase

Q. feature branch を rebase した後、git push したら reject されるのですが？

さてさて。下記はgitの単純なシナリオだと思ったのだけれど、何が足りていないのかな？

master ブランチと feature のブランチを持っている。マスタで何かして、feactureで何かして、それで、master で何か作業をする。下記のようにして何かを終える。アルファベットの順番は、コミットの順を示す。

A--B--C------F--G  (master)
            |    
            D--E  (feature)

問題点：

「既に git push origin feature がされていて、その後新たに rebase をしたという feature をバックアップしたい」となった時なのだけれど、
rebase したことによってツリーが変わってしまったために、この push は reject されてしまった。
git push --force origin feature することでしか解決ができない。

どうしても必要なのでなければ、--forceオプションを使うのは嫌なんですよね。この場合要るのですか？rebase をしたら、次の　push では必ず --force するべきだということなのでしょうか？

edited Jan 25 at 12:14 Drew Noakes / asked Jan 20 '12 at 10:29 Yuval Adam

41+されたAnswer.

問題は、git push というのが、リモートブランチがあなたのローカルブランチに対して fast-foward を想定しているという点です。
ローカル、リモートブランチ間のすべての差分が、新しいコミット群を持っているローカルの中に下記のように最後まである、ということです。

Z--X--R         <- origin/some-branch (Y　コミットに対して fast-forwarded の関係になれる)
           |        
            T--Y    <- some-branch

git rebase をすると、コミットDとEが新たにベースに適用されて、新しいコミット群が作られます。
rebase した後、下記のようになるわけです：

A--B--C------F--G--D'--E'   <- feature-branch
           |  
            D--E                <- origin/feature-branch

この状況において、リモートブランチはローカルに対して fast-forward にはなれません。

理論上はローカルブランチはリモートにマージさせられるのだけれど（もちろんここではそんなことはしないわけで）、git push は fast-forward でのみ動くので、マージさせようとするとエラーになります。

そして、--force オプションが何をするかなのですが、単にリモートブランチの状態を無視するだけです。リモートpush しようとしているコミットについて無視をするという設定をします。つまり、git push --force origin feacture-branch は origin/feacture-branch をローカルのfeature-branch でただ単に上書きします。

個人的な意見としては、
featureブランチをmasterでrebaseすること、
リモートリポジトリにそれらをforce push することで戻すこと
は、あなたがそのブランチで１人で作業するだけなのであれば、問題無いと思いますよ。

this answer edited Jan 20 '12 at 13:30 answered Jan 20 '12 at 10:55

【翻訳ここまで】

感想

で、これを読んで、よーくわかった。遅まきながらわかったよやっと！
でも、新たな悩みが。-f オプションでpush したら、一所懸命スクリーンショットとか貼り付けてmarkdownでとりまとめたGithubのコメントが、丸ごと消えてしまうのだ！
- 今のチームでは、PRレビューではなくて、ブランチの各コミットごとに細かくレビューしていく、という運用でやっているので、コミットに対するGithubコメントで画面動作確認のエビデンスを添付したりすることが多い。
それで、参考にさせて頂いたツイートが下記。

https://twitter.com/udzura/status/379296419271548928

結論

私の用途だと、rebaseではなくて、毎日こまめに merge (or pull)で最新developの取り込みをするやり方になる。
rebaseは一人で開発している時限定で使おうと思った。
うーん。そもそも、エビデンスの管理をGithubコメントでやっているのがいけてないのかもしれない。ふむー。

参考リンク

rebase にまつわる３つの誤解
- http://www.slideshare.net/HirotakaYamamoto?utm_campaign=profiletracking&utm_medium=sssite&utm_source=ssslideview
Git チームワークフロー: マージ (merge)、それともリベース (rebase) ?
- http://japan.blogs.atlassian.com/2013/11/git-team-workflows-merge-or-rebase/

2013-09-16

Packagistにパッケージ公開してみんとす

php

はじめに

BEAR.Saturdayで、すぐにテストを始められるインストールツールが必要と思った。

公開されたパッケージ「BEARSaturday.Skeleton」

BEAR.Saturdayのアプリケーションスケルトンのインストールとphpunit等のQAツールのセットアップを行います。
詳細は、READMEに全部書いてあるので省略。

実装

composer のscript （post-install-cmd）を使った。イベントフック。
- 公式マニュアル http://getcomposer.org/doc/articles/scripts.md
- 解説記事 http://www.sitepoint.com/build-automation-with-composer-scripts/
配布について、PEARパッケージからcomposerへの移行を視野に（もともとオートロード対応しているので可能）

具体的で細かいことが難しい

運用上、QAツール一式をどこにどう置くのが良いか。とりあえず「Composerのシステムグローバル」に入れることにした。とにかく、「プロジェクトのVCS リポジトリ」にコードそのものは入れない。

Packagistに公開する作業でつまずいた点のメモ

下記、ちょっとうろ覚え。微妙に間違っているかも。そのうちまた思い出す。

間違ったデバッグ方法
- ローカルでイベント処理をデバッグ -> イチイチ Packagistに Submit -> composer install で script をキック
正しいデバッグ方法
- ローカルでイベント処理をデバッグ -> composer install で直接キック（ダウンロードしにいかずにローカルを見にいくからだいじょうぶ）

余談（日記）

相方と共に東京から関西に引っ越すことになった。
１０月から関西の会社で働きます。
次の会社に、違った良さ、魅力を発見しました。そこにフィットした形でがんばっていきたいです。仕事内容は、PHPでB向けのWebサービスを作る仕事。BEARユーザではなくなったけれど、学習は、今後もプライベートで続けていきたいな〜と。

2013-08-17

自分用Githubメモ

Git

この間ペアオペしたら、今までずっと無駄が多いオペレーションでがんばっちゃっていたことに気づかされた。PRについての自分用メモ。

通信を http ではなくて ssh ですれば、いちいちアカウント情報を入力せず、ノーパスワードで鍵だけで push できる　＜これはひどい
Github アプリで cloneしたリポジトリの閲覧、操作、push、ブランチ切り替え、いろいろできて便利
PRがマージされて要らなくなったブランチは、git push origin :ブランチ名　で消す
master/develop があること
git flow 使う。コマンドラインツールは Github アプリから入れられる。
git rebase --continue
git rebase -i HEAD^^^
git fetch upstream ワークツリーのファイル自体は更新されない。リモートの情報と同期するだけ。
Syncing a fork　https://help.github.com/articles/syncing-a-fork
git rebase upstream/develop

2013-07-15

初めて知らない人のOSSに Pull Request を送った

php

経緯

最近、テストのやり方や関連ライブラリについて、学習しています。そんな流れで、Awesome PHPを見返していたところ、気になるライブラリが・・・

Faker - フェイクデータジェネレーターライブラリ。

へ〜、こんなのがあったんだ、と思った。
READMEを見て、composer でインストールして、手元で動かしてみた。一言で言うと、

「らしい」テストデータを作ってくれるプチツール

です。（もともとRuby やPerl にあったもの。ref. http://blog.takeda-soft.jp/blog/show/238）。
「山田太郎」とか、「hanako@yamada.jp」といった適当なダミーデータを、超簡単な使い方でサクサクと生成することができて、かわいい。

ローカライゼーションに対応していて、中国語とかいろいろな言語が同梱されているのだけれど、日本語対応がまだされていないことに気づいた。これまで知っている人には何回かプルリクしていたけれど。初・知らない人にプルリクエストしました。まだマージされていない・・・この歳になってもこういうのはちょっとドキドキします。

→　半日ほどでマージされた。記念ショット。

感想

怒られないようにしよう、と思って、過去のプルリクコメントをまず慎重に調べていったところ、「CSに従え」って差し戻しされている人がいた。「あ、コーディング規約って、CSって略すんだ」と思った。
最初「日本語対応、できた！」と思ったバージョンは、phpunit したら見事にレッドになって、「あ、テストって大事なんだな」と思った。あのまま出さなくて良かった。
OSSコードは、自分が知らなかったオシャレな関数が使われていたりして啓蒙的
自分のリモートリポジトリにpushして、できたできた、さあプルリク出すぞ、と思ってdiffを確認したら、修正漏れを１個発見・・・！もうコミットログまとめちゃったよ、どうするんだ、これ、と。そこから、今まで１回も使ったことなかったGitコマンドを使うなどして、その操作でさらに間違えちゃったり、やり直したりしつつ、どうにかきれいなPRを送ることができました。本件の活動成果としては「Gitの理解が進んだ」、笑。

解説記事に感謝です。