2008年2月29日金曜日

ブタとニワトリ

先日から、相方が強烈お勧めしていた
Amazon.co.jp: アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣: Venkat Subramaniam,Andy Hunt,木下 史彦,角谷 信太郎: 本
を読み始めました。

さくさく読めていけていい感じです。
今日読んだところで、おもしろい例えがあったんで、引用してご紹介。
スタンドアップミーティングについて書かれているところのコラムです。
Scrumでは、チームメンバーと非チームメンバーの役割を、それぞれブタとニワトリと名づけている。
チームメンバーがブタで、非チームメンバー(マネージャ、サポート、品質保証担当など)がニワトリだ。
ブタとニワトリという表現は、一緒にレストランを開こうとしている家畜の寓話にちなんでいる。
レストランで朝食にベーコンエッグをだそうとすれば、ニワトリも確かに手を貸すが、ブタにはコミットメントが求められる。
ニワトリは卵を産むだけでいいが、ブタの方は命がけだ。
Scrumでは「ブタ」だけが、スタンドアップミーティングに参加できる。

ぱっと読んだだけではイマイチ内容がつかめなかったんですけど、もう一回読んでみて納得。
ニワトリだけで会議や打ち合わせなどをやたら時間かけたのに、実際作業をさせてみたら思うよう進まない。 ブタは身を削って作業してるのに・・・ なぁーんてこと心当たりありません?
私はあるなぁ・・・ 私の立場って主にブタの方なんですけども・・ね。

この寓話、いい例えだなぁと関心しましたぁー。
しかし、Scrumでは本当にブタとニワトリって名前にしてるんでしょうか・・?
早速ググってみると・・・
@IT:SCRUMワークショップ体験記
という記事を発見。

・・・あ、

(注3) ブタとニワトリについては、読者がワークショップを受けるときまでの楽しみとして取っておくために、あえて触れない(筆者)


やべ、書いちまった。ごめんなさい。

ほかの記事をみてみると・・・ Scrumでは結構有名な話なんですね、コレ。いろんな所に書いてありました。
Chickens And Pigs


Blogged with Flock

• • •

2008年2月25日月曜日

Air正式リリース来たー!

Adobe Air正式リリース とうとう来ました!

待ってましたよーー。

Yahoo! Mail が (JavaScript使いまくりで?)重かったけど、Flushに移行して断然早くなった という話とか、ExtのAPIドキュメントが Airで提供されている話とか・・・聞くと、Airは無視できませんよね。

Extのサイトを見てみたら、ブログで Simple Tasks v2 - Multiple lists, NativeWindows and Reminders  というのを発見。


In collaboration with Adobe, one of the key additions in Ext 2.0.2 was Adobe AIR 1.0 support for running in the application sandbox. Also, the Simple Tasks AIR application sample was rewritten to take advantage of more of the native functionality in AIR and gained some cool custom Ext components that can be used outside of AIR.


内部はExtのJS+HTMLをそのままAirでパッケージングしたのと思うので、対応は簡単なんだろう とは思うのですが、反応早いなぁ~



Blogged with Flock

• • •

2008年2月19日火曜日

JWSのJavaアプリケーションキャッシュビューア

JRE5.0になってから、JWSの Javaアプリケーションキャッシュビューア のショートカットが自動的に作成されなくなりました。
起動するためには、JRE5.0の場合、JRE/JDK の bin/javaws.exe を実行しますが、JRE6.0の場合は JRE/JDK の bin/javaws.exe だけでは起動できないみたいです。(引数を指定しないとダメ・・でも引数には便利なものもありますね。)
以下のリンクを使用すると、出すことができるみたいです。
http://java.sun.com/products/javawebstart/apps/player.jnlp

こんなのあるの・・・知らなかった。手軽でいいですね、これ。
興味本位に このjnlpのファイルの中を見てみると

<?xml version="1.0" encoding="utf-8"?>
<!-- Jump specific JNL file for launching the player -->
<player/>

