SCMBootCamp in Tokyo3 #scmbc を開催しました。
はじめに
SCMBCもはやいもので、来週で初開催からちょうど1年になります。
1年の間に
SCMBC in Tokyo 1
SCMBC in Tokyo 2
SCMBC in Nagoya 1
SCMBC in Hokkaido 1
SCMBC in Tokyo 3
と、計5回開催できました。皆様のおかげです。本当にありがとうございます。
開催経緯
きょん「そろそろ東京でやりたいわー」
@pocketberserker「やるっすー、やるっすー」
以上。
（いや、いろいろあったとは思うんだけど。
基調講演
@flyingfoozyさんが担当してくださいました。何度見ても勉強になります。広範な資料というのはつくるのがかなり難しいです。ですが、僕にとってはあのような広範な資料が理解しやすいし、新しい？発想というのも出易いので、講演を見るたびになにか思いつきます。非常に勉強になります。ありがとうございました！
DVCSサポーター
毎度のことながら、豪華なサポーターによって支えられました。本当にありがとうございます。idとDVCS名だけですがご紹介させていただきます。（簡略してすいません。
Git
運営サポーター
今回は運営でかなり手厚くサポートしてくださいました。本当にありがとうございます。僕が当日結構余裕を持って勉強会をまわせたのは間違いなく彼らのおかげです。
@kaori_t_spica、@irof、@inda_re
演習
今回もいつもと同じチートシート作成になりました。
id:flyingfoozyさんのブログにあるようにチームによっていろいろ状況があるようで、少しずつ進め方のコツがたまってきたかもしれません。
また、サポーターのツイートを見ているといろいろあったようで、ふりかえりでいろいろ考えたいと思います。次回に活かしたいですね。
参加者さん
初参加者が8割以上で嬉しかったです。もちろん、リピーターさんも大歓迎ですが、いろんな人に知ってもらえたのだなぁと実感しました。
SCMBC自体は3,4ヶ月に1度開催していますが、実に東京は8ヶ月ぶりでしたね。
レビューで気づいた事
mdとかreSTとかをデフォルトで表示できるGitHubとかBitBucket便利だなーと思いました。
あ、あと、歴史がグチャグチャっていうけど、ルールがないコンフリクトとルールのあるコンフリクトは区別しないと、「歴史一本至上主義」になりそうでこわいなーと思いました。
僕はmergeもrebaseも使うけど、歴史を検索しやすくするとか、間違ったコミットを直し易くすることに重きをおいていて、それは、作業の分割の仕方とかチームでのコミット頻度が強く影響します。
設計でいうと、なんでもかんでも、同じデザインパターン使ってたら破綻するよ？ってところかな。
最後の質問タイムでのこと
- GitにはMercurialnおEOLエクステンションのような改行コード強制拡張はありますか？
- >あります。->core.autocrlf
- Git/Hg/Bzrでどれがいいんですか？
- >こわい質問なので却下
- Git/Hg/Bzrでのブランチの違いは？
- >これがわかって、なにか一つでいろんなブランチ戦略とれたらサポーターできます
- >>簡単な説明であれば、@methaneさんのSCMBC in Nagoya 1の基調講演資料内にあります。
- 長期開発バージョンと保守バージョンの並行開発ではブランチはどうすべきか？
- >神速:ブランチではなくて、アプリの設定でバージョンを切り替えられるようにしておくほうがいいです。ブランチで解決しようとして苦労した経験があります。いい解放があれば、教えてほしい。
- >@methane:保守ブランチからcherry-pickで開発ブランチにもってくる。開発ブランチからマージをする。保守ブランチがx.1 , x.2とふたつあるなら、x.1 -> x.2 -> dev と一つずつ同じ事を行うイメージ。
- >>片方向へのマージは大丈夫なのですが、両方向にすると、煩雑になる。
- >>cherry-pickだと結局内容一緒でも違うコミットなので、それを補完する意味での空のマージをいれなければいけないということですね。
- >>気になる方は実際にちょっといじってみるといいと思います。
- TotoiseBzrのreverse cherry pick とはなにか？
- >逆パッチのこと。git revert, hg backout のようなこと。発行コマンドとしてあるわけではなく、GUI上の名前としてある。
他にもあった気はしますが、回答をおぼえていません。ごめんなさい。
僕から言える事
DVCSに関する情報はたくさんWebで共有されつつあります。
個人的にはGitはPro Gitを読めばだいたい書いてあっていつも役立つし、Hgは標準ヘルプが日本語訳されているのでだいたい事足ります。（ごめんなさい。Bazaarはまだ触っていないんだ。
DVCSで困ったら、サポーターの方達に質問のリプライやメールをしてみてください。きっと快く答えてくださいます。
特にHgであれば #mercurialjp ハッシュタグ付きでツイートしてみましょう。きっと何かの手助けになると思います。
重要なのは概念であって、コマンドリファレンスではないこと。
あくまでDVCSはSCMをするための一手段でしかないです。
管理しなければいけないものは何であるか、どうやって共有し、どうやって更新するか。それがSCMであると思っています。
闇LT
僕のは全然、闇じゃなかったわけですが。
本当はMercurialでhogehogeやってみたというのを発表しようと思っていましたが、明らかに会場ドン引きだと思ってやめました。
機会があればブログにするかもうちょっと濃い話をしても大丈夫そうな場所でやります。
あと、メイドさんがLTタイムリミットで「お時間です。ご主人様」と言っているのにpocketberserkerさんは「もうちょっと」とか言って発表続けてた。メイドの言う事は聞いてください＞＜
SCMBCでやりたいこと
本当はSCMをやりたいので、もっとSCMをやれるような演習テキストを用意することが課題だと思っています。
いくつか案はあって、何人かには相談しました。まぁもっといい案もでてくると思うのでもっと考えます。
どうでもいいこと
SCMBCとNagoya.Testing(プロセス入門編)で重要視しているのは「すぐに解決できるサポーターがいること」です。
つまり、課題に集中してほしいのです。もちろん、僕を含めたサポーターでどうにもならないことも、時間がかかることもあります。
でも、出来る限り、出来る限りでいいから、すんなりと課題に集中出来る環境を提供したいのです。
現実に、DVCSを使ったり、テストの設計をすればたくさんの質問、たくさんのトラブルが発生します。とくにDVCSはあるでしょう。つまり、採用したブランチモデルに沿ったワークフローがあり、そこでのミスもたくさんあります。それをササッと解きほぐす。
僕は他のDVCS勉強会に参加したことがありませんが、僕がSCMBCの今の形式に拘る(ある程度できるサポーターを6人以下に1人つける)のは、「入門ハンズオン勉強会には安心感(手詰まり感が少ないこと)が必要」だと思っているからです。
結構適当にやっているように見られるという自覚はあるし、僕はサポーターの方達の足下にも及ばないですが、出来るだけ良質な時間を提供できるようにしているつもりです。（あくまでつもり。
お弁当とスイーツが毎回出るのは、僕が食いしん坊だからです。
最後に
会場を貸していただいたニフティさん、Tシャツをプレゼントしてくださったアトラシアン様、参加してくださった皆様ありがとうございました。
