アジャイルプラクティスとGettingReal

Getting Realは、37signalsの人たちによって書かれています。
37signalsは、BackPackとか、BaseCampとかのWEBアプリケーションを開発し、サービスとして提供してる会社です。（だよね？）

アジャイルプラクティスは、その後に書かれた本です。
どちらもアジャイル開発についての手引きみたいな感じの内容ですが、ともに英語の翻訳なので、翻訳のされ方で若干、読者に伝わるニュアンスが違うのではないかと思います。

僕が読んだ感想で言えば、アジャイルプラクティスは、より現場サイドでの出来事を想定しているのに対して、Getting Realは、より哲学的な印象が濃い。

両方を読んで感じるのは、現場ってどこも大変だよなと。うまくいく開発なんて存在しないんじゃないかと思うぐらいです。うまくいっているように見えて中身が大変なことになっていたりすると思いますし。

結論になるかどうか分からないけれど、自分たちが携わっている開発は、情報社会の上に成り立つものであって、その情報社会がめまぐるしく変わる状況の中では、お客さんがそのとき良いと思ったもの、僕たちがそのとき、これだと思ったモノは、次の瞬間まったく意味をなさなくなることもある。だから、発注する側も受注する側も常に変わり続けることを前提としなければ上手くいかない。
工業製品として車を作ります、というシステムであれば、その最終の形が見えているわけで、それを出せばよい。でも、最終の形が見えていない、見えないものを作り出すシステムというのは、世の中の情勢とともに進化し続けるシステムとして成立させていくしかないんじゃないかと思います。

なので、作る側として、どんな小さな案件でも、小さなモジュールでも、より真剣にならないといけないし、お客さんと一緒に、さらにその先をしっかり見続けることが必要だなと思います。

GrailsでBDDとTDDの比較

Pluginを作ってみようと思って調べてたら、antを使ったサンプルがあったので、試してみようと。
[Java][Groovy] Grails プラグインの作り方 - シンプルな easyb 実行プラグインを作成

で、easybってなんぞやと、Javaのビヘイビア駆動開発をやさしく実現する"easyb"を試すを見て、へえー
、知らなかった。easybとはビヘイビア駆動開発（BDD）ですと。

テスト駆動開発（TDD）との違いも書かれているのですが、どっちがいいんだろうな〜。
お客さんから聞いた内容を、検査仕様としてまとめていきやすいのはBDDかなと。BDDはDSLで書くみたいだから、文章（ドキュメント）にはしやすい気がします。
無いものと言えば、TDDとしてのWEBTestのプラグインはHTMLとかファイルが出てくるけど、easyBのプラグインでは出てこない。出せるようにすれば良いんだけど。
面白いなと思うのは、Pendingという内容が書かれていない検査項目の数が出てくるところかな。

「こういう状況で(given)、こういう条件を満たしたとき(when)、このように振る舞う(then)」
だそうです。

でもって、初回、バージョンアップリリース直前とか、そういうときには、TDDで作ったテストを回した方がいいのかな。使い分けるべきか、使い分けられるものなのか、きっと山本氏が答えてくれるんじゃないかと。

GrailsアプリをMorph AppSpaceで動かしてみる

●morphでデプロイするPluginがあった....
参考はここです。
ゲンゾウさん作成のGrailsプラグインをインストールすれば、
grails deploy-morph
で終了です。

●DataSource.groovyの中に書くProductionのDataSourceについて
ここを参考にしました。
上記Pluginからデプロイさせればgrails install-templatesをしてweb.xmlを触る必要ないです。
自分は、これではまった後、Pluginを見つけました。
ちなみに下記のように書き換えました。（サンプルはMySQLだったのでPostgresに変えました）
production {
dataSource {
　　dialect = org.hibernate.dialect.PostgreSQLDialect.class
　　driverClassName = "org.postgresql.Driver"
　　username = "Username" //dashbord→database→show detail→username
　　password = "Password" //dashbord→database→show detail→password
　　dbCreate = "update"
　　url = "jdbc:postgresql://*Host*:5432/*Name*?CharSet=UTF-8"
}
}

●補足
morph_deploy.propertiesをMorphAppSpaceのControllePanelから落としてきて、Grailsアプリの直下に置きます。

morph.usernameと、morph.passwordを追記するapplication.propertiesファイルは、Grailsアプリ直下です。既存の内容の下に追記すればよいです。書いてないと、grails deploy-morphの後に、UsernameとPasswordを聞かれます。