う、 これだけですか・・・。そんな仕様があったとわ。

Blogged with Flock

• • •

2008年2月14日木曜日

デブサミ 2日目

・・・に行ってきました。
今日は 2セッションのみ見てきたので、すでに会社に着いております。。

さて、1つ目は【14-E-3】SubversionとMaven 2による構成管理:バージョン管理・ビルド・リリース・自動化
まずはSubversion。構成管理のパターンからの説明でした。

1. メインライン ・・・ 基本の開発をするところ。 Subversionではtrunk。

2. リリースブランチ
会社の製品開発では リリースしたタイミングでブランチを切ったりすることの方が多かったのですが、話の中で、「リリース前でブランチを切る。リリース作業はそのブランチで作業する。もちろん、リリースチェック時に見つかったバグ修正は、メインラインにも戻す」というパターン紹介してくれました。
あー 確かになぁー と思うところが。 リリース という作業は、それなりに時間がかかったりもするんですが、その間、次の修正などが加えられなくて待つ・・・ってことありました。
リリース前でブランチを切ることにより、そういうことが回避されるわけですね。
リリースチェック時のバグ修正がやたら多いと手間になってしまいますが、そんな不具合が多い状態からリリース準備は普通しないでしょうし・・・ね。

3. タスクブランチ
実験的なコードを書いて試してみたりするブランチ。
採用!となったら、メインラインにマージ。
話の中では 普通ブランチっていったらこのイメージを持たれる方も多い・・・ 的な事を言っていたと思いましたが、(違ってたらごめんなさい) 私はしてませんでした。
これ・・・したいですねー。 何か始めるときに実験的なコードを書いて試してみるって結構な作業量が発生したりします。なんせ、"こうやろう!"と方法が決まっているわけでもないですし。
そんな実験的なコードって、今まではローカルでの作業でやっていました。
でもブランチ切ってやると、マージ作業も楽になるし、こっちのほうが断然よさそうです。

4.タグつけ
リリースタイミングなどで、タグをつける。 話にありましたが、重要だけど忘れがち。 その通り(笑)

スピーカーの方は ブランチは 1.0.x のように最後に x を付けて、タグのときに 1.0.0 としているとの事。
branch
    /1.0.x
    /1.1.x
tags
    /1.0.0
    /1.0.1
のような感じ。 これは 分かりやすくていいですね。

次はMaven2.
会社で丁度(やっとで?)ちゃんと導入してみようという感じになっている所なんです。
まず、”お、注意せねばな”とおもったのが、「POMは書き換えて実行するのはNG!」ということ。
プロファイル(-pオプション)を使ってやりましょう。
今まで、会社のオフィシャルな環境ではAntでのビルドをしていたんですが、個人でビルドするときにはAntの定義をちょこっと直してやったりしていることもありました。
リリース用のパッケージ、テスト用のパッケージ、テスト用の環境に接続しての自動テスト・・・とか環境毎のビルドの自動化はMavenをうまく使って・・・ 「みんな同じ環境、条件でBuild、テストしましょー!」って事ですね。まさしくその通り。

あと、話に出ていた "社内リポジトリ" 。 社内で蓄積した共有ライブラリとか置いておくのは、重要ですね。
社内の財産共有のためにも。 ○○使っていたけど、最新じゃないの!? なんて事が起きないためにも。

しかし、これも社内の開発環境がすべてMavenに移行できたら有効性が高まるけども、簡単に じゃー全部移行するか ゆーて出来るもんでもない。
スピーカーの人の会社では、2年かかったそうです。

といって、実際手を動かしてやってみないと分らないものでもあるので、時間に余裕がある時とかに色々ノウハウためていきましょう ・・・ というので シメでした。

セッションが終わり出口まで歩いている間に見かけたんですが、
管理者っぽい上司:どうなん? ウチでもコレつかって・・なんとかならんもんか?
作業者っぽい部下:いやぁ~、XMLで地道に描かないといけないしぃ・・・そんなスグにできるもんでも・・(困)
なんて会話が交わされていました。

