肉とビールとパンケーキ by @sotarok

少し大人になった「肉とご飯と甘いもの」

最近お気に入りのPHPライブラリ開発手法

PHP

PEAR2/Pyrus ってどうなったんだっけ？
という話はとりあえず一旦置いておいて、最近わりかしカジュアルにPHPライブラリを開発して配布する方法がなんとなく自分の中で定着してきたので超ざっくりまとめておく。

ソースコードはGitHub、開発にはgitflow、配布はOpenpear

Openpear で世界征服の話はどうなったんだ、というのは置いておいて、ざっくり、上記の通り、

というのが一番楽だと思っている。

ソースコードはGitHub

Openpear はとっても便利なサービスで、SVNでのホスティングもサポートしているのだけど、今更SVNを使いたくもないし、Openpear で今後Gitをサポートする予定もない。
GitHubではGitによるfork/pull request のエコシステムが出来上がりつつあると思っていて、開発者もそこにいるし、GitHubでなんか作っておけば人にコード見てもらったり修正してもらったり、それを取り込んだりが非常にやりやすい環境が揃っている。

もうGitHubを使わない手はない。

配布はOpenpear

で、GitHubで開発したものを直接PEARパッケージ化して、PEARコマンドでインストールできるようにしたいわけだ。
だけど、GitHub登場以来何度かForumに登場しているPEARの公式サポートの件はまとまらないまま話が立ち消えたりして、なんともなっていない。

と、ここで登場するのがOpenpearだ。

Openpear は、上記の通りSVNリポジトリのホスティングはしているが、パッケージの設定で、外部のリポジトリ（SVN、Git、Mercurial）が指定できる。

つまり、ここに、ホスティング先のGitHubのリポジトリを指定すれば、それだけでPEARパッケージ化することができるし、以下のコマンドでインストール可能な形式で配布できる。

$ sudo pear install openpera/Git_Daily


ところで、OpenpaerでGitHubからリリースするにはちょっとした設定のコツ？がいるというか、注意すべき点があるので、一応それはここで説明しておく。


参考画像:


以下参考：

開発ツールとしてgitflow を使う

gitflow は、上記Openpearの制約にぴったりなツールだ。
develop ブランチを開発用ブランチとして普段のやりとりにつかい、releaseブランチを経て、最終的にタグと共に master ブランチに merge される。master ブランチは、常に、安定してきた開発用のブランチからのマージコミットしか存在せず、つまり、master ブランチが、「配布して良いブランチ」となる。

参考:

あ、ちなみに、さっきから例に用いている git-daily というのは、gitflow に似たツールなんだけど、ライブラリ開発用というより、もっと頻繁に修正リリースとかが発生するようなウェブアプリ開発用のgit補助ツールであったりする。最近はいつも自分もコレを使ってウェブアプリの開発をしているわけだけど、これはこれで相当便利なのでまた今度話題にします。

一応参考:

具体的な手順

  1. 手元で、Gitでライブラリ開発を開始する
  2. git flow init して、develop で開発
  3. 適当なタイミングでGitHubにリポジトリを作ってpush
  4. developブランチでなんやかんやしてよしリリースやー、となったら git flow release start, -> … -> git flow release finish
  5. master にマージされるので、これをGitHubにpush
  6. Openpear にそのライブラリ用のパッケージを新規作成
  7. リポジトリ設定で、GitHubのURIを指定する
  8. リリース処理
  9. pear コマンドでインストール可能な形で配布完了

という感じです。あとはGitHubで開発継続、gitflowでmasterへマージ、Openpearで配布（リリース）を繰り返せばなんとなくうまくいく感じがしませんか。

まとめ

で、まぁ現状こんな感じ。
まとめると、繰り返しになるけど、

まぁ、PHPライブラリ開発の話ですが、そして個人的な話ではありますが参考になれば幸いです。


余談:

