dfltweb1.onamae.com – このドメインはお名前.comで取得されています。このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
なぜITアーキテクトは流行らないのか (arclamp.jp アークランプ)
先週から原稿の締め切りが重なり、かつクライアント向けの書き物が多かったのでブログの更新が止まりました。「ヒトが一週間で書ける文字量は決まっている」と思っているのですが、他の人はどうなんだろう。なんか、ずっと同じリズムでブログを書けるヒトは本当にすごいと思う。 閑話休題。某雑誌の執筆者飲み会に行ったときのこと。雑誌の方を目の前に「ITアーキテクトが認知されないのはマスコミのせいもありますよ。PMばっかり持ち上げて。いま、現場で必要なのはテクノロジーとマネジメントのバランスですよ！」みたいなことを言ってみました。 「確かにそうかも」と同意していただいた後に"ITアーキテクトを流行らせにくい理由"を教えてもらいました。 PMの大切さを伝えるときに、ロジックだけではなくてストーリーで伝えることも大事だと思っています。その点、PMは危機的な状況に陥ったプロジェクトを救うストーリーがある。ITアーキテ
仮想化の課題は使う側の意識 (arclamp.jp アークランプ)
仮想化技術の成熟度には目を見張るモノがあります。先日もCitrix社が XenServerを無償化しました（Citrix XenServerが無償化（XenCenter、XenMotion、Resource Pools、ストレージ管理機能を搭載）（20090223-1））。この製品は 複数のホスト（XenCenter）を管理するエンタープライズコンソール、VMライブマイグレーション（XenMotion）技術、リソース共有（Resource Pools）技術、そしてエンタープライズストレージ管理技術など、膨大な数のエンタープライズ向け機能も無償配布する。 というもので、主要なプレイヤーであるVMware社が無償公開しているESXiと比べて （もちろん勝負にならない）。 ぐらいの機能差。これまではエンタープライズ向けの仮想化は高級な技術ということで認知されていたためVMwareのが市場シェアで
客のことを真剣に考えると、儲からない。から、どうするか (arclamp.jp アークランプ)
先日、クラウド研究会の後、朝まで飲んでた時にNRIのSさんに「なんか、仕事してて悩みないの？」って言われて、ふと出たのが 「客のことを真剣に考えると、儲からないんですよ」 っていうので、「そーだよねー、ウンウン」って大ウケされました。で、そのあとにSさんと語ったのですが、それって1つの真理ですよねと。だけど、これをきちんとエコシステムとしてビジネスモデルにするのが僕らがやるべき仕事ですよと。 今、｢見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること｣っていうのが話題ですが、それって業者からすれば儲からないってことで、これをSIerがやる理由がないんですよ。これっぽっちもない（まぁ、記事は煽りすぎで、実際には職員の工数がかかっているので2000万ぐらいにはなるのではないだろうか。それでもひとケタ違うけど）。 で、ござ先輩に言いたい。プログラマの誇りを減衰しないビジネスモ
マクロフローとマイクロフロー (arclamp.jp アークランプ)
アプリケーションのビジネスロジック層にフロー制御を行うフレームワークを使っていくことが重要だと思っていますが、BPELやBPMの概念とかぶっていて、うまく説明できませんでした。最近、マイクロフローをいう言葉を知ったのですが、このマイクロフローの導入について、多くのアプリケーションで検討が必要です。 Webのプレゼンテーションにフロー制御を、というのはSpring Web FlowやSeamを初め、主流になってきている考え方です。こうしたフロー制御フレームワークは、MVCに加えて画面間の遷移についても制御を追加します。 歴史的に見ればコンポーネント化が進んできているということです。処理の「そのもの」「起動制御」「流れ」の分離と捉えることが出来ます。コンポーネントの「再利用」の夢は消えて久しいですが、それでもコンポーネント化が重要なのは保守性向上と分業化推進として捉えられます。DIや単体テスト
次のアーキテクチャと3つのテスト (arclamp.jp アークランプ)
今度のデブサミ2009でもアーキテクトゾーンの担当をします。ご一緒させていただくユニシス牧野さんとも3年目。毎回のことながらテーマ設定がかっちりしていて楽しいです。 今度のテーマは「次のアーキテクチャ」。そして、裏テーマが現在のアーキテクチャと次のアーキテクチャの断絶をいかにつないでいくのか。 これまでのアーキテクチャの歴史を概観すると、集中＞分散＞統合と説明することができます。ホストでの「集中」処理を行い、ユーザーはダム端末を利用していました。それがオープン化とダウンサイジングの流れ、そしてインターネットを超えて「分散」化していきます。そこからEAI、SOAと続く「統合」の流れになっています。 では、「次のアーキテクチャ」はなにか。それはアプリケーション同士が緩やかにつながりあいながら、システムが動的に立ち現れてくる時代。 もはや1つのアプリケーションではシステムは完結しません。複数のア
モデリングの本質（石川初さんがオモシロすぎる件） (arclamp.jp アークランプ)
今年のデブサミ2008で、ジョエルを抑えて満足度1位を獲得したランドスケープデザイナーの石川初さん。最近のエントリが面白すぎる。 バックヤードとしての港湾 最近、Googleマップの空撮が普及して、上空からの高解像度の写真を眺める機会が増えるにつれて、建物の屋上が街のバックヤードと化していることがよくわかる。特に都心部にはほとんど「屋根の景」がない。空調の屋外機が延々と並んでいる光景は、自動販売機を後ろ側から眺めているみたいなおもむきだ。 これが、都市のスケールでは、「海岸」がでかいバックヤードになっている。高度に近代化した都市の港湾の「海側からの眺め」というのはほんとに、都市の「裏側」である。きっと、沿岸の「栄養源」から「物資の流通媒体」へと、海岸がその価値を転換させたときから、海側は巨大な荷捌き場になっちゃったのだ。 街へ出よ、驚愕せよ。 （建築学科の学生に地図を見せて『なにか変なこと
Springの生産性 (arclamp.jp アークランプ)
これは言っておかねばなるまい。ひがさんのCTCと夜の決闘より。 生産性を向上させるということを主目的としてフレームワークが作られたのは、基本的(もちろん例外はあるけど)にRails以降のフレームワークです。 Railsは、Struts、Spring、Hibernateへのアンチテーゼとして登場しています。裏を返せば、Struts、Spring、Hibernateを組み合わせても生産性は出ないということです。 生産性という言葉をどう取るかによりますが、確かにSpringはコードを短く書くためのフレームワークではありません。 そもそも生産性を上げるためには、アプリケーションの部位毎に個別最適化していき、それらを統合するというのが正しい戦略です。これは規模にかかわりませんし、Seasarを使おうが、Springを使おうが同じ事です。 Seasarは最適化をうまく行っているフレームワークです。ただ
テクノロジーとデザインの境界線があいまいなもの (arclamp.jp アークランプ)
Web2.0 Expoでベスト講演をあげるとすればチームラボの猪子さんによる「インターフェースデザインのイノベーション（テクノロジーとデザインの境界線があいまいなもの）」です。これはヤバイ。 以下、サマリ。 サーチやマッチングというテクノロジーがあるおかげで、Webにある情報はサイト内外の情報を動的に再編集して構成されるようになった。だから、そのリンク構造も動的。当然、サイトマップやきれいな階層構造なんて存在しない。 サイトの構造が動的なんだから、インターフェースも当然、動的だよね。逆にインターフェースが構造の動的さを引き出して魅力を出さなきゃいけない。 テクノロジー（構造）とインターフェースは切り離して考えることなんてできない。一体なんだよ。 いえーい！も、マイナビバイトも、SAGOOLも、Laboo!も、そうやって作った。 これって「インターフェースの革新の本流」。すごい西洋的。iPa
Webアプリケーション開発の今後- Rails + Spring (arclamp.jp アークランプ)
11/6日本Javaユーザーグループによる「クロス・コミュニティ・カンファレンス 2007 falll」に参加してきました。Seasarひがさん、Rails高井さんとともに 「Webアプリケーション開発の今後を占う」という題名でポジショントークとパネルを行いました。よういちろうさんがuStreamで録画してくれたので見てください。ちょっと、音声がぶつぶつですが、だいたい聞き取れると思います。ポジショントークの資料はこちら。 RailsでSpring ポジショントークで紹介したのがRailsとSpringを統合してみた、というやつです。コードはここに。 まずJavaアプリケーションですがjava\src\java\mainに入っています。クラスBusinessLogicImplは、メッセージを返却するだけのメソッドshowMessageが実装されています。 package jp.java
Struts化するRails (arclamp.jp アークランプ)
良い悪いは置いておくとしてRubyOnRailsはStrutsになるのだなと感じています（エンタープライズ開発でデファクト・スタンダードになって一定のポジションを獲得する）。先日のRubyKaigiでの話し、あるいは最近のエンタープライジーな企業のプレスリリースを見ていると着実にその道を歩んでいるようにみえます。特にSUNがJRubyへのコミットメントを強めている中でJava環境でもRailsが使えるという期待感が強まっており、この傾向に拍車をかけているようです（既にJRubyの上で動きます）。 背景としては金融･内部統制景気が続く一方で、中大規模のSIerでも小粒案件（1-4千万円）をちゃんと利益出してやっていこうよ、みたいな流れがある気がします。これまではプロダクトなどでカバーしていましたがOSSの発展や顧客ニーズの多様化によってSI案件化せざるをえなくなってきた。でも社内の標準フレー
私的ITアーキテクト考：1.ITアーキテクトが作るもの (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 連載を始めると書いたものの第1回までに時間がかかってしまいました（ｗ。さて、第1回は、いきなり「ITアーキテクトが作るもの」からはじめようと思います。僕もこの質問に困っていましたが、最近ふと気づくことができました。それは、 ITアーキテクトは「そのシステムがある世界」を創っている ということです。なんだそりゃ、と思われるかもしれませんが、もう少しだけ読んでみてください。 なぜそのアーキテクチャになったのか 普通に考えればITアーキテクトが作っているのはアーキテクチャです。例えばシステムの設計思想や具体的なフレームワークの構成のようなものでしょう。もちろん、これ自体は誤りではありません。 とても大事なことは「なぜそのアーキテクチャになったのか」という理由をきちんと説明
揺らいでいる方が安定する (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 友人と話していて、妙に感心されたので書いておきます。僕は高校から大学にかけてアーチェリーをやっていたのですが色々と学ぶことが多い競技でした。その中の１つ。 射撃も同じなのですが、アーチェリーは動かない的を対象にしています。ですから、狙いを定めて、つまり照準を的に合わせながら打つという行為が発生します。そのときに最も安定（一定）して狙う方法がわかりますか？ それは揺らぎ続けること、動き続けることです。 人間というのは面白いもので「動きを止めよう」と思うと力が入って硬直してしまいます。力の入った筋肉というのまったく良いところがありません。硬直した筋肉では無駄な力が入りコントロールできない動きがうまれ、柔軟性が失われてしまいます。 そうなると風がちょっと吹いただけで大きく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。