プログラマ老いやすくハッカー成り難し - ひがやすを技術ブログ
おごちゃんのところで、「おっさんハッカー」ってエントリがあったから、最初は小林さんのことかと思って読み始めた。でも、エビちゃん好き、CanCam好きのおっさんって違和感あるから、そうではないのか。 ところでここで説明なしに「おっさん」と言ってしまってるけど、一応おっさんについての定義をしておこうと思う。いろいろ考えたのだけど、 本人の能力 ＜ 本人の社会的位置 となったらおっさんではないかと思う。たとえば、「高給とってるダメな上司」なんてぴったりこの式にあてはまるし、「評論家」なんてのもその評論対象の世界ではそうだし(そうでなかったら評論家なんかならなくて現役のはずだ)、「35歳」過ぎて単価と原価が逆転してしまったプログラマなんかもあてはまる。つまり、 他人の稼ぎで給料が作られるようになったら「おっさん」 ではないかと思うわけだ。だから、要員派遣だけで歳なりの給料はもらえないし、プログラム
NTTデータの黒船コンプレックス - ひがやすを技術ブログ
日本のソフトウェア産業とかSI業界が世界に出て行けない要因は気合いとか技術力ではなく産業構造や規制に起因していることが分かったし、日本でトップに立った会社が世界に出て成功するかというと難しいと感じている。 日本のSI業界は、「世界に出て行けない」んじゃなくて「世界に出て行く必要がなかった」というのが、事実だと思いますよ。国内で儲かっていれば、リスクを犯して海外に進出するメリットがないもの。 自動車産業だって、国内では十分に成長できなくなったから、海外に進出したんでしょう。 国内のSI市場が既に飽和しているかというと、そんなこともないと思います。これは、あくまで自分の感覚ですが。 でもうまみのある儲けの機会が減ってきているのと、海外から黒船が来日している、だからNTTデータのようなこれまで成長を続けていた企業が騒ぎ出しているんだと思う。 「自動車のような産業構造に再編すべきだ」。NTTデータ
WebSphereでさくさく開発 - ひがやすを技術ブログ
WebSphere Application Server v6.1（以下 WAS）には、WebSphere Application Server Toolkit v6.1（以下 AST）と呼ばれる Eclipse をベースとした統合開発環境（IDE）が同梱されています。AST を利用すると、WAS 上で動作するアプリケーションの作成、テスト、およびデプロイが行えます。 AST には、アプリケーションの「自動公開」という機能があり、デフォルトで有効になっています。「自動公開」機能は、WAS 上で動作中のアプリケーションの Java コードが変更された場合に、その変更を感知し自動的にアプリケーションを更新（アプリケーションサーバーへ再デプロイ）します。この機能を利用することで、アプリケーションを手動で更新する手間を省くことができます。 ASTの「自動公開」は便利な機能ですが、Java コードの
罰当たりな僕が感謝していること - ひがやすを技術ブログ
それゆえ、私には 「エンジニアが幸せになるためにはその産業が国際競争力を持つことだと思う」 というのは、ちょっと違うでしょうってこと。という台詞がひどく罰当たりに聞こえる。もしひがさんが日本以外の国に生まれ育ってオープンソースプログラマーを志したらこんな牧歌を歌っていられるのですか、と。 今の私がオープンソースプログラマーをやっていれるのは、日本のような国際競争力のある国(産業ではない)にいるからってのは、そのとおりだと思います。 しかし、私にとって、「日本に生まれたこと」より、「誰と知り合ったか」がやっぱ重要だなぁ。感謝しているのは、日本というより「まわりの友人たち」。 はぶさんに「Seasarつくってよ」っていわれなかったら、Seasarなんか作らなかった。でたばっかりの無名のSeasarをメディアを通じて広めてくれたのもはぶさんのおかげです。 Seasarが盛り上がってきたときに、仲
エンジニアの幸福感に国際競争力が必要ってのはおかしいと思うよ - ひがやすを技術ブログ
エンジニアが幸せになるためにはその産業が国際競争力を持つことだと思うんだよね。 エンジニアは、「自分の仕事を人に認めてもらうこと」で幸福感を得る。国際競争力があるかどうかなんて関係ない。ただし、国際競争力があれば、自分のことを認めてくれる人が増えるので、幸福感の量は増えるかもしれない。でも、それだけのことにすぎない。 日本に唯一あるのはゲームの世界で，ゲームの世界のエンジニアはすごく幸そうですよね。 任天堂の岩田聡社長と話したんですが「うちには好きなことをやっている人間しかいません」と豪語されていましたね。それでその周囲に放っといてもゲームのプログラムを書いてくれる人たちが万単位でいて。 ゲームのクリエータは，成果報酬で億単位のお金を得ている人たちがけっこういて，そういうひとたちがロールモデルになって，人材がその産業に流れ、しかも育っています。 でもそれは、突き詰めて言うと，ひとえに日本の
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
ゾウはイノベーションの夢を見るか - ひがやすを技術ブログ
スターロジックから新しいサービス「ギョイゾー！」が発表されました。 私たちは長年にわたり、多くの会社さんにて業務のIT化を実現してきました。それらのノウハウを集約して生まれたのがギョイゾー！です。ギョイゾー！をITの専門家向けに一言であらわすと「ワークフローとデータベースの合体したもの」となります。ギョイゾー！には次のような特徴があります。 あくまでもオーダーメイドですから、自社の業務にぴったり合ったシステムを実現します 余分な機能は一切ついていませんので、使いこなせないということがありません 導入にかかる期間も費用も非常にコンパクトなので、すぐに導入効果を感じていただけます 詳しくははぶさんのこころをみてください。 今回は、イノベーションの観点から「ギョイゾー！」を分析してみたいと思います。イノベーションといえば、クレイントン・クリステンセンのイノベーションのジレンマ、イノベーションへの
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
Seasar2でサクサクか炎上か - ひがやすを技術ブログ
可燃プロジェクトに飛び込むことになりました。下記のような炎上する要素満載。 関係者各社に告知済みのためカットオーバーは伸ばせない 外部仕様を策定した会社は行方不明 外部仕様はあるが、OS も AP サーバも環境もアーキテクチャーも未定 外部仕様を分かる人がいないw 開発は 3 社合同なのにソース管理方式も決まってない DB アーキテクト不在っぽい フレームワークに詳しい人がいない AJAX っぽいのたくさん お金がない、規模はわりとでかい、納期短い、残業禁止、増員不可 最初このエントリを見たとき、4/1だったこともあり、一瞬ネタかなと思ったんですが、その後に、SAStrutsとS2JDBCに対する具体的な質問がいくつもあり、私のほうもできる限り質問に答えました。 その後、どうなったのか気がかりだったんですが、今見たらこんな書き込みが 開発メンバからは、簡単で楽でいい！ 1 機能が 1 時間
「日米トップJ2EEアーキテクトが語るフレームワーク」の未来のみどころ - ひがやすを技術ブログ
http://itpro.nikkeibp.co.jp/article/COLUMN/20080416/299267/ Gavin:Railsの中で使われているテクノロジー自体は，それほど新しいものではありません。オールドスタイルとさえ言える。 これは、悪い意味ではなく、テクノロジーが新しくなくても、開発スタイルが新しければ、価値のあるものを生み出すことができるということです。 Gavin:そして，（ソースコードの変更が再コンパイルすることなく即座に反映される）ホット・デプロイメントの重要さが注目されるようになった。この点に関してはJavaのバーチャル・マシン（JVM）はあまり良くなかった。そして，Javaのフレームワークもさらに悪かった。 Javaの世界では、今後ますますHOT deployが重要になってきます。Gavinも私もJVM任せではなく、フレームワークで解決しようとしているとこ
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
SpringとJBossの全面対決はじまったな - ひがやすを技術ブログ
今月末ぐらいに、Springsource Application Suite Enterprise Editionというのを発表する予定。これは、Springアプリ用のコンフィグ済みコンテナみたいなもんで、アプリケーションサーバとして、 JBOSSの対抗馬として出すようです。 ウェブサーバはカスタマイズしたTomcatを使って、クローズドソースを含んで、GPLとコマーシャルデュアルライセンスで、コマーシャルの場合はサブスクリプションベースのサポートつきだそうです。 これまでも、あまり仲のよくない(ようにみえる)SpringとJBossですが、ついに全面対決をはじめるみたいですね。 いままで、JBoss上でSpringを使っていたユーザーも多いと思うので、それがSpringのサーバに流れたら、JBossも苦しいでしょう。 このサーバ対決は、その上で使われるフレームワーク対決になるんじゃないで
「お前が言うか」シリーズ - ひがやすを技術ブログ
日本のソフトウエア開発では、なぜか各工程に関わる職種のなかでもプログラマーの地位が低くなってしまっている。その労働環境の悪い一面が新３Ｋ（きつい、厳しい、帰れない）などと言われ、業界イメージ全体が悪くなっている。 私は本来プログラミングは創造的で楽しいものだと思っている。何故このようにイメージが悪くなって、楽しくないものだとされるようになってしまったのか、大きく二つ考えられる。 一つ目は、適性の判断や必要な訓練をせずにプログラマーと称する人たちを粗製濫造してしまったことだ。一般に優秀なプログラマーと適性のないプログラマーでは、その能率や品質に20倍前後もの差があるといわれている。このような人たちをまとめて「平均単金×工数」というような価格設定で、たいして差の出ない処遇をするからプログラマー全体の価値が下がってきている。同じプログラムを10分の1の時間で、しかも品質よく作成できるプログラマー
技術者はもっと自分の評価(給料)にこだわるべき - ひがやすを技術ブログ
私も，自分がやったぶんは認められたいという思いはあります。好きなことをやらせてもらっていれば，別にどういう評価だって関係ないよ，というのは技術者にとって良くない。やっぱり自分がちゃんとやったぶんは，ちゃんと世の中からも会社からも認めてもらうような形にしないと，後から入ってくる人が，がんばろうというモチベーションがなくなるじゃないですか。今後のIT業界のために，ちゃんと何かやったぶんはほめられるよ，という世界にしていきたいなとは思っていますね。私をそのための良い踏み台にしてほしいです（笑）。 『Seasar2によるスーパーアジャイルなWeb開発』発売記念インタビューの後編が公開されました。 この中で最も伝えたかったことは「技術者はもっと自分の評価(給料)にこだわるべき」だということです。好きなことをやらせてもらえるなら、「評価はそんなに気にしない」だとか「給料はそこそこでいい」だとか、思って
技術が枯れる瞬間の見極め - ひがやすを技術ブログ
ギークなら、わくわくするような新しい技術をいつも試してみたいと思っているでしょう。しかし、現実の開発の現場では、ギーク以外の人がほとんどなので、新しい技術には興味がないわけです。たぶん、新しいことを覚えること自体面倒だと思っているでしょう。 そういう中に新しい技術を導入するには、「生産性が高くなる」「開発が楽になる」ということをまわりに納得してもらわなければいけない。最初は、反対されるでしょう。自分が責任取るからと強引に導入しようとするときに、考えて欲しいのは、その技術の枯れ具合です。 新しい技術なので、枯れていないのは当たり前です。なにかあったときに、頼れる場所があることが重要です。頼れる場所とは多くの場合、MLやフォーラムなどでしょう。そこでのレスポンスが早ければ、多少枯れてなくても何とかなります。 何とかなるとはいえ、枯れていない状態が長く続けば、それだけ利用者の負担も増える(MLな
なぜ、SIerが「なにを」作ったのかを公開しないのか - ひがやすを技術ブログ
なぜ、SIerが「なにを」作ったのかを公開しないのか、それが私には不思議でならない。同じくソフトウェアを開発するものとして、納得が行かない。もちろんNDAの壁はある。私でさえ、開発に携わった事実そのものを公開できない案件をいくつか手がけて来た。しかし誰がどの案件を手がけたかすらデフォルトで非公開というのは理解に苦しむ。 あいかわらず弾さんの突っ込みは、内藤のフェイント(相手を見ずに自分の打ちたいところに打つ)のようだと思いつつコメント。 「NDAがあるから」デフォルトで非公開というのは、「あたりまえ」だと思うけど、これだけだとつまらないので、もうちょっと突っ込んで書きます。 一番の原因は、「公開することがお客様にとってメリットがない」あるいは「公開するとマイナスになる」ことが多いからです。 特に社内に閉じているようなイントラ案件は、自分たちの動きが同業他社に知られないように隠しておきたいも
メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの
Seasar2はRailsのマネだという人にそろそろ一言いっておくか - ひがやすを技術ブログ
まとまって読めるものがないと、伝わらないと思っていたので、ずっとスルーしてたけど、「Seasar2によるスーパーアジャイルなWeb開発」が本屋に並び始めたので、そろそろ言っておこうか。 最初にHTMLを書いて、やりたいことが決まったら、そこから、Javaのクラスを自動生成していく開発スタイル(ページ駆動開発)は、「他ではほとんど行なわれていない」かつ「有効」な技術で、「Railsのマネ」なんかじゃないと思うよ。DoltengはRailsのようにテーブルからscaffoldもできるだけで、本命は「ページ駆動開発」です。 もちろん、Seasar2は、Railsから多くのものを学んでいます。一番学んだのは、「動く状態を常に保ちながら開発していく」ということ。これを実現するために、HOT deployを完成させたわけです。 たぶん、多くの人が勘違いしているのは、CoCの概念をSeasar2はRai
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
