git勉強会 in Okinawa に行ってきた

2013/09/28 に git勉強会 in Okinawa があったので紛れ込んできました。
togetter は こんな感じ。


まずは git のハンズオン。資料はこんな感じでした。
ハンズオン形式は始めてでしたが、これは個人でやるタイプなのでひたすらもくもくでした。
割と見たことある内容なので資料を読んでました。
rebase で fixup にするとコメント無し squash にできそうなので便利そう。


次は @Tomohiro さんによる git を使った開発の話。

git は「複数人数で開発とかする上で使えそうなもの」であって、開発のスタイルとかに合わせて使っていこう、みたいな話とか。
例えば git-flow とか github-flow とかみたいに git を使うスタイルはいくつかあるらしくて、自分達に使えそうなものを取り入れていけば良いのでは的な話。
具体例として @Tomohiro さん達はスクラムしてたりします、とかとか言ってました。
github 使うなら huboard 使えばカンバン化できたりするよー、とかとか。
型に合わせるのも良いけれど必要なところだけ取ってけるともっと良いんだろーなー、とか思いましたまる。

あとは、環境な話とか。
vagrant を使えば環境構築のレシピをテキストベースで保存できる == git で管理可能ですよー、とか。
環境の依存とかも解決できるしロールバックもできるし良い感じそう。

packer を使って OS Install -> vagrant で上げて -> puppet でコマンドとかを入れる

とかしてるみたいです。
chef も良いけれど、 chef は割と厳密なファイル構成でファイルを書かないといけないらしくて、 puppet は単純な構成でも厳密な構成でもできるし良いよー、と。
とりあえずテキストベースで環境を構築できるしこうやって公開もできます、みたいな話。
便利そうなので次何か構築する時は使ってみたいなー、とか思ったり。


ハンズオンの二回目はコンフリクトの解消。
だけれど曰く「ちゃんとコミュニケーションできてたらコンフリクトなんて起きないよ」と。
ハンズオンでは積極的にコンフリクトして解消する作業。
「コンフリクトするのは怖くないよ」みたいな印象を持ってもらえば良いな、って形らしいです。

ちなみに、 rebase 派 と merge 派 は分かりあえないらしいです。
rebase は svn とかのユーザの感覚らしい。まっすぐなので。
merge はなんだろ。 mercurial かな。
ちなみに私は rebase からの merge --no-ff 派。
merge 時に conflict するのは面倒だけれど master に残すのは merge commit じゃないと面倒そうなので。
なので rebase -i で 1つにするほどでも無いけれど、master に 直 merge も嫌かなー、くらいのスタンス。



おまけで勉強会の時に飛んできた URL 群たち。

Git を学ぶ - @Tomohiro さんによる gist。 git を学ぶ上で便利そうな tips とか command とかの紹介。
あと、git-バルスでは「どうやるとgitがぶっ壊れるか学べるから良いよね」とのこと。
ちなみに加えて「まぁやらないですけれど」とのこと。

ChangeLog を支える英語 - yamane さんが投げてたURL。
commit message の先頭は大文字にしましょうねー、とか comment を書く上での tips 集。

git commit時のコメントを英語で書くための最初の一歩 | hiro345 - kanpe さんが投げてました。
これも tips 集みたいな感じ。ざっとしか目を通してません。
commit する前に確認すべきこと、みたいなのは良い感じだったよーな。

ChefとPuppetの比較 - こちらも kanpe さん。git じゃないけれど。実を言うとまだ目を通してない。


感想。

全体的にもくもくな感じでした。
コンフリクトのハンズオンの時に知らない人とあたればまた違ったのかもしれませんが。
というか私が知らない人と話してないだけか。
git そのものは知ってる知ってるみたいな反応してしまったし。でもほぼ個人でしか使ってないオチ。
個人的には仮想環境な話が聞けて良かったかなー、と。次に git を使った開発の実例とか。
git user (というかバージョン管理する人)が増えると良いなー、とか思いながらかんそーおしまい。

リファクタリング・ウェットウェア を読んだ

リファクタリング・ウェットウェア を読みました。

2009年の本らしいです。
なんで今読んだかと言えば、本屋でふらふらまわって立ち読みしてて見付けてしまったので。この辺は本屋流石ですね。

さてこっちも確か読み終わったのは昨日。
最近は一日数章読んで数日かけるスタイルかもしれない。単に一気に読み切る集中力が無いとも言う。

内容としては達人プログラマをちょっとアップデート + プログラマ臭が少し抜けた、みたいな印象。 達人プログラマは全部読んでないので憶測ですが。

