SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
年齢を重ねるに従って磨かれる能力 - ひがやすを技術ブログ
僕は今31歳ですが、末恐ろしいヤングライオンがいっぱいいることをひしひしと感じています。ある能力で局地戦を挑まれたら負けちゃう。経験はつんでも、時の流れで陳腐になっちゃうスキルはいっぱいある。 それをふまえた上で、「年をとってもヤングライオンに負けないようにする為には何を実施し、何を辞めるのか」を決めることがキャリア戦略というものだろう、と思うようになりました。誰もこの辺語ってくれないんだけどね。経験が能力に勝つ為にはどうすべきか。考えないといかん。 そんな迷えるごーざ先輩に年齢を重ねるに従って磨かれる能力を教えてあげよう。 それは、「勘」。 「勘」は偶然ひらめくものではない、また、「勘」が当たるのも偶然ではない。 これは、あくまでも自己の経験からくる個人的な感覚だけど、「勘」というのは自分の中に蓄積された膨大な経験から、右脳が瞬時に似たパターンを見つけ出したものだと思う。 自分の過去の記
受託開発に未来はない? - ひがやすを技術ブログ
私は1年以上、エンタープライズの世界(企業向けSIとか)から離れ、ずっとGoogle App Engineをやっています。今は、Google App Engine + Webkitベースのブラウザで動くHTML5を使ったグローバルな新サービスを提供しようとしていて、新規事業立ち上げのために日々奮闘しているので、エンタープライズな世界に戻ってくることは、基本無いでしょう。 私は、受託開発に未来はないと思っているので、自分でサービスを提供する側に回ろうとしているわけです。受託開発に未来はないといっても、文字通り未来はないという意味で、すぐになくなるわけではないし、生きてくために必要な部分も多々あると思います(うちの会社もSIerだし)が、今後は撤退すべきだろうという判断です。 受託開発になぜ未来がないかというと、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものが生き
DIって本当に必要? - ひがやすを技術ブログ
DIって本当に必要?たまにそう思うときがあります。DIによって開発は本当に楽になったのか。 DIのメリットでよく語られることとして、インターフェースと実装を分離し、機能の利用者側はインターフェースを通じて機能を利用することで、実装に直接依存しなくなり、後で実装を変更しても影響を受けなくなるということがあります。 実際後から、実装クラスを変更するということはめったにないので、よくあるのは、テストのために実装クラスをモックに変えることです。 でも、別にそれだけならDIContainerなんていりません。たとえば、次のようにServiceクラスに直接依存したClientがあるとします。 class Client { Service service = new Service(); void setService(Service service) { this.service = service;
DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/
SIerの解体と再生 - ひがやすを技術ブログ
ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの
NTTデータの黒船コンプレックス - ひがやすを技術ブログ
日本のソフトウェア産業とかSI業界が世界に出て行けない要因は気合いとか技術力ではなく産業構造や規制に起因していることが分かったし、日本でトップに立った会社が世界に出て成功するかというと難しいと感じている。 日本のSI業界は、「世界に出て行けない」んじゃなくて「世界に出て行く必要がなかった」というのが、事実だと思いますよ。国内で儲かっていれば、リスクを犯して海外に進出するメリットがないもの。 自動車産業だって、国内では十分に成長できなくなったから、海外に進出したんでしょう。 国内のSI市場が既に飽和しているかというと、そんなこともないと思います。これは、あくまで自分の感覚ですが。 でもうまみのある儲けの機会が減ってきているのと、海外から黒船が来日している、だからNTTデータのようなこれまで成長を続けていた企業が騒ぎ出しているんだと思う。 「自動車のような産業構造に再編すべきだ」。NTTデータ
HOT reloadingとClassLoaderを理解しよう - ひがやすを技術ブログ
JavaではClassはClassLoaderに読み込まれます。これはほとんどの人が知っていると思います。AOPを使うときのエンハンスされたクラスも同様にClassLoaderに読み込まれます。 これらの情報は、パーマネント領域に格納されますが、ClassLoaderがGCされると解放されます。 Seasar2のHOT reloadingでは、リクエストの度にClassLoaderを作って、そこにClassをロードし、そのClassLoaderは、リクエストが終わったら破棄しているので、Classの情報は、リクエストごとに破棄されています。 HOT relodingによって、パーマネント領域が使いつくされることはありません。 さらっと書きましたが、きちんとClassLoaderを破棄するのは、かなり大変です。リフレクションの情報がキャッシュされているとそれだけで破棄されなくなってしまうから
山城先生、泥酔状態のO容疑者に乳をもまれる - ひがやすを技術ブログ
java-jaの飲み会のとき、山城先生が、泥酔状態のO容疑者に乳をもまれたという疑惑が浮上している。O容疑者は、他にも"バイ"疑惑があるようだ。 O容疑者は、最初「山城先生の乳をもんで何が悪い」と暴れていたようだが、その後何も覚えていないとコメントしている。 この事件の後、山城先生は、一年間も誰にも言えず(ヨシオリには相談したらしいが)一人で悩んでいたらしい。 事件の早期解決を期待したい。 事件の調査中に判明した驚くべき事実として、山城先生は、合コンではもてるらしい。女の子から、かわいいと思ってもらえているようだ。乙女ゲー好きで有名なYから聞いたので間違いないだろう。 しかし、二度目のデートのときには、イメージと違うことが判明し、ふられてしまうようだ。山城先生のリア充への道は遠い。
メタプログラミングの光と影 - ひがやすを技術ブログ
メタプログラミングとはソースコードを生成するプログラミングのことです。メタプログラミングによって生成したソースコードは、eval関数で実行することができます。 メタプログラミングとは、ロジックを直接コーディングするのではなく、あるパターンをもったロジックを生成する高位ロジックによってプログラミングを行う方法、またその高位ロジックを定義する方法のこと。 メタプログラミング - Wikipedia だから、eval関数は、手段であり、メタプログラミングそのものではない。これは弾さんが指摘してますね。 evalだけがメタプログラミングの技法ではないし、またevalはその威力ゆえ最後の選択肢とすべきだ。 弾さんのパフォーマンスの指摘に対して、miyagawaさんが、「必ずしもevalが遅いとは限らない」と指摘してますね。 メタプログラミングとevalのベンチマーク - Bulknews::Subt
Seasarに関してこの2年間やってきたこと - ひがやすを技術ブログ
おととい、Seasarの理事、主にまさたかさんと、しばらくぶりにちゃんと話しました。そこで、おいらが、この2年間くらいの間、何を考え、何をしていたか話したんだけど、「ひがさんが何をしていたかしらなかったよ」と、まさたかさんがいってたので、きっと、コミッタの人やユーザーの方も同じだと思うので、Seasarに関してこの2年間やってきたことについて書いておこうと思います。 まさたかさんと、ここんとこ話をしていなかったのは、別に仲が悪かったわけではなく、はぶさんが理事を抜けた後、飲み会とかやらなくなったから、というのが原因。後、おいらも結婚したので、あまり外で飲まなくなったってのもあります。 2年前のSeasarがどのような状態にあったかっていうと、ちょうど、キャズムに陥っている状態。そこそこの知名度はあるけど、アーリーアダブタ以外は手を出さない。 そこで、私が行なったのは、HOT deploy、
貴腐ワインを楽しもう - ひがやすを技術ブログ
そしてお店のおねーさんが勧めてくれた、貴腐ワインなるものを頂く。 あま?い。とってもスイート。スイーツではなく、スイート。これが貴腐クオリティ。 新ジャンル：貴腐女子もここで生まれた。 「フォルシュター・シュネフェンベルグ・フクセルレーゼ・トロッケンベーレンアウスレーゼ」 貴腐ワインってなんだか知ってます? ぶどうにボトリシスシネレア菌が付着することにより、干しぶどう状態になります。干しぶどうって甘いですよね。なぜかというと水分が飛んで、糖分の割合が増えたからです。 この干しぶどう状態のものを醗酵させるのですが、糖分が濃すぎて、アルコール発酵は、途中で止まってしまいます。すると残りの糖分がそのままワインに残るので、貴腐ワインは甘くなるわけです。アルコール発酵を人工的に止めることもあります。 世界3大貴腐ワインというと、フランスのソーテルヌ、ドイツのトロッケンベーレンアウスレーゼ(TBA)、
40になる前に宝くじを買っておけ - ひがやすを技術ブログ
明日で40になる前に、一言言っておきたいことがある。 40になる前に宝くじを買っておけということだ。 「宝くじを買う」というのは、もちろん比喩で、「チャンスをつかもうと行動する」ことをあらわしている。 前に、エンジニアの未来サミットで、よしおかさんもいっていた「宝くじは買わなきゃあたらない」。宝くじは、ほとんど当たるものではないけど、でも、買わなければ絶対にあたらない。これと同じで、「チャンスをつかもうと行動しても、成功する可能性は低いかもしれないけど、でも行動しなければ絶対に成功しない」ということじゃないかと思う。 これは、「成功する可能性は低くても、まずは行動しろ」というメッセージだ。 今、自分は、仕事で何をするかはすべて自分で決めることができる。それで、自分のやりたいこととしてオープンソースにかかわっている。プログラマとしては、かなり恵まれた立場だろう。こうなれたのは、オープンソース
第一回ひがやすを飲み会やるよ - ひがやすを技術ブログ
エンジニアの未来サミットのときに予告した「IT業界をざっくばらんに語る会」を10/8(水)におこないます。 学生だとか若手でIT業界についていろいろ聞いてみたい人だとか、業界の人といろいろ話してみたい人だとか、自由に参加してください。もちろん、若手じゃなくてもOK。 http://d.hatena.ne.jp/hyoshiok/20080915 表では聞けないようなことも自由に聞いてください。ただ、そういうことは後からblogに書かないように(笑)。 営業の方だとかエンジニアでない人も、IT業界に関係ない人も遠慮なくどうぞ。いろんな人がいたほうが、有意義な話になると思います。 エンジニアの未来サミットのようなちゃんとしたイベントも重要だけど、こうした草の根的な飲み会も重要だと思う。 開始は、19:00から。参加したい方は、higayasuo_at_gmail.com(_at_は@に変更)に
華のあるイベントやりまーす - ひがやすを技術ブログ
以前予告した日本Javaユーザグループでクロスコミュニティカンファレンスの中身が大体決まったので、お知らせします。10/16の午後は空けておいてね。 タイトル:パフォーマンスチューニング入門 講演者:amachang 概要:IT戦士 amachang が日頃やっているパフォーマンスチューニングの方法を紹介いたします！ポロリもあるよ！ タイトル:ギークなお姉さん(仮) 講演者:べにぢょ、山田あかね タイトル:『JavaからRubyへ』・アンド・ナウ 講演者:角谷、高井、和田 概要:角谷がついカッとなって『From Java to Ruby』と題された書籍の翻訳をはじめてから2年が経ちました。『JavaからRubyへ』というバズワードは我ながらうまく状況をとらえたと思っていますが、書籍に書かれているのはあくまでも著者Bruce Tateの主張です。このセッションでは私たちそれぞれの立場と視点と
アルファギークが空回り - ひがやすを技術ブログ
エンジニアの未来サミット、一部が学生とアルファギークの対談、二部がアラサーにとってのIT業界。 一部は、企画者としては反省点がいろいろあります。一番の反省点は、弾さんをモデレータに選んだこと。 これは、弾さんが悪いということじゃないですよ。弾さんは、熱くて、場の空気は読まない人だから、スピーカーには向いているけど、モデレータには向いていない。 弾さんをモデレータに選んだのは私なので、これは完全に私のミス。 学生とアルファギークの対談も空回りしていたと思います。あんまり対談になっていなかった。猛獣の中に、ウサギを放り込んだような。チャットでもいわれていたけど、前半は、学生が空気のようになっていたかもしれないです。ごめんなさい。 泥の話も空回り。泥の話って結論が出にくい割りに、たとえ結論が出ても前向きな話にならない。泥はテーマからはずすべきでした。 チャットによって、見ている人の意見がダイレク
NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ
昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
年功序列がITの進化を阻害している? - ひがやすを技術ブログ
例えば、ITは1980年代以降のものですから、その頃すでに企業の中堅になっていた世代の人たちが、いま企業において決定権を持っているわけですね。その人たちは、新しい技術に適応力を持っておらず、ITが得意なのは若い人です。だから、もし会社の中でITを活用するようなことになったら、下克上が起こる。 そういう人たちがITの導入に積極的な考えを持つとは考えられません。これは、日本型企業のひとつの特徴である年功序列制が、新しい技術の導入に抑制的に働くことを意味します。 会社の中で、ITを活用するようになったら、ITの得意な若手によって下克上が起こるそうです。どんな下克上なんでしょうね。 まぁ、これはネタだと思いますが、でも、鋭いところもある。 「日本のSIの生産性は20年間進化していない」と読みかえてみると、実はあっているんじゃないでしょうか。ITの技術は、常に日進月歩ですよ。これはまちがいない。SI
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
