要求2.0開発 (arclamp.jp アークランプ)
要求開発アライアンスの10月定例にて「要求2.0開発」というテーマで話をしてきました。題名は理事の細川さんから依頼をいただいたときにノリでつけた名前です。かなり勢いに任せた内容はなっていますが、まぁまぁ（ｗ。 要求開発2.0ではなくて、要求2.0の開発。これからの時代は要求その物が2.0化してきます。手法うんぬんではないのです。言い換えれば「ビジネスのシステム化2.0」ではなくて「ビジネス2.0のシステム化」をテーマにしていかないといけないと考えまています。 資料はアライアンスのページにあがると思いますがサマリを書いておきたいと思います。 今、何が起きているのか 次のスクリーンショットを見てください。なんだと思いますか？ 実はこれ、日本全国1万ヶ所のホテルに●を置き、最低価格が高いほど赤くしたものなのです。長野から伊豆とか、京都奈良ならあたりが赤くて、東京、大阪は件数が多いものの価格が高
我らJava世代の課題 (arclamp.jp アークランプ)
最近、何度も思うことがあります。 JavaOneでも強調されていましたが、この10年をかけてJavaは成熟してきました。女子高生がJavaという言葉を知り、あらゆる分野にJavaが進出しています。スコット・マクニーリー氏はMicrosoftもIBMもけなさずに、貧困を解決するためにデジタルデバイドへ取り組むことが使命だといいました。Javaなしに地球は回らなくなっています。 同時にJava開発者も10年という時を過ごしてきました。今、30代の多くの開発者はJava世代といえると思います。VBやCOBOLなどのクラサバ時代から、インターネットをつかったWebアプリケーションの時代へ。Javaは、そんな中で成長してきた言語です。 JavaOne報告会2006の座談会で「Javaの成熟をいつ感じますか？」と聞かれました。僕の答えは「次の世代と会話の中」というものです。 はてななどの20代の開発者
SpringFramework利用実績公開 (arclamp.jp アークランプ)
豆蔵の長谷川さんが言いだしっぺで集めたSpringの利用実績情報が公開されました。豆蔵さんをはじめ、永和さん、エーティーエルシステムズさんなどにご協力いただきました。なおGNUライセンスなので好きに使っていただいて大丈夫です（自分の実績を足したい場合にはご一報を！）。 http://modern.sourceforge.jp/ 僕の周りでは、どんなに大規模な案件でもDIコンテナを使わないというのは考えられない状況にあります。 そもそも使わないリスクというものがほとんどないのです。 DIコンテナがEJBに対して軽量コンテナと呼ばれるという説明があるからか、ランタイムのアプリケーション・フレームワークであるかのような印象を持ちがちです。 しかし、実際にはDIコンテナはアプリケーションの構成管理をしているだけで、その解決をランタイムにしているに過ぎません。ですから、ランタイムで変なことがおきる
SOAとは何かを考える from JavaOne (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 丸山先生が語るSOAのサマリともいうべき内容でした。短い時間でしたがSOAの定義がきれいに組み立てられていて非常に勉強になりました。すばらしいです。メモ書きをのせておきます。 ------------------------- ◆SOAの技術的な切り口 SOAの定義はWebサービスを念頭においているので、表現が抽象的にならざるを得ない。近年やっと具体的になってきた。 最近の言い方は「Webサービス"で"統合」から「Webサービス"を"統合するためにSOAが必要」 ◆SOAのビジネス的な切り口 ビジネスの変化に即応する（アジリティ、オンデマンド、アダプティブ）ためのSOA。 これは、逆に言えばSOAが適応する経営モデルも定義してしまっているのでは？ ビジネス
なぜオープンソースを採用するか リスクと責任と価格 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ とある記事のお仕事でオープンソース・プロダクトを現場に導入するためにはどうしたらよいか（そもそもはDIコンテナを採用してもらうには）という内容を書こうとしたのですが筆が止まってしまいました。 友人とも議論したのですが、この話を突き詰めると「責任の所在」という根本論になってしまい、なかなか書きにくいからです。 責任論でオープンソースを語るのは間違い オープンソースには様々な利点があります。 メリット1 コモディティ化の原理で、共有されているからこそ品質が良い メリット2 コードが見れるので、問題が生じてもなんとかできる可能性がある それでもなおオープンソースを採用しないのは「責任が取れない」という理由からではないでしょうか。自分で責任を取らない（責任は誰かに取って
SOA as Web2.0 ? [第1回] (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 既報の通りJavaOne Tokyoで「SOA as Web2.0 ?」という講演をさせていただくことになりました。BOFということもあり多くの方に楽しんでいただくために、我々が行っているディスカッションをエントリしていきたいと思います。 初回のミーティングでは「SOA as Web2.0 ?」の定義を明確にすることに費やされました。大前提は「SOAにWeb2.0の盛り上がりを」ということでありエンタープライズ・アプリケーションを対象にします。 技術的な視点から まずWeb2.0といえば？で出たのがAjax、XML（REST/RSS/ATOM）、HTTP、ブラウザ（Firefox）といった技術要素。SOAでは同じXMLでもSOAP、BPEL。そしてESB、JBIとい
arclamp.jp アークランプ: コモディティ化と人月
最近考えていることを独り言。ITにおけるコモディティ化の流れは、ここ最近のエントリで書いている。コモディティ化がおきると、価格競争に入りやすくなり、果てしない消耗戦が始まる。それでは、とても健全なビジネスを行うことは出来ない。 ビジネス単位の変化でコミディティ化を乗り切る、とはいうけれど 大きな話から入れば、ビジネスの世界ではコモディティ化を乗り切るための手法として、ビジネス対価の変革というのはよく議論されることである。ちょっと前の号になるがハーバードビジネスレビュー 2005年8月号の"「脱」コモディティ化の成長戦略"で論じられていたのが、UOB（unit of business：ビジネス単位）の変革だ。 例えば、セメント業界のセメックスは、販売するものを「生コンクリート」から「生コンクリートの配送」に変化させた。それは、顧客は必要なときに必要なだけの生コンが手に入ることを望んでいたこ
第6回 J2EEカンファレンスに参加 (arclamp.jp アークランプ)
朝一は「JavaOne05報告:10周年を迎えたJavaをどう捉えるのか」ということで稚内北星学園大学の丸山先生、SUNの石原さん、日経BPの星さんによるパネルディスカッション。SUNの石原さんからはJavaOne05の報告ということで、キーメッセージ「情報の時代からParticipation Age（参加の時代）へ」「Share（共有）」という話に引き続きトピックスの紹介。 - DTrace for Java - NetBeans + Matisse - SPOTプロジェクト スマート・ダスト - Project Looking Glass - Project GlassFish - JBI (JSR208) - EJB3 - Persistence APIの独立 - デジタルデバイドの解消 （JEDIプロジェクトなど） - 名称変更 （Java EE、Java SE、
スクラムは現実解 (arclamp.jp アークランプ)
アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebや本で探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠（土日を含む30日間）を基準とする。 チームは少人数（7人前後）で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで
ゴールに向かってリスクを管理する (arclamp.jp アークランプ)
Goodpic.comさんの 「オープンで無いソフトを書いたり使ったりするエンジニアはリスク」という考えとオープンな基盤の上に創られるシステムとはより。 テクノラティのエンジニアがいった、 「オープンで無いプロプライエタリなソフトを使ったり、書いたりするエンジニアは、特に小さなスタートアップ・ベンチャーではリスク要因になるんだよ。あるエンジニアが急に会社をやめたりしたときに、オープンなソフト、コンポーネント・モジュールで開発がされていれば、新しく担当になった人が、最小限の時間で状況を把握して、開発を継続できるから。」 という言葉から、金子さんが リスクというと、無ければいいような気がしますが、リスクを冒さないと得られないモノもあります。 リスクを取らないとリターンが得られないので、重要なのはリスクがコントロールされていること＝リスク・マネージメントという発想がまず第一の前提。その上で、オ
賢いデータは必要なのか (arclamp.jp アークランプ)
きっかけは、「オブジェクトからサービスへ」というエントリに対して、通りがかりさんからコメントいただいたことだった。これまで、長い間、もやもやしたものを感じていたのだ。 オブジェクト指向の本を紐解くと、データと振る舞いをクラスにカプセル化すると書かれている。僕も疑問は、そもそも、それが正しいのか、つまり、データに振る舞いを持たせる必要性があるのだろうか？賢いデータは必要なのか？ということだ。 Javaでは、データと振る舞いの分離が進んでいる まず、現状として、Javaの世界では、データと振る舞いの分離が大きくすすんでいる。EJBにしても、EntityBeanとSessionBeanというのは、データと振る舞いの関係にあり、分割がよいこととされている。さらに、O/Rマッピングツールが流行するにつれ、データの保持クラスはPOJOとなった。一方、ビジネスロジックは、FacadeやServiceと
Struts1.Xって、もう古いよね (arclamp.jp アークランプ)
最近、再びStrutsをいじるようになったことで、あらためてStrutsのアーキテクチャが古くなったことを感じた。Strutsは2001年ごろに開発されたものであり、1.X系は、現在もそのアーキテクチャを引き継いでいる。そのため、去年あたりから注目されているPOJOやDIという概念に対応していないのだ。 POJOへの未対応でわかりやすいのは、ActionFormの存在だ。ActionFormの責務は、reset、validate、そしてマルチパートのハンドリングだ。つまり、入力情報に関わることは自分で処理するというオブジェクト指向らしい考え方である。しかし、現在であれば、ActionFormをPOJOにしてしまい、validateやresetは、Actionにおいて実施すればよいと考えるだろう。すぐに思いつくメリットとしては、Strutsから先のビジネスロジックに引数として渡しやすいこと。
Dependency Injectionとは、なにか (arclamp.jp アークランプ)
先のエントリ、「POJOがしめすアプリケーションの形」に対して、クープルのjugyoさんから指摘をいただいた。（この人「頭固いな～」と思った。） つまり「DIコンテナ」ってのはバーチャルマシンの一種なんだよ。 なんでみんなPOJOとかDIとかっていう難しい言葉で表現しようとするかな～。 うーん、ま、僕の表現が小難しいのはお許し願うとして、言い訳させてもらえれば、先のエントリは、DIコンテナを説明したかったのではなくて、POJOやDIで、何が出来るのかを説明したかったのだ。 現在、DIといえば、DIコンテナ（Spring Framework、Seasar2など）、いわゆる軽量コンテナである。DIコンテナでも、DIの効果は十分に証明されている。しかし、DIという概念そのものは、もっと応用性が高いのではないかと言われている。ま、DIコンテナ自身も、すべての可能性が洗い出されたわけでもないのだが
POJOがしめすアプリケーションの形 (arclamp.jp アークランプ)
Javaの世界では、POJOというものが流行している。Plan Old Java Objectの略で、Martin Fowler氏らの造語だ。シンプルで、依存性をなくしたオブジェクトのことをさす。しかし、このPOJOというものをどう捉えるべきか、まだまだはっきりしていないのではないかと感じる。ここでも、僕なりの説明を試みるわけだが、正解といえるかは分からない。ただ、方向性としては間違っていないと思っている。 POJOとは まず、POJOを、もう少し詳しく定義するなら、「自分がするべきことに対して最低限しか知らないオブジェクト」、さらに「実行環境やフレームワークのことは一切知らないオブジェクト」といえるのではないか。たとえば、ビジネスロジックを担当するPOJOであれば、自分のするべきこと、まさにロジックと、そのロジックに必要な他オブジェクトのインターフェース（まさに、interface）し
抽象化によるシステム設計？ (arclamp.jp アークランプ)
『バブルの生んだ5大粗大ごみ』発言でおなじみ（？）の磯崎新氏の著作「空間へ 根源へと遡行する思考」を読んでいる。その中で、日本における都市計画がシンボルの分布によって考えられているという指摘が非常に面白かった。 デフォルメによる表現 まず、磯崎氏が取り上げたのが懐宝御江戸絵図である。 この地図に対して、 実在の道路と比較して奇妙なひずみをもったパターンと、その地図上にプロットされたシンボルとしての記号の分布、それだけの材料で、かえってわれわれは《正確な》江戸のイメージを描くことが可能になる。 （※シンボル=諸大名の屋敷を示す家紋と、寺社仏閣） と指摘する。実は、日本には今でのこれと良く似た地図がある。"観光マップ"といわれるものだ。車を運転する側になってみると、なんとも頼りない地図だが、徒歩で歩き回わるには分かりやすい。そして、 いまわれわれが都市空間を解析しイメージを提出しようとすると
儲ける構図 (arclamp.jp アークランプ)
先日のZope Weekend 5にて、オープンソースCMSという内容のパネルディスカッションに、Java系CMS代表（？）ということで参加してきた。その話題で、いくつかエントリしたいことはあったのだが、まずこの話題から。パネルディスカッション中、モデレーターの桜井さんから、「なぜ、Javaが企業システムに良く使われるのか」ということが指摘された。僕の答えは、簡単に言えば「企業が儲ける構図がはっきりしているから」というものだ。いかにも、卑下した答えに聞こえたかもしれないが、やはりきちんとこのことを理解していないといけないことだ。 儲ける意味とは まず、企業が儲けられる意味とは、どういうことだろうか。当然のことながら、ほとんどの企業は営利目的であり、株主の利益になることをすべきだ。だから、儲けるというのは、当然の目標になる。企業にまったく永続性がなければ、安心してベンダーを採用することなん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
http://www.arclamp.jp/blog/archives/000551.html
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。