submoduleにGitHubのprivate repoがある場合、Herokuへのデプロイがさくっといくかと思ったらガツッとハマったので、メモとして残しておきます。
ちなみに、以下はRailsアプリでの例です（他のフレームワークでも応用が効くとは思いますが、効かないかもです）。基本的にはHerokuの公式ドキュメントを見ていただければ載っているので、それで事足りそうな方はそちらに飛んでください。

まず、ローカルで幸せに開発していたときは、githubにある他のrepoをsubmoduleとしてaddするときは以下の様なコマンドでやってました。ここでは、アプリフォルダの中のvendorの中にprivate repoなgemたちを突っ込んでいる感じです。

$ git submodule add git@github.com:keiko713/some_gem.git vendor/some_gem

この場合は、GitHubのSSHキーがローカルのマシンに登録してあれば、some_gemがprivate repoであろうがなかろうが、submoduleとしてvendor/some_gem以下に登録されます。GitHub上で見てもその部分はリンクになっていて、クリックするとそのrepoにジャンプできます。

ここでHerokuにアプリをデプロイしたい場合、もしaddしたsubmoduleがprivate repoでなければ、git push heroku masterの結果は次のようになり成功します（以下はdeviseをsubmoduleとしてaddした例）。

$ git submodule add git://github.com/plataformatec/devise.git vendor/devise