割と心理学とかそーいうもの寄りで、効率良く学ぶには、みたいな話とか。
心理学うんぬんで若干うさん臭いけれど、「うさん臭い話ですが」みたいな書き方されてる。根拠が不明瞭な分ちょっと違和感はある。ただ、こういう役に立ちそうな話ありますよ、みたいな感じ。

特に印象的なのがドレイファスのモデル。
「技術を修得するためにはこのような段階を持つ」みたいなの。
実際、これが正しいかとかは謎だけれど。

一応、具体的な学習例とかあるかな、とか思ったけれど割とアバウト。
方針は示してくれるので、本に書かれている通り「レシピ」チック。

「毎年言語を学べ」みたいに、達人プログラマの方が具体的なのかも。あれ。「学べ」って具体的かな?
学習の仕方とかも「目標立てよう」とか。確かに立てた方が良さそうだけれどどうしようーん。みたいな。いやそれも含めて自分で考えなアカンのか……。

うさん臭いうんぬんと言えば、脳の仕組みの活用とかいろいろあったり。別に否定してる訳じゃないけれど。いかに効率を上げるか、みたいなのが大量にあるから少しでも取り入れると良いんじゃないかなー、みたいなスタンスで読んでました。

あとは印象的な単語はエクソコーテクス。
実を言えば「エクソコーテクス」って 単語は憶えていなかった。
エクソコーテスが何かと言えば、外部脳、らしい。
本とかを丸暗記するんじゃなくて「この本にはアレが書かれてた」って憶えれば、その知識は活用できるし丸暗記の労力は減るよね。みたいな。
私が「エクソコーテクス」って単語を忘れたら恐らくこの記事を見るはず。ちゃんと「そういうものが残ってる」って憶えてればだけれど。

効率を高めるためのtips集みたいな感じだったかも。



というか Teem Geek といい リファクタリング・ウェットウェアといい、最初の章はインパクト強めなー。立ち読みを買わせる戦略か何かなのだろうか。

Teem Geek を読んだ

Teem Geek を読みました。xHago とかで評判が良かったので読みました。

というか読み切ってました。実を言うと数週間前くらいに読み終えて、感想を今書こうかとしてるところです。
割と記憶が薄れ気味なのでパラパラ捲ったり目次を読みながら書くことにします。

記憶薄れてるってことは微妙だったのか感あるので、まずは憶えてることから。
印象としてはやっぱり HRT 。

• Humility - 謙虚
• Respect - 尊敬
• Trust - 信頼

人と関わるんならこれを信条にしよう、みたいなもの。
確かにHRTを実践できると悪く思う人は減りそうだなー、とは思いました。
ただ、これができたら苦労しないよね、とか思ってしまうので私にはまだまだ精進が必要そう。

次に憶えてるエピソードは文化を大事にしよう、みたいな話。
ここで言う文化はコーディングスタイルとかで、オープンソースなソフトウェアに「とても良い機能だけれど文化が少し違う」ものを取り入れるかどうか、みたいな。
Teem Geek で出てきたエピソードでは、文化を優先するためにそのコードは取り入れてませんでした。そこまでするのかー、と印象に残ってます。
あとは天才の神話とか。「一人でやるには限度がある」とか「誰もが一人で籠って完璧なのを作り幻想を抱くが幻想だ」みたいな感じ。

この辺からパラパラ捲りつつ書きつつ。

全体的な印象としては オープンソースのコミュニティの失敗例と成功例、みたいな感じ。
「ギークでなくても本書のアドバイスは読む価値がある」って帯に書かれているんだけれど、やっぱり目線はギーク寄りなのかな、とか思う。
なんだろ。この文脈としての「ギーク」は「創造的なことをする」とか「複雑なことをする」とか「それ以外のことに苦痛を感じる」みたいなニュアンスかな。

ブログに感想を書いていて思ったのだけれど「そういう人達の処世術」とかみたいな意味合いっぽいな、とか。この本を一言で言うなら割とそれっぽい感。
最初の辺りに書かれているのが「チームワークについてどう思うか」で「誰も信じられない」とかだし。
この部分立ち読みして買ったのもあるのだけれど、割と冷静に見ると失礼だよなー、とか思う。いや確かにチームワークの思い出には苦いものが当然あるんだけれど。
そういう人に向けてるんだろーな、とか思いました。

ちなみにそういった内容エピソードとしては、チームワークの残念例とか、その対処とか、組織でこの先生きのこるには、とかとか書いてありました。
割とあるある事例紹介みたいなところもあるので、てっきり自分がギークなのかと思わせてしまう辺りも流石かもしれない。
そしてその事例に俺はこうしたぜ、的な。それこそ経験をまとめて本にしちゃいましたー、って流れなのかもしれない。

チームワーク面倒、とかって思ってしまったことある人向け本なのかもなー、とか思いつつ。