トップ > etc

遅延評価ってなんなのさ

etc

何なんでしょうね。分かりません。
自分の頭の中をとりあえず整理するためのエントリなので、あなたの頭を混乱させるだけになるかもしれません。
もし混乱してしまったら忘れてください。え、無理？忘れてください。


自分の考えを明確にしたので、こちらをどうぞ。
遅延評価いうなキャンペーンとかどうか - ぐるぐる～

これは遅延評価ですか？

関数を渡すだけ
// Scala
def hoge(f: Unit => Int) =
  for (i <- 1 to 2) println(f())

(* F# *)
let hoge f =
  for i in 1..2 do printfn "%d" (f())

この関数に渡す f は 2 回実行されます。そのため、f の中で画面出力をしていた場合、2 回出力されます。
これは遅延評価でしょうか？俺は違うと思います。
ここは多くの人で合意が取れると思ってます。

Scala の名前渡し
def hoge(x: => Int) =
  for (i <- 1 to 2) println(x)

この hoge に対して、

hoge { println("hoge"); 10 }

と呼び出すと、hoge が 2 回呼び出されます。
これは遅延評価でしょうか？俺は違うと思います。
が、これを遅延評価と呼ぶ人もいるかもしれません。

IEnumerable 的なもの
(* F# *)
let hoge f =
  seq { for i in 1..10 -> f i }

let xs = hoge (fun i -> printfn "hoge"; i)
xs |> Seq.iter (printfn "%d")
xs |> Seq.iter (printfn "%d")

// C#
static IEnumerable<int> Hoge(Func<int, int> f)
{
    for (int i = 0; i < 10; i++)
        yield return f(i);
}

// ...

var xs = Hoge(x => { Console.WriteLine("hoge"); return x; });
foreach (var x in xs)
    Console.WriteLine(x);
foreach (var x in xs)
    Console.WriteLine(x);

これを実行すると、10 回ではなく 20 回 hoge が出力されます。
これは遅延評価でしょうか？俺は違うと思います。
でも IEnumerable 的なものを遅延評価とする人は多いような気がします。
これを遅延評価と呼ぶ場合、何が遅延評価されているのでしょうか？
シーケンスの値である「関数」自体は渡すときにもう評価されているので違いますよね。
ではシーケンスの値として取り出す要素でしょうか？
でもそれを遅延評価と言ったら、一番最初の「関数を渡すだけの例」も遅延評価と呼ばないとおかしくありません？

F# の lazy
(* F# *)
let hoge (Lazy x) =
  x |> ignore
  x

hoge (lazy (printfn "hoge"; 10))

これを実行すると、hoge は 2 回ではなく 1 回しか出力されません。
これは遅延評価でしょうか？んー、このスタイルだと遅延評価と呼んでもいいような気もします。
では、こっちのスタイルはどうでしょうか？

(* F# *)
let hoge (x: Lazy<'a>) =
  x.Force() |> ignore
  x.Force()

これ、上を書き換えただけでです。これははたして遅延評価・・・？
これは迷います。

lazy の自作
(* F# *)
type MyLazy<'a> = {
  mutable Value: 'a option
  Source: unit -> 'a
}
with
  member x.Force() =
    if x.Value.IsNone then
      x.Value <- Some (x.Source())
    x.Value.Value
let myLazy f = { Value = None; Source = f }

let hoge (x: MyLazy<'a>) =
  x.Force() |> ignore
  x.Force()

hoge (myLazy (fun () -> printfn "hoge"; 10))

先ほどの例を自作した感じです。これは遅延評価でしょうか？ううむ、もはや遅延評価とは呼べないと思います。
これに Active Pattern を追加すると、

let (|MyLazy|) (x: MyLazy<'a>) =
  x.Force()

let hoge (MyLazy x) =
  x |> ignore
  x

hoge (myLazy (fun () -> printfn "hoge"; 10))

ぬーん。これなら遅延評価と呼べそうな気もするけど、これも違うと思います。

Scala の lazy val
lazy val hoge = {
  println("hoge")
  10
}

println(hoge)
println(hoge)

これを実行すると、hoge は 1 回しか表示されません。
これを遅延評価じゃない、と言う人は少ない気がします。

遅延評価の条件とは？

ここまで色々と見てきました。
今の自分の中では、

  • シーケンスの要素の場合、そもそも遅延評価と呼ばない (単に要素として考えることができるはずなのでシーケンスを特別扱いしない)
  • 呼び出し元でラムダ式とかで関数に包む方式はその時点で遅延評価ではない
  • 使う側で何か特別なこと (Force の呼び出しとか) が必要な場合、違う気もするがいいような気もする

くらいの線引きがあるような気がします。線引きと言いつつしっかりと線引かれて無いですね。
F# の lazy は遅延評価と呼んでいいような気がする、というのは lazy が構文として用意されているからです。
myLazy の場合、myLazy 自体は構文でも何でもなく、単に関数を受け取る関数なので、一番目の理由から遅延評価とは呼べない、としています。


あなたの線引き、定義も一度考えてみてください。

遅延評価関連のキーワード

lazy evaluation
Haskell 界隈の人が言う遅延評価は 100 % これでしょう。call-by-name も含めるかは意見の分かれるところ？
delayed evaluation
call-by-need と call-by-name を分けて考えたい人が使ったりします。lazy evaluation は call-by-need、delayed evaluation は call-by-name みたいに。でも、日本語に訳すとどちらも遅延評価となって混乱します。
call-by-***
関数の引数の評価方法の話ででてきます。が、変数の評価方法を指していることもありそうな気がしてよく分かりません。
call-by-name
Scala の名前渡し引数で見たようなやつです。
call-by-need
call していませんが、Scala の lazy val でみたようなやつです。
call-by-value
ラムダ式で包んだり、MyLazy で包んだりしてるやつは実はこれですよね。関数とかインスタンスを値として渡してる。それを言ったら F# の lazy もこれですががが。

ぐーぐるせんせーに聞いてみた

ぐーぐるせんせーで「遅延評価」を検索してみました(2012/3/3)。pws=0を付けています。
上位 10 個を見てみましょう。

Wikipedia

一旦計算された値はキャッシュをすることが可能であり、遅延プロミスは最大で一度しか計算されないようにすることができる。ただし、Haskellの実装によっては、何度でも同じ計算を行う。

遅延評価 - Wikipedia

call-by-name も遅延評価という立場のようです。

IT Pro 本物のプログラマは Haskell を使う

遅延評価のための評価戦略としてよく説明されるのが，「名前呼び出し（call-by-name，名前渡し）」または「必要呼び出し（call-by-need，必要渡し）」です。実際のHaskellの処理系では必要呼び出しがよく使わます。

本物のプログラマはHaskellを使う - 第8回 遅延評価の仕組み：ITpro

こちらも Wikipedia と同じ立場ですね。

404 Blog Not Found

遅延評価(lazy evaluation)したいものを関数でくるんでしまえばいいのだ。こんな感じに。

var todo = function(){ return 1 };

値を取り出したいときは、そのクロージャーを評価すればいい。JavaScriptなら、尻に()をつけるだけ。

todo(); // 1.

厳密には、これは遅延評価ではない。クロージャーを作る部分というのは先行評価されている。しかしクロージャーを作ったら、そのクロージャーはすぐに返ってくる。「評価された値」はクロージャーそのものなのだ。中身はそのクロージャーを評価するまでおあずけってことに出来るわけだ。

404 Blog Not Found:λ Calculus - まずは遅延評価から

お、こちらは「厳密には違う」としていますね。
call-by-name は遅延評価とみなさない立場と取ってよさそうです。

ひらせチャンネル
int tarai(lazy int x, lazy int y, lazy int z)
{
    if (x <= y) return y;
    return tarai(tarai(x-1, y, z), tarai(y-1, z, x), tarai(z-1, x, y));
}
ひらせチャンネル - 遅延評価って何だ？

D 言語だ・・・
ここでは、call-by-need を遅延評価と呼んでいますが、call-by-name については言及がありません。

はてなキーワード

最外簡約。引数よりも先に、外側の関数から評価を進めること。

遅延評価とは - はてなキーワード

簡約と評価は別物だ、って話を聞いたことがあるのですが、それは一旦おいておきましょう。
ここではキャッシュの話は出てきませんので、call-by-name も遅延評価と呼んでいるようです。

IBM developerWorks

このバージョンの calculate-statistics では、値が必要になるまで何も起こりません。そしてそれと同じく重要な点として、どれも 1 度しか計算されません。最初に分散が要求されたとすると、calculate-statistics が実行されて最初に平均が保存され、そして calculate-statistics が再度実行されて分散が保存されます。次に平均が要求されると、既に平均は計算されているため、calculate-statistics は単純に値を返します。

遅延プログラミングと遅延評価

call-by-need を遅延評価と呼んでいますが、call-by-name への言及がありません。
後ろの方で

しかし例えば Haskell など一部の言語では、通常の評価プロセスの一部として遅延機能を持っており、これは遅延評価と呼ばれています。遅延評価では、どのパラメーターも、必要になるまで評価されません。プログラムは基本的に最後から開始され、逆方向に実行されます。プログラムは、何を返すべきかを判断し、逆向きに動作を続けながら、どの値を返すべきなのかを判断します。基本的に、すべての関数が、各パラメーターへのプロミスを付けてコールされます。計算に値が必要になると、その計算はそのプロミスを実行します。値が必要な時しかコードは実行されないため、これは call-by-need (必要によるコール) と呼ばれます。従来のプログラミング言語では、プロミスではなく値が渡されるので、call-by-value (値によるコール) と呼ばれます。

遅延プログラミングと遅延評価

とあるように、call-by-value と call-by-need しかないように受け取れます。
call-by-reference とか、call-by-name どこいった。

Rubyist Magazine

「遅延評価」というのは、「その値が必要になるまで実際の計算を行わない評価方式」のことです。前もって評価した結果を利用するのではなく、それが必要になったときに初めて評価して結果を得る、ということです。

Rubyist Magazine - enumerable_lz による遅延評価のススメ

これだけではどういう考えかわかりませんが、実際に enumerable_lz を使ってみると、配列の代わりにシーケンスを返すだけのようです。
ぬぬぬ。

neue cc

hogeEnumerableに包まれている状態では、まだ何も実行は開始されていません。そう、遅延評価！

neue cc - LINQの仕組みと遅延評価の基礎知識

これも enumerable_lz と同じ感じですね。

Scheme 入門

全体的に遅延評価を取り入れた言語としては Haskell が有名ですが、 Scheme も部分的に遅延評価を取り入れています。

Scheme 入門 17. 遅延評価

Scheme の遅延評価について述べています。
つまり、call-by-need についての言及のみで、call-by-name への言及はありません。

@IT .NET 開発者 厳選ブログ記事

xxxEnumerable変数（＝前述の「selectEnumerable」／「takeEnumerable」などのIEnumerableオブジェクト）の中に包まれている状態では、まだ何も実行は開始されていません。そう、LINQは遅延評価されます！

LINQの仕組み＆遅延評価の正しい基礎知識 − ＠IT

これは上で登場した neue さんのブログ記事を加筆・修正したものなので、基本的には同じです。

さて・・・

うまい具合にばらばらですね。
call-by-name も遅延評価、という立場の人が検索結果の上位にいるのは意外でした。


結論？そんなものはないです。
でも一度個人個人で「自分はどれを遅延評価と呼び、どれを呼んでいないか」をはっきりさせてみてください。

デブサミで自分戦略についてしゃべってきた

etc

いやぁ、ためになるセッションでした。
自分が若造でまだまだぺーぺーだと痛感させられましたね。
これに呼んでもらわなかったら今年はデブサミパスしようと思っていたので、呼んでもらって本当感謝です。

発表資料

自分戦略
View more presentations from bleis tift

話さなかったこと

この業界に入ったきっかけになった出来事

この業界に入るきっかけとなったのは、鈴鹿高専の推薦に受かったことです。
高専の推薦って、結構早い時期に合否が出るので、受験勉強から一抜けしちゃったんですよね。
一人だけ暇になっちゃって、先生からも「周りはまだ受験シーズン真っ最中なんだから、嬉しいかもしれないけど浮かれすぎないでね」とか言われちゃって。
で、「暇をつぶすために何かやろう。せっかくだから高専に入ってから役立ちそうなことやろう」と思い立ったんですよ。
その時やったのが、微積とプログラミングだったんです。
知ってる人は知ってるんですが、この時「Java というものが流行っているらしいからそれをやろう！」と思って本屋行って買ってきたのが JavaScript の本でした。まんまと罠にはまってますね。
なんという本だったか忘れちゃったんですが、サンプル集だったのは覚えています。
それを打ち込んで、マウスカーソルに追従するウザい画像だったり、時間とともに背景色が変わるページだったりを遊び半分でやりました。
サンプル集なのであまりプログラミング自体が分かったわけではありませんでしたが、面白かったのは確かです。
おぉ、なんかよく分からんけど俺すごい！面白い！！みたいな。
これがきっかけで、高専時代もろくに電子・電気のことはやらずにひどいことになってた感じです。

本と勉強会について

発表資料に載せた写真は、本を積んで写真を撮るのが一部で流行った時のもので、2009/7/10 のエントリのものなので、もう 2 年以上たつんですね。
あそこには 120 冊くらい写っているんですが、当時は確か 300 冊くらいあったので、あれで大体 1 / 3 ですね。
今ではもっと増えているんですが、人に貸したり弟に貸したり実家に置いてあったりで、もう全部を積んで写真を撮るとかできなくなっちゃいました・・・残念。
現在の正確な蔵書数は分かりませんけど、技術書だけで大体 500 冊くらいですかねぇ。
昔に比べると本からのインプットの相対量はかなり減ったと思います。
そのかわり、勉強会でのインプットの量が圧倒的に増えました。


勉強会というと、たまに「勉強会とか言って勉強してないじゃん」とか言う人もいます。
確かに、勉強会と言いつつフォーマルな雰囲気がない勉強会は多いです。
ともすれば、うちわで騒いでるだけじゃねーか、と思わるかもしれません。
いやまぁ確かに騒ぎたいというのもあってそこは否定しないし、うちわ感が出ちゃうのもどうにかしたいとは思ってます。
でも、だからといって勉強になっていないかと言うと、そうじゃないんですよね。
勉強会に参加して何かしらの気づきを得られるかどうか、そしてその気づきを学びに活かせるかどうかが大事だと思うのです。
そのために心がけていることとして、「否定から入らない」というのがあります。
人の意見を否定しちゃうと、そこで話が終わっちゃうんですよね。
なので、なんか肌に合わない話だな、と思っても、同意できる部分を探してみるのです。
そうすれば、何かの気づきにつながることもありますし、実は自分よりも深い部分を見ていて、それが単に今の自分の肌に合わなかっただけと言う場合もあります。

フォントについて

まとめを見てたら「使ってるフォントなんだろう」的なつぶやきがあったので紹介しておきます。
うずらフォント
基本的にはプレゼンはこのフォントを使わせてもらっています。
こわくない感じが非常に気に入っています。ゆるふわゆるふわ。

アウトプットを広める

やりすぎると自己顕示欲の塊に見えちゃうかも・・・とか恐れる人もいるかもしれません*1。
でも、ちょっとでもそういう風な考えに至る人は、全然気にする必要はないと思いますよ。
・・・とは言っても、気になりますよね？
そういう人は、自分にルールを課してみてはいかがでしょうか？
例えば、「一つのブログエントリにつき、一回しか tweet しない」とか、「自分のオープンソースプロダクトに言及があっても、一日一回しか RT しない」とかそういう。

Quick Test Switcher

まだテストコードと実装コードを切り替えることしかできないんで、「こういう機能欲しい！」というのがあれば、どんどん連絡ください。
何でもかんでも実装するわけじゃないですが、実際に使っている人の意見は通る可能性も大きいので。
あ、あのロゴはまだあれで決定なわけではないですが、あんな感じのものになる予定です。

他の人のキーワードを拾う

情報発信

「自分には情報発信するようなものは何もない」と思ってしまう人がいるという現実に対して、「情報発信は最初の一回じゃなければならないなんてことはない」てのに激しく同意。
自分自身の発表スタイルって、すごい人たちにいろいろ教えてもらったことを自分なりに噛み砕いて、他の人に提供するというスタイルなんですよね。
全部が全部そうというわけじゃないけど、そういうスタイルの発表は結構多いです。
俺は能力的にはあくまで普通側の人間だという自覚があるんですが、俺の周りにはすごい人たちがいっぱいいて*2、その人たちにいろんなことを教えてもらっています。
難しいと思っていたことを、その人たちが分かりやすく説明してくれたりするんですが、その人たちにとっては既に分かりきったことなので、今更それを発表したりとかってことはあんまりないです。
でも、世の中には俺と同じように難しいと思って苦しんでいる人たちもいるので、その人たち向けの高速道路が提供できたらいいな、と思ってブログにまとめたり発表したりしています。
もちろん、アウトプットすることで自分の理解を深めたい、という思惑もありますが。

英語

英語で情報発信すると確かに受け取れる人は増えますよね。
でも、やっぱりまずは日本人に向けて情報を提供したいです。
べ、べつに英作文が苦手ってわけじゃないんだからねっ！
・・・あ、はい。苦手です。いいわけです。頑張ります。

環境を含めて自分の価値

目から鱗でした。
こんな考え方したことなかったなぁ。
Dis るのは楽なのでそこに逃げちゃいがちですよね。ちょっとこれからは安易に環境を Dis らないように気を付けようと思います。

全体を通して

自分の自分戦略はこれまでの自分がやってきたことの整理にはなったので、それなりに有意義ではあったんですが・・・
それを圧倒的に上回ったのがみなさんの発表が間近で聞けたこと。
すごいためになったし幸せでした。
もっともっと、精進しないといけないですね。

*1:そうじゃない人はどんどん広めていきましょう

*2:勉強会で出会った人たちとか、本とか

Developer's Test 勉強会に行ってきた

Git etc

すごい楽しかった！
事の発端は、「SCMBC の時の資料を使わせてもらえないか？」というツイートでした。




最近大阪行ってないなー、面白そうだなー、ということで行ってきました！
得るものがたくさんあったので、行って正解でした。
資料の公開はもうちょい待ってください。


以下感想。

  • (K) ポジションペーパを Github に push してもらって、pull request を投げてもらうというのは良かった。
    • (T) ただ、マージの時にテーブルごとにディレクトリを分けてマージした方がよかったかも？
  • (K) 講演の反応は上々。これまた行ってよかったと思えてうれしいです！
    • (K) 「Git の勉強会には何回か参加したことがあるけど、今までで一番分かりやすかった」と言ってもらえた！
    • (T) gitk は紹介しといたほうがよかった。
    • (T) git status も。
  • (P) サポートの人数が少ないと、手が回らなくなる。やっぱり 1 テーブルに 1 人 TA がいる体制は素敵。
    • (P) だけどいつもそれだけの人数をそろえられるとは思えないので、どうにかしたい。
  • (P) 環境構築のサポートが不完全で、文字化けや改行コードに悩まされるグループが多かった。
    • (T) 環境構築をさくっと終わらせてくれるツールを書きたい。
  • (K) 各演習の終わりには、困ったことを話してもらうようにしたけど、これがいい感じだった。
    • (K) 1 グループ 1 分から 2 分くらいで十分。
  • (K) 最後の演習の終わりは、俺の PC に全グループのリポジトリをリモートに追加して、プロジェクタに写しながら進めたけど、これもいい感じだった。
    • (K) PC を繋ぎ直す必要がないので、トラブルで時間を食うことはないし、切り替えの時間も食うことがない。
    • (K) 自分が PC を操作するので、突っ込みを入れたり、解説入れたりできる (邪魔だったかもしれないけど)。

以下勉強会自体とは関係ない感じの感想。

  • id:kiy0taka (きよたかさん) が TDDBC 北陸に参加していたことを知った。
    • 第一回の Jenkins 勉強会の Ust を見て、すっかりファンになったんだけど、その前に会っていたという事実。
    • そのとき Git で発表してたことが印象に残っていたらしい。
  • id:coolstyle (こくぼさん) に会ってみたいという人が多かった。
    • アイコン通りの人です、と言っておいた。
  • 懇親会の豚が美味しかった。
    • TDDBC 福岡の参加者のみのテーブルができたりした。あれ、ここ大阪・・・
    • 名古屋を Dis られた・・・ような・・・？
  • id:irof (いろふさん) の部屋がすごいきれいだった。
    • 誰かさんの部屋とは大違い。
  • バナナの串カツは普通にいけた。

名古屋クリスマソン 2011 を開催した

etc

去年のクリスマス、楽しかったなぁ・・・
と、いうことで、クリスマスに開発合宿しました。
ケーキ美味しかったです。
12 月の頭からずっと忙しくて、ぐだぐだな感じですみませんでした。
でもクリスマソンのおかげで無事に正月を迎えることができましたよ！

2011 年

etc

2011 年は色々なことがあったなぁ・・・
発表したけどブログに起こしていないものとしては、

仕事で使うF#
View more presentations from bleis tift

ぼくのかんがえたさいきょうのLL
View more presentations from bleis tift

F#で始めるスマートフォンアプリ
View more presentations from bleis tift

F# 関連多いですね。
思えば今年最初の発表もデブサミで F# の発表でしたし、F# の年になりました。
Groovy は・・・Groovy は・・・とりあえず保留で。

SCM Boot Camp 2 in Tokyo に行ってきた

Git etc

今回は Git の講師として参加しました。
2 回目と言うこともあって、よりスムーズに進めることができたように思います。

個人的なもくろみ

今回参加して、SCM Boot Camp の DVCS イベントの部分はある程度パッケージ化したいと考えるようになりました。
まだ 2 回しかやっていませんが、DVCS (少なくとも Git) の効率的な習得のためのスキームというのが見えてきた感じです。
最終的には、講師が 1 人いれば小規模なイベントを開くことのできるところまで落とし込めるのでは、と考えています。


以下時系列順の雑多な感想や補足など

開催前

今回は、開催の準備として数回 Lingr によるミーティングを行いました。
資料の作成も段階的に行うことができたのでフィードバックを取り入れることができてとてもよかったです。
にも関わらず、

となってしまったのは反省点です。
次回以降やりたいのは、

  • 全てを Github で管理 (Issue とかも使って)
  • ミーティング開催までにやることをよりはっきりさせる (Milestone と Issue)
  • 発表用とは別に、配布する用の資料の作成

の 3 つです。

発表

SCMBC Git入門セッション発表資料
View more presentations from bleis tift

基調講演の後に Git の入門セッションを発表したわけですが、直前まで誰が発表するかすら決まっていなかったという。


とあるように、slideshare の図が間違ってます(汗
これに関しては、Github のリポジトリから取得できるものでは修正してありますので、そちらをどうぞ。

勘違いしないでよね！
これはちゃんと指摘できるか試すためにわざと間違えておいたんだから！

・・・嘘ですごめんなさい。

入門・・・セッション・・・？

入門セッションと言いつつ、

という。
これに関しては別のところで、

とあり、まさにその通りです。
ただし、一番最初にこれを言うべきでした。
次回以降の資料にはここについても考慮したものを用意します。

ぶれいすさんのようすが・・・


・・・はい。

前日 2:30 頃まで資料作成
↓
5:30 起床
↓
新幹線で闇LT用の資料作成
↓
会場で発表資料の最後の手直し
↓
発表

という流れで、「3時間しか寝てないわー」な状況だったのです。
・・・どう見てもいいわけです。本当にごめんなさい。

全体的な話

言い訳はこのくらいにして、今回の発表資料と発表内容について。

とつぶやいたように、今回の資料は Git チーム全員で作りました。
これまで Git に関する発表資料は 1 人で作っていたんですが、今回の資料はそれらを上回るものになりました。
発表中の反応も上々で、発表中に Git のオブジェクトモデルを理解して、資料中の間違いを見つけるまでになった人がいたのは嬉しかったです。

演習

演習は、id:katzchang がいたおかげで割とスムーズに進みました。
1 テーブルに 1 人、katzchang さんが欲しいところです。
というのは冗談としても、Git の簡単な使い方を理解している人はテーブルに 1 人以上いるとスムーズですね。
自分が担当したグループでは、katzchang さんの他にももう一人 Git ユーザがいたので、俺の存在意義があばばばば

Github の準備

前回よりはよくなりましたが、やはり Github の準備に関するサポートはもうちょっと行うべきでした。
具体的には、

  • Github の簡単な使い方ガイド (Collaborators への追加など、演習に必要な範囲のみ)
  • 各環境ごとの鍵ペアの作り方と、登録方法
  • 鍵ペアの作成/登録がうまくいかない場合の HTTPS を使った方法
  • pagent の話

が書かれた資料を用意しておく、と言った感じでしょうか？

おススメ設定の提供

msysgit を使っている人は、デフォルト状態で git-completion とか現在の working tree の状態の表示とかが有効になっているのでいいのですが、他の環境ではそうではないので、そこら辺の設定を用意しておけばよかったです。
もちろん使う人にとってもやさしいですし、講師も参加者の PC を操作することや画面を見ることがありますので、講師にとってもやさしいと思うのです。


他にも、Vim の最低限の設定なんかもあったほうがよかったです。
デフォルト状態では、ファイルのエンコーディングが分からないので、cp932 でコミットメッセージを保存してしまって文字化け、という人が何人かいました。
これに関しては、How to install Git の方でカバーする話な気もします。

gitk

gitk (やそれに類するもの) は、常に立ち上げておいた方がいいです。
これは、演習で必要な操作方法を含めて入門セッションの内容に組み込んだ方がいい内容でした。

トピックブランチの導入

マージ地獄でコミットグラフがぐちゃぐちゃになる、というのはなかなか体験できないことだと思います。
なので、これは基本的に続けたいと思うんですが、途中でトピックブランチを導入してコミットグラフをきれいに保つ、という運用も今回取り入れてみました。
が、サポートが足りなかったようで、最後マージが発生してしまいました。
このあたりはよりスムーズに導入できるようにもうちょっと考慮が必要な部分です。

TortoiseSVN ユーザのための Git Bash 入門の必要性

TortoiseSVN 便利なんですけど、それしか使ったことが無い人にいきなり Git Bash 使えというのはスパルタすぎるなぁ、と思い直しました。
なので、

  • 演習に最低限必要なコマンドの説明
  • ディレクトリやオプションとかを Tab で補完できる話
    • あと「困ったらとりあえず Tab を 2 回叩く」とかそういう
  • ディレクトリ名の横に出ている (master) の部分の意味

あたりを用意しておいた方がいいかなー、と思いました。

次の一歩

Git グループずるいわー、俺らがあたふたしてるの横目で見てしてやったりとか思ってたんでしょー？

と懇親会でなじられた Git グループですがw
これも演習中だか休憩中だかに思いついたものですよ！と言うと、

でも教えてくれればよかったじゃーん

確かにw
事前に質問を集めておいてそれに答える、というスタイルは時間の制御もしやすくていい感じでした。

懇親会

懇親会はカオスでした。
なんか持ち上げられたりこわいこわい言われたり・・・こわくないよ！

闇 LT

LT と言いつつほとんどの人が時間を守らないという。みなさん時間は守りましょう！！！

花映塚

前回、神速さんと「時間があったら花映塚やりましょう！」と約束していて結局できなかったのが心残りだったのですが、今回実現しました！
隅っこの方でこっそりやろうとしていたら見つかって一時見世物状態にw
いやー、次回以降もやりたいですね！(ぇ

最後に

すごい楽しかった！
次は名古屋らしいですよ？

第4回 Jenkins 勉強会に行ってきた

etc

って、もう一か月も前のことですね・・・

輪るビングドラム.NET
View more presentations from bleis tift

どんな感じだったかは
第4回Jenkins勉強会 - 日本語 - Jenkins Wiki
から辿れるリンクをどうぞ。


懇親会では、F# の話とか Jenkins のプラグインの話とかうちの会社でやってることとか色々な話をしました。
で、前日まで何も調べてなかったんですけど、調べると懇親会にフルで参加したら名古屋に日帰りできないことが判明。
まーネカフェにでも泊まればいっかー、と思って懇親会参加したんですが、懇親会後にサボテンの人とかに誘われて三次会に参加しました。
サボテンマンは超いい人でした。


で、それが終わってから近くのネカフェで過ごしてたんですけど、Jenkins のプラグイン作る最初の一歩として素敵なドキュメントを見つけたのではっつけておきます。

Jenkinsプラグイン開発
View more presentations from Takahisa Wada

なんか俺の環境だと見れないんで、もし見れない方がいたら Download してから見てください。
ppt が落ちてきます。
スライドの順番は一部変な気もしますけど、なんとかなるでしょう。