dfltweb1.onamae.com – このドメインはお名前.comで取得されています。このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
仮想化の課題は使う側の意識 (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 アークランプ)
世の中ではサービスが重要と言われていますが、まだまだ定着していない気がします。なので、「サービスを作ることと、ソフトウェアを作ることは何が違う？」という問いがブームです。今日は、R天の人にぶつけてみました。 「『あと1週間あったらきれいなコードで出せる』がソフトウェアで、『今リリースしてPVが増えるなら、何でもいいから出せ』がサービス」 リアリティあるなぁ、やっぱり。じゃ、サービスとソフトウェアを近づけるために何かやってる？ 「プロジェクトの開始時にサービスとしての中長期的なPKIを決めてエンジニアにも意識させる。儲からないシステムはダメだ、という認識が共有されている」 ソフトウェアをサービスに寄せていく、っていうのがプロセスや文化に織り込まれているんだよね。あと、開発チームの中にコストをコントロールする人がいるっていうのも、きちんとガバナンスを効かせるために大事なことだなと思いました。
生産性（続き）、アーキテクチャとフレームワーク (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 アークランプ)
先日開催されたJJUG（日本Javaユーザー会）主催のクロスコミュニティカンファレンス 2008 Springにおいて、Webアプリケーションフレームワークパネルでモデレーターを務めてきました。 参加メンバーと、紹介してもらったフレームワークは次の通り。 ・山田 正樹 (メタボリックス) : Grails ・田中 洋一郎 (ATL システムズ) : JRuby on Rails ・竹添 直樹 (NTT データ先端技術) : Click Framework ・矢野 勉 (Wicket-ja) : Wicket 議論の詳細は省くとして、ポイントとしては、 ・Strutsの時代があった ・しかし、Strutsでは最近の要件には応えられずに改修する部分が必ずある（実際には当時のStrutsも「独自拡張」がされていた） ・現在はWebアプリフレームワーク乱立の時代。機能的な決め手がない。重要な
会社にとってのオープン化の意義 (arclamp.jp アークランプ)
改めてソフトウェアのオープン化について考えています。ソフトウェアの特性を考えると、共有を実現するためにソフトウェアほどすばらしいモノはありません。しかも、この活動を会社としてやることに大きな意味があると思うのです。 ソフトウェアの「所有の同時性」と「同質性」 ソフトウェアの特性を整理すると「所有の同時性」と「同質性」というものになると思っています。 サービスは「無形性（所有できない）」と「同時性（生産と消費が同時）」という特性があります。これと比較するとソフトウェアは媒体（メディア、サーバ）を通じて所有できるので無形とは言えません。ですから所有できます。しかも、同時に所有することができます。これが「所有の同時性」です。 しかもソフトウェアはどんなに所有が同時に発生しても品質の劣化は一切発生しません。工業製品のコピーや製造工程はブレを管理しなくてはなりませんが、ソフトウェアのコピーはまさに
ITアーキテクトは中途半端なもの@デブサミDAY1 (arclamp.jp アークランプ)
デブサミ1日目に参加してきました。いろいろ楽しかったですが、自分のセッションについて。 アーキテクチャクロニカルは、あっという間の90分で個人的にはすごい楽しめました。メンバーはIBMの榊原彰、ユニシスの牧野さん、そして3日前にアサインしたウルの河村さんと僕。ただ、僕自身も驚くほど「技術」的な話になりませんでした。結論めいた所だけメモ。 現在のシステム開発というのは「開発者に依存したシステム開発の限界」に到達していると。これは登場する「様々なユーザーに対応しきれない」からです。昔はシステムを使うののは会社にいる10%ぐらいでしかなかったけど、今では全員（まさに子供から老人まで）が使うようになっています。こうした多様性に対して、これまでは標準化と汎用化という形で対応してきました。しかし、標準化は不満足を招き、汎用化はめんどうさを招いてしまった。 だからこそ、これからは「良い意味でのあきらめ」
根っこをつかむこと (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 最近、コードをいっぱい書いています。仕事半分、趣味半分というか。OSSのプロダクトですが、将来はビジネスにすることも踏まえています。今週、金曜日にデモをしないといけないので、かなりピンチです。それはさておき（置いといちゃいかんのだが）。 手を動かし続けること 手を動かし続けることは大事だなと思っています。僕はアーキテクトを「使う側と作る側をつなげる人」と定義しています。その点において「手を動かし続けること」はとても大切なことです。いまのシステム開発は作ることの品質が安定していないから、特に作る側に対する理解が重要なのです。少なくとも、この10年は同じ状況が続くでしょう。 プレイングマネージャーが辛いのはよく分かるので、案件の中で100%コードを書けとは言いません。で
言葉の関係性 (arclamp.jp アークランプ)
前回のエントリ「イマドキのオブジェクト指向」は僕が思っていた以上に注目がありました。気づいた人もいるのかもしれませんが、僕はオブジェクト指向というものをきちんと学んだことがありません。なので「オブジェクト指向ってオブジェクトが大事なんだなー」ぐらいにしか思っていなかったのが事実。 というわけで、はてブではyojikさんに メッセージ指向vsクラス指向は最初期からあった対立軸だと思う。 と言われて、あと、よういちろうさんには「メッセージ指向なオブジェクト指向でのUMLって？」で、 太古の昔から、オブジェクトは「メッセージのやり取りによる処理の委譲の繰り返し」だったはず。 と言われました。両方ともなるほど。この原因としてよういちろうさんが、 JavaやC++など、構造化言語から派生した言語を習得することによってオブジェクト指向を学んでしまった人間にとっては、メッセージのやり取りという発想ではな
イマドキのオブジェクト指向 (arclamp.jp アークランプ)
最近、改めてオブジェクト指向の説明というものを見直すことがあったのですが、出てきた結論としては「イマドキのオブジェクト指向」という形で再編集しても良いのではないかと。 先週の丸山先生レクチャーシリーズ2007-2008 第3回「SOAの現在」で発表した「メッセージ指向によるシステム開発の変化の兆し ～遍在するメッセージ指向～」は、その表れ。ウルの河村さんと話しているときに盛り上がって、そのまま形にしたものです。 では、「イマドキのオブジェクト指向」とは何か。それはメッセージ指向という解釈です。オブジェクト指向は「メッセージによる処理の分割」であり、「分離された処理をオブジェクトと呼ぶ」と定義します。これまではオブジェクト指向とは「オブジェクトによる処理の分離」であったわけです。 背景 現在、ソフトウェアを作る時に重要なのは「処理をいかに分離し、作業を分担するのか」ということです。これはプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
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で取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。