●Grailsアプリ
http://mkawa.morphexchange.com/に置いてあります。
Bookのドメインクラスを作って、コントローラには、scffoldを書いただけのものです。

●動かしてみた感想
もっさり感がちょっと。認証付きの状態のアプリなら全公開でもいいけど、途中の段階で、全世界にお披露目するのは、どうなのかなと。自分のSubscription自体に認証かけられるといいんだけどなぁ。いちいちテストサーバ立てるのもめんどいし（もしくは空いてないし）、っていう面では重宝しそう。ただ、お客へのプレゼンツールとしては無理ですねえ。とすると、検証用のテストアプリとかそういうのを確認用として置くのはいいかもしれないな。Jettyみたいだし。何か作ったりした後、説明だけだと本当に動いてるか分からないし。これするとエラーでるんだぜっていうのを出したりとか？あと完成して、多少もっさりしててもいいからっていう場合？

●関係ないけど
domainClassに付加させたいものを、ゲンゾウさんのPluginにあるsrc/templates/artifacts/DomainClass.groovyを見て、いつも山本氏の言っているartifactsを使って「規約によるコーディング」をするんだい、というのが、そういうことなんだなと、なんとなく分かった気がする。意味違ったらごめんね。

CMSを探してみる

自分に合うか、合わないかで勝手に比較してみる。

●もともとCMSなツール

• Xoops
• Zope/Plone
• Confluence
• GoogleSites
  

●ブログツールをCMSとして使う

• MovableType
• WordPress

●手軽さ（設置までの楽さ）
だいたいどれも似ているが、全般的にブログツールの方が楽だと思う。
ドキュメントも多いし。

●デザインのカスタマイズの楽さ
これもブログツールの方が楽。自分はPloneのデザインカスタムで挫折したことがある。

●ユーザ認証（SNSっぽさを出す）
CMSツールの方がよい。MTでもWPでもプラグインで出来るらしい。あとBASIC認証すればよいとか。

●運用・管理
手軽さからいけばブログツール。ユーザ、コンテンツに細かい権限を与えるとか、するのであれば、それ自体がCMSの要求なので、頑張ってCMSを使いこなす。

●コスト
導入コストは、MovableTypeが商用ライセンス版ならかかる。あと、Confluenceもかかる。
あとはフリーだが、知識を必要とするから、それなりの人に頼むとか、自分で勉強するとか、考えると、結局はコストがかかる。立ち上げにどれだけ時間を割くかで考えた方がよい。あと運用面でも、サーバをレンタルするか、自前にするかでも変わってくる。

●GoogleSitesについて
簡単にSNS作ってみるかと思いつつ、触ってみたけど、手軽さと機能、使い勝手、という面でバランスが悪くて、中止。一番気になったのが、エクスポートが無いこと。やっぱり書き出せないのはつらいと思う。

●まとめ
ブログツールは、CMSよりになり、CMSはブログよりになってきているのかなと。
見た目にあまり拘らず、コンテンツをがんがん貯めていくのであれば、WikiであるConfluenceが一番。ただし、お金がかかる。
見た目もちょっとカスタムできて、なんとなく見栄えよく、それなりに、ならMTとかWPでいいのかなと。あんまり複雑にすると、メンテが大変になるので、バランスよくするのが大事。
それから、何にせよ、気合いは必要。

写植の「収める」技術

どなたか合理的なＤＴＰの仕事を下さいを読んでたら、いろいろと思い出した。

まだ会社が5人ぐらいだった頃、某組版ソフトメーカー大手の故Mさんが言っていた。
写植がプロフェッショナルな仕事だと言える理由は、「限られたスペースにバランスよく文字を収めることができる」ということだと言われたことを思い出した。
やっぱりセンスが問われる領域の職種だと思う。
今ならDTPアプリ上で編集者がちょちょいとやると思いますが、
昔は、ラフレイアウトとそこにかかれたQ数、書体、文字間、行間で指定されたものを発注主が納得いくようなセンスで、写植（版下も含む）をこなしていたと思うのです。
その方がよっぽど効率がよかった。
大先生のデザイナーさんの指示だったとしても、この方がいい、って言えるぐらい写植屋は強かったんじゃないかな。それぐらい組版というところに執着していた気がする。

だからやっぱりソフトの操作に執着してはいけないのです。
こうしたいという結果にたどり着く為の、あくまでもツールであるということです。
そして価格（工賃）は、落とすべきではなかった。
機械によるところではなく、人によるところだから。
製版とか印刷の類は、完全なオートメーション化や、明らかな工程の削減があったかもしれないが、写植で言えば、逆に手数が増えている。

