2/11(水)から、Seasar2入門の発売が開始されました。 http://www.amazon.co.jp/Seasar2%E5%85%A5%E9%96%80-%E3%81%B2%E3%81%8C-%E3%82%84%E3%81%99%E3%82%92/dp/4797345241/ref=sr_1_7?ie=UTF8&s=books&qid=1232424964&sr=1-7 書評は、ここまでトラックバックしていただければ幸いです。 とりあえず、うちのかみさんが、欲しいといっていたので、1冊プレゼントしよう。ちなみに、前回のSuper Agile本は、JSFベースなので、あまり興味がないといってました。なんだかんだいっても、Strutsは、もてフレームワークということですね。

日本航空（JAL）は日本IBM、IBM ビジネスコンサルティング サービス、SAPジャパンの協力で、新しい整備業務システム「JAL Mighty」を開発し、11月に稼働させたと11月28日に発表した。SAPのERPパッケージ「SAP R/3」を使い整備計画などの管理を行う。19のモジュールを使うシステムで、4社によると「世界最大の航空整備業務システム」だ。 JAL Mightyが対象とするのは約160機の機体、460基のエンジン、50万個の装備品。それぞれに対して整備計画や品質管理、部品在庫管理を行えるようにした。利用するのはJALの約6000人の整備士ら。開発に当たっては整備管理や品質管理のほか、整備士の資格管理も含めた約100の業務システムをSAP ERPに統合した。開発プロジェクトは2005年4月に開始。累積の投資額は約300億円にのぼるとみられる。 JAL Mightyによって業務

「ソフトウェア開発の匠」。このタイトルには、ソフトウェアエンジニアは現代の匠（たくみ）になるべきだという筆者の思いを表現している。現在のソフトウェア開発は、残念ながら多くの人が過去の職人気質（かたぎ）を捨て去り、サラリーマン化しすぎている。ビジネスの価値を高める最適なソフトウェア開発の姿について、自ら描くことをしていない。 しかし、ただ旧来の職人気質を取り戻すだけでは駄目なのである。ヨーロッパのマイスター（匠）のように尊敬されるためには、ビジネスを知り、ビジネス価値を高める職種になることが必要である。それが、ITエンジニアの目指すべき匠である。そのような人材像を「ソフトウェア開発の匠」とし、本連載では、そこに近づくための考え方や解決法を読者にお伝えできればと思う。 まず第1巻（連載第１～2回）では、現在のソフトウェア開発手法が未熟であることを、さまざまな問題を例に述べる。そして、これらの問

「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ

最近のハードディスクはどんどん大容量化が進み、小さな容量のものの入手がだんだんと難しくなってきて悩んでいます。このことを他の人に話すと、大抵は「え？大は小を兼ねるので大容量なものを使えばいいのでは？」という返事が返ってきます。しかし、必要以上に大容量のハードディスクは、いろいろと不便が多いのです。今回はその理由について述べてみたいと思います。 フォーマットやRAID再構築に時間がかかる 例えば80GBと1TBのハードディスクでは、実に12.5倍もの容量差があります。いろいろな要素を省いて単純に考えると、フォーマットやRAID再構築も12.5倍の時間がかかるということになります。仮に80GBのハードディスクを使ったRAIDの再構築に3.5時間かかるとすると、1TBのそれは、諸要素を除いて単純計算すると44時間もかかることになりそうです。フォーマットやRAID再構築は結構時間がかかりますので、

今は友人までの公開になっているので、リンクをクリックしても発言を読めません。このエントリを書いたときは誰でも読めたんだけどね。 勉強会とかコミュニティ活動に参加できるのは、下請けに仕事を押しつけてるからじゃねーの？ 仕事は、一人ではできないので、いろんな人に支えられてやっています。そういう意味で、支えてくれる人なしには何もできないのは事実です。 で、だ。 自分はどうかといえば、おれは、ほとんど、一人で仕事をしているから、下請けとか関係ないです。うちの会社でどうかといえば、下請けに仕事を押し付けている人なんていないですよ。みんな仕事大変だからね。忙しいし。 で、だ。 誰に言っていてもいいんだけど、上記の言葉の裏には、コミュニティ活動は、暇だからできるみたいなニュアンスが感じられるんだけど(間違っていたらごめん)、コミュニティ活動ってかなり大変だよ。 例えば、この前、「ひがやすを飲み会」なんて