現実の会社の象徴っぽい会話だなぁー と。
このツール使ったら便利そうやから、つかえや! と 管理者は当然思うと思うんですが、こぅいぅツールのノウハウは短期間で身につくものでもなく、全員が理解して使ってもらわないといけない部分も多く。。
会社全体が やるぞ! となってくれて、ノウハウを積む時間やリスクも考えてくれて・・・となって欲しい処ですね。


さて次は 【14-C-4】Inside JavaVM ~安定したシステム構築のための勘所~
こちらは・・・すいません、予想と違う内容だったんで、ちょっと残念でした。
「これからのアーキテクチャ」の内のセッションだったので、よけいに間違えやすかったんかなぁ。
内容としては、メモリのOld領域がいっぱいになるとFullGCが走って速度が遅くなる。
Old領域はSession情報が入るので、Session情報の容量と接続数などを考慮してOld領域がいっぱいになるタイミングのを計算で出す。メモリリークの検出はCosminexusでの機能の説明でした・・・。

期待していたのは、jconsole やhprof、jhat とか (J2SE5や6でより便利になったり、含まれるようになったりしたところ)するものとか、見方を変えて、JMX使って こんな感じ方法もあるよ とか・・・ あればなぁー なんて思っていました。

ということで2日目の報告でした。
あ、今日は 意識したせいか 女の人は多かった気がします。
あと、1日目よりも人は少なかったかなぁー。



Blogged with Flock

• • •

デブサミ 一日目

本日は デブサミ2008の第一日目でした。
行かれた方いらっしゃいますか?

今日は、少しばかりですがその模様のご報告をしたいと思います。

デブサミは目黒にある目黒雅叙園で行われました。
目黒に降り立ったことさえも無い私@方向音痴。
無事にたどり着けるかな~と不安でしたが、駅降りると 黒い行列が
あり、(男の人ばかりだと黒くなるので・・・)それについていくと無事に到着。
やっぱり、男の人多いですねー。女の人は1割もいなかったんじゃないでしょうか??
年齢層は・・・もっと若い人多いと思っていたんだけど、中間層ぐらいの人が多かったかな。。

最初に参加したのは  【13-D-3】リッチクライアント最前線
Adobe,Curl,Microsoftのパネラーの方と
モデレータの方による、ディスカッションでした。
AdobeはAir,MicrosoftはSilverlightを前面に押しだしたい!って時期だと思うんですが、まぁ・・・実際そんな感じの内容でした。
「Webアプリケーション」 と 「デスクトップアプリケーション」 という括り、各社ツールの比較表があったんですが・・・例えば、Adobeの場合はWebアプリケーションはFlushとかで、デスクトップアプリケーションはAir というように。

ですが・・・私的な感想は・・・この括り自体が無意味になってきているんだろうな~と。
昔のイメージでは Webアプリはコンシューマ向け、デスクトップアプリは業務向け みたいな所もありましたが、今では コンシューマ向けでもデスクトップアプリを使ったり、業務向けでもWebアプリにしてみたり・・・多いですよね。
「Webアプリケーション」 と 「デスクトップアプリケーション」 ・・・始めに、どっち使う? を入り口にするんじゃなくて、全部を見てみて、自分の要件にはどれが一番適しているかなぁー って探す感じかな と。



次に参加したのは 【13-C-4】 XMLデータベースというカンブリア爆発とその行方
このセッションの内容は、XML-DB が発表された時期として 1次、2次・・・とタイミングがあったんですが、現在いろんなXML-DBがヒシメいている ということ。
ヒシメイテイル理由としては、XML-DBには ”これが正解!" という解析ロジックがないため、各社がいろんな方法や特徴がある ということ。
・・・ということから、選択する観点などを分かりやすく説明していただいたという感じです。
XML-DB自体、具体的なことは知らなかったので、それら内容も面白かったんですが・・・・それよりも、へぇー と思わせてくれたのは、プレゼンの仕方です。
日経平均のグラフとXML-DB発売時期を重ねたグラフだったり、ゲルマン民族の大移動と兼ねて説明してみたり・・・と、プレゼン素人にはちょっと出来ない資料だなぁ と。