Openpear もっと海外でも使われれば色々良くなるよね、と思いつつ全然海外で広報活動をしていないんですけど。
あと、PEAR2を全然追ってないし、Openpear でそれをサポートするほど僕らの活力が残っていないので、いやむしろOpenpearってGitHubにあるから誰か（ｒ

Capistrano + rsync で省エネデプロイ

capistrano

こんにちは。

タイトルの通りなんですが、Capistrano みんなつかってるよねー。
ってことで独自のデプロイシステムをもってなくてさすがにFTPでUPはしてませんって人は結構使ってるもんだと思ってるんですけど、Capistrano ってなんかデフォルト各サーバで vcs の update 的なことをするか、ローカルにソースツリーを用意してやる場合に使えるのは scp で、なんかエコじゃないよねと言う話で、いちいちソースツリー全部配布されてたら転送量も時間もかかってしょうがないので、まーrsyncがいいんだよね、ということで、そんな時は capistrano_rsync_with_remote_cache (なげえよ) を使えばいいよね！ってお話です。 *1


このご時世なんでも省エネがいいんです。

インストール

gem で適当にインストール。

$ gem install capistrano_rsync_with_remote_cache

今だと2.4.0ってやつが入りました。

使い方

deploy_via が重要なわけだけど、その他ももろもろ揃えておく。多分このツールのすごいところは、scm 的なところは既存のリポジトリの枠でそれを local cache として保持して、deploy_via で、deploy の strategy だけちゃんと切り替えられるところのような気がしている。

set :scm, :git
set :deploy_via, :rsync_with_remote_cache
set :git_enable_submodules, true
set :repository, "."
set :copy_exclude, %w(
    .git
    Capfile
    config/hogeohge.ini
    cache
    app/logs
)
set :rsync_options, '-az --delete --delete-excluded --exclude=.git --exclude=' + copy_exclude.join(' --exclude=')

えーなんかこうですね、 :copy_exclude ってでデフォルトの Capistrano のオプションを指定しつつそれを :rsync_options に指定しちゃうところがオサレなかんじでしょうか？（ここの中身は適当に。）
でなんかこんなことにしておくと、よしなに rsync でremoteにあるディレクトリに差分でアップロードして、そこからrelease_pathにコピーして使ってくれる感じになります。


ちなみに deploy strategy にはデフォルトで :remote_cache っていう似てるっぽいやつがあるんですがこれはこれで全然違うやつで、 deploy -> remote の転送は普通に scm なやつで、remoteにリポジトリのコピーを1つもっておいて、そこからrelease_pathにコピーして使うんですよっていうやつです。

仕組み

超適当ですがこんなかんじの仕組みで動いてます。まぁあまり気合の入った図ではないんですが適当に感じ取ってください。


簡単に言うと、repository "." なので、そのディレクトリをすでに git リポジトリにしておくわけですが（いやこれはdeployサーバとか作ったらわりと普通ですよね？）、deploy時にはそこから一度 .rsync_cache ディレクトリに clone （次回以降はpull）されます。で、デプロイ先には shared ディレクトリに cached-copy というディレクトリができて、local の .rsync_cache から remote の cached-copy に rsync で差分アップロードされます。で、 cached-copy から release_path に日付でディレクトリ cp されて(いや実際はここも rsync です)、最後に symlink の貼替えが行われる、という流れです。

結論

ということで無事に省エネデプロイができるようになりました。

そして最終的には Ruby なので、何したってOKだよね、というところが Ruby 系ツールの良いところなのかどうか、というのは別にして。 *2

*1:Gitとかだと pull とか圧縮してやってるからそこまでコストも高くないのかな？

*2:そしてなんというか、Ruby系ツールはほんとDSLだから、Rubyがわかってればそれが使えるというよりは割とそのツール特有の文法を学ばなきゃいけない所が面倒なところではあるといえばあるのだけど、でもまぁそうはいっても結局最終的にはRubyなのだ

Git関連ツール開発中に手元で remote 関連の動作テスト

Git

いやまあこんなことは、どうでもいいといえばいいのですが、意外と知らない人もいるかも意知れないと思ってメモ。

