2009年7月31日金曜日

まとめ読み:Agile関連記事 3

Minibook: 塹壕より Scrum と XP (2008年8月12日)
『Scrum and XP from the Trenches』という、Scrum プロジェクトの実録風チュートリアル。ややボリュームがある(138ページ)ので、時間が空いたときに集中して読んでみようと思うので、内容はひとまず保留。

それにしても Scrum の記事が多い。もしかして既に XP の後継的な地位に決まってしまってるんだろうか。なんとなく体育会系っぽい雰囲気があってちょっと敬遠していたんだが、そろそろちゃんと体系的に知識を取り込んでおいた方がいいのかもしれない。プロジェクトに参画すると、開発チームリーダ的なポジションになる事が多いから、明確にリーダの権限と責務が定義されているプロセスの方がむしろやりやすいかもしれない。


ソフトウェア開発: いつ起きてもおかしくない交通渋滞 (2008年8月15日)
交通渋滞と測定ライトの比喩はそれほどでもないが、「10 Principles of Agile Project Time Management」は気に入った。元ネタには各条文の内容が書いてあり、さらに詳述したページへのリンクもある。


アジャイルの採用に関する感覚的な障害 (2008年8月20日)
「年を重ねるにつれて、もっともややこしい問題は技術ではなく人の問題であることに気づいたんだ」って、そんなの大して年重ねなくても分かるだろうに・・・なんて思いつつ見てみると、ちょっと面白そうなのが紹介されている。
  • Responsibility Process Model (責任プロセスモデル) Christopher Avery
  • Responsibility Virus (無責任ウィルス) Roger Martin
  • Ladder of Inference (推論のはしご) Chris Argyris
どういうわけだが、何しろモデル化されたものは何でも面白そうに思えてしまう(まあよく見ると面白くないモデルも多いが)。あとはカタログ化されたもの好きでたまらない。モデル化されたものとカタログ化されたものがなぜか好きで、なぜか集めてしまいたくなる。

まとめ読み:Agile関連記事 2

誠実さはアジャイルにとって価値と言えるか? 2008年8月9日
「誠実さ」は原文では"Truthfulness"。見たままの意味なんだろうけど、やや見慣れない単語。

"sincerity"とも"honesty"とも異なる、ネイティブにとっては明瞭なニュアンスがあるんだろうと想像しながら、本文に進む。まあ「嘘や隠し事は困るよね」といった、アジャイルの現場に限らない一般的な道徳の教訓話なんだけど、同業者の経験談として耳を傾ける価値は当然ある。

ちなみに記事の元ネタのブログのさらに元ネタの PDF ファイルがあって、どこか海外の会社がやってるアジャイル/スクラムのトレーニングコースのチラシみたいなものなんだけど、現在の agile 開発のエッセンスが結構上手くまとめられている。

この中にPMBOK を勉強した人なら誰でも知ってるチーム形成段階のモデルなんかも出てきたりする。自分も PMBOK を勉強していたとき、思ったほど agile と相性が悪くない感じがしていたので、こうやって Agile の文脈でも取り上げられるようになったのを見ると、ちょっと面白い。

ユースケース、それともユーザストーリー?2008年8月10日
ユースケースかユーザストーリーか、記事の中で決着がついているわけでは全然ないが、なかなか面白い。はっきり言って自分はユースケース派で、ユーザーストーリは使った事が無い(というより、よく違いがわかっていない)。

Alistair Cockburn のユースケース本には、ユースケースの3段階の formality のうち、最も簡素な use case brief のようなものがユーザストーリに当たると、確か書かれていた。自分もずっとその程度の認識で、たまにユースケースとユーザストーリは違うなんて話を聞いても、ほとんど同じものの違いを、こだわりすぎな人たちが論じてるのだろうと思うだけだった。むしろ対立があるとしたら、FDD (今もあるのかな)の feature とユースケース≒ユーザストーリの間の選択だろうと考えていた。

ところが記事では、当の Cockburn も交えて、ユースケースとユーザストーリで鋭く対立している。原文の方にはいくつかコメントもついていて両派の論争があるが、中には「ユースケース=ウォータフォール」なんて極論というか偏見もあってびっくりする。これはユースケースが全ての作りこみに先立って全ての要件を洗い出すものだとの誤解に基づいているが、本文では Cockburn 自身がいかにもそう読まれてしまいそうな論調で、ユーザストーリを批判している。まあ、わざと議論を面白くするためにやってるのかもしれない。

このテーマはまた立ち戻って考えてみたい。

Scala 練習5

今日も、ネットの連載記事を読みつついじってみる。
第4回 Scala言語を探検する(2)

今回は trait の説明が中心。「mix-in型の多重継承」、「アスペクト指向を簡易に実現」なんて書いてある。多重継承なんて何だかつまらない話っぽいけど、下の方に何気なくサラっと書かかれてる「インスタンス生成時にそのオブジェクトに対して個別にtraitの性質を与えることもできます。」ってところがとても面白い。多重型付けなんだな。

ちょっと古いけど Martin Fowler の「アナリシスパターンAnalysis Patterns)」(通称アナパタ)という絶品な良書があって、その付録の「A.13 汎化」で「多重継承(multiple inheritance)」と「多重型付け(multiple classification)」の違いについて説明がある。

