はじめてもらったpull requestをmergeするまでの話。

以前、Rubyの練習でちょっと書いた「やる夫に学ぶTDD メイヤーズの三角形編」(dproject21/yaruo_tdd_triangle · GitHub)が2012/07/06 リーダブルコード − 忘れてもいいコードを書こう。#devlove - Togetterまとめで取り上げられました。（ディスカッションのチュートリアル材料として。）

その翌々日。ふとメールをチェックするとgithubから「pull requestされてるよ！」というメールが来てました。
初めてもらったpull request。どうやって対応すればいいのかも分からず、いろいろ調べて対応した流れを書き残しておきます。

pull requestされたソースを自分のリポジトリへ

まずはpull requestされたソースを扱うブランチを作りましょう

git checkout -b {pull requestされたソースを扱うブランチの名前} master
git pull git://github.com/{forkされた相手のリポジトリ}

これで相手のコミットが自分のブランチに入ってきます。
相手のコミットの内容をチェックして、問題がなければマージしていきます。
その前にコミットをしておきましょう。

git commit

自分のブランチからgithubへ

以下、自分のmasterにmergeしてpushします。

git checkout master
git merge {pull requestされたソースを扱うブランチの名前}
git add
git commit
git push origin master

pull requestへの返事をする。

pull requestされたソースをmergeしpushすると、pull requestがcloseされます。
これでpull requestの対応が終わりました。
pull requestの画面から感謝のコメントを書いておきましょう。

ちなみにpull requestを終えたあとはこんな感じになってます。
めっちゃpoor english...
Hi! dproject21 by changeworld · Pull Request #1 · dproject21/yaruo_tdd_triangle · GitHub

対応の方法はA-Liaison BLOG: github で pull request をされたとき・するときの手順を参考にしました。

鈍行電車写経のススメ

最近、鈍行電車で技術書を写経するようになりました。この「鈍行電車写経」が思いの外はかどっていい感じだったので、その利点について書いておきます。。

迷惑度合いが低い。

そもそも、電車内でパソコンを開くことが公共マナーとしてどうかという問題がある。
ただ、ちょっと調べてみた限りでは、満員電車でパソコン開くことはあまり快く思われないけど、空いていたらまあいいんじゃないのという感じがします。
僕が使ってるのは小田急ですが、急行だと通勤時間帯は満員電車で席にも座れそうにないし、仮に席に座れたとしても、そこでパソコン開くのは・・・となってしまいます。
その点、鈍行電車だと車両によっては普通に座席が空いています。混んでいないので、パソコン開いて写経してても、そこまで迷惑はかからないかなと。

電子書籍を使う。

最近はいい時代になりまして、紙と同じ内容の電子書籍がパソコン上で見られる時代になりました。
さすがに電車の中で紙の技術書を広げながら写経するスペースはありません。ですが、電子書籍ならパソコン一つで済むので、スペースの問題が解決します。

MacBook Air最強。

特に11インチモデル。僕の場合、電車内で写経したりアプリ作ったりするためにMacBook Airを買ったようなところがありまして。
まず、MacBook Air自体が軽いので、持ち歩きが苦になりません。
次に、11インチモデルだと、大きさも小さいのでスペースも少なく済みます。
電池も持つので、往復電車の中だけであれば結構なんとかなります。
今期モデルでメモリを8GBにすれば、ブラウザ、Twitterクライアント、IDE、PDF、iTunesなどなど全部立ち上げていても十分動いてくれます。

欠点

まず、朝の通勤時間帯は諦めたほうがいいと思います。フレックスタイムが使えるなら、ピーク時間帯を避ければ、多少は出来るかもしれません。
絶対的な通勤時間も長くなります。でも、通勤時間を有効活用できるので、いいんじゃないでしょうか。
時には乗り過ごしたりすることもあるかもしれません。ですが、僕の経験上iPhoneのゲームアプリに興じて乗り過ごすよりも、写経で乗り過ごす確率のほうが低いです。

そんなわけで、なかなか勉強する時間がないというあなた。鈍行電車で写経してみませんか。
ちなみに、いまはこの本の電子書籍版を写経しています。

RailsによるアジャイルWebアプリケーション開発 第4版

プログラミングScala

RailsによるアジャイルWebアプリケーション開発第4版をRails3.2で写経してたらエラーが出た。