git-daily の開発とかでよく remote とのやりとりの動作確認とかが必要になるんだけど、そのテスト方法について。いちいち gitosis やら github やらの実際のサーバを用意しなくてもテストはできるんですよ、という話。

適当なリポジトリを用意

$ cd /path/to/tmp
$ mkdir hoge
$ cd hoge
$ git init
$ touch hoge.txt
$ git add hoge.txt
$ git commit -m "first commit"

remote 用のリポジトリを用意

続き。bare リポジトリ作成

$ mkdir ../fuga
$ cd ../fuga
$ git init --bare

remote 追加

hoge に戻って、相対パスで remote の追加＆first push。

$ cd ../hoge
$ git remote add origin ../fuga
$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 231 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To ../fuga
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

あとは適当にリモート操作

pushしたり

$ touch fuga.txt
$ git add fuga.txt
$ git commit -m "add fuga"
[master 263204f] add fuga
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 fuga.txt
$ git push
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Unpacking objects: 100% (3/3), done.
Writing objects: 100% (3/3), 280 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../fuga
   d3a54c5..263204f  master -> master

clone もできます

$ cd ..
$ ls
fuga  hoge
$ git clone fuga piyo
Cloning into piyo...
done.
$ ls
fuga  hoge  piyo
$ cd piyo
$ git log
commit 263204f294a67959a5978fbe5a862e2c05526e91
Author: Sotaro KARASAWA <sotarok@crocos.co.jp>
Date:   Wed Jul 13 22:22:47 2011 +0900

    add fuga

commit d3a54c5d76851286052d216db0925637460e6f03
Author: Sotaro KARASAWA <sotarok@crocos.co.jp>
Date:   Wed Jul 13 22:16:07 2011 +0900

    first commit

結論

Git は簡単。

パーフェクトPHPが増刷されました (第3刷！)

こんにちは、もう夏のような毎日ですが皆様いかがお過ごしでしょうか。

さて、タイトルのとおりですが、昨年11月に発売された、パーフェクトPHPが増刷され、この7月に第3刷となりました！みなさまのおかげです。本当にありがとうございます。


第3刷での更新

以下のポイントが修正されています

関係ないけどPHPカンファレンスがありますよ

あ、発表者の締切りもう終わってました（ブログ書くの遅・・・

ということで

PHP 5.4 alpha1 も出たりしてますます楽しくなってきている PHP ですが、パーフェクトPHPをこれからもよろしくお願いします。

パーフェクトPHP (PERFECT SERIES 3)

パーフェクトPHP (PERFECT SERIES 3)

今すぐ Follow すべき PHP 界のスーパーエンジニア

neta

流行に乗りました。反省してます...

順不同。PHP界隈の人で、PHP のこと結構つぶやく人中心に。そしてわりかし適当です。

  • @moriyoshit , PHP
  • @shin1x1 , CakePHP
  • @yando , CakePHP Lithium
  • @tokushima , rhaco
  • @hidenorigoto , Symfony2
  • @fivestr , Symfony2
  • @heavenshell , ZF
  • @rsky , Extension
  • @yoya , Extension , SWF
  • @nazo , rhaco , LOCAL
  • @chobi_e, Extension
  • @yohgaki , PHP, Security
  • @koyhoge , Various
  • @iteman , Piece , Testing
  • @riaf , Various ...
  • @brtriver , Symfony2
  • @takagi , Documentation
  • @mugeso , Agavi
  • @hnw , 浮動小数点数
  • @ethnyan , ?


もっと詳しい 2008 年版はこっちを参考に。なんか印象としては、3年前と比べると、PHP 最近書いてません or 興味なくなりました or もう書く時間ありませんみたいな人がちらほらいる気がする。

追記

今すぐ読むべき PHP 界のパーフェクト書籍はこちら:

パーフェクトPHP (PERFECT SERIES 3)

パーフェクトPHP (PERFECT SERIES 3)