要約すると「多重継承といっても個々のオブジェクトが持つのは単一の型だから、それは単一型付け(single classification)だけど、それに対して多重型付けは個々のオブジェクトが複数の型を持ちうるという別ものの話であり、概念的には後者の方が自然である。」といった内容。Scala の traitは多重継承だけでなく多重型付けもサポートしているようなので、分析レベルと実装レベルのギャップが狭くなるというわけで、これは歓迎。

ちなみにアナパタの同じ箇所に「多重型付け」と並んで「動的型付け(dynamic classification)」についても記述がある。この記事のサンプルをもじって言うと、Person with TPianoPlayer から例えば Person with TGuitarPlayer への、実行時の動的な変更が言語的にサポートされていれば「動的型付け」なんだけど、Scala ではどうなんだろう? いたるところで「Ruby は動的だが Scala は静的」なんて言われているようだからやっぱ無理かな。ちなみにJava や C++ は、もちろん動的型付けはサポートしていないから、 Strategy か State パターンを使うのが定石。

続くアスペクトのところもまあまあ面白いが、この記事では軽く紹介されているだけなので、フックのための小さい仕掛けのレベルを出ていない。もっとよく調べれば本格的な Separation of Concerns の技法の、Scala的なイディオムがあるのかもしれないが、Scala 初心者の自分にはまだ分からない。ちなみに mix-in といえば、昔アスペクト指向が流行始めた頃(2002年頃?)、AspectJ の対抗馬的な扱いで MixJuiceってのがあった気がするんだがどうなったんだろ?

最後の方に型の話があって、より純粋なオブジェクト指向言語って事らしいが、まあ、うん。

====
今日は、Eclipse をエディタとして使って、コンソールから :load して実行という変な使い方をしてみた。
scala> :load Person.scala
Loading Person.scala...
defined class Person
defined trait TTeacher
defined trait TPianoPlayer
defined class PianoplayingTeacher

scala> val t1 = new PianoplayingTeacher
t1: PianoplayingTeacher = PianoplayingTeacher@107e9a8
Eclipse のScala IDE でクラスを新規作成すると、[Finish]押してファイルも生成されてるのにフォームが閉じない。テンション下がる・・・

2009年7月30日木曜日

まとめ読み:Agile関連記事 1

Agile Allianceの機能テストワークショップ2008年8月6日
Agile Alliance が主催した、機能テスト(functional test)の自動化ツールに関するワークショップに関する記事。

現場での実感とも大いに一致するが、機能テストの技術体系は xUnit によるユニットテストほどには、まだまだ普及も成熟もしていない模様。自分と同様に機能テストの難しさを感じている人が世界中にいるというわけで、なんだか安心してしまった。

Ward Cunningham の言葉が引用されていて、「機能テストの次なる進歩においては、中心的な役割を果たすのはツールだとしても、進歩するのはツール自体ではなくてツールにまつわる実践だろう(意訳)」というような内容。激しく同意。

第二回Functional Test Workshopの成果2008年8月7日
上の記事のワークショップの結果報告。

「承認が先の開発」なんて見慣れない言葉が出てくるが、どうって事はない Acceptance Test Driven Development(ATDD)を訳した語で、記事中で Unit Test Driven Developtment(UTDD)と対比されている概念。(「受入テスト駆動開発」と「単体テスト駆動開発」とでも訳せばいいのに。)この単語が絡む辺り、他にもミスリーディングな訳文があるが、原文は要するに「プログラマ」にとっても「ビジネスパーソン」にとっても人気が得られなかったというだけの事で、難しい話ではない。

DSL についての議論があったようだが、顧客主導のテストとなった場合、どんな DSL をどのように紹介すれば受け入れてもらえるんだろう? 英語圏ならば自然な生活言語にかなり近いDSLを作れるだろうし、「それ自体で動作するテスト仕様書」として顧客に認知されるもチャンスも大きいと思うんだが。

ただ日本でのシステム開発の場合は難しいだろう。日本語ライクな DSL はどうにも無理っぽい。かといって英語ライクだと「また別の新しいプログラミング言語か」なんて敬遠されそう。グラフィカルな DSL なら顧客へのアピールもありそうだが、テスト対象項目が限られそうなのと DSL 開発自体のコストが問題。とまあ、こんな風に最初の基本的な方針選択で、いろいろ悩みどころがある。

DSL 自体には可能性を感じているんだが、ビジネスパーソンとの協働の場面で用いるには、まだまだ自分にも業界にもプラクティスの蓄積不足を感じる。

まとめ読み:Agile関連記事 0

なんだか、この2,3年、Agile開発関連の最新動向に疎遠になっていた気がする。

もう昨今の現場では、普通に xUnit や continuous integration ツールのような Agile系ツールが普及して、多様性も利便性もかなり高まっていて、そういったツールがもたらす便益の範囲内に限ればだけど、結構スモールリリースの反復型開発も許される状況になってきている。そんなわけで、ウォーターフォール時代に感じていたフラストレーションは少なからず解消されつつあり、何となく満足していたりする。

ただ、そういったAgileツールの普及効果による満足というのは、アジャイル・マニフェストに含まれる、"Individuals and interactions over processes and tools"というくだりを想起すると、なんだかちょっと志が低くて姑息な感じもしないでもない。「Agile」から本来もたらされるはずの効用を想起すると、いつまで経っても解消されていない不合理・不経済・不健全が、まだまだ多い。

