DIContainerはコモディティ化する - ひがやすを技術ブログ
SpringやSeasar2など、現在のDIContainerは、独自の機能を追及し、機能の豊富さを競っているようなところがありますが、この動きはもう直ぐ終わりを迎え、DIContainer自体は、コモディティ化するでしょう。 例えば、DIやライフサイクルのアノテーションの@Resource, @PostConstruct, @PreDestroyなどは、common annotationとして定義され、SpringやSeasar2では、既に利用可能になっていて、独自のアノテーションよりもこれらのアノテーションを使うほうが(Seasar2の場合は)推奨されています。 Seasar2では、既に、EJB3.0にも対応していますし、SpringもPitchfork ProjectでEJB3に対応しているので、Spring 3.xでは、コアでEJB3.1に対応してくるでしょう。 EJB3.0は、イ
「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ
自社のバックオフィスの方が、外注先に対してどんな立ち居振る舞いをしているのかご存じですか？ 自社と外注先との間の契約がどのようになっているのかご存じですか？ それを目の当たりにしても同じことを言い続けられる自信はありますか？ そういうことはスーツの仕事とレッテルを貼って見て見ぬ振りをしてませんか？ それでいて業界を変えたいなどといいますか？ 業界を変えたいっていってるところから、おいらのことを言ってるとして話を進めるよ。 バックオフィス(この文脈では調達のことかな)の方が、外注先に対してどんな立ち居振る舞いをしているのかは、正直良くわかりません。転職したことがないので、他の会社のことは良くわからないけど、弊社の場合は、調達と外注先が価格や条件の交渉する場に、案件側の人間は立ち入ることはないためです。必要だといわれたらもちろん同席するけどね。 新規取引をさせていただくときの最初の顔合わせに同
Seasarに関してこの2年間やってきたこと - ひがやすを技術ブログ
おととい、Seasarの理事、主にまさたかさんと、しばらくぶりにちゃんと話しました。そこで、おいらが、この2年間くらいの間、何を考え、何をしていたか話したんだけど、「ひがさんが何をしていたかしらなかったよ」と、まさたかさんがいってたので、きっと、コミッタの人やユーザーの方も同じだと思うので、Seasarに関してこの2年間やってきたことについて書いておこうと思います。 まさたかさんと、ここんとこ話をしていなかったのは、別に仲が悪かったわけではなく、はぶさんが理事を抜けた後、飲み会とかやらなくなったから、というのが原因。後、おいらも結婚したので、あまり外で飲まなくなったってのもあります。 2年前のSeasarがどのような状態にあったかっていうと、ちょうど、キャズムに陥っている状態。そこそこの知名度はあるけど、アーリーアダブタ以外は手を出さない。 そこで、私が行なったのは、HOT deploy、
ECMAScript4が消える? - ひがやすを技術ブログ
Flash Player 9 の発表以来、Adobe は ActionScript を ECMAScript 標準第 4 版として提案された ECMA-262 Edition 4 （ES4） に完全準拠させるという目標を公にしてきました。この ES4 は、Adobe, Mozilla, Opera, それから Google を主要なサポーターとして標準化が進められていましたが、一年ほど前に Microsoft と Yahoo! 主導で ECMA-262 Edition 3.1 (ES3.1) のワーキンググループが開始されて以来、2 つの異なる ES3 後継仕様案が並存する状況が続いていました。 先週の発表は、ES4 に関する標準化作業を中止し ES3.1 に集中することが決定されたというもので ECMAScript Harmony プロジェクトと名付けられています。 Adobe, Moz
NTTデータがウォーターフォールから脱却? - ひがやすを技術ブログ
筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。 浜口さんが、ウォーターフォールの問題点を指摘している。そして、反復型開発のマイクロソフト版である同期安定化型も今後は検討すべきだとしている。 一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム（３?８人）で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。 わが国の市場の大半を占める企業向けの個別システムに対して
SIをやるのは正社員の終身雇用を守るため? - ひがやすを技術ブログ
ある大手SIerの偉い人がこういっていたという。 SIをやるのは終身雇用を守るためこれだけでは、何を言っているのか良くわからなからないけど、真意は次のことのようだ。 アメリカではSIerは存在せず、ユーザ企業が自らシステム部門を持ち、 自社内でシステム開発を行う。 しかし、それができるのは、アメリカが終身雇用でないからだ。 アメリカでは巨大なシステム開発が完了したときに、 プログラマを解雇することができる。 日本ではそれができないため、ユーザ企業の雇用調整の機能をSIerが担っている。 ユーザ企業の雇用調整の機能をSIerが担っているのはいいんだけど、その雇用調整の仕方が、下請け構造なんだと思う。 この国の労働構造においては、正社員というのは、派遣社員無しには維持できないんです。企業が正社員に福利厚生をして、給料払って、失業から守ってあげれるのは、派遣とか期間工とか、フリーターがいるからな
IT業界は成功するチャンスの多い夢のある業界 - ひがやすを技術ブログ
泥問題、あるいは老害問題で、すっかり評判を落としたIT業界(SI業界)。他の業界へ転職しようと思った人、IT業界には入るまいと思った学生も多く出たことでしょう。 ネガティブな面は確かにあります。老害は一朝一夕にはなくならないことも確かです。 しかし、一方で、努力すれば、成功するチャンスの多い夢のある業界でもあるのです。 いまだにソフトウェアの世界では「下を走ってくる」奴が上に行く余地がどっさり残っている。理由は二つある。 一つはインターネットという別の高速道路網が存在すること。ソフトウェア「エンジニアリング」に限って言えば、こちらの高速道路の方が学校という高速道路よりもずっと充実している。しかも料金ははるかに安い。わざわざ「学歴高速道路」に乗るのはかったるくて仕方がないだろう。 しかし、もう一つの理由を忘れてはならない。それは、ソフトウェア「エンジニア」になるための投下資本が実に少ないとい
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
ゾウはイノベーションの夢を見るか - ひがやすを技術ブログ
スターロジックから新しいサービス「ギョイゾー！」が発表されました。 私たちは長年にわたり、多くの会社さんにて業務のIT化を実現してきました。それらのノウハウを集約して生まれたのがギョイゾー！です。ギョイゾー！をITの専門家向けに一言であらわすと「ワークフローとデータベースの合体したもの」となります。ギョイゾー！には次のような特徴があります。 あくまでもオーダーメイドですから、自社の業務にぴったり合ったシステムを実現します 余分な機能は一切ついていませんので、使いこなせないということがありません 導入にかかる期間も費用も非常にコンパクトなので、すぐに導入効果を感じていただけます 詳しくははぶさんのこころをみてください。 今回は、イノベーションの観点から「ギョイゾー！」を分析してみたいと思います。イノベーションといえば、クレイントン・クリステンセンのイノベーションのジレンマ、イノベーションへの
「日米トップJ2EEアーキテクトが語るフレームワーク」の未来のみどころ - ひがやすを技術ブログ
http://itpro.nikkeibp.co.jp/article/COLUMN/20080416/299267/ Gavin:Railsの中で使われているテクノロジー自体は，それほど新しいものではありません。オールドスタイルとさえ言える。 これは、悪い意味ではなく、テクノロジーが新しくなくても、開発スタイルが新しければ、価値のあるものを生み出すことができるということです。 Gavin:そして，（ソースコードの変更が再コンパイルすることなく即座に反映される）ホット・デプロイメントの重要さが注目されるようになった。この点に関してはJavaのバーチャル・マシン（JVM）はあまり良くなかった。そして，Javaのフレームワークもさらに悪かった。 Javaの世界では、今後ますますHOT deployが重要になってきます。Gavinも私もJVM任せではなく、フレームワークで解決しようとしているとこ
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
2008-03-05 - ひがやすを blog - SIerが自動車産業をまねしようとするのはいい加減やめなさい
「自動車のような産業構造に再編すべきだ」。NTTデータの山下徹社長はインドや中国など海外ソフト会社が日本市場に本格進出してくる前に、ソフト産業の構造改革を実行する必要性を説く。日本のソフト産業が崩壊の危機にあるからだ。 パッケージベンダが自動車産業を参考にするのは、100歩譲るとありかもしれない。消費者に受け入れられるだろうという予想にもとづきプロダクトを開発していくモデルだから。 でも、やっぱないな。車は、多少の違いがあっても、どれも基本的な構造は同じ。パッケージは、いろんなものがあるからね。 それに対して、SIは一品ものだもの。規格(パッケージ)通りじゃないものを作るのがSIです。 マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを
From Ruby to Java - ひがやすを技術ブログ
本当は、Rails風にしようと思ったわけではなく、ふたがわさんがCubbyがいいっていってたので、インスパイヤされて作ったらRails風になっちゃったって感じ。 http://locahost:8080/sa-struts-tutorial/loginにアクセスすると、tutorial.action.LoginAction#index()が呼び出されます。 index()の戻り値がlogin.jspだと、/login/login.jspにフォワードされます。 また、/employee/list.jspが表示されているときにリンクタグが <a href="edit/${e.id}">...</a>だと、/employee/edit/idの値に遷移し、idがActionにセットされ、edit()が呼び出されます。 edit()は以下のとおり。 @Execute(urlPattern = "ed
2007-12-16 - ひがやすを blog - WebBeans
JBUGのセミナーでGavinから直接、WebBeansの仕様を聞かせてもらった。 EJB3、JSF、JPAとも必須じゃないんだね。それぞれの実装を必要と思えば利用できる感じ。これは、悪くないと思う。 WebBeansは基本的にはDIの仕様。SeamよりもGuiceに似ていて、Guiceよりもさらに進化した感じ。Guiceは設定はJavaで書くんだけど、WebBeansはアノテーションで書く。 そして、アノテーション地獄に陥らないように、ステレオタイプという概念がある。ステレオタイプとは、複数のアノテーションをグルーピング化したもの。 例えば、A,B,Cというアノテーションを1つにまとめた、Dというアノテーションを用意し、Dをアノテーションで指定すれば、A,B,Cがそれぞれ指定されたのと同じように振舞う機能。これも良い。 残念なのは、HOT deployに対応できないところかな。全部のコン
2007-11-21 - ひがやすを blog
java-jaに流れるようなインターフェースでMapを組み立てる話が出ていましたが、Seasar2の2.4.18(もしかしたらもっと前かも)からは、Mapsクラスでその機能はサポートされています。 java-javaはhttp://www.lingr.com/room/java-ja/archives/2007/11/21#msg-18798710。 使い方はこんな感じ。 Map<String, Integer> map = Maps.map("a", 1).$("b", 2).$("c", 3).$();Listの場合は、Java標準のArraysでサポートされています。 List<Integer> list = Arrays.asList(1, 2, 3, 4);矢野さんのところで、別のライブラリが紹介されていますね。 http://d.hatena.ne.jp/t_yano/2007
2007-10-25 - ひがやすを blog
っていうか、Hibernateにも昔からcriteriaあるよね？ http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#querycriteria List cats = sess.createCriteria(Cat.class) .add( Restrictions.like("name", "Fritz%") ) .add( Restrictions.between("weight", minWeight, maxWeight) ) .list(); 流れるようなインターフェースとメソッドチェーンは違うものだよヨシオリ。ぱっとみは似ているかもしれないけど。 流れるようなインターフェースでは、ソースコードを書いている人が、中断することなく流れるようにコーディングできなければいけない。 HibernateのCrit
ひがやすを blog - 2007-09-24 - 「なぜお前らは「好きだからコードを書く」はできるのに「好きだからメンテナンスする」ができないのか?
本当の問題は「スーツ + 頭のカタイおやじ VS. 無垢な技術者」という話だろうか。なんで、スーツの人や、頭のカタイおやじや、無垢な技術者がいるのか、その前提条件を問わなくちゃいけないんじゃないのか。その前提条件に、自分がどんな一手を打てるのかを考えて、世界を変えていこうよ。ていうか、世界を変えていたじゃない。 なんか、高井さんが勘違いしているみたいだから、書いておくけど、俺は、「だから世の中が悪い」とかいうつもりはありません。この構図は、過去何度も繰り返されている事実だから、まず私たち技術者は、その事実をきちんと認識しなければならない。 昨日は書かなかったけど、実は、「弱い技術者」というのは、「頭の固いおやじ予備軍」でもだったりする。 実際良く見かけるんだけど「最新の技術についていくのは疲れた」「なにかスーパーなデファクトが現れてそれで統一されて欲しい」「考えるのめんどくさいから標準で統
ひがやすを blog - Javaを古くしたやつとRubyを煽っているやつ
その正体はわかったよ。正体わかった瞬間からだが震えたよ。まじで。 まずは、羽生さんのこのエントリを見て欲しい。 http://d.hatena.ne.jp/habuakihiro/20070922#1190464426 その後によしおりのこの有名なエントリも復習して欲しい。 http://d.hatena.ne.jp/jYoshiori/20070826/1188150596 もうさぁ、変わってないよねぇ。昔からのこの構図。歴史は繰り返すっていうの。 あからさまにいうとさぁ。賢いスーツな奴らと、頭の固くてあわれで保守的なおやじの歴史だよ。 最初は、EJBだよ。EJB。これからは、ビジネスコンポーネントが流通して、もうプログラミングはいらなくなる。コンポーネントの組み合わせを考えるだけでOKみたいな。最初にね、キャッチーな言葉とともに、あらたなテクノロジーを広めようとするのは、賢いスーツな奴
ひがやすを blog - [Seasar]JavaとLL
Seasar自体を使うかどうか、とかいうレベルではなくJavaという重量級言語でもテクニックを駆使することでここまでLL的に開発が行える、という意味でです。 Seasar2を使えば確かにLL的な開発が可能です。でも、Javaでそこまでがんばらなくても、LLを最初から使ったほうがいいんじゃないのと思われる方もいるでしょう。WEB+DB Pressの「Alpha Geekに逢いたい」で小飼弾さんにもそういわれました。 Railsの得意なところはRailsに任せればいいじゃんとは考えなかったんですか。システムの一生というものを考えたときに、LL的な開発が必要なのはほんの一瞬です。大部分は、運用のフェーズなのです。運用で大切なのは、「安定性」と「パフォーマンス」で、LL的な側面ではない。 だから私は「Railsに任せればいいじゃん」とは考えない。「LL的な面が必要な場合は、HOT deployを使
![ひがやすを blog - [Seasar]JavaとLL](https://cdn-ak-scissors.b.st-hatena.com/image/square/9911d3379caeb8ea97c0562417faa4fe56ca183d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126970898857%2F17680117126970927287%2F1550549910)
ひがやすを blog - ドメインモデルに対する日米の温度差
ドメインモデルに対する日米の温度差 ひさびさにみたなぁ、この話題と思いつつ、コメントします。 昔書いた自分の記事をすべて読み返したわけではありませんが、どこにもトランザクションスクリプトが良いと書いたことはないはず。 この話題に関する問題の根源は、ファウラーが トランザクションスクリプトは、単純だから単純なシステムには向いている。でも、複雑な問題を扱うには、真のオブジェクト指向であるドメインモデルを使ったほうが良い。としたところにあると思います。これが、そもそもおかしい。複雑なシステムを扱うには、ドメインモデルのほうが向いているというのは根拠がない。データと振る舞いを一つにまとめることがオブジェクト指向というのも単純すぎる。 別にオブジェクト指向はこうあるべきなんていまさら議論するつもりはありませんが、私の中でのオブジェクト指向は、「それぞれのオブジェクトがきちんと割り当てられた責任を果た
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
