Seasar Conference 2007 Autumn 参加レポート

event Seasar

まず、お会いできた人にidトラバを乱射。

会場に着いて、まずお会いしたのが、サイオスのお三方、id:bose999さん、id:yousukeharaさん、id:kacchi123さん。ブースのスタッフをしておられました。

結構早めに会場に着いたので、フラフラしていたらid:dewaさんに声を掛けて頂きました。そこで、id:taediumさん、id:jfluteさんと共に、DBやJiemamyまわりのお話ができました。

セッション間の移動時間、id:kompiroさんと（どこかに居るだろうとは思っていたのですが）ばったり。テストのモック話をちょろっと。

自己紹介せずに、私から一方的に質問をしてしまったのは、演者のid:y-komoriさん。Uruma(旧S2JFace)のEclipse Plugin対応について、少しだけお話をさせて頂きました。

そして懇親会。最初のテーブルでご一緒させて頂いたid:t_yanoさん、id:tonocchiさん、id:tarchanさん、mouriさん。また、mixi等でご連絡を頂いていたid:tagui99さん。やっとお会いできました〜。

前からお話してみたかったid:habuakihiroさんですが、飲み会終わりにご挨拶をさせて頂いただけになってしまいました。また次の機会にゆっくりお話させて頂きたいなと思っています。

その後、なんとなく二次会についていき、id:higayasuoさん、id:nowokayさん（きしださん）、id:Yoshioriさん、onkさんと同席。Java-jaの面々に打ちのめされましたｗ こんな面々にハカー薬剤師とか呼ばれていたとは…。何度も言いますが、自分、ハカーにはまだまだまだまだ遠い存在です(汗) と、とにかく、良い刺激になりました。自分はまだまだということで、やる気満々です。

みなさん、これからもよろしくお願いいたします。

そしてセッションレポート。聞きたい演題は山ほどあったのですが、結局これを聞いてきました。

S2Flex2

前提知識として分かっているつもりになっていて、実はほとんど分かっていなかったFlex2。この手のソフトウェアにしては安めとは言えど、個人で手に入れるのにはちょっとキツいFlex Builderを持っていない為、あまり体験できていなかったのが敗因。

セッションでは実例も交えて色々な物を見せて頂いたので「こんなものが作れる」という事にはwktkできました。が、「こうすれば作れる」という部分がうまく飲み込めなかった為、ちょっと勉強不足だったなぁ、と反省。色々調べて、もう一度スライドを見直したいと思います。

  • TODO: LCDS, ALivePDFについて調べる。

Uruma(旧S2JFace)

間違って、2006年のスライド資料を印刷して持ってきてしまったのは秘密ですｗ

Eclipseプラグインを作ってるので、飲み込みやすいセッションでした。RCPを使う場合は、かなり使えるんじゃないかな、という感想を持ちました。前半に書いた通り、Eclipseプラグインへの対応を質問させて頂いたら、今後対応していくというお話でした。そうなったらJiemamyに取り入れてみるのも面白いかもしれません。（ただ、一度作り込んでしまったインターフェイスを、あらためてUrumaにする必要はあるのか…？ｗ）

セッションの大部分は理解できたので、「アレのplugin.xmlはどうなってるんだろう…」などの疑問がわきました。というわけで…

  • TODO: サンプルアプリをDLして中身を眺める。

テストは人のためならず

テスト駆動開発(TDD)には随分前から興味を持っているのですが、未だに踏み込めていない分野です。セッションの内容としては、比較的初心者向けの内容だったと思います。その為、楽に聞くことができました。

ただ、やはり「実際に踏み込んでいない分野」なので、感覚的に分かっていない事もあります。例えばこんな。

  • そもそも、具体的・実用的なテストの書き方が分からない。「例」として見ることができるレベルまでは理解しているが、現実にはどんなテストケースを書くのだろうか？ この辺は、他人のテストコードを読んで感覚を掴むしかないだろう…。
  • アジャイル開発では、しばしばリファクタリングが行われる。そのリファクタリングによるデグレ対策でもある「テスト」。そこで例えば「aaa()メソッド」があって「testAaa()テストケース」がある。リファクタリングによりメソッド名を「bbb()メソッド」に変更した場合、同時に「testBbb()テストケース」に直さなければならない。（直さなくても動くだろうけど、最終的に理解ができなくなる。） こういった追従って、結構面倒じゃないだろうか。
  • 上と同じような例で、あるメソッドから処理を「別のメソッド」として切り出したとする。そうしたら、新たに「別のメソッド」用のテストを追加しなければならない。逆に、切り出してあった複数のメソッドの粒度が細かすぎた場合は、メソッド同士が合併することもあるだろう。そうなった場合は、関連するメソッドのテストケースを全て書き直さなければならない。これも結構面倒じゃないだろうか。
  • Mockを作って…、とは言えど、Mockを作る為には現物（Mockに対する本物）に対する深い知識が必要ではないか？ つまり、情報隠蔽されていて、その内部構造は知らなくて良い前提であったのだが、Mockを作る為にはある程度内部を知っていないといけないのではないか？