だから、現場ではもっともっと、チームについても段取りについても、やる事があるはずなんだけど、所詮自分は外部の人間なわけで独断で物事を決める決定権はないから、何か方策を提案するにしても人一倍の理屈と説得力がなければならない。

そのためには新しい情報も当然いろいろ知っていなければならないけど、この業界では Agile 開発のような割と新しいジャンルの常識も、すぐに古くなったり陳腐化したりする。例えば「XPは小規模チームにしか適用できない」だとか、そういう古い知識をうっかり開陳したりすると、「その程度か」とすぐに足元を見られ発言力を失う。

というわけでAgile系開発の最近の動向を掘り返してみようと思い立った。いろいろ見て回るとInfoQ にまとまった量の記事が載っているようなので、一年遡って2008年8月の記事から、今後しばらく継続して読み返してみようと思う。

Scala 練習4

仕事ではほぼ常時テストファーストでやってるので、Scala で遊ぶのもユニットテストのフレームワークを使ってやってみたくなる。探してみると、Specs というのを見つけた。このサイトで QuickStart というのがあったのでやってみるが、せっかくなので Eclipse IDE を使う事にした。以下レポート。

◆試行環境
・Eclipse 3.5
・specs-1.5.0.jar
・JUnit 4.5 (Eclipse 3.5 のデフォルト)

◆新規 Scala プロジェクトを作る


◆Scala オブジェクトを生成する

QuickStartの step3 のとおりにコードを書くが、以下のようにビルドエラーとなる。

◆ライブラリを追加する
以下のように、SpecsのjarとJUnit4ライブラリを追加する。
そうするとエラーのマーカが消える。どうやらビルドできたらしい。

◆実行してみる
コンテキストメニューには「Scala アプリケーションとして実行」的なメニューは出ないので、[Run Configuration] から設定する。

QuickStartと同様のコンソール出力が得られた。

◆JUnitから起動
さて、これがやってみたかったのだが、どうしても Eclipse のテストランナーがテストクラスを認識しない。いろいろやってみたがギブアップ。まあ、そのうち分かってくるかもしれないから今は良しとしよう。

※Specs は良いが、Eclipse Scala IDEがいろいろ困ったちゃんで面倒くさい。言う事聞かない。まあ Scalaは人気あるみたいだし、そのうち何とかなるだろう。

※Specs のテストの書き方が全面的に EDSL で面白い。こういうのは実に良い。いいもん見つけたわ。

2009年7月29日水曜日

Scala 練習3

今日もちょっと Scala をいじってみた。

引き続きネットで連載してる記事を読みながらいろいろ試してみる。連載第三回だが筆者が変わったらしく、前二回のおさらいから始まり、いったん関数型っぽい話題は保留にしてJava 側から近接するアプローチで話が進む。

コード例も「Java と違ってこうも書ける」なんてのが多くて、今回はそれほど面白そうなのはない。引き継いで初回だからしかたないか。途中、パッケージスコープで関数を定義しているようなコードのスニペットがあるが、どうしてもエラーになる。記事中のコード例に何が欠けているのか調べようかとも思うんだが、なんだか一気にテンションが下がって、面倒くさくなってきた。

最後に Java とScalaの文法の違いが箇条書きされているが、まあわざわざ Java 以外の言語を JVM 上で動かそうと言うのだから、そういうのじゃなくて、もっと抜本的に違うところを読みたい。ただ記法レベルの話に混じって、static なメンバからシングルトンオブジェクトへの移行や、for ループなどの制御構造からオブジェクト構造への移行など、パラダイムのレベルでよりオブジェクト指向になっている項目もあって、これらはちょっと面白い。

今回は特に演習する事もないので、Eclipse に Scala IDEを組み込んでみた。1年以上前のちょっと古い記事だが、ITPro の「イマドキのIDE事情 29 EclipseでScalaプログラミング!」を参考にしてみた。

いろいろいじってみると、記事中に紹介されているTestPadがコンテキストメニューに出てこない。さらに、同じく紹介されているインタプリタの方は、一瞬コンソールに表示しようとする努力が見られるのだが、速攻で消えうせて何事もなかったかのようになってしまう。EclipseのバージョンはGalileo。さらにテンションが下がる。でもクヨクヨしない。

まあ、コード補完やその他の Eclipse の良い所はまあまあ使えるので、ある程度のコード量が増えてきたら便利になってくるだろうと思う。あとScala自体が普及すれば、それに応じて品質も上がって来るのだと思う。

ここまで書いて思い出したが、前回までの記事でも書かれていたような、あるいはScalaを語る他の言説でもよく言われているような「オブジェクト指向と関数型の融合」みたいな言い方はどうなんだろう。GoF本の昔から、既に Dylan とか CLOS とかあって、古臭いというと言いすぎだけど、かなりありきたりな話だと思うんだが。

ちなみに上記の「パッケージスコープで関数を定義する」コードは、Eclipse IDE上でも同様のエラーになった。何がまずいんだろうなあ。

2009年7月28日火曜日

Erlang 練習1

並列処理が得意な言語という事で Erlang というのを調べ始めたら、こんな良サイトを見つけた。→「Erlang World」 並列の手前まで読んだところで、ちょっとコードを書いてみた。最近使った数学の問題集でちょうどシンプソンの公式が出てきたので、これを Erlang で書いてみる。被積分関数は 4 / (1 + x^2) で、これを0から1まで積分するとπ(パイ)が出るが、2000等分のシンプソン法で近似値を求めるコードを以下のように書いた。
-module(simpson).
-export([integral/1]).