タイトルの通りです。

RailsによるアジャイルWebアプリケーション開発 第2版

こちらの本の第9章でエラーが出ました。

カートの作成のところで、ActiveModel::MassAssignmentSecurity::Errorが出ました。
で、いろいろググってたら『RailsによるアジャイルWebアプリケーション開発 第4版』"9.3 イテレーションD3:ボタンの追加" で rake test:functionals するとエラーになる件 - 牌語備忘録 - pygoで、「attr_accessibleを追加すればよかった？」と書いてありましたのでやってみました。

これでテストが通りました。

Rubyの練習始めました。

いま、Clean Coderを読んでいるのですが、そのなかで練習という章があります。そのなかで、「型を学べ」とあります。

Clean Coder プロフェッショナルプログラマへの道

プログラミングの型というのは、プログラミングの問題を解くためのキーボードやマウスの動きの練習である。実際に問題を解くわけではない。解き方はすでにわかっている。問題を解きながら身体の動きや意思決定の練習をするのである。

また、「プロ意識」の章でこうあります。

居心地のよい空間の外側にあるものを学んでみよう。.NETのプログラマならJavaを学んでみよう。JavaのプログラマならRubyを学んでみよう。C言語のプログラマならLispを学んでみよう。頭の体操がしたいなら、PrologやForthを学んでみよう。

そんなわけで、ちょっと前から始めていたRuby on Railsの写経と共に、Rubyの型を学びはじめました。
（ちなみに写経に使ってるのはこちら。）

RailsによるアジャイルWebアプリケーション開発 第4版

Clean Coderではボウリングゲームとか、ライフゲームとか挙げられているのだけど、まだそこまで書けず。
基礎の基礎からってことで、「やる夫で学ぶTDD メイヤーズの三角形」をやり始めた。

「やる夫で学ぶTDD」一日目 #ytdd - Togetterまとめ

一日目のコードは[Yaruo] - DT戦記(zonu_exeの日記)を写経して、二日目以降はTogetterを参考にして書いていった。
そんな感じで、どう書けばいいかがわかったので、今日から反復練習を始めています。
何度書けば、Rubyが体に馴染むのかな。

とりあえず、GitHubはこちら。
dproject21/yaruo_tdd_triangle · GitHub

@ITのScalaの記事を写経していた。

今日はタネマキさんで@ITのScala連載記事を写経していました。

スケーラブルで関数型でオブジェクト指向なScala入門

初Scala

Scalaの開発環境を作るところからやりました。
zshでpathを通すのにちょっと迷いましたが開発環境を作るのはすぐ出来ました。
.NETだとインストールだけでだいぶ時間がかかるのに、なんだこのお手軽さは。

写経してみる。

第3回くらいまでは結構余裕でした。基本的な文法は何らかのプログラム言語の経験があれば大丈夫ですね。
わけが分からなくなってきたのは高階関数とかのあたりから。写経してても「なんでこのコードがこうなるんだ？」という感じで、頭で追えない感覚。

慣れると.NETには戻れないな

と感じてます。よく「新しいパラダイムの言語を学べ」と言われますが、その言わんとするところをおぼろげながら感じました。

鹿駆動勉強会でLTしてきました。

GW前半戦はこれがメインでした。鹿駆動勉強会でLTをしてきました。
スライドはこちら。

イノベーションを起こすための3つのソウ

View more presentations from Daiki Tanoguchi

参戦のきっかけ

ITコミュニティ夏祭りでお世話になってから仲良くさせてもらってる@daiksyさんが奈良で勉強会しようと発案していたところに@bash0chさんが「能楽ホールが借りれますよ」とリプライ返したのを見て「これは行かねばLT芸人（？）の名が廃る」と思い参加を決意していました。
申し込みが始まってすぐ申し込み。その場でLT参戦表明までしてました。

今回のLT

これまでのLTでは自分語りの要素が極めて強かったです。でも最近「自分語りだけじゃいかんかなぁ」と思っていました。当初は「自分でプロダクトを作るということ」という、自分語りなテーマでネタを練っていました。そんなとき、今回のキモである「空想・構想・実装」の要素がふと浮かんで「イノベーションを起こすための3つのソウ」というタイトルが生まれました。
このタイトルにしようと決めた段階で脱自分語りの方向性が定まっていました。

