TFServiceを使って F# プロジェクトのビルドを試した時のメモ

F#

そういえば、TFServiceを触ったことがないなーということで、作業メモ。
とはいえ、基本的に以下の記事を参考にすればビルドとテストが行えるようになります。

私の環境 + 今回使用したプロジェクトはこんな感じです。

Team Foundation Serverの資料であってもServiceのほうも似たような形で設定できるので、そんなに問題にならなかった気がします。
あと、C#とF#で設定方法に差は見られないようです。

細かい設定方法はまだ調査中なので、また今度。

詳しい手順

あとでかく

まとめ

TFSUGの方々が素敵すぎた。

"Async in C# and F#: Asynchronous gotchas in C#"を翻訳しました

C# F#

4月末に C#の非同期の落とし穴 でとりあげられていた Async in C# and F#: Asynchronous gotchas in C# を読みながら「面白いなぁ」とつぶやいたところ、ハマの子連れ狼さんに翻訳を勧められたので、英文和訳の訓練も兼ねて翻訳しました。

Async in C# and F#: Asynchronous gotchas in C# (Japanese translation)

公開後も diff を確認しやすい Gist で公開しています。

謝辞

4月末の連休に翻訳を開始してから公開まで、2週間くらいでしょうか。
この速度で、かつこの訳質で公開できたのは、的確な助言をくださったハマの子連れ狼さん、翻訳について快諾くださった原文著者のTomas Petricekさんのおかげです。

ありがとうございました。

短いあとがき

あとがきを書いておきます。
翻訳者個人の言葉であって原文著者の言葉ではないことを理解した上で、下記を読んでください。

記事内でも記述されていますが、決して C# async を批判する記事ではありません。
あくまで"こういった部分に気をつけましょう"という話です。

訳に問題があるとすれば、それはすべて翻訳者である私の責任です。
訳について指摘事項などありましたら、Gist もしくは本ブログ記事のコメント欄に投稿していただければ幸いです。
Twitter のメンションでもかまいませんが、見逃す可能性があるのは否定できないので…。

それでは、引き続き Async な世界を楽しみましょう！

ScalaやHaskellのライブラリをF# に移植するときのTips？

F# Haskell Scala

こんなことを思っていたりすることもあるため、HaskellやScalaに面白そうなライブラリがあると聞きつけるとF# に移植できないか試したくなります。

で、いくつかTipsというかこんなことがあるよ、的なことをまとめておきます。

用語はてきとーなので表現が微妙であれば順次修正していきます。

【この記事は書きかけです】

型パラメータが型パラメータをもつ

Free Monadを例にしてみると

sealed trait Free[S[+_], +A]

や

data Free f a = Pure a | Free (f (Free f a))

などの型パラメータが型パラメータをもってるよ的なやつです。

これが出た場合、私は白旗をあげます。

型エラーが解決できない

基本的には多相ではないのであきらめなければらなない場合か、解決できそうだけど根気負けする場合の2択です。

obj型なら通る、とかもたまにありますね。

再帰なlazyちゃんマジlazy

これはscala-machinesやHaskellのmachinesのrepeatedly関数を例にしましょう。
まずはScala。

def repeatedly: Machine[K, O] = {
  lazy val r : Machine[K, O] = this >> r
  r
}

次にHaskell。

repeatedly (Plan m) = r where r = m (const r) Yield Await Stop

lazyだからこそできる再帰ですね。

HaskellやScalaではlazyが型に現れることはないので、これで問題なしです。

が、F#ではこう単純にはいきません。この例の場合だと、

