平々毎々 (Hey hey, My my)

2008年4月29日火曜日

あなたのエディタで.NET開発

ハッカー気質の人にしてみれば自分の使い慣れたエディタで開発したいわけで、Visual Studioみたいに汎用性もないくせにやたらとデカくて重いIDEを強制させられるのは悪夢以外の何者でもない。
……と、いうことなのではないか。

いや、何が言いたいかというと、.NETのつまみ食いをしようと思った時にVSが障壁になってしまって、結果として敬遠されている面もあるのかなと。

もちろん、Visual Studioは使わなくたって開発できる。MSの技術カンファレンスやWebCastを見てても分かるが、MSの中の人でもたまにEmacsを使ってデモをしている人もいる。
# ITゼネコンな仕事でチーム開発をしている立場としては、Visual Studio縛りというのは（しょぼい独自フレームワークとか独自ツールとかを押し付けることを考えれば）かなりマシな方だと思うのだけど、それはまた別の話。

ってことで、たとえばVSを使わず、もっと言うとmsbulldも使わず、素のcscを使ったり、あえてmakeとかantとかから呼び出したりするサンプルとか、たとえば「連載：好きなエディタでSilverlight」みたいな企画はどうか。

MSも動き出しているんだね。

Perfumeと中二病 (Young, Alive, in Love)

「Duft Punkカコイイ! Perfumeパクんな!」: ……中二病
「Duft Punkメジャーすぎ! Perfume興味ない」: ……高二病
「Perfumeと中田ヤスタカはクール」: ……大二病
「のっちかわいいよのっち」: ……オッサン

こうですか！？わかりません！

そろそろTable Moduleについてひとこと言っておくか (overflow)

Table Moduleを語るにはDomain Modelのことも語らざるを得ないわけで、そんな頃にドメイン駆動が出たから買って読んでおり、まあ無駄に長い本で読むのに苦労し、くやしいからドメイン駆動の感想みたいなのもブログのネタにしようと準備していて、そしたらTable Moduleの方はすっかり手が止まってしまっている訳で。
先にドメイン駆動の方を片付けてしまう予定。

2008年4月21日月曜日

クライマックス刑事

ネタバレする気はないけど、一言感想だけ書いておく。

面白かったよ。でもね、もともとVシネマだった事を忘れてはいけないと思うんだ。

2008年4月18日金曜日

日立デザイン本部

本日、仕事で赤坂の日立デザイン本部を見学してきました。

「画面設計ソリューション」というのを持ってるということだったので話を聞きに行ったのですが、ソフトウェア製品とかツールというのではなく、要件定義工程で提供するサービスの名称でした。

日立のデザイン本部は家電デザインから始まり、昨年で50周年を迎えた組織なのですが、 1985年からはGUI、1994からはWebも対象としているとのことです。

事例としては、

などがあります。

説明を受けた内容はものすごく真っ当でした。ユーザを理解し、具体的なペルソナを想定してシナリオを作り、プロトタイピングとユーザー評価を繰り返し実施し、画面設計の標準を策定し、それを元に全画面設計を行う、まさに教科書通りの進め方。日立デザイン本部には黒須教授がいると言えば分かる人もいるでしょうか。

オフィスに併設されていた「ユーザビリティ・ラボ」も見ました。本当にマジックミラーで仕切られているんだ！と変な所で興奮しました。

説明の中で心に残った点を列挙します。

デザイン本部は150人ほどだが、日立グループの中で考えると小規模。
デザイン本部は業務横断組織だが、その中でも分野ごとの担当がある。
- プロダクト（家電、公共機器、産業機器など）
- コミュニケーション（情報機器、ソフトウェアなど）
- ヒューマン・インタラクション（新規デバイス研究など）
- ユーザー・エクスペリエンス（ユーザビリティ評価など）
- サービス・イノベーション（新しいビジネスやサービスの考案）
お客様にユーザビリティ（利用品質）の価値を理解してもらうのはやはり大変。経営層に働きかけて、業務改革の一環として理解してもらうのがよい。
ノウハウをドキュメントなどに落とし込む（形式知化する）ことも大事だが、組織としての暗黙知をメンバー全員で共有することも重要と考える。
ファシリテーション能力が重要。
高レベルなサービスを提供できなければならないので、全員参加のトレーニングコースなどを定期的に行っている。

日立デザイン本部の50年に及ぶ歴史は、この本にまとめられています。

ソーシャルイノベーションデザイン―日立デザインの挑戦