-define(Start, 0).
-define(End, 1).
-define(Steps, (1000 * 2)).

-define(DeltaX, ((?End - ?Start) / ?Steps)).
-define(XOf(Index), (?Start + Index * ?DeltaX)).

integral(F) ->
    sum(F) * ?DeltaX / 3.

sum(F) ->
    sum(F, ?Steps - 1, 4) + F(?XOf(?Steps)).
sum(F, Index, _) when Index == 0->
    F(?XOf(0));
sum(F, Index, M) ->
    sum(F, Index - 1, 6 - M) + M * F(?XOf(Index)).
結果は以下のような感じで、だいたいOK。
170> c(simpson).
{ok,simpson}
171> F = fun(X) -> 4 / (1 + math:pow(X, 2)) end.
#Fun<erl_eval.6.13229925>
172> simpson:integral(F).
3.1415926535897998
最初に書いたときは、ガードで分けた関数にたくさん重複コードを書いてしまっていたり、他にもかなりゴチャゴチャした汚いコードだったが、いろいろ調べて工夫してリファクタすると、少しはすっきりした。ちなみに新しい被積分関数 x^2 を渡すと以下のようになり、
174> F = fun(X) -> math:pow(X, 2) end.
#Fun<erl_eval.6.13229925>
175> simpson:integral(F).
0.3333333333333335
筆算で得られる値、1/3 に近い出力を得た。 並列が入ってないけど、最初だからこんなもんかな。次はまた同じシンプソンの公式をネタにして、両端の値の計、奇数項の値の計、偶数項の値の計をパラレルに計算して、合流したところで合算して h / 3 を掛けるようにしてみよう。まあ、まだ並列の辺りの解説は全然読んでいないので、そんな方針でいいのか判らないけど。あと Java と連携できるのかも調べてみたい。

2009年7月26日日曜日

Scala 練習2

先日に引き続き、ITProに載ってる Scala 講座の、「第2回 Scalaの基本的な文法」をやってみる。 今回のポイントは簡単な変数宣言から簡単な関数の定義まで。ハイライトは高階関数とパターンマッチングといかにも関数型言語風の再帰処理。いろいろ疑問も生じるが、そのうちわかるのだろうと、とりあえず最後までやってみる。掲載されているコードは、特に問題なく動作した。 復習のために、今回で紹介されていた事と、検索でたどり着いた他のサイトから得た少々の知識を使って自主練習してみた。以下、分散を求めるコードを、まず再帰とパターンマッチングを使って書く。次に、これを高階関数を用いるパターンに書き直してみる。更に現時点の手持ちの知識で書き直して、いろいろ試してみる。 1.高階関数なし まず単純にList中の要素の合計を求める sum() 関数を定義してみる
def sum(l:List[Double]):Double = l match {
 case Nil => 0
 case head::tail => sum(tail) + head
}
各要素について平均値との差の2乗を計算しリストを生成する varianceSub() 関数を以下のように書く(これは後で直す)
def varianceSub(list:List[Double], average:Double):List[Double] = list match {
 case Nil => Nil
 case head::tail => Math.pow((head - average), 2) :: varianceSub(tail, average)
}
最後に、varianceSub() で求めたリストの平均値を算出して分散を求める variance ()関数を書く
def variance(list:List[Double]) = {
 average(varianceSub(list, average(list)))
}
2.高階関数を使ったやつ 上記コードを無名の高階関数を使って書き直してみた。
def sum2(l:List[Double])(f:Double=>Double):Double = l match {
 case Nil => 0
 case head::tail => sum2(tail)(f) + f(head)
}

def variance2(list:List[Double]) = {
 val avg = sum2(list)(elem => elem) / list.length
 sum2(list)(elem => Math.pow(elem - avg, 2)) / list.length
}
高階関数ありと無しの二つのコードで、以下のように同じ結果が得られる事が確認できた。
scala> variance(List(46.1, 52, 48.5, 46.5, 46, 44.8, 48.5, 53.4))
res60: Double = 8.169375
scala> variance2(List(46.1, 52, 48.5, 46.5, 46, 44.8, 48.5, 53.4))
res61: Double = 8.169375
3.標準のList操作関数を使ってみる sum2 のようなのはList操作関数としておそらく標準的に提供されているに違いないと考え、検索してみると、やはりある。そこで variance2() 関数を sum2()を使わないパターンで書き換えてみた。
def variance3(list:List[Double]) = {
 val avg = list.foldLeft[Double](0) {(sum, y) => sum + y} / list.length
 list.foldLeft[Double](0) {(sum, elem) => sum + Math.pow(elem - avg, 2)} / list.length
}
4.タプルを使ってみる ここまでのコードは、平均値を算出するときと、差の2乗値 を算出するときの2回往復分リストを走査しているが、本来は、行きで平均値を算出し戻りで差の2乗を出せるはずなので無駄がある。但しこれをやるには、差の2乗と一緒に平均値も同時に関数の戻りとして返す仕組みが必要になる。そこで調べてみると、タプルというものを使って複数の戻り値を返せるというので使ってみた。 まずリストの「先頭→末尾」方向に走査する際に合計を出しておき、末尾(case Nil のところ)で平均値を算出し、これを Tuple の要素1に入れておく。折り返して「末尾→先頭」方向に戻るときに、この平均値を使って差の2乗を算出し、これを足しこんで要素2に保持しておく。
def variance4(l:List[Double], sum:Double, len:Double):Tuple2[Double,Double] = l match {
 case Nil => new Tuple2[Double, Double](sum / len, 0)
 case head::tail => x(tail, sum + head, len) match {
  case Tuple2(avg, sum) => new Tuple2(avg, sum + Math.pow(head - avg, 2))
 }
}
最終的に関数が終了したときに返されるのは、差の合計を保持する Tupleオブジェクトなので、ここから分散を得るにはTupleの要素2を取り出して、要素数で割る必要がある。適当に関数を定義してもよいが自明なので省略。下のような結果が得られ、正しく動作している事が確認できた。
scala> aList = List(46.1, 52, 48.5, 46.5, 46, 44.8, 48.5, 53.4)
aList: List[Double] = List(46.1, 52.0, 48.5, 46.5, 46.0, 44.8, 48.5, 53.4)

scala> variance4(aList, 0, aList.length)._2 / aList.length
res103: Double = 8.169374999999999
上記コードのように戻り値を二つ返す際にTupleを使う場合に、毎回 new しているのが気になる。Tuple がイミュータブルにできているようなので、このように書かざるを得なかったが、今後マシなやり方を探してみたい。

2009年7月25日土曜日

ワークフローパターン 1

BPMN 1.1 仕様の10.2節から、ワークフローパターンに関連する記述が始まる。
ただし、ここで使用されているパターン名は、2003年辺りの古いパターンカタログに基づいていて、最新版のカタログとは少し違いがある。違いについて調べておいたので、以下にまとめておく。

10.2.1 Normal Flow
  • #1:Sequence :変わりなし

10.2.1.1 Forking Flow
  • #2:Parallel Split :変わりなし。
    (メモ) BPMN では、"uncontrolled flow"、"forking gateway"、"parallel box"を使った、三つのバリエーションを紹介。

10.2.1.2 Joining Flow
  • #3:Synchronization :変わりなし
    (メモ) BPMN では、Parallel Gatewayと"parallel box"を使った、二つのバリエーションを紹介。

10.2.1.3 Splitting Flow
  • #4:Exclusive Choice :変わりなし
  • #6:Multiple-Choice → #6:Multi Choice
    (メモ) BPMN では、アクティビティから直接条件付フローを出すのと、Inclusive Gatewayを使うのと、二つのパターンを紹介。

10.2.1.4 Merging Flow
  • #5 Simple Merge :変わりなし
    (メモ) BPMN では、"uncontrolled flow"と"Merging Gateway"を使う二つのパターンを紹介。
  • #7 Multiple Merge → #8 Multi-Merge
    (メモ) WCPサイトのFlashを見ると、凄く分かりやすい。
  • #8 Discriminator → #9 Structured Discriminator
    (メモ) 今のカタログには単なる"Discriminator"はなくて、"Structured Discriminator"、"Blocking Discriminator"、"Cancelling Discriminator"の三つが載っている。"1-out-of-M join"という別名が紹介されている"Structured Discriminator"が、もとのDiscriminatorに近いのだと思う。
    ちなみに カタログをみるとBPMN1.0での対応は不完全とされている。BPMN 1.1との違いを再確認する必要があるかも知れない。
  • #9 Synchronizing Join → #7:Structured Synchronizing Merge
    (メモ) カタログに別名として"Synchronizing Join"と記述があるから、この対応だろう。
  • #8 N out of M Join → #30 Structured Partial Join
    (メモ) カタログから、"N out of M Join"というパターン名が消えている。現在のパターンでは、多分これが相当する。結構、印象に残るパターン名だったんだが・・・

10.2.1.7 Sequence Flow Looping
  • #10 Arbitrary Cycles → #16 Arbitrary Cycle
    (メモ) パターン番号と名詞の単複が違うだけだろう。

2009年7月24日金曜日

Scala 練習1

ITPro で Scala 講座の連載を見つけたので、「第一回 なぜScalaなのか?」の通りにやってみる。

・指定サイトからのファイル入手からインストールまで、すんなり成功。ただ、動作確認のためバージョンを見る箇所で、記事中、2.7.1.finalとあるが 2.7.5.finalと表示された。バージョンが上がっているらしい。

・対話形式での実行 → 成功。試しにわざとfooと入力してみると、以下のようなエラーメッセージ

scala> foo
<console>:5: error: not found: value foo
foo
^


・スクリプトとして実行 → 成功。ここでも正しい記述の代わりに"foo"と書いて実行してみると、以下のエラー出力を得た。
(fragment of helloWorld.scala):1: error: not found: value foo
foo
^
one error found
!!!
discarding <script preamble>


・コンパイルして実行 → 成功。javaのクラスコードが二つ生成されるが、それぞれの役割は何だろう。特に"$"がついてるやつは?

・Carクラスを作るところで、記事の通りに「>scalac CarMain.scala」と打ちこむと、
CarMain.scala:3: error: not found: type Car
と言ってくる。「>scalac *.scala」としてみると成功。

・記事中に Car.scala を UTF-8で保存するよう指示があるが、試しにSJIS で保存して再試行してみると、デコード不能という事でコンパイル時に Java の IOException が発生。そこで「>scalac -encoding "sjis" Car.scala」として、encodingを指定してみると、SJISでも試行成功。

・Javaコードから使用するところの試行では、classpathに含めている scala-decoder.jar なるものが見当たらずコンパイル失敗。代わりに scala-library.jarを指定すると成功。scalaのバージョンの違いだろう。

・ついでに、カレント直下のディレクトリ src と classesを、それぞれソースディレクトリと出力ディレクトリに指定してみる。以下のようにやってみたらできた。
scalac -d classes -sourcepath src src\*.scala

----
連載目次はここ

2009年7月22日水曜日

Wikipedia の「ワークフローシステム」

ワークフローについて考えていて、たまたま wikipedia のエントリ「ワークフロー」にたどり着いたら、関連項目から「ワークフローシステム」にリンクが張ってある。閲覧してみたら、どうもおかしい。最新版は2008/11/22に最後に更新されたもので、英語版に無い日本語版独自のエントリらしい。

まず段落「主な機能」のところに列挙されている「ワークフローシステムが有する主な機能」からして、すでに怪しさ満載。既存の「ワークフローシステム」製品群のうち、どの程度に共通して言える事実なのかわからない。客観的事実ではなく、特定の誰かの特定の製品体験にのみ基づいた思い込みだけが並べられている。

またそれ以前に、粒度や観点の異なる項目が並置されていて、ぜんぜん整理されていない。「主な機能」として「決裁ルート、決裁ルート自動生成、決裁種別、フォーマット、経費申請、経費連携、勤怠申請、ファイル添付」と並べるなんて、これでは「主な果物」というお題に対して「バナナ、和歌山産みかん、焼きりんご、南国の果物、干しブドウ、以上終了」と答えるのと同じくらいナンセンス。

更に、この段落「主な機能」の下に、段落「決裁ルート操作機能」と段落「ワークフロー一覧取得機能」が続く(2007/09/06 に 220.145.250.67が編集)。「主な機能」に含まれなかった機能の詳述がいきなり始まってビックリするが、内容を見ると、いかにもある特定の製品にだけしか成立しない固有仕様が並べられている気配が濃厚。誰が何を根拠に書いているのか知らないが、箇条書きで項目を列挙するときの異様なクセが「主な機能」の記述と似ているところを見ると、IPアドレスは違うが同じ記述者かもしれない(断言できないが)。

最後に「ワークフローシステムのアーキテクチャ」の段落が続くが、これもまた変。「ワークフローアプリケーション」と「ワークフローエンジン」という形で、アプリとミドルウェアを分離するアーキテクチャは良いが、何故それを「一般的」と言い切るのか。実際にはワークフローエンジン用のミドルウェア製品を用いず、自前でフローを制御する仕組みをアプリケーション自体に持たせている製品がたくさんあるのが現実。

Wikipediaについては、特に国際問題に関連するエントリで編集合戦が起こったりしてトラブルが多いのは聞いていたが、技術系のエントリでもこの有様とは残念だ。自社製品の仕様やコンセプトを、他者を押しのけて「常識」の地位に格上げするために、Wikipediaを利用する事も多いのだろうと思う。あるいは1開発者が自分の主張を社内やチーム内で通す際、説得力を水増しするために使う事もあるかもしれない。

ところで、このエントリの一番最初の投稿(2007/04/12)を見ると、上述の「主な機能」の下に「代表的な製品」として、ディサークル社の「POWER EGG」というのが一つだけ載っている。誰が投稿したのか見ると 211.5.139.0 とあるが、これを Whois で調べると「ディサークル 株式会社」と出てくる。

というわけで、まあ、やはりディサークル社の方が宣伝のためにか情報操作のためにか、自分都合で立ち上げたエントリなのだろう。まあ気持ちはわからないでも無いが、余りにも偏向した内容を全然未整理の状態で載せるのは、いかがなものだろうと思う。

これまでWikipediaは読むだけだったが、ルールを覚えたら編集なんかにも参加してみようかと思う。余りにも酷い記事、特にIT技術に関する記事は、同じ業界で暮らす技術者としてちょっと不愉快。「ワークフローシステム」はエントリごと削除してしまうのが良いだろうが、他の項目については客観的な根拠や出典を要求するような形で少しずつ参加していきたい。

2009年7月21日火曜日

マクロ経済学入門

IT技術者がたずさわるたいていの仕事は、社会制度や慣習の一部をITに置き換えたり、あるいはその隙間にITをはめ込んでいく作業だけど、その社会を動かしている原理は主に「経済」だと常識的に言えるだろう。

だからIT技術者は、社会の仕組みについての知識(我々の業界で言う業務ドメインの知識)はもちろんの事、社会の力学としての経済学についても基礎的な教養として嗜んでいるべきという事になるはず。

というわけで、やや遅い気もするが経済学の勉強を始めた。で、当初の想定では適当な問題集でも解きながら、足りない情報はネットで集めるつもりだったものの、やってみるとネットには意外と良い資料が無い。そこで、入門レベルのものを探しに本屋に行き、日経文庫の中谷 巌著『マクロ経済学入門 (日経文庫)』というのを買って読んでみた。これがかなり良い。

GDPや三面等価の原則について、「何となく分かる気もするけど自信はない」といったレベルから入って、IS-LM曲線、マンデル・フレミング・モデル、AD-AS曲線、フィリップス曲線などについて、かなりスカっと納得した気分になれる。

著者がどういう人なのか良く知らないけど、もともと教えるのが上手いのか、それとも実際に教えてきた経験からツボを熟知しているのか、「だいぶ前のページに出てきたアレ、何だっけ?」といった、ちょっと理解がぼやけて始めた頃に、ちょうど良いタイミングで重要事項が繰り返される。対面して理解度を測りながらレクチャーを進めているような気配りがある。

まあ内容的に入門の入門だから、分かった気になれてしまうってのもあるだろう。それに簡単とは言っても、もう後一回は読んで、さらに問題集も解いて脳に定着させないと、すぐに忘れてしまうだろうし。やっぱ、ちゃんとマイルストーン設定して勉強しないとだめだ。

ちなみに、Amazonで調べてみたら、同著者の入門書で『入門マクロ経済学
』というのもあった。これはもう少し踏み込んだ本格的な「入門書」らしい。あと同じ新書のシリーズのミクロ経済学入門も買ってきて既に読了したが、これもなかなか良かった。また今度書こうと思う。

2009年7月20日月曜日

スクラム関連記事

InfoQ:スクラムマスターインタビューのコツ

スクラムそのものに関しては特に新しい事は書いていないと思う。Agile をたしなんでる開発者なら、ほぼ常識的あるいは感覚的に分かっている事を再確認するような内容。
ちょっと知らない言葉が出てきたので、調べておいた。
イテレーションマネージャ
名前から、反復型開発のマネージャなんだろうと言う事は想像できるが、『ThoughtWorksアンソロジー』の第6章「ところでイテレーションマネージャとは何だろうか」に詳しい説明が載っているようだから、機会があったら確認してみる。
また、iterationmanager.comなんてサイトもあって、"IterationManager.com's missions is to contribute to the overall development and body of knowledge・・・"なんて言ってるくらいだから、PMBOK の PMI がプロジェクトマネージメントの領域で果たしているような役割を目指しているのかもしれない。
あと、Martin Fowlerの「Planning and Running an XP Iteration」にも出てくる。2001/01の記事だから、けっこう昔からある言葉らしい。
フィボナッチスケール
要約すると、Agile開発の見積りに使われる技法に point を用いる方法があって、これは時間単位ではなく feature 間の相対的なサイズを直感的に point で表現するやり方なんだけど、この point にフィボナッチ数列から取った「1,2,3,5,8・・・」という値を振っていくというもの。指数関数を使っても似たような効果が得られそうだけど、整数に限定して例えば2のn乗とかにすると増え方が急すぎるし、有理数に広げて例えば3のn/2乗などにすると面倒くさいし、やはりフィボナッチくらいが丁度良いのだと思う。
Aye Conference
ここが本拠地→「Aye Conference
一見、老人ホームとか宗教団体って感じに見えないこともないが、主にシステム開発・IT分野での問題解決技法と創造性向上のためのプログラムらしい。以前、プロジェクトに入っていた開発会社で「すごい会議」というのに参加した事があるが、多分、似たようなものなんだろうと思う。

CSM/CPOトレーニング
CSM:Certified ScrumMaster
CSPO:Certified Scrum Product Owner(記事ではCPOと書かれているが)
ScrumAllianceという組織が認定しているもので、トレーニングも開催しているとの事。
ここ→「Scrum Alliance: Training & Certification

2009年7月19日日曜日

日本語検定2級 合格

一昨日(09/07/17)、日本語検定サイトで合否発表が始まったので見に行ったら、受験級の2級に認定されていた。まあ、今回はほとんど無勉で受かったが、上の級はそう簡単にはいかないと思う。

日本語文章検定(以下、文検)のところでも書いたけど、技術者の仕事は毎日かなり大量の日本語を読み書きすることになるから、国語力も技術者の重要なスキルなんだろうと考えている。そういう意味で、この検定も文検(当分休止らしいが)と同様、国語の勉強のマイルストーンとして有効だと思う。

ただ、受験者が言う事ではないかもしれないけど、2級受けた感じだと、もう少し社会生活上の実践力にウェイトを置いても良いと思った。

例えば、速く読むスキル。技術者に限らず、ホワイトカラーならメールやら専門書やら、毎日大量の文書を読んでいるはずだけど、ここにも計測可能なスキルの差が各個人間に存在すると思う。長い文章から必要な箇所を最短時間で見つけ出したり、あるいは全体の構造を素早く把握して偏りなく要約する能力だとか、この辺りは実践面での必要性と計測可能性のどちらもありそうなので、出題されてもいいかなと。

それと簡単な言葉で表現する能力。たぶん上位級では、難度の増した語彙レベルの日本語が問われるのだろうけど、逆に社会の現場ではほとんどの場面で、高度な概念を簡単な日本語で説明する能力の方がより有益とされているはず。上手に例える能力なんかも、簡単に表現するスキルの一つだと思う。ただ、これはちょっと試験問題にはしにくいかもしれないが。

文の構造に関するスキルもある。音楽の分野だと楽式論というのがあって、曲の構造に着目して、細部から分析したり全体構成の面から観察したりする形式知の体系がある。音楽家は一旦それを標準的な知識として取り込んだ上で、自己の個性に応じてその形式知を運用していく事になるわけだけど、実用文章でも似たようなのではないかと思う。