さらに追記

すいませんでした、大事な人書き忘れてたので追記しました。 @hnw

Time Capsule から任意のファイルを任意の場所に復元する

Mac

どうも、love++ の件で密かに話題になっているそうたろうです。Mac を買うたびに Mac ネタかって話ですが、タイトルのとおり、Time Capsule から任意の場所にバックアップされているファイルを復元する方法です。

http://farm6.static.flickr.com/5111/5835945151_c081f1c8f0_z.jpg

今回、自分のマシンで問題になったのは、復元「先」が指定できない問題でした。Mac は Time Machine を使って Time Capsule に常にバックアップしていて、ファイルは存在しているのですが、今回新しい iMac を買って、構成が

と変更されました。ここで問題となったのは、 Primary ディスクかつ起動ディスクとなっているシステムのボリュームが 256 GB SSD の方になっていたことでした。
Time Capsule から以前のファイルを復元しようとしたところ、復元先を指定することができず、256 GB SSD のほうに復元されようとしてしまい、当然容量が足りない *1。
で、仕方なく OS インストールの際には、iTunes のディレクトリと iPhoto のディレクトリを除いて復元したのだが、後から復元できるかなーと思ったけど、「移行アシスタント」を使っても、同じ状況で復元先は指定できなかった....

もうだめや...


と思っていたが、要するに以下の要領で復元した。

  • Time Capsule の Data ディレクトリをマウント
  • 旧 iMac のバックアップファイル (.sparsebundle … スパース・ディスクイメージ・バンドル) をマウント
  • そのマウントされたディレクトリの Latest ディレクトリから rsync

Data ディレクトリをマウント

これはもはや言及するまでもなく、Finder から Time Capsule を選択すれば勝手にマウントされる。

スパース・ディスクイメージ・バンドルをマウント

マウントされた Time Capsule の Data ディレクトリをひらいて、 .sparsebundle となっているファイルをダブルクリック。

rsync

基本的に Terminal.app とか iTerm とかで作業。
マウントされた .sparsebundle は、

$ ls /Volumes
Backup of Monopoli      <- バックアップファイル (これは Monopoli というマシン名)
Data                    <- Time Capsule のディスク
Macintosh HD            <- ローカルの SSD
Macintosh HD 2          <- ローカルの HDD

な場所にあるので、中身をとりあえず見てみる。

$ ls -la /Volumes/Backup\ of\ Monopoli
total 16
drwxr-xr-x  6 sotarok  staff   408  6 13  2010 .
drwxrwxrwt@ 6 root     admin   204  6 15 23:27 ..
-rw-r--r--@ 1 sotarok  staff  6148  9  4  2010 .DS_Store
drwx------  3 root     staff   102  8 14  2009 .Spotlight-V100
d-wx-wx-wt  3 sotarok  staff   102  6 15 23:27 .Trashes
-rw-r--r--  1 root     staff     0  8 14  2009 .com.apple.timemachine.supported
drwx------  2 sotarok  staff   102  6 15 23:29 .fseventsd
drwxr-xr-x+ 3 root     staff   102  9 13  2009 Backups.backupdb

Backups.backupdb ディレクトリが実体になってて、日付ごとのディレクトリ + Latest ディレクトリがある。

$ ls -la /Volumes/Backup\ of\ Monopoli/Backups.backupdb/Monopoli
...
drwxr-xr-x@  3 root  staff   204  6  8 23:04 2011-06-08-230426
drwxr-xr-x@  3 root  staff   204  6 11 01:37 2011-06-11-013743
drwxr-xr-x@  3 root  staff   204  6 11 02:37 2011-06-11-023745
...
drwxr-xr-x@  3 root  staff   204  6 13 19:42 2011-06-13-194209
lrwxrwxrwx   1 root  staff    17  6 13 19:42 Latest -> 2011-06-13-194209