作者: 紺野登
出版社/メーカー: 日本経済新聞出版社
発売日: 2007/12
メディア: 単行本

PS
日立ユニバーサルデザインのブログもありました。

2008年4月11日金曜日

C#で関数型: Unfold

関数型言語にはUnfoldという関数が用意されていることが多い。Schemeだとこんな感じ。

(unfold p f g seed tail-gen) ==
   (if (p seed)
       (tail-gen seed)
       (cons (f seed)
             (unfold p f g (g seed))))

これをC#に直訳する。ただし、tail-genは無視する(optionalなので)。

public static IEnumerable<U> Unfold<T, U>
(
  Predicate<T> p,
  Func<T, U> f,
  Func<T, T> g,
  T seed
)
{
  if (p(seed))
    return Enumerable.Empty<U>();
  else
    return Cons
    (
      f(seed),
      Unfold(p, f, g, g(seed))
    );
}
 
public static IEnumerable<T> Cons<T>
(
  T car,
  IEnumerable<T> cdr
)
{
  yield return car;
  foreach (T element in cdr)
    yield return element;
}

これって、結局こういうこと。(そして、C#には末尾最適化がないのだから、必ずこう書くべきだ。)

public static IEnumerable<U> Unfold<T, U>
(
   Predicate<T> p,
   Func<T, U> f,
   Func<T, T> g,
   T seed
)
{
   for (T i = seed; !p(i); i = g(i))
      yield return f(i);
}

だったら、パラメータの順番を変えたほうが、Unfoldを呼び出すときにIntelliSenseが効いてうれしい。

public static IEnumerable<U> Unfold<T, U>
(
   T initial,
   Predicate<T> until,
   Func<T, T> next,
   Func<T, U> convert
)
{
   for (T i = initial; !until(i); i = next(i))
      yield return convert(i);
}

C#にわざわざUnfoldを用意する必然性はあるのだろうか。自分でも考えてみる。
そうだな、匿名メソッドやラムダ式ではyieldが使えないけど、それで困るようなシチュエーションならFoldとかUnfoldとかその類のメソッドがあると便利。
でもより重要なのは、きっとDLinqやPLinq(んー、でもUnfoldを並列処理するのは難しいか)みたいな世界に簡単に対応できるというポテンシャルなんだろう。そういう意味では、今現在での意味は薄いのか。

2008年4月8日火曜日

404 Table Module ないわー (そろそろTable Moduleについてひとこと言っておくか) (2)

前回のエントリにひがやすをさんからコメントをもらった。

DataSetは
org.seasar.extension.dataset
で一応実装されてます。

ひがさん、ありがとうございます。
しかしながら、JavaでDataSetを実装するエントリで時間を稼ぐという目論見はあっけなく崩れ去ってしまった。

さて、Seaser2のDataSet実装を使って話を進めようと思うが、今回のネタのためにSeaser2を使うのはちょっと重装備すぎるように思ったので、DataSet実装だけ切り出してみた。ファイルはここに置いた。
元ファイルに加えた変更点は：

ログ機能は削除

リソースからメッセージを取得する機能も削除

それに伴い、SRuntimeExceptionとSSQLExceptionを使わないように修正

Beanを使ってDataTableをセットアップする機能を削除

といったところ。

2008年4月7日月曜日

戦わないプログラマ＠はてな

leptonさんがはてなダイアリーに。memo.

2008年4月5日土曜日

そろそろTable Moduleについてひとこと言っておくか(1)

まずひとこと。このシリーズではJavaを使うよ！

ビジネスロジック部分のパターンとしてMartin Fowlerの"Patterns of Enterprise Application Architecture"(以下、PoEAA)で挙げられているのが、"Transaction Script"、"Table Module"、そして"Domain Model"。
ビジネスロジックについてはこの分類に沿って語られることが多いのだが、ほとんどの場合Table Moduleはいらない子扱いされている。
「んー？Table Module? なんか.NETのやりかたでしょ？うちらはJavaで(Spring|Seasar2)でDomain Modelだから関係ないしー」
まあ、確かにDomain ModelでやれてるんならTable Moduleはシカトしてもいいけど、でもTransaction Scriptで頑張ってるんなら、そしてDomain Modelがハードル高いと感じているのなら、Table Moduleにも目を向けたほうがいいんじゃないの？

とはいっても、Javaでの実装の仕方が分からん。
分からんけど実装してみよう。というのがこのシリーズだ。

まずは、.NETのTable Moduleで使われている(とされている) DataSetをJavaで使えるようにしてみる。