一つの文の中で、それぞれの構文要素がどんな順番で並べられるか、また段落の中での文、文章全体のなかでの段落がどのように配置されるかに関する知識。そしてそれらの配置の違いからどのような効果が生まれるかなどに関する知識。これらは実務の現場で日々生産される文書の価値に大きな影響を与えるはず。こういったスキルについても、適切に計測する手法があった方が良いと思う。

できれば上位級の試験が、こういったスキルが問われるような出題だと、勉強のモチベーションも上がって嬉しい。

あと、この検定の範囲外かもしれないけど、「読む」「書く」の他に、「聞く」「話す」のスキルを測る仕組みもあって良いはず。話を聞いて意味を把握・記憶する能力、特定のお題について紹介・解説・説明・講釈する能力、またそれらに加えて、議論を通じてベターな解を得る能力などについても、何らかのスキルを測る物差しがあれば、もっと良いと思う。これと上に書いた事を含めて、はじめて「日本語の総合的な運用能力」なんじゃないだろうか。

次の試験は、11/07。申込は、08/01~10/09。この試験は、ある受験級について、得点率に応じて「認定」と「準認定」の段階で評価される。例えば準1級というのは、1級受験者の得点率が、認定には至らないものの一定の基準を超えている場合、1級の準認定として与えられる。

次はこれ。準1級を狙ってみようと思う。あえて1級ではなく。

2009年7月16日木曜日

All-In-One Trac プロジェクト作成

本日ダウンロードした版で、以下のようにプロジェクトを作成しようとしたが、

>create-trac-env wfproto wfproto

なぜか新たなプロジェクトが生成されていない模様。

コンソールに出力されているログを見ると、PROJECT_ID=default とある。
そこで、

set PROJECT_ID=wfproto

のようにPROJECT_IDを明示的に設定してから、上記のようにコマンドを
叩いてみるとうまくいった。

2009年7月12日日曜日

日本語文章能力検定2級合格

6/21に受験した日本語文章検定の2級に合格した。合格率16%という事で、半々くらいの確信しかなかったので、ちょっと安心した。

◆ この検定を受けてみたもともとの動機は、情報処理技術者試験の午後Ⅱ論説の準備をするのが第一だったけど、過去問題を中心に作文練習をしていると、情報処理技術者試験にとどまらず、IT技術者の日常業務全般に良い効果がある手ごたえを感じた。

技術者の仕事には、テクニカルライターではなくとも、かなりの量の作文が含まれるわけだけど、にもかかわらず、作文はおまけのように考えられている節がある。IT技術者の職能とは、プログラムを作成したり、何かを設定したりして何かを動かす事が主であって、作文などは取るに足らない瑣末な事と考えられているから、下手な作文をしても反省しないし、誰も突っ込まないし、したがって上達もしない。

で、それに自覚したとしても、作文練習なんてものすごく億劫だし面倒くさいし、やる気がおきないし続かない。というわけで、モチベーションを維持するために、客観的・合理的なマイルストーンが欲しいわけだけど、この資格がそれにちょうど良かった。身に付けたい作文力の方向性とテストの方向性が、ちょうど良く一致していた。

◆ テストの資料としては、過去問題集と「徹底解明」という参考書を使ったのだが、この「徹底解明」の冒頭に「本書に寄せて」というタイトル書かれている検定の趣旨が、非常に共感できるものだった。

要するに、「文学作品の読解に偏重した現代の日本語教育は、特に国際社会の場においては、実戦力に乏しく教育の効果が乏しい。だから日本語文章能力検定が、その弱点を補完する。」と言っているのだが、国語教育の批判については非常に同意できるものがある。技術者の日常でも、客観的事実と主観・情緒・感想が弁別されていない技術報告を、現場で大人の技術者が書いたりするのを頻繁に見かけるのだが、やはり書くスキルの訓練が本当に不足しているのだろうと思う。

教育に関する専門的な事は分からないけど、日ごろから国語教育は再構成したらどうかと思う。例えば、古典の全体と、現国のうち文学に相当する部分は、「文学」って科目にまとめて、音楽や美術と同じカテゴリに位置づけた上で、芸術系科目として選択制にすべきじゃないのか。

詩や小説は、専門家としてその道に進みたい人を除いて、完全に遊びの世界だから、数学や化学や政経と同じように扱うのはおかしい。そうやって、現国から趣味と遊びの部分を除去した上で、体系立った「書く訓練」を追加増量して、なおかつ「話す訓練」と「議論する訓練」を追加するのが、学問の基礎としても、社会的実践の面でも、どちらにも効果があるような気がする。

◆まあ、 そういった個人的な思いはともかく、とりあえず今回の2級の試験に合格したのは、ちょっと嬉しかったのだが、なんと驚いた事に、次回以降の文検が休止になる事が文検公式サイトでアナウンスされていた。

どうも、例の漢検スキャンダルに関連しているらしく、試験の運営に協力していた漢検サイドが、文検サイドと手を切る事になり、文検協会が立ち行かなくなったらしい。なんとも残念。経歴書に箔をつけるような意図はそもそもなかったから、資格の権威としての面は別にどうでもいいけど、作文練習のマイルストーンがなくなるのがちょっと困る。これは、なるべく早く復活して欲しいが、ちょっと無理っぽい気配もするなあ・・・