TDDBC 福岡
Nakayama Yuki
TDDBC福岡の現状について、一度まとめておきます。
-
【日程】
2011年3月19日(土)～2011年3月20日(日)
【プログラム】
1. 初日(TDD体験)
11:00~17:00予定
2. 懇親会
18:00~20:00予定
3. 宿泊
4. 2日目(SCM予定)
10:00~17:00予定
【会場】
サンピア福岡（ネット環境なし）
【定員】
40名
【参加方法と参加費】
1. 全部参加・・・15000円（初日と二日目昼食、二日目朝食込）
2. 初日+懇親会+二日目・・・10000円（初日と二日目昼食込）
3. 初日+二日目・・・5000円（初日と二日目昼食込）
-
基本的には名古屋と似たような感じになっています。
ただし、初日にアイスブレイクを入れる場合は10:00~にしようと思っています（要相談）。
講師の方々への交通費支給は20000~40000円を予定。
本当は参加費をもう少し抑えたかったのですが、講師人数が推定3~4名なので、このあたりが限界かと思われます。
宿泊用の部屋は4人1部屋×10をとりあえず押さえてあります。
宿泊のキャンセル料が1カ月前から発生するらしいので、宿泊込みでの募集は2月15日で打ち切る予定です。
イベント内容はSCMにする予定です（git担当の方から、お受けできそうだとのお返事をいただきました）。
以下、現在のTODOリストです。
【1/10,TODOリスト】
・イベント内容について打ち合わせ
・svn講師を探す（なお、hgは現在お返事待ち）
・アイスブレイクをどうするか
・告知ページの作成
・参加者募集（1月中に募集開始）
・スタッフ募集
・機材集め
このうちSVN、アイスブレイクに関してはtwitter上でも質問を行おうと考えています。
なお、今後決まったことは本ディスカッションに追加という形をとろうと思います。
以上、TDDBC福岡の現状についてでした。
よろしくお願いします。
秋猫
疑問に感じた点などがありましたので質問したいと思います。
１日目は他のTDDBCと同じような内容なのかなと思うのですが、
２日目のSCMとはどのような内容をお考えなのでしょうか？
個人的には、TDDとバージョン管理システムの組み合わせはというと、必ずしも必須とは思わないのです。
もちろん、個々のする事による恩恵を考えたらどちらも必ずやりましょう！って事にはなるのですが、
これはあくまで個々の有効性を考えたらという結果の考えになります。
TDDとバージョン管理システムは密に関係した開発手法ではなく、より良い開発をという目標への並行した手段だと思うのです。
じゃあ以前に「バージョン管理システムもあった方がいい」と言っていたのは？と思うかもしれませんが、
これはTDDBC名古屋に参加した際の感想としてもブログ( http://d.hatena.ne.jp/Akineko/20100714/1279090993
)の方にも書いたのですが、
レガシーコード改善をする際にはいつ壊れるかわからないので、バージョン管理システムでしっかりと管理していった方がいいのでは？という事でした。
なので、
「レガシーコード改善の為にはほぼ必須だと思うのでやりましょう！で、どうせやるのなら最初の方に簡単に使い方説明して少しずつでも実践してみましょ
う！」
という考えだったのです。
えーと、結局のところ何を言いたいのかと言うと、２日目はTDDの勉強というよりはSCMの勉強になってしまっていませんか？という事です。
もちろん内容次第だとは思いますので、冒頭でもお聞きした通り、どのような内容をお考えなのかお聞かせ願えますでしょうか？
Mercurialの講師を引き受けた身でもありますので、現状の考えもお聞きしておきたいですし、よろしくお願いします。
ここに書いた事はあくまで僕の考えであって、やる事に対する反論ではないですので萎縮しないで下さいね。
考えは人それぞれだと思いますし、中山さんのやりたい事の考えも聞きたいなと思ったので、
まずは僕はこう考えてるのですがどうでしょう？と書かせていただきました。
Twitterで時々見かける感じでは、１人で運営をやられてるようですし、内容についても悩んでるんじゃないのかなーと思いました。
見かけた時は忙しくて助け舟を出す事ができず、すみません。。。
１人で出来る事には限りがありますし、経験がない事に対しては全く思いつかないものもあると思います。
なので悩んだり迷ったりしているのでしたら、まずはここに書きこんで相談して見てください。
ここはその為のグループなので何も遠慮する事はありませんよー＾＾
以上、よろしくお願いします。
秋猫
連投すみませんorz
すごくどうでもいい事なのですが、
SCMはソフトウェア構成管理(Software Configuration Management)としての意味の方が広く使われているように思い
ますし、
バージョン管理システムの略称としてはVCS(Version Control System)の方がいいんじゃないのかなーとｗ
On 1月31日, 午後1:30, 秋猫 <kuusoumangek...@gmail.com> wrote:
> 秋猫です。
> 疑問に感じた点などがありましたので質問したいと思います。
>
> １日目は他のTDDBCと同じような内容なのかなと思うのですが、
> ２日目のSCMとはどのような内容をお考えなのでしょうか？
>
> 個人的には、TDDとバージョン管理システムの組み合わせはというと、必ずしも必須とは思わないのです。
> もちろん、個々のする事による恩恵を考えたらどちらも必ずやりましょう！って事にはなるのですが、
> これはあくまで個々の有効性を考えたらという結果の考えになります。
> TDDとバージョン管理システムは密に関係した開発手法ではなく、より良い開発をという目標への並行した手段だと思うのです。
>
> じゃあ以前に「バージョン管理システムもあった方がいい」と言っていたのは？と思うかもしれませんが、
Nakayama Yuki
追加事項などをまとめて投下します。
【講師陣】
@t_wadaさん
@bleisさん
@akinekoさん
@kaorun55さん
上記4名です。
ティーチングアシスタント事情も書いておいたほうがいいのですかね？
【2日目のプログラム】
2日目のイベント時間が下記に変更されました。
10：00～16：00
2日目の内容についてですが、個人的には以下のように考えていました。
・バージョン管理システム（VCS）が使えるは今必須スキルである
・ではTDDと組み合わせた場合（組み合わせなくても？）どのような恩恵が受け
られるか
・一言でVCSと言ってもコマンドや動作体系は各システムで違う
・ではTDDを行っている時に各VCSをどのように運用していけば、より良い開発が
行えるか
これらをもとに、午後はレガシーコードか何かに実装を追加したりする、という
ような順序です。
ただ、上記項目のいくつかは調べればわかることなので削り、レガシーコードの
話とセットにしたほうがいいのかな、と秋猫さんの言葉を見て思いまし た。
あとは、言語の制限なしだとVCS×言語数でペアが増えるので対応できるかどう
か、というのも悩みの種ではあります。
このあたりは自分には経験が全然ないので皆様のご意見を頂ければ幸いです。
（もっと早くからこの議論ができていればよかったのですが、先週までビジョン
すらほとんど見えていなかったので話を出せていませんでした。私の落 ち度で
す。）
【昼食の場所、会議室内での飲食】
昼食は施設内のレストランで行う、とのことでした。
また、会議室内は飲食禁止とのことです。
これに関しては早急に対応策を考えたいと思います。
【マイクロバス】
2日目終了後のホテルー最寄駅間のマイクロバスを手配しました。
16：30出発です。
【ポジションペーパー】
募集ページにも書きましたが、ポジションペーパーを導入します。
内容に関しては
・氏名 or twitterID or ハンドルネーム(参加登録時の名前)
・希望言語(複数可)
・希望SCM
・普段使っている言語(複数可)
・普段使っている開発環境、テスティングフレームワークなど
・好みのキーバインド
・その他(興味のあることや広めたいこと、講師や参加者に聞いてみたいことなど)
としています。
テンプレートを公開し、当日pdfデータで持参もしくは2日前までにメールで送付
する、という形をとろうと思っています。
今回の追加情報に関しては、以上です。
--
なかやん＠中山裕貴
mail:nakaya...@gmail.com
blog:http://d.hatena.ne.jp/pocketberserker/
twitter:http://twitter.com/pocketberserker
かおるん
みなさん
こんにちは
@kaorun55こと中村です
TDDBC福岡ではSVN講師を担当します。
午前中に中山さんからDをもらい、CSM改めVCSの講演の話がありました。
今回のイベントの主旨や話の流れをよく知らないので、いくつか疑問が出てきたので、
中山さん含め皆さんで議論したいと思います。
1,VCS講師の立ち位置
2,ここでの講演と当初依頼されてた時の講演は同じ？別？
3,別であれば、共通の講演の他に、VCSごとの講演がある？
4,そもそも中山さんとして、TDDBCにVCSを入れることで参加者の方に何を感じてほしい、
何を持ち帰ってほしいのかという想い。
・TDDBC全体としてのゴール
・2日目としてのゴールを知りたいです
5,和田さんから最初にお話をいただいたときに、TracなどBTSとの連携の話(チケット駆動のような)も
あったのですが、その辺りをどうするか。
今までの話の中でのことと重複することもあるかと思いますが、
思いつく限りのことをつらつらかきました。
以上、よろしくお願いします
Takuto Wada
TDDBC 二日目にバージョン管理を持ってこようというアイデアの発端は、 Twitter 上の議論だったかなと記憶しています
#tddbc イベント設計についての議論(9/24)
http://togetter.com/li/53162
これまでの全ての tddbc において、最初の講演で三本柱(バージョン管理、テスティング、自動化)の話をしてきました。ただ、そのあとの演習では主眼は
TDD とペアプロにあるので、バージョン管理は「あるものとして」進めてしまっているというところがあったと思います。
プログラミング言語と同じく、バージョン管理ツールも文化や環境毎に多様性があるので、 TDD
演習にこれ以上の不確定要素を持ち込めないかなと考えていたところもあります。各 SCM 毎の深みまで突っ込んでいく余力は TDDBC
一日目には無い、と判断したところがあります。あと、 git や hg ならローカルに環境を用意してもらうという選択肢もありますが、 svn
はどうするのというところもありました。ネットワーク的なリスク等も考えてのことです。
これまでの TDDBC では、二日目はレガシーコード改善を行い一定の成果を挙げてきましたが、ここらで SCM
に深く取り組んでみるのも面白いのではないか、という Twitter 上の議論は、魅力的に思えました。
二日目に SCM を試してみたい理由はもう一つありまして、それは TDDBC の私への依存度を減らす試みをしたい、というものです。
これまでの TDDBC では二日間共に私が牽引してきましたが、これはトラックナンバー/ハネムーンナンバーが1の状態そのものです。私が今後も引っ張っていくのは別に構わないのですが、今後の開催のバリエーションや、各地で第2回などを行っていく際に、常に私が全部牽引するというのは、イベントとしては健全な状態ではないと思うのです。なので、ここで過去の
TDDBC 参加者/主催者の方に講師として立っていただき、イベントとしてのバリエーション、多様性と価値を増すと共に、私への依存度を下げて
TDDBC としての継続性を上げる、という機会があっても良いのではないか、と考えました。開催者、登壇者、(そして参加者も)過去の TDDBC
経験者が多そうな TDDBC 福岡は、その試みにちょうど良い機会だと考えています。
なんか質問に全然答えていない上に私の思いばっかり書いていますが、とりいそぎ、以上です。
2011/1/31 かおるん <kaor...@gmail.com>:
おおたに かずのり
何となくですが、こんな場面が思い浮かびます。
--
なんらかの既存システムがある。当然、レガシーコード。
中央レポジトリはsvnでそれなりに管理されている。
ただ、ブランチはあまり使いこなせていないような気がするが、担当者は確信できない。
各メンバーでの管理は特に指定されていない。TortoiseSVNなんかを何となく使っている。
この状況で、チームに対して不具合改修や機能追加の依頼があった。
さて、どうしていく？
--
レガシーコード対策を基本として、複数のペア（2名じゃなくてもいいですが）が
同じシステムに対して別の変更を加え、最終的に一つにしてリリースするような場面です。
仕事でよくあるパターンだと思います。
こういうときに「コードをどう管理するのがスマートか」というのは、とても気になるところです。
そんな演習というか、ロールプレイングがあると面白いのかなーと思いました。
一日でそこまで詰め込めるか…難しそうですけど…。
2011年1月31日16:29 Takuto Wada <takut...@gmail.com>:
--
おおたに かずのり
mailto:katz...@gmail.com
http://d.hatena.ne.jp/katzchang/
http://twitter.com/katzchang/
中村薫
ちょっと話がそれますが、TwitterのTL上でTDDBCでSVNを入れる意味の話が出ていました。
僕も午前中にそのあたりのことを中山さんにメールしてましたので、僕の考えというところで
シェアします。
>>
2日目の流れが分からないのでなんとも言えないのですが、
参加者全員に対してTDDとSCMの話をするのであれば、
SVN(中央)とGit、hg(分散)は性質として異なると思うので、中山さんが
参加者に何を持って帰ってもらいたいかで、そもそもSCMが
変わってくるかと思います。
例えばRed、Greenごとなど、一歩一歩コミットするようなやりかたなら
コミットが速い分散の方が良いでしょうし、ある程度まとめてのコミット
であれば中央でも分散でもどちらでもといった具合です。
<<
以上
2011年1月31日16:59 おおたに かずのり <katz...@gmail.com>:
--
かおるん＠なかむら かおる
mailto:kaor...@gmail.com
blogto:http://d.hatena.ne.jp/kaorun55/
twitter:http://twitter.com/kaorun55
Oonaka Hiroyuki
今日のtwitter上での議論は以下にまとめてますので、ご参照ください。
--
大中浩行(せとあずさ)
az...@fieldnotes.jp
ikikko
はじめまして。ikikkoと申します。
# 本名は中村ですがkaorunさんとごっちゃになるので、ikikkoで通させてください
TDDBCは東京のみの参加でした。
少し話に上がったので、現状確認 兼 提案を。
私はNulabという福岡本社の会社に所属しており、
弊社ではBacklogというBTS+SVNの製品を取り扱っています。
（ご存じの方もいるでしょうが）
http://www.backlog.jp/
ちょこちょこ話があがっているように
内部ネットワーク内にサーバを建てるのももちろんありでしょうが、
手軽に環境構築できて、後からネット上のサーバにアクセスして復習するのに
Backlogといったサービスを使うのもありかと思っています。
ということで、
・インターネットが繋がっている（基本ASPの製品なので）
・SVN
という前提ならば協力できるかもしれません。
もしBacklogを利用したいその他意見があれば、ご連絡ください。
# なお、最善は尽くしますが都合上協力できないということも考えられますので
# その点はご容赦ください
以上、よろしくお願いします。
おおたに かずのり
福岡はネットワークがつながらないようなので、難しそうですね。
毎度無茶ぶり、申し訳ない……。
個人用途であればgithubなりbitbuscketなりを使えばいいと思いますが、
現状、お仕事での中央レポジトリはやはりsvnが鎮座していると思います。
SCMについて語るのであれば、svnは欠かせない。
もちろん、自分たちで用意するのはそんなに難しいことではないですが、
ネットワークがつながる環境であれば、外部のサービスを使ってみるっていうのは
面白いと思っています。
環境を構築する人がイベント開始直前に「やばい、つながらない……！！」とか青い顔する
危険性が減るし。イベントで内部ネットワークの構築とか、色々とトラブルが起こりそう。
もちろん、スタンドアローンでも扱えるけど、面白みが半減するような気がします。
福岡でsvnを内容に組み込むとしたら、ネットワークとサーバ構築はあった方がいい…でしょうね。
2011年2月1日1:33 ikikko <iki...@gmail.com>:
--
Nakayama Yuki
2日目で何を伝えたいかについて、ちょっと「伝えたいこと」からは外れるかも
しれませんが記述しておきます。
私がTDDBCで伝えたい（と勝手に考えている）ことは「安心してコードを実装
（改善）していくにはどうすればよいか」です。
これに関しては、TDDやペアプロ（あるいは乱取り形式）を行うことで伝わると
は思います。
ただ、名古屋に参加した時に思ったのですが、講演で言及された中でVCSだけが
「あるものとして」扱われていたように感じました。
また、VCS自体やコマンドを知らないことでペアの方に負担をかけてしまった、
ということもありました。
（ちなみに、私は当時cvsを少し触ったことがある程度だったので、前者に該当
しました）
そんな中、Twitter上で2日目についての議論でVCSの話がでていたので「これは
面白そうだ」と思って相談したのが企画初期の頃です。
「VCS基礎+レガシーコード改善」で行うのがベストなのかもしれませんが、これ
は福岡では明らかに時間が足りません。
そこで今回は試験的に、（少なくとも表向きには）レガシーコードをはずしてみ
るのもアリかな、と考えました。
代替案としては「一日目の追加課題＋VCS」が妥当ではないかと考えています。
これについての問題はVCS×言語数分の環境が用意できるかどうか、です。
あとBTSの話ですが、これは名古屋で「スライドが移動していて仕様の書かれた
ページが見えない、どうしよう」と思ったことがあるためです。
Wikiでも構わないかもしれないですが、仕様などをあらかじめチケットで管理し
ておけば楽かなと考えました。
話が横道にそれてしまっている気もしますが、以上です。
--
なかやん＠中山裕貴
mail:nakaya...@gmail.com
Shuji Watanabe
福岡でバージョン管理を扱うことについては和田さんからも聞いていました。
札幌でも少しやろうかなとも思いましたが、結局は扱っていません。
ただ、デモをJava＋Eclipseでやったのですが、その時にほぼ思いつきでMercurialを使っています。
さて、本題ですが、自分としてはバージョン管理をTDDBCに組み込む事自体には賛成です。
ただ、何を伝えていくかという点にブレがなければという話です。
中山さんの言うように「安心してコードを実装 （改善）していくにはどうすればよいか」を伝えたいのであれば、
確かにバージョン管理は1つの大きな柱であることは間違いないでしょう。
しかし、個人的には丸１日使うテーマか？と思います。
テスト駆動開発に関しては想像も付きにくいですから、実際に体験するのが一番と思います。
バージョン管理についても実際の運用では色々な場面が想定されますし、様々なテクニックやノウハウがあると思います。
ですが、大きな違いが１つあると思います。
それはバージョン管理は「とりあえず使ってみようぜ」でも十分な効果があるという事です。
それならば、ちょっとだけGUIの使い方をレクチャーすればいいではないでしょうか？
帰って本格的に学ぶためのコマンドラインツールを覚えるのは良いことですが、
TDDBC時にコマンドラインでやる必要あるでしょうか？
IDEやGUIのツールを使って、特定のSCMに絞って、基本操作だけをレクチャーして「使ってみる」が良いのではないでしょうか？
自分として感じた点はそんな所です。
バージョン管理のノウハウとスキルを学ぼうではなく、使ってみようが重要かなと。
参考になれば幸いです。
2011年2月1日22:30 Nakayama Yuki <nakaya...@gmail.com>:
--
================================
Shuji Watanabe (skypeId: shuji.w6e)
Blog:
http://d.hatena.ne.jp/shuji_w6e/
Labo:
http://www.deathmarch.jp/
Community:
http://www.sapporo-java.org/
おおたに かずのり
> しかし、個人的には丸１日使うテーマか？と思います。
について、これは私も最初に思いました。
初級者向け内容も悪くはないですが、厳しいことを言うと、
コミットやアップデート程度であれば「2日目は行かなくてもいいかな…」と思ってしまいます。
でも今回の参加は1日目・2日目がセットな様子。これがちょっと苦しい。
それなりの経験者も集まるだろうと思うので、
もしかして、1日目参加者の顔ぶれやレベル感を踏まえて2日目の内容を調整していくような
エクストリームな対応が求められるかも知れません。（こういう部分もまた楽しいところですが…ｗ
でー、Twitterにも書きましたが、例えば
>SCMとフォルダコピー管理の違いはどこにある？（という質問にどう答える？
というのは、初級者に示すゴールの一つだと思うわけです。
「なぜSCMが三本柱の一つなのか？」という質問でも同じです。
そして、ゴールまでの道のりを1日でどこまで体験してもらうことができるかというのは、
むしろ講師が考えることかも知れません。中山さんは未経験、見積もりは難しいでしょうし。
受講者は中山さんを想定し、内容は講師が考える。
イベントとしてのゴールは「自分で学習を進めるための起爆剤」というのが"Boot Camp"らしいかなーと思います。
結果的に「コマンドの習得は簡単だから事前にやっておいてね」と結論づけるのも、また良しだと思っています。
（そういうブログ記事をまとめてブクマを集めてもいいんじゃね？という意味でも）
以下は細かい話です：
>これについての問題はVCS×言語数分の環境が用意できるかどうか、です。
中央にsvnを用意するのであれば、一つサーバにレポジトリを複数立てれば問題ないはずです。
git/hgは無論、問題ないですよね。
（gitやhgで「中央レポジトリ」をどう管理するかというのも、個人的には知りたい部分ではあります）
>あとBTSの話ですが、これは名古屋で「スライドが移動していて仕様の書かれた ページが見えない、どうしよう」と思ったことがあるためです。
チケット駆動開発の場合「そのチケットの担当者を決めて、その人の対応が終わったらクローズして…」となるので、
同じ課題を複数が並行してチャレンジするという場面には向いていないかも知れません。
プリンタを用意できれば紙に印刷して配ったり、ホワイトボードに書きだしておいたりみたいな、
シンプルなやり方が良さそうです。
2011年2月1日22:54 Shuji Watanabe <shuj...@gmail.com>:
--
Takeshi Kakeda
すべてのコンテキストを理解しておりませんが、このスレッドについての意見を述べさせて頂きます。
まずTDDBCの一番の価値は何かを考えてみたいと思います。
ちなみ私は第一回にアシスタント役で参加したに過ぎませんので、2Days版は話にしか聞いておりません。
私にとってTDDBCの最大の価値は、日本のNo.1エバンジェリストである和田さんから直接TDDの
解説とそのメソッドに乗っ取った演習を体験できるという点です。
2 days版では、1日目がその部分に当たるのかと思います。
2日目にレガシーコード改善を持ってきている、というのは狙いとしては、
TDDの心は1日目で体感した。しかし実際の現場ではレガシーコードがまっている。
新規でTDDでできればよいが、なかなかその機会もない。悪い設計をテスト容易性の観点で
良くしながら進むプロセスは非常に実践的である。
またレガシーコード改善は、新規開発よりも、より慎重に一歩一歩進まないといけない。
TDDの細かいフィードバックサイクルを身体に染み込ませるためには、新規開発をTDDで作って
いくよりも、レガシーコードを改善するほうがより深く体験できる。
という感じでしょうか。
他方、SCM(私はVCS以前からSCMという言葉を使っていたのでこちらの方が馴染んでます)を絡める
ケースの狙いとしては...
TDDは非常に小さなフィードバックサイクルの連続である。そのプロセスにおいてSCMへのコミットタイミングや
ブランチの使い方は、非常に密接に関わってくる。TDDをより実践的に行う上で、SCMとの連携は切っても
切れない。特にDSCMを効果的に使ったTDDは、そのプロセスを大幅に強化し、より理想的なTDDを体験する
ことができる。またコードの共同所有という観点で、チームでどうTDDで開発するか、という体験も兼ねる。
という感じでしょうか。
いずれも、非常にTDDを体験する上で大事な点ではありますが、限られた時間の中での選択肢としては
ターゲットを絞る必要性があります。
前者のレガシーコード改善は、どちらかというと、実際のプロジェクトでTDDを導入したい、既存のソフトウェア
をTDDでより良くしたい人向けと思います。後者のSCM連携は、これから新規のプロジェクトを始める際に、TDDで
理想的に進めたい人向けに近いと感じます。
両者を混ぜるというスタンスもありだとは思いますが、対象者のレベルによっては、無理が生じてしまう可能性も
あるかと感じます。特に初心者だとその傾向が強いでしょうね。
理想的には、1度目のTDDBCは、初日は和田さん、二日目は開催主催者の想い&対象者によってのカスタマイズという
スタイルがよいでしょうね。
ちなみに松山でやる場合は、二日目はより初心者向けという観点から、レガシーコード改善なのかな、と漠然と考えています。
(素材次第ですが...)
以上です。
2011年1月31日17:32 中村薫 <kaor...@gmail.com>:
--
Best regards,
-Takeshi Kakeda
twitter: kkd
web: http://giantech.jp
秋猫
えと、みなさんが本名だされているので一応名乗っておくと清水です。
別に隠す気などそういったのは特にないのですが基本的に秋猫で活動しているので、以降も秋猫でやりたいと思います。
（僕の周りではVCSと呼んでいる人が多かったのでこっちの方がいいのでは？と思ったのですが結局どっちがいいのか…）
SCMをTDDBCに取り入れるのは僕も賛成ですし、
書き込みやTwitterを見た感じではみなさんも反対はないように思います。
ですが、既にあがっている通り１日やる内容ではないように思いますし、
仮に内容を詰めたとしてもそれはもうTDDBCではなく、ただのSCMの勉強会になってしまうのではないかなと。
もちろん、TDDBCという枠にとららわれずにSCMについてしっかりと伝えたいんだ！と言うならばそれはそれでありかと思います。
個人的には中山さんが書かれていた、
＞ ただ、名古屋に参加した時に思ったのですが、講演で言及された中でVCSだけが「あるものとして」扱われていたように感じました。
＞ また、VCS自体やコマンドを知らないことでペアの方に負担をかけてしまった、ということもありました。
＞ （ちなみに、私は当時cvsを少し触ったことがある程度だったので、前者に該当しました）
という事を同じく名古屋で参加した時に感じましたので、SCMについて最低限の
初期化 ・ 管理下への追加 ・ コミット ・ 履歴の表示 ・ 過去へ戻る
あたりをレガシーコード改善を行う前に軽く説明してみんなで使ってみる、
というのがSCMを取り入れる無理のない範囲なのかなと。
と、思っていたんですがTwitter上の議論がまとめられたTogetterを見たら、これはこれで面白そうだなやってみたいなという思いもありま
す。
とかまぁいろいろと思っている事は書いてみたのですが、思いを言ってるだけでは決まらないので
まずは 「SCMについて参加者の想定レベル または 事前に準備してもらうこと」 をどうするのか決めてはどうでしょうか？
で、そのレベルから１日で教えれる範囲を考えるのが早いと思います。
僕としては、大分広まってはいますが、SCMの特に分散型はまだまだみんなが使えるというほど広まってはいないのかなと感じます。
なので想定レベルは「全くの初心者」で、事前に準備してもらうことは「使いたいバージョン管理システムのインストール」かなと。
以上です。
> 2011年1月31日17:32 中村薫 <kaoru...@gmail.com>:
>
> > 中村です
>
> > ちょっと話がそれますが、TwitterのTL上でTDDBCでSVNを入れる意味の話が出ていました。
> > 僕も午前中にそのあたりのことを中山さんにメールしてましたので、僕の考えというところで
> > シェアします。
>
> > 2日目の流れが分からないのでなんとも言えないのですが、
> > 参加者全員に対してTDDとSCMの話をするのであれば、
> > SVN(中央)とGit、hg(分散)は性質として異なると思うので、中山さんが
> > 参加者に何を持って帰ってもらいたいかで、そもそもSCMが
> > 変わってくるかと思います。
>
> > 例えばRed、Greenごとなど、一歩一歩コミットするようなやりかたなら
> > コミットが速い分散の方が良いでしょうし、ある程度まとめてのコミット
> > であれば中央でも分散でもどちらでもといった具合です。
> > <<
>
> > 以上
>
> > 2011年1月31日16:59 おおたに かずのり <katzch...@gmail.com>:
> >> 大谷です。大雪です。
>
> >> 何となくですが、こんな場面が思い浮かびます。
>
> >> --
> >> なんらかの既存システムがある。当然、レガシーコード。
> >> 中央レポジトリはsvnでそれなりに管理されている。
> >> ただ、ブランチはあまり使いこなせていないような気がするが、担当者は確信できない。
> >> 各メンバーでの管理は特に指定されていない。TortoiseSVNなんかを何となく使っている。
>
> >> この状況で、チームに対して不具合改修や機能追加の依頼があった。
> >> さて、どうしていく？
> >> --
>
> >> レガシーコード対策を基本として、複数のペア（2名じゃなくてもいいですが）が
> >> 同じシステムに対して別の変更を加え、最終的に一つにしてリリースするような場面です。
> >> 仕事でよくあるパターンだと思います。
>
> >> こういうときに「コードをどう管理するのがスマートか」というのは、とても気になるところです。
> >> そんな演習というか、ロールプレイングがあると面白いのかなーと思いました。
>
> >> 一日でそこまで詰め込めるか…難しそうですけど…。
>
> >> 2011年1月31日16:29 Takuto Wada <takuto.w...@gmail.com>:
> >>> 和田(@月末ェ…)です
>
> >>> TDDBC 二日目にバージョン管理を持ってこようというアイデアの発端は、 Twitter 上の議論だったかなと記憶しています
>
> >>> #tddbc イベント設計についての議論(9/24)
> >>>http://togetter.com/li/53162
>
> >>> これまでの全ての tddbc において、最初の講演で三本柱(バージョン管理、テスティング、自動化)の話をしてきました。ただ、そのあとの演習では主眼は
> >>> TDD とペアプロにあるので、バージョン管理は「あるものとして」進めてしまっているというところがあったと思います。
>
> >>> プログラミング言語と同じく、バージョン管理ツールも文化や環境毎に多様性があるので、 TDD
> >>> 演習にこれ以上の不確定要素を持ち込めないかなと考えていたところもあります。各 SCM 毎の深みまで突っ込んでいく余力は TDDBC
> >>> 一日目には無い、と判断したところがあります。あと、 git や hg ならローカルに環境を用意してもらうという選択肢もありますが、 svn
> >>> はどうするのというところもありました。ネットワーク的なリスク等も考えてのことです。
>
> >>> これまでの TDDBC では、二日目はレガシーコード改善を行い一定の成果を挙げてきましたが、ここらで SCM
> >>> に深く取り組んでみるのも面白いのではないか、という Twitter 上の議論は、魅力的に思えました。
>
> >>> 二日目に SCM を試してみたい理由はもう一つありまして、それは TDDBC の私への依存度を減らす試みをしたい、というものです。
>
> >>> これまでの TDDBC では二日間共に私が牽引してきましたが、これはトラックナンバー/ハネムーンナンバーが1の状態そのものです。私が今後も引っ張っていくのは別に構わないのですが、今後の開催のバリエーションや、各地で第2回などを行っていく際に、常に私が全部牽引するというのは、イベントとしては健全な状態ではないと思うのです。なので、ここで過去の
> >>> TDDBC 参加者/主催者の方に講師として立っていただき、イベントとしてのバリエーション、多様性と価値を増すと共に、私への依存度を下げて
> >>> TDDBC としての継続性を上げる、という機会があっても良いのではないか、と考えました。開催者、登壇者、(そして参加者も)過去の TDDBC
> >>> 経験者が多そうな TDDBC 福岡は、その試みにちょうど良い機会だと考えています。
>
> >>> なんか質問に全然答えていない上に私の思いばっかり書いていますが、とりいそぎ、以上です。
>
> >>> 2011/1/31 かおるん <kaoru...@gmail.com>:
> >>>> 中山さん
> >>>> みなさん
> >>>> こんにちは
>
> >>>> @kaorun55こと中村です
> >>>> TDDBC福岡ではSVN講師を担当します。
>
> >>>> 午前中に中山さんからDをもらい、CSM改めVCSの講演の話がありました。
> >>>> 今回のイベントの主旨や話の流れをよく知らないので、いくつか疑問が出てきたので、
> >>>> 中山さん含め皆さんで議論したいと思います。
>
> >>>> 1,VCS講師の立ち位置
> >>>> 2,ここでの講演と当初依頼されてた時の講演は同じ？別？
> >>>> 3,別であれば、共通の講演の他に、VCSごとの講演がある？
> >>>> 4,そもそも中山さんとして、TDDBCにVCSを入れることで参加者の方に何を感じてほしい、
> >>>> 何を持ち帰ってほしいのかという想い。
> >>>> ・TDDBC全体としてのゴール
> >>>> ・2日目としてのゴールを知りたいです
> >>>> 5,和田さんから最初にお話をいただいたときに、TracなどBTSとの連携の話(チケット駆動のような)も
> >>>> あったのですが、その辺りをどうするか。
>
> ...
>
> もっと読む ≫
中村薫
かおるんです
話が環境の方にそれますが、当日は空きPCを借りるような話がありましたので、
そこにTracLightningを入れておいたらどうでしょうか？
http://sourceforge.jp/projects/traclight/wiki/FrontPage
TracLightningであれば、Trac(BTS),SVN(VCS),Wiki(Trac付属),Hudson(CI)など必要なものはそろいますし、
チームごとにプロジェクトを作ることも簡単です。
またhgであればhglightというTracLightningでhgを使うためのインストーラもありますし、git環境も
今作ってる(未確認)ようなので、それがあれば今回の要求は満たせるような気もします。
＃redmineがいいとか細かい話は別途対応するとしてw
http://sourceforge.jp/projects/shibuya-trac/wiki/hglight
せとさんからWikiのご提案がありましたので、あわせてご検討ください
以上
2011年2月2日21:07 秋猫 <kuusoum...@gmail.com>:
--
Nakayama Yuki
本名のほうが浸透している気がするので、私は本名で通したいと思います。
SCMについて参加者の想定レベルと事前準備ですが、基本的に秋猫さんの
『「全くの初心者」を想定し、「使いたいバージョン管理システムのインストー
ル」を事前準備してもらう』
に同意見です。
余裕のある人はコマンドを調べておく、というのもつけるかもしれません。
（GitとMercurialについては基礎最速マスターのエントリを紹介しようと思います）
空きPCの件ですが、イベント時に中央サーバとして使う予定のPCを確保しました。
TracLightingは良さそうですね（Tracを使ったことがないので希望的観測）。
Redmineしか触ったことがないですが、この際なので勉強します。
OSはFedoraの予定です（特にこだわりはないので別のOSでもいいです）。
「これいれてほしい」などの要望がありましたらご連絡ください。
以上です。
--
なかやん＠中山裕貴
mail:nakaya...@gmail.com
Nakayama Yuki
ようやく身動きが取れる状況になったので、状況整理も兼ねて。
【１日目】
- あいさつ(５分程度)
- TDD講演（～12:00）
- お昼(12:00～13:00)
- 実習(13:00～18:00、途中休憩を含む)
- 懇親会(18:00～20:00)
基本的に名古屋と似たような感じです。
講演や練習問題考案など、和田さんに依存している部分が多いのでちょっと申し
訳ない気分だったりします…。
TAに関してはbleisさん、秋猫さんにお願いしています。
【２日目】
- バージョン管理システム講演(10:00～12:00?)
- お昼(12:00～13:00)
- 実習(13:00～16:00)
内容に関しては初心者を対象にSCMとTDDの連携について・・・と考えていましたが、
午前にどういった話をするのか(あと講演を担当してくださる方)を含めて要検討
です。
【希望言語(複数回答可)】
現状では以下の通りです。
・ Java １０
・ C# 4
・ VB 2
・ OCaml 4
・ PHP 2
・ Ruby 4
・ JavaScript 2
・ C++ 1
・ Scala 2
・ Python 1
ペアが１組以上できればいいという考え方で行こうと思っています。
（ペア組み替えは参加人数が少ないので難しい気がします）
【第１希望SCM】
現状は以下の通りです。
・ Git 14
・ Mercurial 1
・ Subversion 1
Gitが無双しすぎていてどうしようか迷っています。
言語との兼ね合いを考えて、数名第２希望にまわって頂くのが妥当なのですかね。
【その他】
ポジションペーパーのテンプレートは近日公開予定です。
中村薫
中村です
希望言語、SCMや内容を見ていて、補助の講師はbleisさん、秋猫さんで十分なのかな
という気になってきました。
＃あまりお役に立てることがないような＾＾；
あ、後ろ向きな発言ではなく、内容が煮詰まってきて方向性が見えてくたところで
変化があるのは自然なことだと思っていて、その変化に対してどうしましょうか？
いうような感じです。
Git無双はそれはそれでいいような気がして、hgとSVN希望の人がGitでもOKなようなら
いっそGitオンリーでもいいのかなと思います。
SCMを統一したほうがハプニングも少ないでしょうし、おなじGitを使っても
各チームで「使い方」は違うと思うので、より踏み込んだ議論ができるのかなー
なんて思ったりします。
2011年2月27日22:54 Nakayama Yuki <nakaya...@gmail.com>:
--
秋猫
秋猫です
SCMについては僕も中村さんと同じで他SCMが１人ずつしかいないのでしたら、
無理に他SCMを取り入れるよりはGitに統一してしまった方が教え合う事ができますし、
講演の時間も取れるので初心者向け講座を複数やるよりも、より良い内容が出来るのではないかなと思います。
で、その場合の提案なのですが、今のSCMの講演時間10:00～12:00を
10:00～11:00（または10:00～10:50+10分休憩） bleisさんによるGitの講演
11:00～11:30 僕or中山さんのTDDについての講演
11:30～12:00 僕or中山さんのTDDについての講演
にするというのはどうでしょうか？
bleisさんの負荷が高くなりますし、中山さんも代案を考えなければなので、
SCMをGitに統一することと合わせて、みなさんがOKでしたらの提案ではありますが＾＾；
On 2月28日, 午後12:59, 中村薫 <kaoru...@gmail.com> wrote:
> こんにちは
> 中村です
>
> 希望言語、SCMや内容を見ていて、補助の講師はbleisさん、秋猫さんで十分なのかな
> という気になってきました。
> ＃あまりお役に立てることがないような＾＾；
>
> あ、後ろ向きな発言ではなく、内容が煮詰まってきて方向性が見えてくたところで
> 変化があるのは自然なことだと思っていて、その変化に対してどうしましょうか？
> いうような感じです。
>
> Git無双はそれはそれでいいような気がして、hgとSVN希望の人がGitでもOKなようなら
> いっそGitオンリーでもいいのかなと思います。
> SCMを統一したほうがハプニングも少ないでしょうし、おなじGitを使っても
> 各チームで「使い方」は違うと思うので、より踏み込んだ議論ができるのかなー
> なんて思ったりします。
>
> > twitter:http://twitter.com/pocketberserker
>
> --
> かおるん＠なかむら かおる
Takuto Wada
みなさん議論ありがとうございます。 TDDBC が私への依存を確実に減らしてきていることを実感できて、とても嬉しいです。
で、 Git 無双はちょっと予想できていなかったですね…
> SCMについては僕も中村さんと同じで他SCMが１人ずつしかいないのでしたら、
> 無理に他SCMを取り入れるよりはGitに統一してしまった方が教え合う事ができますし、
> 講演の時間も取れるので初心者向け講座を複数やるよりも、より良い内容が出来るのではないかなと思います。
>
中村さんと秋猫さんのご意見、なるほどと思います。
他の皆さんの意見もお聞きしたいところです。
> で、その場合の提案なのですが、今のSCMの講演時間10:00～12:00を
>
> 10:00～11:00（または10:00～10:50+10分休憩） bleisさんによるGitの講演
> 11:00～11:30 僕or中山さんのTDDについての講演
> 11:30～12:00 僕or中山さんのTDDについての講演
>
> にするというのはどうでしょうか？
> bleisさんの負荷が高くなりますし、中山さんも代案を考えなければなので、
> SCMをGitに統一することと合わせて、みなさんがOKでしたらの提案ではありますが＾＾；
>
これは、中山さんでなくて中村さん(かおるんさん)でしょうか?
例えば秋猫さんとかおるんさんが、それぞれ TDD や SCM (や ITS)
に関してどう考え、どういうことをやっているかを講演していただけるのは素晴らしいと思いますし、私もお聴きしたいです(午前の枠を伸ばしても良いかなと思えるくらい)。なので、代案としてのこの案は、非常に魅力的に見える、と言っておきます。
とりいそぎ。
秋猫
> これは、中山さんでなくて中村さん(かおるんさん)でしょうか?
はい、中村さんと間違えていました。。。orz
中山さん、中村さん、申し訳ありませんでした。
bleis-tift
秋猫さんの案、面白そうですね！
宿泊なしの参加者も Git ばかりになるかはまだわかりませんが、
この比率なら確かに Git 一本に絞ったほうがいいような気がします。
その場合問題になりそうなのが、対象とする人のレベルでしょうか。
* バージョン管理知らない
* 集中型を使っている
* 分散型を使っている
くらいに分かれると思うんですが、集中型を使っている、
という前提は置いてもいいものかどうなのか・・・
一日目に関しては、C#、VB、Scala、OCaml あたりのアシスタントをしようと思います。
OCaml は TDDBC 名古屋参加者の mzp さんがいるので、わりと何とかなりそう。
それにしても OCaml 4 人・・・
あと今週いっぱいは本業が忙しくてあまりこちらに書き込めないかもしれません。
以上です。
On 2月28日, 午後2:58, 秋猫 <kuusoumangek...@gmail.com> wrote:
> 秋猫です
>
> > これは、中山さんでなくて中村さん(かおるんさん)でしょうか?
>
> はい、中村さんと間違えていました。。。orz
>
> 中山さん、中村さん、申し訳ありませんでした。
>
> On 2月28日, 午後1:55, Takuto Wada <takuto.w...@gmail.com> wrote:
>
>
>
>
>
>
>
> > 和田です
> > みなさん議論ありがとうございます。 TDDBC が私への依存を確実に減らしてきていることを実感できて、とても嬉しいです。
>
> > で、 Git 無双はちょっと予想できていなかったですね…
>
> > > SCMについては僕も中村さんと同じで他SCMが１人ずつしかいないのでしたら、
> > > 無理に他SCMを取り入れるよりはGitに統一してしまった方が教え合う事ができますし、
> > > 講演の時間も取れるので初心者向け講座を複数やるよりも、より良い内容が出来るのではないかなと思います。
>
> > 中村さんと秋猫さんのご意見、なるほどと思います。
> > 他の皆さんの意見もお聞きしたいところです。
>
> > > で、その場合の提案なのですが、今のSCMの講演時間10:00～12:00を
>
> > > 10:00～11:00（または10:00～10:50+10分休憩） bleisさんによるGitの講演
> > > 11:00～11:30 僕or中山さんのTDDについての講演
> > > 11:30～12:00 僕or中山さんのTDDについての講演
>
> > > にするというのはどうでしょうか？
> > > bleisさんの負荷が高くなりますし、中山さんも代案を考えなければなので、
> > > SCMをGitに統一することと合わせて、みなさんがOKでしたらの提案ではありますが＾＾；
>
> > これは、中山さんでなくて中村さん(かおるんさん)でしょうか?
> > 例えば秋猫さんとかおるんさんが、それぞれ TDD や SCM (や ITS)
> > に関してどう考え、どういうことをやっているかを講演していただけるのは素晴らしいと思いますし、私もお聴きしたいです(午前の枠を伸ばしても良いかなと思える くらい)。なので、代案としてのこの案は、非常に魅力的に見える、と言っておきます。
Nakayama Yuki
秋猫さんの案、とても魅力的ですね！
比率もそうですが、より踏み込んだ内容にしたいと考えるとGitに一本化したほ
うがよさそうですね。
hg,svn希望の方の第２希望SCMがGitなので、お願いすれば了承していただけるか
もしれません。
いずれにせよ、私の独断では決められないので、OKを頂ければという話ではあり
ますが・・・
対象とする人のレベルですが、難しいところですね・・・
たぶん「集中型を使っている」を想定して問題ないとは思うのですが、
念のため参加者に確認をとりたいと思います。
以上です。
Nakayama Yuki
hg,svn希望の方に連絡をとったところgitでもOKとのことでしたので、
SCMはGitに一本化することにしました。
というわけで、2日目午前は秋猫さんの案を採用したいと思っているですが、講
師の皆様いかがでしょうか？
【2日目午前（再掲）】
10:00～10:50+10分休憩 bleisさんによるGitの講演
11:00～11:30 秋猫さんor中村さんのTDDについての講演
11:30～12:00 秋猫or中村さんのTDDについての講演
2日目午後の実習なのですが、私がぱっと思いついたのは以下の2パターンです。
１：新しい課題についてGit＋TDD
２：一日目の課題を軸にGit＋TDDで機能追加
１は基本的に一日目にGitを加えた状態です。
欠点としては、基本一日目の焼きまわしなので少し退屈になるかもしれないこと
です。
２は一日目の課題にさらに仕様追加・変更を行う形です。
こちらの欠点は各言語のデータをすべて事前に用意しなければならないことです。
そういえば、講師賞などはあったほうがいいでしょうか？
今のところほとんどの地域で参加賞か講師賞があったと聞いているので、ちょっ
と気になりました。
--
なかやん＠中山裕貴
mail:nakaya...@gmail.com
bleis-tift
秋猫さんの案の採用に賛成一票で。
二日目午後の案 2 ですが、前日のものをそのまま使えばいいと思います。
一日目の仕様を全部実装できていなくても、続きをやってもらうというのもいいでしょうし。
その場合、ペアや言語によってかなり進み方に差が出るような気がするので、
二日目はペア交代できる言語のグループがあってもペア交代しない方がいいのかな。
参加賞/講師賞については、やはり t-wada 賞は欲しいな、と思います。
今回の形式だと、二日目も何らかの賞があった方がいいのかな、と思うので、
贈呈用の本をいくつか持っていきましょうか？
課題に関しては、最近作ったツールがいいかなー、というのがあるのですが、
ちょっと大きすぎるような気もします。
この ML は基本オープンな場所なので、ネタバレを避けるために
* 中山さん
* 和田さん
* 中村さん
* 秋猫さん
に後で直接メールを送っておきます。
以上です。
秋猫
2日目の案は発案者でもありますし賛成でｗ
現在仕事がデスマーチ気味なので資料がちゃんと作れるか微妙ですが、
内容についての考えはまとまっていますので、一応そのつもりで少しずつでも進行しときますね。
講師賞については僕も t-wada賞 は最低でも欲しいですね。
送っていただいた課題についてはちゃんとは見れてないですが、
ざっと見た感じではいい課題だと思います。
以上、最低限の要件のみですみませんがよろしくおねがいします。
Takuto Wada
こちら、きちんと ML に返答していませんでしたね。申し訳ありません。
bleis さん、秋猫さんの案に賛成です。
そして t-wada 賞を何か持っていきますね。
以上です。ではまた。
2011/3/9 秋猫 <kuusoum...@gmail.com>: