dfltweb1.onamae.com – このドメインはお名前.comで取得されています。このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
生産性（続き）、アーキテクチャとフレームワーク (arclamp.jp アークランプ)
前回のエントリから時間が空いてしまいました、ごめんなさい。せっかくひがさんとkoichikさんにコメントをいただいたので整理します。 ひがさんのコメントが象徴的だと思っていて、 選ぶことが大事じゃなくて作ることが大事なのでは。 という点で、僕は「選ぶことが大事だ」と思っています。そもそも僕はひがさんやkoichikさんのように「（フレームワークを）作る」力がない（気持ちとか、そういうのも含めて）。 なので、koichikさんの 規模で世の中の 80% を占めるところのエンタープライズシステムでは Spring の方が生産性を高められる＜中略＞の根拠たり得る説得力ある意見が聞きたかった については、「選ぶ」という視点ではSpringの方が最適化されているからという答えになります（ここまで断定的な言い方をしているつもりはなくて、『そういう場合が多い』というぐらいだけど）。 「規模で世の中の 8
Springの生産性 (arclamp.jp アークランプ)
これは言っておかねばなるまい。ひがさんのCTCと夜の決闘より。 生産性を向上させるということを主目的としてフレームワークが作られたのは、基本的(もちろん例外はあるけど)にRails以降のフレームワークです。 Railsは、Struts、Spring、Hibernateへのアンチテーゼとして登場しています。裏を返せば、Struts、Spring、Hibernateを組み合わせても生産性は出ないということです。 生産性という言葉をどう取るかによりますが、確かにSpringはコードを短く書くためのフレームワークではありません。 そもそも生産性を上げるためには、アプリケーションの部位毎に個別最適化していき、それらを統合するというのが正しい戦略です。これは規模にかかわりませんし、Seasarを使おうが、Springを使おうが同じ事です。 Seasarは最適化をうまく行っているフレームワークです。ただ
言葉の関係性 (arclamp.jp アークランプ)
前回のエントリ「イマドキのオブジェクト指向」は僕が思っていた以上に注目がありました。気づいた人もいるのかもしれませんが、僕はオブジェクト指向というものをきちんと学んだことがありません。なので「オブジェクト指向ってオブジェクトが大事なんだなー」ぐらいにしか思っていなかったのが事実。 というわけで、はてブではyojikさんに メッセージ指向vsクラス指向は最初期からあった対立軸だと思う。 と言われて、あと、よういちろうさんには「メッセージ指向なオブジェクト指向でのUMLって？」で、 太古の昔から、オブジェクトは「メッセージのやり取りによる処理の委譲の繰り返し」だったはず。 と言われました。両方ともなるほど。この原因としてよういちろうさんが、 JavaやC++など、構造化言語から派生した言語を習得することによってオブジェクト指向を学んでしまった人間にとっては、メッセージのやり取りという発想ではな
イマドキのオブジェクト指向 (arclamp.jp アークランプ)
最近、改めてオブジェクト指向の説明というものを見直すことがあったのですが、出てきた結論としては「イマドキのオブジェクト指向」という形で再編集しても良いのではないかと。 先週の丸山先生レクチャーシリーズ2007-2008 第3回「SOAの現在」で発表した「メッセージ指向によるシステム開発の変化の兆し ～遍在するメッセージ指向～」は、その表れ。ウルの河村さんと話しているときに盛り上がって、そのまま形にしたものです。 では、「イマドキのオブジェクト指向」とは何か。それはメッセージ指向という解釈です。オブジェクト指向は「メッセージによる処理の分割」であり、「分離された処理をオブジェクトと呼ぶ」と定義します。これまではオブジェクト指向とは「オブジェクトによる処理の分離」であったわけです。 背景 現在、ソフトウェアを作る時に重要なのは「処理をいかに分離し、作業を分担するのか」ということです。これはプ
Facebook Platformから見る、次のアーキテクチャ (arclamp.jp アークランプ)
Facebookの認知度は上がってきていると思います。2007年5月にFacebook Platformを発表して以降は「次世代のソーシャルOS」というラベルが貼られ、その動向が注目されています。10月24日にはMicrosoftが2億4000万ドルを出資し、評価額は150億ドル（1.7兆）に跳ね上がりました。また、11月2日に発表されたGoogleのオープンソーシャルに対しては当然のように参加を表明していません。 Facebook Platformとは Facebook Platformはサードパーティの開発者がFacebook上の情報を利用してアプリケーションを開発できる仕組みです。それだけならデータベース型ですが、加えて開発したアプリケーションはFacebookに登録することが可能です。Facebookユーザーはアプリケーションの一覧から欲しいアプリケーションをクリックするだけで自
ITには物語や視点が必要 (arclamp.jp アークランプ)
ITが事務・業務効率化のツールからどこへ向かうのか。1つの答えが「見える化」に代表されるような広範囲を対象にした情報分析です。 業務効率化というのは、あくまでも個人の視点で語られがちです。個人が行っていた計算や整理作業を高速化、自動化することで「人の作業を代替する」わけです。 でも、それだけではITの持つ力を使いきってはいません。ITとは「情報をデジタル化して扱うための技術」のことです。デジタル化されたものは場所と時間を超えて共有することができます。 だかこそ、様々な場所で非同期に発生したコトを集めることができます。これは個人の視点ではなく、より大きく俯瞰したマクロ的な視点です。 もちろんデジタルデータは現場のすべてを示すものではありません。ビデオカメラも同じこと。テレビの向こうの出来ことが虚実入り混じって感じるのも、デジタル化された情報が端的にしかリアルを伝えないことを示しています。
JavaWorldDAY講演：JavaとLLで実現する「アジャイル・アーキテクチャ」 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 2007年6月19日に実施されたJavaWorldDAY2007にて、JavaとLLで実現する「アジャイル・アーキテクチャ」という講演をさせてもらいました（使用したパワーポイントのPDFファイル）。 もともとがITアーキテクト次号の特集用に書いたものなのでコードよりも概論が多くなっています。しかも、マシンがうまくディスプレイを認識してくれなくてもデモもできずにすみませんでした。以下、概要です。 アジェイル・アーキテクチャとは何か どんなことにでも対応できる万能アーキテクチャは存在しません。僕なりには「ビジネス環境で起こりうる変化に迅速に対応できるように適切に選択されたアーキテクチャ」ととらえています。ポイントは以下の2つになります。 - 起こりうる変化を管理する
Struts化するRails (arclamp.jp アークランプ)
良い悪いは置いておくとしてRubyOnRailsはStrutsになるのだなと感じています（エンタープライズ開発でデファクト・スタンダードになって一定のポジションを獲得する）。先日のRubyKaigiでの話し、あるいは最近のエンタープライジーな企業のプレスリリースを見ていると着実にその道を歩んでいるようにみえます。特にSUNがJRubyへのコミットメントを強めている中でJava環境でもRailsが使えるという期待感が強まっており、この傾向に拍車をかけているようです（既にJRubyの上で動きます）。 背景としては金融･内部統制景気が続く一方で、中大規模のSIerでも小粒案件（1-4千万円）をちゃんと利益出してやっていこうよ、みたいな流れがある気がします。これまではプロダクトなどでカバーしていましたがOSSの発展や顧客ニーズの多様化によってSI案件化せざるをえなくなってきた。でも社内の標準フレー
DIコンテナとGenericsを利用して品質や効率をあげるテクニック (arclamp.jp アークランプ)
今日、メンバーと話をしていて面白かったのでコーディングしてみました。 メタプログラミングっぽくDIコンテナを利用する XMLの名前空間をトリガーにしてローカル名でオブジェクトを発見し、処理を委譲するというアイデアです。例えば名前空間がcommandとして、そのローカル名でDIコンテナをルックアップします。 ＜コマンド定義ファイル test.xml＞ <?xml version="1.0" encoding="UTF-8"?> <commands xmlns:command="http://www.arclamp.jp/command"> <command:out command:message="ほげほげ" /> </commands> DIコンテナの設定ファイルはこんな感じ。command:outという指定なので、commandsプロパティにoutというキーでBeanをインジェ
SOAがなぜ流行らないか (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ SOAがなぜ流行らないか いまさらSOAかよ、という感じかもしれないですが。SOAがなぜ流行らないか、ということには分かりやすい理由があります（この場合のSOAというのは「インターフェース・ネットワーク（＝サービス）指向のアーキテクチャ」という広義な意味を示します。WebServiceｓとか、製品はどうでもよいです）。 荒地に種を蒔いても収穫はありません。ちゃんと荒地を耕して畑にしてから種を蒔かないといけない。しかも、一気に耕すことはできないから、耕しやすいところを見つけて一歩一歩やっていく。たぶん小学生でも理解できる。 SOAも同じこと。SOAが求められるビジネス（＝マーケット）がないのにSOAは売れません。今やるべきことは、製品を作ることではなくマーケットを耕す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