以前、「簡単コピー・プログラミングの罠」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。 そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。 アプリケーションに固有の「業務ロジック（ビジネスロジック）」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想

ITにおけるデスマーチを語るからには当然ヨードン先生の「デスマーチ第２版」くらいは読んでおかないと資格はないよ、と言うべきところなのだろう。 デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか 作者: エドワード・ヨードン,松原友夫,山浦恒央出版社/メーカー: 日経BP社発売日: 2006/05/03メディア: 単行本購入: 9人 クリック: 355回この商品を含むブログ (119件) を見る訳者あとがきでは語源について触れられていつつも、あくまで表象だけをとって言葉を当てはめた、ということは理解できると思う。もちろん、本文に語源であるところのいわゆる「死の行進」に触れられたところはなくて、プロジェクトマネジメントにおけるデスマーチのことしか書かれていなく、かくしてIT業界の戦士(なんていうから突っ込まれるのか？)たちは語源の政治性など気にせず自らのおかれる立場をデスマーチ

「『まつもとゆきひろ×最首英裕』〜Rubyを仕事に2008〜」の対談のレポートがあがっていたので、とりあえず気になった点を突っ込んでおきます。 最首氏はRubyとJavaを比べたとき、「RubyはJavaのように使うことができて、 JavaはRubyのように使うことは出来ないかもしれない」と述べ、RubyをJavaのように使うことも危険だし、JavaをRubyのように使うのも同じように危険だと思います。 またRubyを仕事で使うメリットとして 「アジャイル開発がしやすい、プロトタイピングが容易」 「学習曲線が早い」ことを挙げた。Railsがあるので、プロトタイピングはやりやすいと思います。アジャイル開発は、チームのマインドの問題なので、言語は関係ないよね。 「学習曲線が早い」というのは、賛成できないなぁ。 まつもと氏は「10年前のJavaに似ていると言われる」と述べ、 最首氏は「Javaの

SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大

SI業界が開発するシステムの目的は何か？　それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない

この老害リトマス試験は、スーツな人もギークな人もスイーツな人も受けて欲しい。自分の老害危険度がわかるはず。 老害とは、「状況の変化を認識できず、古い考えを押し通し、回りに迷惑をかけること」。 詳しくはこちら。 SI業界の老害が若手と下請けを蝕む理由 日本版iPhoneのニュースを見たとき、あなたはどう思っただろうか。 「ぜひ欲しい」と思ったあなた。正常な反応だけど、「でも、それだけ?」 日本でiPhoneがどれくらい売れるのかを予想してもあまり意味がない。だって、神様でもない限り先のことはわからないんだから。 でも、これだけはいえる。 「iPhoneは新しいアプリケーションプラットフォームになる」 新たなアプリケーションプラットフォームの立ち上がりに参加できるなんてすごい幸運だ。スーツな人なら、新しいビジネスを考え付けば、大もうけできるかもしれない。 ギークな人なら、このわくわくするテクノ

泥問題、あるいは老害問題で、すっかり評判を落としたIT業界(SI業界)。他の業界へ転職しようと思った人、IT業界には入るまいと思った学生も多く出たことでしょう。 ネガティブな面は確かにあります。老害は一朝一夕にはなくならないことも確かです。 しかし、一方で、努力すれば、成功するチャンスの多い夢のある業界でもあるのです。 いまだにソフトウェアの世界では「下を走ってくる」奴が上に行く余地がどっさり残っている。理由は二つある。 一つはインターネットという別の高速道路網が存在すること。ソフトウェア「エンジニアリング」に限って言えば、こちらの高速道路の方が学校という高速道路よりもずっと充実している。しかも料金ははるかに安い。わざわざ「学歴高速道路」に乗るのはかったるくて仕方がないだろう。 しかし、もう一つの理由を忘れてはならない。それは、ソフトウェア「エンジニア」になるための投下資本が実に少ないとい