この辺りって、どうなんだろうなぁ、ともやもやしたまま、現在に至る。

サンプルアプリのライブコーディング

前回のエキサイトが忘れられず、また聞きたくなったライブコーディングセッション。今回は、DBFluteのid:jfluteさんと共謀して面白い事を企んでいたようですが、上手くいかず。上手く行ってたらなぁ〜、と見ている側からしても悔やまれます。

その他、F5が効かずに新たなリソースがEclipseに認識されなかったり、起動したDB(H2)のプロセスがゾンビになって残ったり…。なかなか苦労がいっぱいのセッションでした。

後日談で「やりたいことの半分もできなかった」と仰っていましたが、SuperAgileのエキサイティング感は充分伝わりましたよ！

EMechaというプラグインが出てきたのですが、Doltengと統合して「Super Agile(Teeda+S2Dao+DBFlute)」というプロジェクトが作れるようになればいいのにな、と思いました。DoltengもEMechaも「Seasarを使うための環境構築をする」という同じフィールドで動くプラグインなので、問題はなさそうです…。

さらに、DBFluteのreplace-schemaやgenerateタスクなどもプラグインから実行。そうすれば、バッチファイルを起動させることもなくなり、設定後にF5を押してリソースを認識させるという作業も必要なくなるので、非常に一体感が出てくると思います。

OSSによるSIerの可能性（脱下請）

オープンソースとプロプライエタリの違いは何？ 機能（OS,RDBM,ブラウザ…etc）とプログラミング言語（C,Java,Ruby…etc）は全く同じで、違うのはライセンス（GPL,ASL…etc←→商用ライセンス）と運営者（個人,有志,NPO…etc←→営利企業）だけだよ、という話から。

そして思ったこと。というか、はぶさんのお話をそのままなぞるような感じですが…。

確かにそうですよ。ソフトウェア的に違いは無い。私はSI業界で働いていないので、かえってこういった「真実」がよく見えます。商用ソフトが信用できて、OSSが信用できない、なんて思った事は（最近は）一度もない*1。同時に、商用ソフトよりもOSSの方が質が高い（伽藍とバザール理論により）とも思わない。はぶさんが仰った通り、どっちもどっちだと思います。

ユーザ（非技術者）にとっては、商用もOSSの違いは「有償か無償か」という意味しか無いかもしれません。ただ、私は技術者であって*2、ソースを読む「語学力」を持っています。仮に質の悪い部分（例えばバグ）があったら、自分でコードを追いかけることができる。その可能性が「閉ざされているか開かれているか」という大きな違いがある。

まぁ結局、経営者にとっては「責任を自分で負うか、ベンダに負わせるか」という差になっていくのかな。その"経営者の考え"が、選択に大きく影響している。どっちが良いという問題ではなく、「責任（リスク）を負ってハイリターンを目指すか、リスクを負わず小さなリターンで満足するか」の違い。

ソースを読んでサポート体制を作れば、今まではベンダが得ていた利益を自分が得ることができる。売り上げを上げたいのならば、経営者はそうすればいい。やろうとさえ思えば、こんなに簡単に*3パイを奪えるのだ。

OSSかプロプライエタリかの選択権は経営者にある。しかし、その選択の結果、影響を受けるのは全員（経営者も技術者も）である。経営者は「責任を負わなくていい」のかもしれないが、同時に技術者は「ソースを追えなくなる」のだ。

OSS 商用ソフト
ソフトウェアとしての本質 商用ソフトと同じ OSSと同じ
ユーザにとって 無償(安い) 有償(高い)
技術者にとって ソースを読める・直せる ソースを読めない・直せない
経営者にとって 不具合の責任を負う 不具合の責任はベンダに負わせる

その他、メインフレーム時代、オープンシステム時代、オープンソース時代と、ソフト会社の歴史を振り返っていました。その辺りの知識に疎かったので、なるほどね。現在の多重下請構造というのは、メインフレーム時代に出来上がった負の遺産なのか。

しかし時代はオープンソース時代になった。ソフトを開発するだけならば、誰でも出来る世の中になった訳です。だから自分のような異端児ｗも発生する。だって、私だって技術力を身につけて、ソフトを作れるのだから。（メインフレーム時代〜オープンシステム時代だったら、さすがにソフト開発には手を出せていないｗ）

まぁ、ソフトが作れるのは良いとして、それが「商売になるか」というのは別問題ですがね。

それを成立させるのが「技術力」「営業力」「PM力」の3要素。自分が持っているのはまだ最初の1つダケ。最近の私の考えでは、とりあえず「商売をする」というところまで達する感じではないので、自分自身としては…

  • TODO: 技術者として、「技術力」を磨く。

*1:昔は頭を使わずに盲信してた時期も。まぁ当時はフリーウェアと呼ばれるソフトの質は（高いものもありましたが）低いものも多かった…。

*2:現在の生業は別として、スピリットとしてはｗ

*3:ってのは語弊があるか？ｗ