アナログ→デジタル移行期に、業界としてこの劇的な変化に対応すべく、ちゃんとした協議が必要だったのだろうと思う。

今頃言っても仕方ないですが、どうも業界全体で足掻いているようで仕方がない。

モノを作り出すのは人であって、そういった人たちに合理化のフィルタをかけてしまっては、いいモノを作り出す環境はできるはずがない。もっとプロフェッショナルを育てて、業界全体が活気づくようなことをしないといけないと思う。今のままでは、理不尽さにやられてるだけで、モノを作り出す意欲さえなくなってしまう。
価格を絞るのは不景気だし、仕方がないかもしれない。でも、理不尽はいかんよね。
そして日本の本を外人に作らせるって、ホントにいいのかな。
本作りとか、チラシ作りも含めてクリエイティブさを取り戻さないといけないですね。

※故Mさんは、賛否両論で、敵も多かったですが、僕らは彼に支えられました。彼なくして今の会社はありえません。僕が印象に残っている言葉は、「そら、痛快やな！」。本人の出自はそれほどよくなかったと記憶しています。だから、僕らみたいなちっぽけな会社が少しずつ大きな仕事に取りかかれるようになっていくことを、とても喜んでくれました。

うーん、明日のプレゼン資料は、飛行機の中で書くしかないな。。。

X-DEV2008@目黒に行ってきました

目黒で2008年9月4・5日開催されているX-DEV2008に行ってきました。
といっても、見に行ったセッションは、２つです。
１．リクルートの川崎さんによる「マッシュアップ　×　エンタープライズ開発」
２．アンテナハウス村上さんによるCSSスタイルシートによるページ組版の可能性

１は途中からだったのですが、リクルートさんが公開しているWEBサービス用のAPIを使ったマッシュアップの話。
コマーシャライザーというWEB上でムービーとして流すCMを作れますよ、というサービスの紹介。こちらはネット環境の不具合で作るところは見えなかったけど、会社に帰ったら見てみようと思います。静止画であるJPEGと、テキストを合わせてムービーにする感じです。
携帯百景のノリで、ある画像と文字を合わせて、連続したムービーになってます。
どうなんでしょうか。。。自分は理解できてないかもしれない。それをブログに貼れますよ、というところ？まあ、とにかく後でみてみよう。
川崎さん個人プロジェクトのくるくるあいの方が面白かったかなと。
確かに、母国以外のニュースとかを自分の母国語で見るのは面白いかも。

２は、アンテナハウスさんのXSLFormatter改めアンテナハウスFormtterV5です。
CSS3で書かれたスタイルを取り込んで組版してしまうというものです。
従来のFOの書式では、やはりとっつきにくいところがありますが、CSSで書けるとなると、その敷居はかなり低くなります。
これがどういうことを意味するか？
印刷・出版業界からみると、顧客となる企業内でもコンテンツ管理が進んでいて、紙の需要（印刷するという行為）が減っています。多分紙よりもデータとして蓄積されていることの方が多いと思います。（重要文書は違いますが）ですが、今までは、それらのデータをさすがに紙にするとなると、ちょっと体裁整えてとか、用紙サイズとかマージンとか画像解像度とかあって、加工も含めて印刷会社に頼んでいたとします。（顧客にもオンデマンドプリンタが存在することが当たり前になってきているので、顧客としてはPDFだけでももらえれば、みたいな感じに思うかもしれません。）
また、データを加工するわけですから、校正もしっかりとやらなければならない。（Wordデータ入稿から校正なし、というのは今のところあり得ない）
そういった中で、例えばデータ配信がHTMLが先行するとなると、こういったCSSで書ける組版エンジンがあれば、WEB担当がそこまでできる可能性があります。
その方が、顧客にとっては、データが流用できるわけなので、良いことづくしです。
そうするとどうなるか、、、
制作会社は仕事がなくなり、印刷会社は、本当に刷るだけ、ということになります。
企画提案によって顧客獲得をしなければ、価格競争のみでは今日もう戦えない状態のなか、
企画提案する場所も与えられなくなる、ということになります。（極端に考えればですが）
これは、WEB関連を含むシステム業界が気付かないうちに、早急に手を打たないといけないですね。そう簡単に、入ってこれないと思っていたけれど、これはかなり早い段階で流れが変わる可能性がある、という危機感と、素直に、これはすごいなと思わせる、地味だったのにかなり後を引くプレゼンでした。