なぜDIコンテナを使うのか
本記事は2005年に執筆されたものです。Spring、DI、AOP全般の最新情報は＠IT Java Solutuionのカテゴリ「DI×AOP（Spring／Seasarなど）」をご参照ください。 私がDIコンテナを使う理由 前回までで、Spring Framework（以下Spring）やDIの概念について説明してきました。最近では、実際の開発現場でもSpringのようなDIコンテナを利用するケースが増えてきているようです。 現場のエンジニアはDIの“機能”や“役割”は理解できるようです。しかしながら、「なぜそれが必要なのかピンと来ない」「学習してまで導入するほどの効果があるのか疑わしい」という声をよく耳にします。そのほかにも、自分自身はメリットを十分に理解して開発プロジェクトに導入したい気持ちがあるけれど、導入するためには上司や関係者を説得しなくてはならず、どのように説得すればよいか分
ウノウラボ Unoh Labs: Web Application Testing cheatsheet
こんにちは！ やまもと＠テスト番長です。 先日マサトさんに教えてもらったのですが、 こんなウェブアプリケーション用のチェックシートがあるそうです。 SECGURU: Web Application Testing cheatsheet なかなか面白いので、軽く日本語にしてみました。（Special thanks to: ジュンヤさん） ※間違ってたらごめんなさい。 1. アプリケーション名とバージョン 2. コンポーネント名 3. 通信プロトコル SSLならばバージョンと暗号方式 4. パラメーターのチェックリスト URLリクエスト URLエンコーディング クエリストリング ヘッダー クッキー フォーム フォーム（Hidden） クライアントサイドのヴァリデーションチェック 使用していない余計なパラメータの存在 文字列長の最大/最小値 連結したコマンド（Concatenate
コアテクの路地: エンジニアの働き甲斐を支えるもの
弊社は、外から見ると外資系と勘違いされている人もいるが、実はわりと普通の(?)日本の会社だ。ただし、ベンチャー企業には間違いない。私がこの会社に移ったときに「ミラクル(の仕事の仕方や雰囲気)は日(本)系ですか外資系ですか」と質問したのに対し、面談した武田氏の「私はベンチャー企業だと思ってこの会社に来た」という回答は今でも覚えている。 実際、ほとんどの社員は転職組であり、前職に様々なマイナス要因があったにせよ、あえてこの会社を選んだ理由に、ベンチャー特有の働き甲斐を含めていないわけがないだろう。 とはいえ、ベンチャーであれば常に働き甲斐があるわけではない。 私の失敗経験によると、働き甲斐があっても下記の場合にはうまくいかないようである。はじめに断っておくが、弊社においては下記のような事態には遭遇していないので、安心(?)して欲しい。 ・人に魅かれるエンジニアがカリスマの無い人に出会ってしまっ
プログラマとして - codemaniaxの脱・公務員宣言
■プログラマとして 13:08 わたしが知らないスゴ本は、きっとあなたが読んでいる: プログラマになれなかったわたし http://dain.cocolog-nifty.com/myblog/2006/03/post_8367.html 僕はコードを書いてきた。 僕はコードを書いていきたい。 だけど、だからこそ書くべきではないコードがあると思っている。 昔からいろいろなコードを書いてきた。BASIC、Perl、C、C++、VB、JavaScript、Java、SQL、PHP、Ruby、、、 正直言って、プログラミング言語なんて数日勉強すればどうにかなるのだ。というか、エンジニアたるものはそうでなければならない。構造化プログラミング、ポインタや参照、オブジェクト指向、カプセル化、ポリモーフィズム、継承、イベントドリブン、、、このあたりをきちんと理解していれば、新しい言語を使いこなすことは別に
知的労働者には「組織を移る力」がある
前回のエントリーに、Doraさんという方から「次回エントリー『こうすれば日本のSEは救われる！』を楽しみにしております！？」とのコメントをいただき、少し悩んでしまった。日本のSIer（少し前までは「SI屋」だと思っていた）の階層構造の問題を指摘しておきながら、何も提案しないのはあまりにも無責任かも知れない。 だからと言って、「日本のIT産業はこうあるべきだ」などと部外者である私が本当の意味で影響力のある発言をするのはあまりにも難しい。特に、IT業界に限らず、一旦こういった階層構造が出来てしまうと、業界で力を持つ上位レイヤーの会社や人たちにとって、改革は自己否定にもつながりかねないので良いと分かってはいても自分からわざわざ着手できない、というジレンマがあるのが一層解決を困難にしている。 では、現時点でIT業界で苦しむSEやプログラマーの人たちは何をしたら良いのだろうか。 とても難しい問題では
iandeth. - Perl/CGI辞典 - 土井 毅さん 著 - にて use strict が推奨されていない件について
iandeth. Perl, Flash ActionScript, MySQL, Movable Type, システム開発 - そんなテーマのサイトdeth. p.32 [参考] 他のプログラミング言語では、変数宣言は宣言に含まれることが多いですが、Perlには変数宣言という概念がありません。Perlは変数が最初に評価された時点で領域を確保します。Perlと他のプログラミング言語で大きく異なるのがこの変数宣言機能の有無であり、見通しの悪い複雑なスクリプトを書いてしまう主因でもあります。 最初のイントロダクションの章でそんな風に書かれています。これを読んだプログラミング初心者の人達はきっと「えぇ？そうなの？Perl使いにくそうだなあ」と思ってしまいますよね、きっと。そしてさらには・・・ p.104 strict プラグマは、Perlスクリプトでの記法を厳密にするためのプラグマです。 (中略
ブルックスの法則 バックナンバー（ソフトウェア業界 新航海術 蒲生嘉達 発行）
第120号 2006年3月27日 ●「ブルックスの法則」とは／遅れが生じた場合の有効な対策は？／ 再スケジュールも規模縮小もできない／頭数は一つよりは多いほうが絶対にいい(？) 第121号 2006年4月3日 ●30年前の洞察が今でもそのまま通用する／仕事の４分類／ 人数と時間との関係は仕事によって異なる／人数と時間の関係図についての注釈／順次的であり、且つ、相互関連を持つ／ ブルックスの法則への反対意見 第122号 2006年4月10日 ●当初のスケジュール／マイルストーンＡで1ヶ月遅れが発生／ 第1回の要員追加／2名追加したが、遅れは全く変わらなかった／もとの見積もりになかった仕事が増えたから／ そしてデスマーチへと突入する／ケース２だともっと恐ろしいことが起こる 第123号 2006年4月17日 ●人月による見積もりの是非／人月による見積もりは日本独特の商習慣ではない／ 要員の最大数
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
プログラマの種類とキャリア - naoyaのはてなダイアリー
http://d.hatena.ne.jp/mkusunok/20060426/hr を読んでいろいろ考えた。 最近はてなブックマークとか見てて、優秀な人は自分がすごいことをやってるとか、努力してることに気づかないみたいな話がありましたね。例えば僕なんかはゲームがすごい好きで、ある程度つまらないゲームでも結構ずーっとやってられるみたいな感じがありますが。んなゲームするのが好きでどうすんだよ! ってそういう話じゃなくて。この感覚をときどき、プログラミングをしてたりコンピュータを触ってるとき、新しい技術について調べてるときに感じることがあるよという話。 その一方で、読みづらくて分かりづらい本を読んだり、ひたすらバグを叩いてるときとか、同じプログラミングに関することでも気分が滅入るときはたくさんある。プログラマという職業を続けられるのは、プログラミングが好きだからと思う一方で、好きだからといって
人材不足?の背景 - 雑種路線でいこう
最近「優秀なエンジニアってどこにいるんですかねぇ」とよく聞かれる．本当に優秀なエンジニアは起業したり，大学に残って研究を続けたり，グーグルに就職したりするんだろうけれども，だいたい探してるのは「Ajaxなひと」とか「Web進化論に出てきそうなGeekたち」とか，ヲイヲイ優秀なエンジニアの基準がそれかよとゲンナリしてしまうのであるが，まぁそんなものかも知れない． いわれてみると前の会社を辞める前に登録したエージェントがずっと静かだったのか，ここ半年くらい急に年収1000〜2000万とか妙に景気のいいメールが飛んでくるようになったり，会社に身に覚えのない外人から電話がかかってきて訝しがっていたらヘッドハンティングだったりとか，そういうのが増えた． 僕は基本的に人買いは信用しないし使わないけれども，誘われたら必ず会うようにしている．だいたい印刷屋の親父とかタクシーの運転手とか飲み屋のオーナーは肌
20060401-PerlishHotlinks - Perlish Magazine
Perlish Hotlinks 〜結城浩さん〜 はじめに 著名な Perlish にインタビューを行う企画「Perlish Hotlinks」。今回は、Perl はもちろんのこと、たくさんのプログラミング関係の著作で有名な結城浩さんにお話を伺いました。 今回は Hotlinks インタビュー初の IRC 上でのインタビューです。顔文字も含めてお楽しみください。 プロフィール コンピュータ関連の多数の著作で知られる。また、YukiWiki の作者としても有名。 1963 年生まれ。現在は関東在住。家族は奥さまと二人の男の子。 好きな言葉 「ものみなすべてに時がある」その他。詳細は記事中を参考のこと。 尊敬する人 Donald Ervin Knuth 著書 多数あるため、詳細はウェブページを参照のこと (http://www.hyuki.com/pub/books.html) ご本人のサイト
Passion For The Future: ジョエル・オン・ソフトウェア
ジョエル・オン・ソフトウェア スポンサード リンク ・ジョエル・オン・ソフトウェア―ソフトウェア開発者、設計者、マネージャ、それに幸か不幸か何らかの形で彼らと働く羽目になった人々が関心を抱くであろう、ソフトウェア、並びに往々にしてソフトウェアに関連する諸所の問題について マイクロソフトのExcelなど何百万人が使うアプリケーションの設計と開発に取り組んできた著者が、自分のブログで公開しているソフトウェア開発論。理想的な開発マネジメントがいかにあるべきか、自身の経験から得た奥義を語る素晴らしい内容。 ・Joel on Software 日本語版 http://japanese.joelonsoftware.com/ 目次： 01 Bits and Bytes:プログラミングのプラクティス(言語の選択、基本に帰れ ほか) 02 開発者のマネジメント(採用面接ゲリラガイド、報奨金有害論 ほか)
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
japan.linux.com | 技術者の採用面接法
技術職を募集する際の面接法を扱った解説は数多くあるが、この種の面接で最も肝心な点は、おそらくは、応募者が持つ技術の評価だろう。ここでは、より確実に評価するための一法を紹介する。 応募者の技術を評価する際、筆者らが勧めているのは、応募者に初見の問題を課して自己学習能力を見る方法である。類似のものを含めて扱ったことのない問題であればなおよい。必要な資料とコンピュータを提供し、応募者が問題にどう取り組むかを見る。着実に解に近づいていたら、採用への評価はプラスである。 自己学習能力 自己学習能力の重要性は、GNU/Linuxコミュニティではよく知られている。Eric Raymondは、「How to Become a Hacker」の中で、自己学習能力はハッカーの基本的資質だと述べている。「問題こそ我が師」がハッカー流。問題への対処の仕方を教えてくれる師はいない。我々の生業では、その性質上、高度
Bridge Word
This shop will be powered by Are you the store owner? Log in here
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：創造的なエンジニアのための働く環境とは（２）
創造的なエンジニアのための働く環境とは（２） 公開日時： 2006/02/11 10:43 著者： kenn （前回の続き） 前回のエントリには、金子さんが『１人のプロジェクトと、チーム開発をつなぐ「鳥の目」』というポストでトラックバックをくれたけど、そこに書かれていたことが僕的にはすごくヒットだったのでちょっと寄り道したくなった。 今回は「作家と編集者」というアナロジーでいくつもりだったのだけど、ようするに作家（エンジニア）にも色んなタイプがいるってこと。 こないだCNET編集長の西田さんとも話していて、エンジニアのタイプでも最もはっきり分かれていると思ったのは、この２類型。 （１）クリエイター・ギーク系 小規模なベンチャーで新しいサービスを作りたいタイプの人 会社の中で認められたいのではなく、会社の外で認められたい 週末も趣味でコーディングしている お金、ステータスにこだわら
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：創造的なエンジニアのための働く環境とは（１）
創造的なエンジニアのための働く環境とは（１） 公開日時： 2006/01/23 18:29 著者： kenn 最近、自分のワークスタイルを大きく変えてみて、非常に強く感じることがある。 エンジニア、それも言われたことをソツなくこなすタイプではなくて、アンテナの感度が高く、自発的に新技術を磨き続けることを怠らず、自分の作ったものを広く世に出すことが楽しいと考えるエンジニアが、商業的に実りのあるモノを作り出せるようになるためには、ある特殊な条件が、きわどいぐらいのバランスで揃うことが重要なのだな、ということがわかってきた。もちろん、まだそれを理解するプロセスの真っ最中なのだけれど、考えがひとまとまりの輪郭をとってきたので、つれづれ書いてみようと思う。 ぼくは、インフォテリアというソフトウェアの会社で６年も製品企画その他、会社がリリースする「モノ」の運命にかかわる重大な意志決定に、経営
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日経SYSTEMS：お役立ちWebサイト101