-----> Git submodules detected, installing
Submodule 'vendor/devise' (git://github.com/plataformatec/devise.git) registered for path 'vendor/devise'
Initialized empty Git repository in /tmp/build_1qsjqayd6a5g6/vendor/devise/.git/
Submodule path 'vendor/devise': checked out '7c8f636b98810c21c339df484258c0b1446c0d43'

しかし、これがprivate repoの場合、残念なことに次のようなエラーが出ます（以下はprivate repoであるsome_private_repoをaddした例）。

$ git submodule add git://github.com/keiko713/some_private_repo.git vendor/some_private_repo

-----> Git submodules detected, installing
Submodule 'vendor/devise' (git://github.com/plataformatec/devise.git) registered for path 'vendor/devise'
Submodule 'vendor/some_private_repo' (git@github.com:keiko713/some_private_repo.git) registered for path 'vendor/some_private_repo'
Initialized empty Git repository in /tmp/build_3lbuhu9ljt94n/vendor/devise/.git/
Submodule path 'vendor/devise': checked out '7c8f636b98810c21c339df484258c0b1446c0d43'
Initialized empty Git repository in /tmp/build_3lbuhu9ljt94n/vendor/some_private_repo/.git/
Host key verification failed.
fatal: The remote end hung up unexpectedly
Clone of 'git@github.com:keiko713/some_private_repo.git' into submodule path 'vendor/some_private_repo' failed
! Heroku push rejected, Submodule install failed

今回は、Resolving Application Dependencies with Git Submodulesのドキュメントの中にあるProtected Git submodulesを参考にしてみました。

まず、今追加してしまった分のsome_private_repoを削除します（参考: Stack Overflow）。

• .gitmodulesの中の該当submoduleの部分を削除
• .git/configの中の該当submoduleの部分を削除
• git rm –cached vendor/some_private_repo（後ろにスラッシュはつけない）
• コミットして、untrackedになっているvendor/some_private_repoフォルダを削除

次に、対象のprivate repoにアクセス可能なユーザー名とパスワードを付けて然るべき手順でsubmoduleをaddしていきます。

$ git submodule add https://username:password@github.com/keiko713/some_private_repo vendor/some_private_repo

-----> Git submodules detected, installing
Submodule 'vendor/devise' (git://github.com/plataformatec/devise.git) registered for path 'vendor/devise'
Submodule 'vendor/some_private_repo' (https://username:password@github.com/keiko713/some_private_repo) registered for path 'vendor/some_private_repo'
Initialized empty Git repository in /tmp/build_3dbb0x2kdopen/vendor/devise/.git/
Submodule path 'vendor/devise': checked out '7c8f636b98810c21c339df484258c0b1446c0d43'
Initialized empty Git repository in /tmp/build_3dbb0x2kdopen/vendor/some_private_repo/.git/
Submodule path 'vendor/some_private_repo': checked out '7c8f636b98810c21c339df484258c0b1446c0d43'

成功！ということでちょっとした変更で簡単に立ち上がりました。

ここで注意したいのが、この方法でデプロイをすると、.gitmodulesファイルにusernameとpasswordが残ってしまうという問題です。.gitmodulesはたいていrepoに上げていると思うので、public repoでこれをしてしまうとパスワード等がバレバレです。そもそもprivate repoなgemを使っている時点で、アプリ側のrepoもprivateであることが想像されるので、Herokuデプロイ用のユーザーなどを作ればいいかもしれませんが、セキュリティ的に許容しがたい場合は他の方法を探ってください。

Herokuのドキュメントの中には他にVendoringとPrivate dependency repositoriesの方法が載っていましたが、前者は試行錯誤の上残念ながらうまく行かず、後者は試していません。他にもStack OverflowにGemfile中でやりくりする方法（ENVを使ってusername/passwordを設定するのでよさげだった）やここを参考に生成したOAuth tokenを使ってやる方法も載ったりしていましたが、なんだかうまく行かず、結局上記の方法が一番シンプルでサクッと出来ました。

もっといい方法が見つかったらまた追記したいと思います。（その前にHerokuじゃないところにデプロイすることになりそうだけど…）

ではでは

最近RubyとRailsを使っています。本格的に触りはじめてまだ2ヶ月くらいしか経っていないので、Rubyさんとの会話はまだ小学生レベルですが、それでもなんとか喋れています。

ということで、これまでに学習で使ったおすすめサイトを紹介します。

• ミニツク　（日本語）
• Ruby on Rails Tutorial　（英語）
• RAILS CASTS　（基本英語、たまに日本語の訳あり）
• Railsbridge Installfest　（英語）
• Railsbridge Curriculum　（英語）

とりあえずRuby勉強するぞ！というので使ったサイトが「ミニツク」というサイトです。私はあんまり本を買わない派で、日本語でサクっとRubyの基礎を学べるサイトを探していたらたどり着きました。一章ごとにドリルがあり、理解度が試せます。もれなくMatzのビデオもついてきます。サクサク進めて基礎が学べるので、おすすめです。

次に、WebフレームワークとしてRailsをやっぱり使うわけですが、ここで学習に使ったサイトが「Ruby on Rails Tutorial」です。Railsに関するチュートリアルだけではなくGithubやHerokuの使い方まで載っているので、Webアプリ初心者の方もこのチュートリアルを全部終わらせたら開発プロセスのとてもいい勉強になると思います（でもかなり長いです）。また、「RAILS CASTS」には沢山Railsに関するスクリーンキャスト（ビデオ講座的な物）があり、テンポもよくてサクっと見れて（理解したかどうかは別にして）とてもわかった気になるのでおすすめです。魅力的な有料のコンテンツもありますが、無料のものでも十分に充実したビデオがたくさんあります。

サンフランシスコには非常にRubyコミュニティが発達していて（というかRubyという言語自体コミュニティが発達しているイメージです）、Ruby関連のmeetupがたくさんあります。その中でも先日RailsBridgeというRails初心者に向けたワークショップ（ハンズオン型の勉強会）に行ってきたのですが、これがとても充実していました。

全生徒数は30人+くらいだったと思うのですが、レベル別（プログラミング自体のまったくの素人か、他の言語でプログラミングをしたことがあるかなど）に7人程度のグループに分けて、各レベル先生1人、TA2〜3人で、独自のカリキュラム（これも上記の Ruby on Rails Tutorial に匹敵するほどいいと思います）を使用して1日でRailsを使ってWebアプリを作れるようになろう！というのが概要です。ちなみに、先生はみんなボランティア、会場もお昼ごはんとかも企業がスポンサーということで、こんな恵まれた環境なのにタダです！

スケジュールとしては、Ruby on Railsの開発環境が整っていない人は、金曜日の夜に集まって、このドキュメント（Railsbridge Installfest）にしたがって環境構築をします。ここにも先生が来るので、環境構築でつまずいてなかなか進めない人も、詳しい人に聞きながら進めることができます。土曜日は午前中から集まって、グループに別れてこのカリキュラム（Railsbridge Curriculum）にしたがってアプリを作っていきます。夕方くらいに解散です。この二つのドキュメントはRailsBridgeに参加していなくてもいつでも見ることができますし、チェックをつけながら進めることが出来て達成感もあるのでおすすめです！

実はこのRailsBridgeは、女性エンジニアの割合を増やそう！という趣旨のもとやっている活動なので、参加するには女性である必要がありますが、その女性は+1として男性をつれていくことができます。先生のボランティア自体は男女問いません。蓋をあけてみるとやっぱり先生も含めた参加者全体としては女性の割合が多くなるのですが、男性も2〜3割ほどいます。サンフランシスコでは月に1回ほどコンスタントにやっているので、ぜひ興味がある人は参加することをおすすめします。日本にいて興味がある人は、ぜひorganizerになってみてはどうでしょうか？！

なんかまとまりがない感じになりましたが…まだまだPython&Djangoは好きですよ？

おまけ：今日行ってきたFukuoka Ruby Nightというイベントの写真！初Matzでしたが、ユーモアセンスのあるステキなプレゼンでした！話しかけ忘れたことを後悔…福岡県は日本で（アジアで？世界で？）一番大きなRubyコミュニティがあるらしい。松江でも東京でもなく福岡とは意外。

いつも忘れてしまうので、GithubであるプロジェクトをForkしてからPull Requestをするまでの流れをメモしたいと思います。今回、実際に私がこの流れを使っているCordova (PhoneGap) ドキュメントのプロジェクト、 https://github.com/apache/incubator-cordova-docs を例にやっていきたいと思います。

1. Fork する

GithubでForkしたいプロジェクトまで行って、右上にあるForkボタンを押します。今回、 https://github.com/apache/incubator-cordova-docs をForkしたので、私のGithubアカウントkeiko713上では https://github.com/keiko713/incubator-cordova-docs というリポジトリが作成されます。

2. 自分のPCにcloneする

ターミナルでcloneしたいフォルダまで行って実行（そのフォルダ内にincubator-cordova-docsという名前のフォルダが作成されます）

git clone  https://github.com/keiko713/incubator-cordova-docs.git

3. branchを作る（新規ブランチ作成とそのブランチへの切りかえ）

cd incubator-cordova-docs
git checkout -b [your_branch_name]

4. ファイルを編集する

5. commit する

新規に作成したファイルの場合はgit addするのを忘れずに

git commit -am 'Translate files related to hoge'

6. pushする

git push origin [your_branch_name]

4-6を繰り返す

7. upstream（Fork元リポジトリ）の設定

Forkした自分のリポジトリ (https://github.com/keiko713/incubator-cordova-docs) は、Fork元のリポジトリ (https://github.com/apache/incubator-cordova-docs) の変更内容を自動更新しません。なので、Fork元のリポジトリの最新情報を自分のリポジトリに反映させる必要があります。

ここで、Forkした自分のリポジトリには、大抵デフォルト名としてoriginという名前がついています。新しくFork元のリポジトリにupstreamという名前をつけて追加しましょう。

git remote add upstream https://github.com/apache/incubator-cordova-docs

8. Fork元リポジトリの最新を取得しlocalのmasterを更新

# branchをmasterに変更
git checkout master
# upstreamからpullして最新を取得
git pull upstream master
# localのmasterをoriginにpush（オプション）
git push origin master

9. branchをrebase

# branchを作成したbranchに変更
git checkout [your_branch_name]
# branchをrebase
git rebase master

10. branchをoriginにpush

git push -f origin [your_branch_name]

11. Pull Requestを作成

GithubでForkした自分のリポジトリ (https://github.com/keiko713/incubator-cordova-docs) に行き、左側にあるボタンよりbranchを[your_branch_name]に切り替えます。右上にあるPull Requestボタンを押して、Pull Requestを送信します。

6/30 – 7/1にかけて行われた、LinkedInのDevelopHer Hackdayというイベントに参加してきました。私のチームはMuniMobile（現在SMS通知機能は使用できません）という、サンフランシスコを走るバスMuniの到着をSMSでお知らせするアプリを作り、2位に入賞しました！2位の賞品として、チームを組んだ@ddbrazと@heylaurakellyと一人一台、見事iPadをゲットしました！ちなみに1位の賞品はMacBookAir、3位の賞品はAmazonのギフトカードでした。LinkedIn太っ腹！全体として、とてもよくまとめられたイベントで、おみやげも多く（Tシャツ、ヨガマットなど）、参加費は無料。参加者全員の満足度は非常に高かったと思います。

DevelopHer Hackday イベント全体の流れ

土曜の11時am開始で日曜の11時am終了の24時間で何かアプリを作り上げる開発イベントで、今回は、DevelopHerともある通り、参加者は女性に限定されていました。

参加者は土曜朝10時頃からチェックインが出来、その場でチームを作ります。もしくは、チームはその前から作ることも出来ます。アイデアもその前から考えることが出来るのですが、コーディングだけは開始時間の11時になるまで開始できません。今回はテーマは特に無く、もちろんLinkedInのAPIを使ってハックしてもいいですし、使わなくてもOKでした。

チームを組んだら、とにかく開発！もちろん毎食・軽食・飲み物は全てLinkedInが用意してくれるので、開発だけに集中できます。女性限定Hackdayということもあり、途中カップケーキトラックが来たり、みんなでヨガをしたりと、かわいいミニイベントもたくさんありました。夜は泊まりこみもOKで、シリコンバレーのオフィスなのでもちろんシャワー完備。ベッドにもなりそうな特大ビーズクッションも複数個あり、寝袋持参の人もいましたが、私はこのビーズクッションで仮眠しました。ちなみに、私は3時間ほど寝たので貫徹した人が何人くらいかは分からないのですが、おそらく10人ほどは私が寝る前も起きた後もアクティブに動いていたと思います。

日曜の11時amまでに、アプリ概要を書いたスライド一枚を所定のGoogle Docsに提出してチームとしての審査への登録完了です。最終的に参加者は100人近く、チームは合計19個（1チーム1-8人）となりました。審査は、

• 19チームを3グループほどに分け、別室に分かれ審査員（LinkedIn従業員）4-5人の前で一次審査
• 全員が収容出来る大きな会場に移り、一次審査通過チーム10チームを発表
• 10チームが4人の女性特別審査員（SlideShareのCEOなど）の前で最終審査
• 1位、2位、3位を発表、賞品が授与

といった流れでした。審査の基準は、公式HP曰く審査員が”wow”となるような作品。他にも、このZDNet記事では、シンプルな問題に対してのベストな解決策と書いてありました。私のチームの勝因も、サンフランシスコに住んでいる人なら誰でも「いいアイデア！」と思うような着眼点だったと思います。その他、ファイナリストや入賞作品はここから見れます。1位のチームは、LinkedInと連携したキャリアプラン作成アプリで、アイデアや完成度も1位にふさわしいものだったと思います。

Hackday 感想と MuniMobile について

「ハック◯◯」と名がつくものにはこれまでも参加したことがありましたが、本格的にチームを組んでどっぷり開発するような数日に渡るハッカソンはこれが初めての参加でした。チームもなく知り合いもおらずぼっちな状態で土曜の朝10時頃にはもう着いてしまい、開始までたっぷり1時間チームを組む余裕がありました。アイデアはなかったので、どこかのチームに入ることが目的でしたが、ビビリということもありなかなか人に話しかけることも出来ずにその辺を彷徨っていました。そんなところ、ちょうど他のイベントで知り合った方に声をかけてもらい、フロントエンド要員としてチームに入れてもらうことにしました。

今回は本当にチームに恵まれました。また、アイデアがシンプルで既に固まっていたので、みんな「後は実装して形にしよう！」という雰囲気があり、一つ機能を実装したらハイタッチ！といったように非常に楽しく実装できました。また、チームメンバーみんなハッカソン初心者だったのですが、「動く一つのアプリを作ろう！」という目的をみんなで最後まで持ち続けたこともとても良かったと思います。

途中、例えばログイン機能を作ろうとしたのですが、ログイン機能を作るとサービスとしては良くなるけど、時間がかかるしシステムも複雑になる、一貫して動くものを作るという目的を忘れないでいよう、ということでログイン機能はつけないことにしました。これは非常に良い決断だったと思います。結果、ログイン機能が無くても十分に見栄えの良いシンプルなシステムになりました。

私達も、動くものがきちんと出来た達成感があり、しかも賞までもらえて、とても充実した二日間となりました。なんと、メンバーが通っているプログラミング学校のHackbright Academyから、使用しているTwilio APIについてスポンサーが貰える可能性が出てきました。Twilioは、SMS通知に使っているAPIなのですが、ここが開発者用アカウントを利用しているためにSMS通知機能が限定した電話番号でしか動かず、正式サービスとしてローンチ出来ない状況でした。しかし、ここをスポンサーしてもらえるなら、正式サービスとしてローンチ出来ます。また週末に集まってちょっと作り込もうと言っていて、とても楽しみです。

日本の最近のハッカソン事情はあまりよく知りません、日本でもこんなハッカソンがあるととてもいいなと思いました。

ではでは

PIL (Python Imaging Library) をUbuntuにインストールしてみました。PILを使うと、画像のリサイズなどが簡単に出来ます。インストール自体は、ルートユーザで、またはsudoをつけて

• pip install PIL

で可能なのですが、それだと色々とサポートしてくれないので、今回は

• JPEG
• ZLIB (PNG/ZIP)
• FREETYPE2

をサポートしてくれるようにしたいと思います。それぞれライブラリが必要なので、ルートユーザまたはsudoをつけて、以下のコマンドで取得します。取得の前に、apt-get updateをすることをおすすめします。

• apt-get install libjpeg8 libjpeg8-dev
• apt-get install zlib1g-dev
• apt-get install libfreetype6 libfreetype6-dev

その後、シンボリックリンクを作ります。これもsudoかルートユーザで。

• ln -s /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/
• ln -s /usr/lib/x86_64-linux-gnu/libz.so /usr/lib
• ln -s /usr/lib/x86_64-linux-gnu/libfreetype.so /usr/lib/

シンボリックリンクですが、lnコマンドでももちろん作成可能ですが、同様にcpコマンドでも作成可能です。引数は同じで、cp -s シンボリックリンク元 シンボリックリンク先になります。

最初にpip install PILを既に行った人は、以下でアップデートします。

• pip install -U PIL

これで、以下のような「サポートしました！」の画面が出ると思います。

    --------------------------------------------------------------------
    PIL 1.1.7 SETUP SUMMARY
    --------------------------------------------------------------------
    version       1.1.7
    platform      linux2 2.7.2+ (default, Oct  4 2011, 20:06:09)
                  [GCC 4.6.1]
    --------------------------------------------------------------------
    *** TKINTER support not available
    --- JPEG support available
    --- ZLIB (PNG/ZIP) support available
    --- FREETYPE2 support available
    *** LITTLECMS support not available
    --------------------------------------------------------------------

ちなみに、これを実施した環境はUbuntu 11.10 (GNU/Linux 3.0.0-12-virtual x86_64)になります。ちなみに、インストールにあたってInstall PIL with Jpeg support on Ubuntu Oneiric 64bitというブログを参考にしましたが、apt-getで取得するライブラリの名前が元の記事と少し違っています。

エンジニアの友達にgithubなどgitを使用した共同開発時の豆知識を教えてもらったので、忘れないようにメモしておきます。Thanks, Shawn!

マスターとのマージ時には事前にgit rebaseを使う

gitを使って共同開発をすると、たまにこんなコミットメッセージを見る機会があるかもしれません。

• Merge branch ‘master’ of git://github.com/hogehoge

これは、最新のマスターを私のブランチにマージしたわよ、という意味合いのコミットメッセージなのですが、正直いりません。開発者それぞれがブランチとマスターをマージするたびにこのようなメッセージをログに残してしまうと、それだけでコミット履歴を占有し、重要な情報をたどるのが困難になります。

このマージ時のコミットメッセージが発生してしまう原因は、左側の図のようにpull requestを出す前に最新のマスターを自分のブランチにマージしたいためです。ここで、git pullやgit merge origin/masterをする代わりに、git rebase masterを使いましょう。

git rebase masterで自分のベース（ブランチを作った位置）を最新のマスターと置き換えることにより、自分のコミット（図で言うとadd new function X, modify function Y, fix issue Aの3つ）は最新のマスター以降に起こったものとなり、最新のマスターを自分のブランチにマージするという作業、コミットがなくなります。後にpull request #3をマスターにマージした時も、左側の図だとmerge branch ‘master’ of git…を含めた合計4つのコミット履歴が残るのに対して、rebaseした場合は3つの履歴しか残りません。

注意: rebaseを行ったあとは、ブランチを普通のpushではなくforce pushする必要があります。コマンドは

• git push -f origin [branch_name]

rebaseの時にconflictが起こる場合

これを教えてくれた私の友人は、一度ブランチを作ってしまうと作業中のファイル群はほぼ自分しか修正を加えないので、rebaseの際にconflictが起こることは少ないと言っていましたが、もちろんconflictが起こる可能性もあります。その場合は、conflictを解消しgit rebase –continueを行うか、なにかちょっと良くないことが起きている時はあきらめてgit rebase –abortしてrebaseする前の状態まで戻します。

git -i rebaseを使ってインタラクティブにrebaseする

PythonにはPEP8という公式のコーディングスタイルがあり、それに基づいたチェックができます。しかし、例えば上の図でいうとfix issue Aまで終わってからPEP8をしていなかったという事に気づき、PEP8をしたところ新たに少し変更が生じたとしましょう。それをpep8 fixesとしてコミットしてしまうのはあまりに申し訳ない感じです。

こんな時、git rebaseをするときに-iを追加することで、インタラクティブにrebaseが行えて、このrebaseの際に申し訳ない感じのコミットを一つ前のコミットに吸収合併させることができます。また、あの時勢いで適当に書いてしまったコミットメッセージも編集できます。

ここで、例の図のfix issue Aの後ろにpep8 fixesというコミットがあったと仮定すると、git rebase -i masterを行った時に出てくるインタラクティブな画面（というかテキスト編集画面）は以下のようになります。

pick a123456 add new function X
pick b123456 modify function Y
pick c123456 fix issue A
pick d123456 pep8 fixes

# Rebase a123456 . . d123456 onto z123456
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like squash, but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

細かいそれぞれのコマンドの説明はどこかにあると信じて、今はとにかくpep8 fixesをコミット履歴に残さないようにしたいので、対象行のpickの部分をfに書き換えて変更した部分自体は前のfix issue Aに混ぜてもらって、コミットログメッセージはなかったことにします。vimの要領で書き換えでき、:wqで保存して終了できるので、書き換えた後は終了してrebase処理を実行します。Successfully rebased and updated refs/heads/master.が出たら成功です。