2008-02-15 - ひがやすを blog - アーキテクト以外は「限定されたことだけやっとけ」
> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、 > フレームワーク全体を把握していて、残りのメンバーは >「限定されたことだけやっとけ」みたいなことは好きではありません。 大規模だと好き嫌いに関わらずこういったアプローチになるのでは？ アーキテクト以外の学習コストはむしろ減ると思いますが… きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。 一番の理由は、開発者のモチベーション。「限定されたことだけやっとけ」という状況で、開発者のモチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。 二番目の理由は、開発者が成長しないこと。開発者というのは、いろんなプロジェクトに参加し、いろんな経験をつみながら成長して
インターフェースの押しつけはフレームワーク設計者のエゴだ - y-komori’s diary
ブログさぼってますが、元気です。 S2Swing の kaiseh さんのところでの議論がけっこう面白いので、こちらでも少し書きます。 簡単におさらいすると、フレームワークを作るとき、フレームワークからユーザのつくったオブジェクトを呼び出す場合、3つの方法があります。 インターフェース(もしくは抽象クラス)を提供して、ユーザ側で実装してもらい、FWそのインターフェースを叩く。(もっともオーソドックス) 規約に沿ったメソッド名をユーザ側で実装してもらい、FWはリフレクションで規約を調べてメソッドを叩く。(Teedaとかで採用しているパターン) メソッドにアノテーションをつけておき、FWはアノテートされたメソッドを呼び出す。(Urumaとかで採用しているパターン) 最近流行ってる(のか?)、「規約ベース」の考え方が2ですね。 いろいろ考えましたが、わたしのイチオシはやはりアノテーションです。
ソフトウェアの欠陥はなぜ無くならないのか : らばQ
ソフトウェアの欠陥はなぜ無くならないのか 先日、公衆電話がうるう年を処理できなくてサービス停止というニュースが流れました。 自己診断プログラムに欠陥があり、次の診断日時を設定する際、うるう年を考慮できなかったことがきっかけで、障害が発生したのだそうです。 こういったソフトウェア──機械的・物理的なもの(ハードウェア)以外の部分──の欠陥は、日増しに増えています。 2005年には証券取引所で単純なプログラムミスで半日取引停止になっていますし、同年にウィルス対策ソフトウェアが障害を起こしてパソコンがまともに動かなくなるなどの症状を出しました。 普通に使われてるパソコンに入ってるOSと呼ばれるソフトウェアも、毎月のように欠陥を見つけては修正を配布しています。 さて、こういった問題はなぜ起こるのでしょうか? ちょうど先日、NHKのクローズアップ現代でソフトウエア危機〜誤作動相次ぐハイテク製品〜とい
ブラウザから手軽に使えるJavaScriptの統合開発環境『TIDE』 | 100SHIKI.COM
これはすごい・・・。 TIDEは「Tiny IDE（統合開発環境）」の略らしい。 そのシンプルな名前にたがわず、実に手軽にJavaScriptを書いて、テストすることができる。日本語もきちんと通るようだ。 しかもIDEだけあって、変数の中身をウォッチしたり、ステップごとに実行していくことが可能だ。 JavaScriptは慣れていないとどうにもとっつきにくかったりするが、こうした環境があればその動作を確認しながら学習していくことができるだろう。 まだベータ版ということで多少のバグがあるようだが、これからJavaScriptをやってみよう！と思われている方にはお勧めだ。
404 Blog Not Found:惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら
2007年10月26日01:45 カテゴリ翻訳/紹介Art 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら 全プログラマーが泣いた。 If architects had to work like programmers... 実は一つだけ「ローカライズ」にあたって変えた前提があります。日本ではこちらの方が実情に沿っているでしょう:) 建築士様、 家を一つ設計施行してくださいな。まだ何が必要か具体的なことはわからないので、そこはよきに計らう方向で。 寝室の数は、2から45までの間。寝室の追加と削除は簡単に出来るようにしといて下さいね。青写真が出来次第あたしが何が気に入ったかを最終判断します。それぞれの青写真について明細書を付けるのをお忘れなく。後で気に入ったのをピックアップできるように。 完成後の家の費用は、今住んでいる家よりも安上がりでないと駄目なことを留意してくださいな。そ
XMLが嫌われている？：ITpro
「XMLが“やっかいもの”になっている」──最近，そう感じることが何度かあった。インターネットの普及を促進した立役者の一つであるXMLが，今やある領域では問題児になっているのだ。 すでにご存じの通り，データ構造を自由に定義できるXML（eXtensible Markup Language）の登場は，インターネットの利用形態に大きな変革をもたらした。人間が閲覧するだけでなく，プログラム間でのデータ処理が可能になったからだ。現在では，SOAP，SaaS，Ajaxなどを使ったWebアプリケーションは言うに及ばず，デスクトップで利用するOfficeアプリケーションなどもデータ形式としてXMLを利用している。 しかし，プログラムを作る開発者にとっては，あまりにも多いXMLの活用がやっかいごとになっているという。2007年9月に開催された開発者向けイベント「X-over Development Con
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
[ThinkIT] 第5回：複数人での開発におけるテストの勘所 (1/3)
これまで解説してきたように、ウノウでは各々の開発者の開発環境で慎重に組み上げられたソースコードをSubversionで管理された統一の開発環境にそれぞれコミットし、リリースに向けて足並みを揃えながらシステムテストを実施します。 ウノウではテスト専門の担当者が在籍しており、開発者とは違った視点から成果物のチェックを行う体制を整えています。今回はその実践事例を紹介しながら、複数人での開発におけるテストの勘所について解説していきます。 テスト工程はプロダクトの品質を確保するために欠かせないフローの1つです。組み上げられたばかりのソースコードは、まだ完成度が客観的に保証されていない状態であり、開発者のスキルに対する信頼によってのみ「完成した」と推測されるものでしかありません。極端にいえば、いざ蓋を開けてみたら動かなかったということもあり得るのです。 自社プロダクトの開発がほとんどであれば、問題が発
キミのコードが汚い理由 ― ＠IT情報マネジメント
リスト1は、同じ処理を繰り返すようなコードで初心者プログラマーがよく使う幼稚なスタイルで書かれている。必ずしも複雑ではないが、筆者には散らかっていて効率が悪く見える。リスト2の方が複雑な条件になっているが、Javaを理解していれば、かなり読みやすい。唯一疑問を抱くかもしれないとしたら、最後の「else if」の中にある条件の最初の部分だけだ。このクローズに来るということは、どちらかのプレーヤーが勝ったことを意味する。 いずれのインプリメンテーションも間違ってはいない。実際、これらはどちらも非常に小さく、つまらない例にすぎないので、これらのリストでコードがいかにクリーンか論ずるのはあまり有益ではない。ただ、何をもってインプリメンテーションがクリーンなのかについて読者の興味を深めることはできるだろう。 クリーンなコードについて扱った記事、Webサイト、書籍は多数存在する。何をもってコードをクリ
ソフトウェアの責任の所在: 国民宿舎はらぺこ 大浴場
ものつくりの自由度 (ふとももおれたー さま) ソフトウェア開発者も、製造物責任法 (PL 法) などのような枠組みで責任の所在を明確にすべきだ、という話。なるほど、大筋では大体その通りだと思う。でも、フリーソフトウェア開発者は「賠償責任」と聞けばみんな心臓をバクバク言わせるだろうな。 まず、ひとえにソフトウェア開発とその提供、といっても、形態は様々であることを無視してはいけない。今書いたように、プロプライエタリ (フリーではない) なのかフリーなのか、有料なのか無償なのか (無償であればすべてフリーというわけではありません、念のため)、パッケージ製品として店頭に売り出しているのか受託開発なのか、スタンドアロンなのか Web アプリなのか、プリインストールや組み込みソフトウェアではどうか、などなど、ソフトウェアは実に様々な形態で提供され、あるいは開発されています。 主に受託開発の仕事に携わ
PLATFORM WATCH - ソフトウェア開発は何に似ているか?
プログラミング雑誌の編集をしていると，ソフトウエア開発やプログラミングは，何に似ているだろうか，と思うことがある。 昔から様々な比ゆ（メタファ）が用いられてきている。Webで検索できるものを挙げてみても，料理，音楽（作曲），小説の執筆，面白いところでは，精神分析，臨床心理学…などの意見が見つかる。興味のある方はぜひググってみるといいだろう。 様々なメタファがあるなかで，最も広く知れ渡っているものを挙げるとすれば「建築」だろう。ソフトウエア開発を「建築物を作ること」ととらえ，開発プロセスを大きく上流（設計）工程と下流（建設）工程に分けるという考えは，単なるメタファにとどまらず，ソフトウエア開発の様々な面に大きく影響を与えている。 例えば，○○アーキテクチャとかITアーキテクトといった用語が出てくるのは，建築をメタファとした影響だろう。ソフトウエアの設計ノウハウの集まりであるデザインパタ
あるあるｗｗｗｗ: 国民宿舎はらぺこ 大浴場
おいらはテストと不具合管理の仕事が多かったので、どちらかと言うとプログラマにバグを指摘する立場である事の方が多かったのですが、いろんな機能を同時に並行して使えるタイプの GUI なアプリのクセに、機能追加の要求内容がやたらと手続き的 (っていうのかなぁ) で、しかもそのシナリオ一本だけを想定して (つまり他の想定できる道筋を吟味して潜在要求を洗い出すということが不十分なうちに) 開発を進めようとするものだから、外部仕様レベルで「これをこういう風に動かした場合の動作なんて想定してないんだろうなぁ」ということが結構分かっちゃったりして、しかもそうやって当たりつけて動かしてみせて本当にバグがぼろぼろ出てきちゃうものだから、リリース直前のギリギリの時期とかになると、「むらちさんはテストしなくていいです、むらちさんがテストしちゃうとバグがいっぱい出てきちゃうから」とか言われることもしばしば。。。(^
未処理の例外への適切な対処法2：例外の詳細を開発者に通知する：CodeZine
前回は、実行時にユーザーの手で単一行表示から、複数行表示にレイアウトを変更する形で、エンドユーザーを巻き込んだ検索画面のモックアップを作成する手順を紹介しましたが、今回はそれに続き受注画面のモックアップを作成します。受注画面は、新規データの入力と既存データの表示が行えるものとし、今回もまた、実行時にユーザーの手でレイアウトを変更していただきます。
ソフトウエア開発者の危うい「更地主義」
ソフトウエア開発者は一般的に，次のような2つの認識を持っているものだ。「もしアプリケーションを最初から書き直せば，アプリケーションの既存問題のほとんどを解決できる。現状のコードを更新して問題を解決するよりも，一から書き直す方が労力は少なくてすむ」「Microsoft製品『XXX』の次期バージョンは，少なくとも最初のサービス・パックでバグが解消されるまでは，不安定に違いない」－－－こういった認識は，本当だろうか？ 1つ目の認識はよく「更地（Green Field）主義」と呼ばれる。アプリケーションを最初から作り直すのは，既存の建物を改装するのではなく，更地に建物を建設するようなものだからだ。更地主義の意見を最近，COMコードを.NETコードに書き直すことに関して，聞くことがあった。 例えば先日，筆者が「いよいよCOMに取って代わる.NET」という記事で，COMコードを.NETコードに移行する
[development]設計, [internet]光, [trac][Excel] tracのカスタムクエリの結果を見た目そのままで Excel で整形して出力できるようになればいわゆる管理者層も使ってくれると思うのだが, [cov.. - HsbtDiary(2006-10-30)
■ [development]設計 きちんと設計すれば誰がコーディングしてもきちんとしたソフトウェアが作れるという与太話は誰が最初に言い出したのか気になる今日この頃。あとこれをかたくなに信じている人を量産しているのも何なんだろうね。 ■ [internet]光 帰宅したら住んでいるアパートが光の集合住宅タイプに対応決定とのチラシが入ってた。ずいぶん前に申し込んでからやっとかあ。とりあえず申し込み用紙を記入したので明日投函。 さてと、今はADSLモデム内蔵型のルータを使ってるんで、ルータを新しく用意しないとだ。 ■ [trac][Excel] tracのカスタムクエリの結果を見た目そのままで Excel で整形して出力できるようになればいわゆる管理者層も使ってくれると思うのだが 誰か作って。今だと CSV だけというのと、UTF-8エンコードというのがちょっとした鬼門になってる。 ■ [co
![[development]設計, [internet]光, [trac][Excel] tracのカスタムクエリの結果を見た目そのままで Excel で整形して出力できるようになればいわゆる管理者層も使ってくれると思うのだが, [cov.. - HsbtDiary(2006-10-30)](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cab6183abe73ade0ce0a24c302ac36ee5c17b43/height=288;version=1;width=512/https%3A%2F%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
ウノウラボ Unoh Labs: 「２流のテスター」は要らない！(2)
こんにちは！ やまもと＠テスト番長です。 その1を書いてから間が空いてしまいました。 No More Second Class Testers! という面白いコラムを、引き続きご紹介しましょう。 なぜ１流のテスターでなければいけないか テスターは商品開発における重要な役割を果たします。 テスターは開発中の製品の情報とテストに関する情報を提供します。 テスターには少なくとも3種類の相手（客）がいます。 ・開発者には、分かりにくい箇所、テスタビリティ、そして動作しない箇所について報告します。 ・ユーザーには、サポート係を通して製品の情報を提供します。 ・開発マネージャーには、リリースのリスクについて情報を提供します。 １流のテスターは、コードが書かれている前にシステムのデザインとアーキテクチャを評価することができるくらいクリエイティブです。 コーディングが進む間、テストの準備を整えます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
いまさら聞けない 形式手法入門（1/3） ― ＠IT
安全なWebアプリ開発の鉄則 2004
IPA ISEC セキュア・プログラミング講座