次は・・・【13-D-5】次世代ウェブフレームワークの幕開け~ステートフルはじめました/君が僕を望むなら僕は君を忘れない~
プレゼンテーターが、Java-jaで有名な方だったせいもあり、私が見る限り満席。 凄かった。
でも満席もうなずけるような、プレゼンでした。
飽きさせることなく・・・時々笑いもありーの・・・言いたい目的もはっきり伝わってくるものでした。
一番感動は、プレゼン資料。 基本は 高橋メソッド系で、動きもつけたPowerpoint(?)なんですが、なんせ見やすい! いやはや、黒い背景に白い字っては見やすいもんですねー。 んでもって、変にカラフルよりも、かっこいい。
最初に 警告 ってスライドがあったんですが、遊園地のアトラクションにあるような感じで、パッと見ただけで あー警告の文だー って分かったり。
これは、ぜひぜひ 真似したい!!  あーんど、他のプレゼンターも真似して欲しい!!

・・・と、内容が後まわしになっちゃいましたね・・・
内容は ステートフルなフレームワーク についてでした。
まずは Webの仕組みは基本 ステートレス。でも、システムは ステートフル。
これは簡単には譲れない所なんで、そこを埋めてくれるのは ステートフルなフレームワーク。
”Sessionを使うとメモリ浪費しちゃうから、出来たら使わないよーに” というのが昔からの鉄則の一つとしてありましたが、今はメモリも安くなっているし・・・使わないようにアレコレ頑張る工数よりもよっぽど安くない?
Sessionの削除忘れとかもフレームワークに任せちゃう方が安心だし。
Strutsとかだとセキュリティホールが出たりしちゃっていましたが、JBossSeamやWicket・・・といいモノも出てきているんで、すぐに移行は無理でしょうが、認識はちゃんとしておきましょーよ。
って内容でした。

余談ですが、最後に 「Wicketの情報が少ないんですが、どこから入手したら?」と質問した人。
やっぱり あれはヤラセ?(疎い私でそんなん感じるくらいだから、みんな思ったんとちゃぅ?)
ちなみに wicket-ja がこの前立ち上がりましたよね。
興味本位にhttps://sourceforge.jp/projects/wicket-jaアクセスしてみると・・・今日のアクセス数 めっちゃ伸びてますねw



最後に参加したのは、【13-D-6】 いよいよ現実となるRIA on Desktop。 君はこの流れについてこれるか?
AdobeAirの紹介でした。
Airで作られた既存アプリの紹介や、簡単な作成デモ などでした。
あ、Linux版も2008年中に出るそうですよ。
Airは個人的に興味があって事前に触っていたので、特に目新しい情報は無かったんですが、疑問だったのは、どうしてFlexBuilderのデモの時に ソースビューばかり出して、デザインビューを見せないんだろう?と。
GUIでデザインできる方が受けいいと思うのに・・・?
・・・とはさておき、Airは個人的にも楽しみです。
Airの普及についてですが、どれだけ企業に採用してもらうか・・・ってのもあると思いますが、 ”どれだけ技術者に興味を持ってもらうか" ってのも大きそうですね。

PDFのプラグイン普及があるから、使用者にAirも入れてもらうのは比較的ハードルが低いと思います。
その点、そのほかの デスクトップアプリケーション のものよりも、既に一歩リードしていると思うんですよね。

あとは、カッコいいデザインに憧れているんだけど、そんなセンスが無いのよねー ・・・という (私のような!) 技術者に興味を抱かせて、「お、私でもカッコいいもの作れた」・・・とできれば、WEB上にAirのアプリも溢れるだろうし・・・そうなれば企業の採用も増えるだろうし・・・なんちゃぅかなぁー?と。