いま、NHK Eテレで「スーパープレゼンテーション」という番組が放映されています。TEDトーク×英語学習がテーマの番組です。それ以前からもTEDトークはアプリで見ていました。ですが、いまスーパープレゼンテーションでTEDトークの認知度が上がってきており、脱自分語りもする。ネタにも走らない。ということで、「TEDトーク風にやってみよう！」と決めました。

しかし、それでもネタは欲しい。そう思い、プログラマーズナイトのために京都入りしてから少しずつネタを追加。最終的には発表直前まで資料のリバイスをしていました。実際はなかなかウケはとれず。プログラマーズナイトでもあった「コンテキストの違い」にここで気づいたわけです。
とはいえ、LT自体は成功といっていい感じでした。Twitterでも概ね好評でした。

再開。そして新しい出会い

今回の鹿駆動勉強会では、ITコミュニティ夏祭りでお会いした@ITコラムニストの@moromori31さん、@_funyaさんと再開。他にもコラムニストのひでみさんと会えましたし、フリュー株式会社さんのエンジニアをミサワ化している方にお会いできたり。
また機会があれば関西に遊びに行きたいですね。

実は眠かったし臭かった。

プログラマーズナイトからの徹夜明け参戦はさすがに辛かったです。実際、午前中は奈良公園でポカポカ陽気の中仮眠をとっていたり。ホテル行ってから、自分の体臭に気づいたり。いろんな人に迷惑かけていたかもと反省。身は綺麗にしておきましょう。

鹿駆動勉強会 - Togetterまとめ

鹿駆動勉強会でLTしてきました。

GW前半戦はこれがメインでした。鹿駆動勉強会でLTをしてきました。
スライドはこちら。

イノベーションを起こすための3つのソウ

View more presentations from Daiki Tanoguchi

参戦のきっかけ

ITコミュニティ夏祭りでお世話になってから仲良くさせてもらってる@daiksyさんが奈良で勉強会しようと発案していたところに@bash0c7さんが「能楽ホールが借りれますよ」とリプライ返したのを見て「これは行かねばLT芸人（？）の名が廃る」と思い参加を決意していました。
申し込みが始まってすぐ申し込み。その場でLT参戦表明までしてました。

今回のLT

これまでのLTでは自分語りの要素が極めて強かったです。でも最近「自分語りだけじゃいかんかなぁ」と思っていました。当初は「自分でプロダクトを作るということ」という、自分語りなテーマでネタを練っていました。そんなとき、今回のキモである「空想・構想・実装」の要素がふと浮かんで「イノベーションを起こすための3つのソウ」というタイトルが生まれました。
このタイトルにしようと決めた段階で脱自分語りの方向性が定まっていました。

いま、NHK Eテレで「スーパープレゼンテーション」という番組が放映されています。TEDトーク×英語学習がテーマの番組です。それ以前からもTEDトークはアプリで見ていました。ですが、いまスーパープレゼンテーションでTEDトークの認知度が上がってきており、脱自分語りもする。ネタにも走らない。ということで、「TEDトーク風にやってみよう！」と決めました。

しかし、それでもネタは欲しい。そう思い、プログラマーズナイトのために京都入りしてから少しずつネタを追加。最終的には発表直前まで資料のリバイスをしていました。実際はなかなかウケはとれず。プログラマーズナイトでもあった「コンテキストの違い」にここで気づいたわけです。
とはいえ、LT自体は成功といっていい感じでした。Twitterでも概ね好評でした。

再開。そして新しい出会い

今回の鹿駆動勉強会では、ITコミュニティ夏祭りでお会いした@ITコラムニストの@moromori31さん、@_funyaさんと再開。他にもコラムニストのひでみさんと会えましたし、フリュー株式会社さんのエンジニアをミサワ化している方にお会いできたり。
また機会があれば関西に遊びに行きたいですね。

実は眠かったし臭かった。

プログラマーズナイトからの徹夜明け参戦はさすがに辛かったです。実際、午前中は奈良公園でポカポカ陽気の中仮眠をとっていたり。ホテル行ってから、自分の体臭に気づいたり。いろんな人に迷惑かけていたかもと反省。身は綺麗にしておきましょう。