早春とフィルム写真 カラーネガフィルムとはなんとも不思議なメディアで、その季節の陽光だとか湿度が写真に乗ってくるような気がする。 冬の写真は暗くかさついているし春の写真は霞がかって見える。夏の写真は湿度100%に近い空間を貫いてくる強い太陽光がフィルムの乳剤面に記録されてい…

10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変

俺は大学でコンピュータサイエンスを 4 年間学んだ。とはいっても大学自体の学歴・成績は平凡もいいとこ。真の意味でのプログラマのレベルは凡骨もいいところな自覚はある。まぁその大学は自分と似たよーなレベルの人間を毎年輩出してるわけです。 でまぁ、就職活動に真剣に取り組み始めにゃならん時期になんとなしに 2ch （つーかしたらばか）の出身大学の出身学科のスレ見たら驚いた。そこでの議論の趣旨は「コンピュータサイエンスを 4 年学んだ人間はソフトウェア業界以外の進路は何があるか？」だった。 「今更 IT ドカタやる以外ないだろ常考」「公務員ならなんとかなるかも？」「情報科目の教員免許はどうだろうか」「コンピュータに精通した事務員とか会計士とかアリじゃね」「起業とか？　俺たちのスキルじゃ余りにもリスク高すぎるか……」etc,etc ずっとスレを追っていたわけではないが、前向きにソフトウェア業界行きたい

最初はRailsでいこうかと思っていましたが、SAStrutsとS2JDBCを試してみてこちらの方が良いと判断したためS2で作成することに決めました。 Railsを辞めた理由、S2を採用した理由 ・自分自身Rubyに慣れていない。なので、リリースまでに時間がかかる ・自分自身Javaにはかなり慣れている ・Seasarもたくさん使ったことがあるので、DIやAOPに関する部分も問題ない ・検証していないがパフォーマンスはJavaの方が良いと多くの人が言っている 今までのJavaは設定ファイルは多いしWASの起動時間を修正毎に待たなくてはいけないなど開発効率が悪すぎました。SAStruts+S2JDBCはその部分は全て解決されていました。本当にいい感じです。 最初に言っておくと、Railsは良いフレームワークだし、Rubyは生産性の高い言語だと思います。ただし、Seasar2(Java)も生産

本稿は取材に基づいて客観的事実を伝える報道記事ではなく，谷島個人の考えを書くコラムです。 妙な書き出しになったが，その理由は後で述べる。ITpro Watcher欄の寄稿者，小飼弾氏が書いた『(6000)人が作ったシステムは必ずどこか壊れている』という文章が5月14日付で公開された。冒頭に「ここで語っておきたいのは，ITproの報道姿勢だ」とあったのでITpro関係者として読んでみると，中身は筆者および拙稿に対する批判と苦言であった。ITproではない場所に書いた記事にも言及されているので，ITproというより筆者の「報道姿勢」が問われていることになる。 インターネットの面白い所は双方向のやり取りが簡単にできることだと思う。ご意見を寄せてくれた小飼氏にまずお礼を申し上げる。ご指名を受けた以上，すぐにお答えしないといけないと思ったものの，なかなか書けず，今日までかかってしまった。言い訳になる

「三菱東京UFJ銀行は5月12日、情報システムの一本化をいよいよ始めたが、大きなトラブルは無く、年末まで続く一本化作業はまずまずの滑り出しとなった」 こういう書き出しと論旨の一文を書いて公開したら、読者の皆様の多くは「テレビや新聞は、12日から13日にかけてシステム障害が発生と大々的に報じていたではないか」と首をひねるに違いない。「まずまずの滑り出し」と筆者が書きたいのは、システム全体を見渡すときちんと動いており、一部で発生した不具合を当日すぐに修復できたからだ。 筆者は4月23日付本欄で「失敗を期待するマスメディアを裏切って、三菱東京UFJ銀は一本化プロジェクトを成功させると確信している」（関連記事「失敗を待つマスメディアの監視下、システム一本化を始める三菱東京UFJ銀行」）と書いた。続く4月24日には、IT（情報技術）専門家向けウェブサイト「ITpro」のコラム欄に「この巨大システムは