で、要するに Latest がその中身なので、もう要するに以下のように吸いだした。復元先はもちろん Macintosh HD 2 ですよ。「/Volumes/Macintosh HD 2/Music/iTunes/iTunes Music/」 が新しい iTunes Music ライブラリのディレクトリ。

$ rsync -avP /Volumes/Backup\ of\ Monopoli/Backups.backupdb/Monopoli/Latest/Macintosh\ HD/Users/sotarok/Music/iTunes/iTunes\ Music/ /Volumes/Macintosh\ HD\ 2/Music/iTunes/iTunes\ Music/

みたいなかんじ。結構時間かかるけどめでたしめでたし（多分。今転送中）

というか

みんなどうやって復元しているのだろうか。もっと簡単な方法があるのか？ rsync とか使えないような人ってどうしてるんだろうな。

余談

Time Capsule のディスクを単純にマウントするなら、

$ mount_afp afp://user:password@ip addr of time capsule/Data /path/to/mount

的な感じでできます。

これはこれで、前起動ディスクが死んだときに、OS DVDディスクから起動してターミナル起動してバックアップとってなかったディレクトリを Time Capsule に転送するときに役に立った。

なんとなく参考にしたところ

*1:あ、もちろんもとのディスクで 500 GB 中 256 GB 以下しか使っていない場合は別

退職のお知らせ＆〜

今週の 5/18 日をもって、グリー株式会社を退職しました。
昨年院を卒業し、新卒で入社して1年と1ヶ月、短い間でしたが、これまでの人生の中で最も濃密な1年間だったと思います。

グリーでは、色々端折りますが、PHP 5化、APC 化、Git 化、コーディング規約の策定、バックエンドフレームワークの作成と導入など、自分の望む通りアプリ寄りのインフラの仕事をすることができました。それから、これらの課題を解決してくるにあたっては、当然僕1人の力でどうにかなる問題ではないものもたくさんあり、そういうなかで同じインフラのチームの皆さんや、サービス開発をされてるみなさんが力になってくれたおかげで色々すすめることができたと思います。
最後の数ヶ月では、新プロダクトのサービス開発もしました。新しいバックエンドフレームワークの導入やGit化というミッションをかかえつつ、プロダクト制作の一部始終を体験することができたのは、これまた自分にとってかけがえのない経験でした。

それから、エンジニアブログの立ち上げができたのも嬉しかったです。入社してすぐに色々言って立ち上げたのですが、最初は、かきませんかとお願いしていたブログも、今では書きたいという人が各所から出てきてくれたりなんかして、そういうものにできたというのはやっぱり嬉しいですね。
これからも面白い記事が上がってくるのを楽しみにしています！


グリーで働いてよかったことは、なにより、世界が注目する急成長をしている会社真っ只中で働けたことです。他では得難い体験をしたと思っています。勢いがあって実際に成長している会社の中身はこんなことになってんだなーというのをこの時期に自分の身をもって感じることができる人というのは限られていると思います。


退職の理由らしきものはこれといってないのですが、という某氏の言葉を借りますが、そうですね、しいて言えば、もう少し小さいところで小さい会社からやってみたいと思ったこと、そしてその思いに呼応するように、人と出会い、チャンスに出会い、これはやるしかない、と思えることに出会えたことかと思います。


最後に、いつも、言いたくても言えないし、言ってもどうにも本気にされないのですがw、一緒に働いた藤本さんや梶原さんをはじめとする皆様には、感謝の気持ちでいっぱいです。考えると色々な思いが溢れてきますが、言葉では表しきれないです。本当にありがとうございました。

これから

6月1日付けで株式会社クロコスに入社します。
岡元さんとおざーんに声をかけていただいた数名の仲間と、新しい会社を作り、新しいサービスを作るためにジョインを決めました。
「これまでの人生の中で最も濃密な1年間だったと思います」と書きましたが、これからはそれよりもさらに濃密な時間にすべく頑張っていきます。

これからも色々な面でウェブ開発に携わっていきますし、これからもガツガツやってまいります。
皆様には、これからもお世話になります。よろしくお願いいたします。