業務系アプリケーションって結構しょぼい感じが多いと思うんですが、使用勝手はいいままで、カッコいい外見になる世の中が早くこないかなぁ。
ぜひ Airには頑張ってほしいですー。


長くなりましたが、本日の感想まで。
また明日も行ってきますー

Blogged with Flock

• • •

2008年2月1日金曜日

レガシーバッチ

・・・という言葉があるのかどうか・・・という事さえ、よく分からなかった私。

この業界に入ろう!と思ったきっかけは、ACOSが基幹業務で動いている、ある会社に入ったときでした。
ちょうど、いろんなシステムをオープン化しようとしているようなタイミングで、あまり、COBOLを触る機会もなく、オープンの方に興味が進んでいきました。

そのときは、実際に開発をさせてもらえる環境じゃなくて、出力された帳票をプリンターまで取りに行ったり・・とかでしたが、オペレータの人の様子をよくみていたら、
JOBすぽーん (・・・って言ってたと思うけどあってる?)させてくれたり、
ちょっとプログラムの中身を説明してくれたり・・・で、へぇー凄いなぁ・・・JCLってうまい仕組みだなーって思った記憶があります。

その時に経験が、今となって役立つなんて・・・

最近わが社では、レガシーバッチを対象としてParallelFrameという製品が本格化しようとしています。特に、Adabas/Naturalについては、構造化されたプログラムになっているところから、わが社のアプリケーション作成手法にピッタリ・・・ということで、より注目しています。
検討し始めていったら、思ったよりもコンバードできる量も結構多いよねーっ 結構いいんじゃない・・・って感じ。

そんな事をしていて思ったのが、
時代が変わって・・・言語が変わって・・・
ガラっと激変したとしても、強制的に統一された作り方をしているプログラムは、新しいものにコンバートがしやすい。
これが、人によって作り方が変わるようなプログラムが混じっているようだと、コンバート率がやはり下がってしまうでしょうし。

よく言われることではあるんですが、

”OS,言語,プログラム手法が変わっていっても、業務の要件は変わらない。”

んですよね。んでもって、

”現状のシステムの要件を知るのは、現状のシステムを把握する”

のが一番正確だと思う。

今後は、今まで以上に、時代の流れも速くなるだろうし、どの言語、ツールを使ったらいいのか・・・というのは、とても難しいと思う。 もしかしたら5年、10年後では今は無い ナニか が主流になっているかもしれない。
そうなると、乗り換えやすい作り方 というのが結構重要なんじゃないかなぁーと思います。
今から作るものに対して、今後乗り換えやすいには・・・って考えるのも変な話なんですけどもね。

手前味噌になっちゃいますが・・・、
わが社でもWebtribe,VisualFrameといった開発のための製品があるんですが、もともと作り始めた発想は システム要件を部品を選びつつ組み立ていき、言語や環境に捉われない ものをリポジトリとして作成していく というのがありました。
なんで、今はJAVAでしか動くものがないですが、他のものでも実行エンジン部分を作れば結構他の言語に移行しやすいようになっていると思います。
・・・が、結構、要望やらでいろんな機能を追加していくと、その当初の発想から外れてくる部分って結構あるんですよね。。現実と理想のハザマといいますか。。

小さな会社なんで、開発者も少なく・・・実際案件に直結するようなモノから優先的にしてしまうところがあるんですが、ここは初心にもどって、
”言語や環境に捉われないモノ作り”のツール というのを優先的目指すのもいいんじゃないかなぁー と密かに思ったり。

これはツールによる話でなく、プログラムを作成する人が意識しないと、結局は 無駄な理想論(理想を追いかけて、結局中途半端になり、手間だけかかって利点がなくなった みたいな)になるんかもしれませんが・・・
• • •