let rec repeatedly p : Machine<'k, 'o> =
  let inline (>>.) p (next : Lazy<Plan<'k, 'o, 'a>>) = p >>= (fun _ -> next.Value)
  let rec r = lazy (p >>. r)
  r.Value

こうなります。

まずevaluationが発生して欲しい場所を探します。今回の場合は(>>.)演算子でした。
これを、えいやっとシャドウィングしてLazy版を書きます。
あとは何事もなかったように、自己再帰の警告を #nowarn "40" などで消すなり放置しながら残りの部分を実装します。
こうすることで、他の関数には迷惑をかけずにScalaやHaskellと同様のことが行えます。

この系統はlazy evaluation(?)の良い勉強になりますね。

type class

  1. fsharp-typeclasses - Emulate Haskell's typeclasses in F# - Google Project Hosting を使う
  2. あきらめて地道な実装を行う

前者は使ったことがないのでどんな感じなのかわかりません。

後者はFSharpx内のいくつかのmoduleに方法を見れば、どんな感じなのか把握できると思います。

あ、IOモナドはあきらめてます。

Nothing型

ScalaのNothing型を表現できる気がしないので、コンパイラのご機嫌を伺いながら(型推論してもらいながら)問題のなさそうな型にします。

おわりに

「F#で理想を追求するって、そういうことよ」

F# にMachinesの移植を試みている

F#

某都会ではekmett氏のライブラリを勉強する会があるらしい。

http://partake.in/events/1698f7f8-4151-4048-b317-03a8c3f1a7ab

うらやましいとかそういうことはすごくあるのだけれど、行けないものは仕方がないので自前環境でとりあえずは我慢することに。

本題

というわけでmachinesをF#に移植しようと試みている。

Haskellのmachinesは見た感じF#への移植は難しそうなので*1、scala-machinesを主に参考にしている。

まぁ、現状色々と嵌ったり詰ったりしていますが。。。

特に型周りがちょっときつい。今はこのあたりでとまっている。

Gists

目下の戦いはこの部分。

def left[A]: Handle[T[A, Any], A] = \/.left(_)

Handle部分を展開すると A => A \/ Nothing という解釈であっているのかな？
正しいならそれはそれで詰みそう…。


あと、Scala側にあるTee.mergeOuterJoinってHaskell側にもあるのだろうか？
あるなら参考にできそうなのでちょっと探してみよう。

【2013/03/18追記】
@xuwei-kさんのわかりやすい型講座により把握できました。ありがとうございます！

scala-machines Tee.left

というわけで

地道に現実を知りながら育てていく予定です。


少し話がそれるけれど、こういう感じにコードを書きなぐっているとMachinesハッカソンがやりたくなってくる。

東京で開催できないですかね？
会場をみつけることができればいいのかな…時期はいつでもいいわけだし。
machinesに何かしら思うところがある型は反応していただければ…。

*1:私がへなちょこなだけかもしれないが…

Groovy基礎勉強会とNagoya.Testing in Tokyo3に潜入してました

イベント

主催者のきょんさんに「Groovy基礎勉強会で発表よろしく！」とお誘いをうけたので喋ってきました。
あと、翌日はNagoya.Testingを開催するとのことだったのでお手伝いとして参加しました。

2013/03/09(#GroovyBase)Groovy基礎勉強会 - Togetterまとめ

ことりちゃんがみえたあたりからが私のセッションのようです。

資料など

GParsのActor Modelとか言っておきながらひたすらActor Modelについて喋ってました。
素人知識なので間違いなどあれば指摘していただければ幸いです。

  • 最初にActor Modelがどのような形で応用されている（使われている）のか話せばよかったかも？
  • 公理的操作群ではなく操作的意味論のほうがよかったのかな？
  • 一部、並行と並列を書き間違えていたことに本気で焦った
  • 資料の字が小さかったようで、すみません・・・今後はあらかじめ資料をupするか文字サイズ調整します

理論はからきしな私ですが、たまにはこういう内容を学んで発表するのもアリかなと思ったりおもわなかったりしますね。

ただ、"きょんさんの開催する基礎勉強会"だから問題なかった(?)ものの、他のところで話す場合は前提となる用語の説明とか、実装よりの話を多く入れるべきなのでしょうね。


Groovy基礎勉強会に関しては「やっぱりASTな話が多いのねー」という感じでした。

抽象構文木といえば、コンパイラの学習も再開したい…

『アジャイル開発とスクラム』と『SCRUM BOOT CAMP THE BOOK』を読んだ

書籍

久々の、そしておそらく学生生活最後の読書感想文です。

今回は今年1月、2月に発売されたスクラム系の本2冊。

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

最初は別々に記事を書こうと思っていたのですが、書けるときに書いておかないと両方書きそうにないので、まとめてしましました…。

購入理由

前者は『ユーザー向け』というのに興味をもったからで、後者は

感じたことをざっくりまとめると

アジャイル開発とスクラムが経営層・プロダクトオーナー対象、SCRUMBC本がスクラムマスター対象かな、という印象を受けました。
アジャイルサムライ*1などは開発チームを対象にしている印象があるので、三点セットで読めばアジャイルやスクラムを学べるのではないでしょうか。

スクラムを通して考える

アジャイル開発とスクラムでは、ソフトウェア開発におけるリーダーシップと企業理念・イノベーションについて、スクラムを通して考えることになります。

SCRUM BOOT CAMP THE BOOKでは、スクラムを通して"学びの仕組み"について考えることができます。

雑感

SCRUMBC本にはプラクティスという言葉がほとんど（もしくは全く？）出てこない。TDDやペアプロなどの言葉も登場はするものの、言葉の説明はない。"Scrum Boot Camp"の本だからなのかはわからないですが、この割り切り(?)方は好きです。

対して、アジャイル開発とスクラムにはプラクティスが概説されています。こちらは"ユーザー向け"だからこそ説明を入れたのでしょうか。

そう考えると、この2冊(サムライ入れると3冊か)は絶妙なバランスですね。

気になったところ

SCRUMBC本、p109。

ボク「1週間で8ポイント…全部で168ポイントだから…」
ボク「今の人数で5ヶ月あれば…イケる！」
ボク「ブチョーと営業部長のところに行ってくる！」
キミ「いってらっしゃい…って、なんなの…」

SCRUM BOOT CAMP THE BOOK

仮に1ヶ月=4週間計算だったとして、5ヶ月で160が限界なのではー、と思った*2のはさておき。
これ、どう説明したのだろうね…というところが気になっていたりします。

おわりに

各視点から考えてみたい、学びたい方にもお勧めです。

アジャイル開発とスクラム、SCRUM BOOT CAMP THE BOOKは読書速度の早い方なら土日で読みきれると思います。わりと遅めの私でも前者は3日、後者に至っては1日かからなかったので。ちなみに、アジャイルサムライも3日くらいあればたぶん読めるので、読書の苦手な方にも大変親切な3冊ですね。


最後に。この文章は実践が伴っていない感想なので、仕事でScrumチームに入る日が来れば、改めてもう一度読み直して感想を書こうと思います。

*1:スクラムの本ではないけれど…

*2:前ページに「次のプロジェクトが半年後から始まる」と書かれているので、もしかしてそこから「リミット半年->168ポイントは大丈夫」だと判断した…？