自分の見方とお客さんの見方は違う、もしくは違ってもいい - monjudoh’s diary
http://d.hatena.ne.jp/aureliano/20100114/1263451331 好きを貫いているかというと微妙だけど楽しく仕事してる私が通りますよ、と。 別に自分を捨てなくてもお客さんに喜んでもらえる場合も多々あると思うのだ。 仕事をする人が自分の見方で楽しい・嬉しいと思えるやり方で仕事をしたとして、 その結果が顧客の見方で好ましいものであれば双方ともにハッピーだが、 この時顧客は仕事をする人がなぜハッピーであるかを仮に全く分からなかったとしてもハッピーである。 レガシーコードの改修で高品質を実現したことで顧客が喜んでいるとする。 開発者にとって、そのコード自体は全くエキサイティングでない事も、 俺々バージョン管理を通じて分散SCMでのtopic branchの運用ノウハウを蓄積出来てうれしい事も、 インチキこっそりTDDを通じて乏しかったTDDノウハウが少々身に付
無秩序なバージョン番号 | OSDN Magazine
フリーソフトウェア・アプリケーションやディストリビューションをいくつか試用してみて気づくのは、バージョン番号にほとんど意味がないことだ。昨今のバージョン番号を見ても、そのアプリケーションがどの開発段階にあるのか見えてこない。わかるのは、せいぜい、ビルドの前後関係ぐらいで、バージョン番号はビルドを区別するための単なるラベルに成り下がっている。バージョン番号が適切であれば、そのビルドの進捗状態がわかるはずなのに、これは何ともひどい状況だ。 しかし、複数の番号体系が使われていることが問題なのではない。種々の方式があることさえ知っていれば、GNOMEの奇数番号リリースが開発ビルドであり偶数が公式リリースであることを調べるのは造作ないことだからだ。また、KOffice 1.9.95-4をKOffice 1.0の後続バージョンかと一瞬誤解することはあっても、すぐにバージョン2.0の初期ビルドであること
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
連載：アプリケーション・アーキテクチャ・ガイド2.0解説 第5回 典型的なアプリケーションのパターン（前編） − ＠IT
●キャッシュ化 データや出力をキャッシュしておくことで、データの検索を高速にしたり、ネットワーク越しの通信のオーバーヘッドをなくしたりして、不必要な処理を排除することができる。ただし、不適切なキャッシュは逆にパフォーマンスに悪影響を与えるため注意が必要である。 注意点： よく変更されるデータはキャッシュしない。 データをキャッシュするときは、すぐ利用できる形式でキャッシュしておく。 比較的静的なページでは、出力そのものをキャッシュする。 ネットワーク接続などの共有リソースはキャッシュではなくプールする。すなわち、使い終わったら速やかに返却して再利用する。 もし更新データをWebサーバでキャッシュするのであれば、Webサーバがステートレスにならない。そのため、Webファーム構成をとる場合には同じクライアントからの要求を単一サーバに振り分ける（サーバ・アフィニティ）必要が出てくる。 関連するパ
テストを軽視する者どもに告ぐ:アルファルファモザイク
■編集元：プログラマー板より「テストを軽視する者ども」 1 仕様書無しさん :2008/06/28(土) 19:49:20 何だよ、８割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」 って... コーディングが終わってやっと３割終わったかどうかってところだろが。 コーディングが終わってからが本番だっちゅーの。テスト仕様書に従い、テストデータ用意して、 正常系、異常系含めて、抜かりなく全網羅テストすること。これがどれだけ大変なことか。 本当に理解してんのか？ コーディングが終わってやっとスタートラインに立ったぐらいの気持ち でいろよ、ってくヘラヘラしやがって。 こういう、テストを軽視する輩共が、プログラミングという作業を軽んじ、工数見積りを誤り、 徒に製造を急かし、バグの混入率を間接的に高めているということに気づかんのか。 どんな優秀な奴だっ
TDD、TDDと言うけれども。TDDのダークサイドについてそろそろ一言語ってみる。 - Fly me to the Luna
id:t-wadaさんの話の中で、TDDが品質を保証するわけではない、という話があったんですが、それについて私見をつらつらと。ちなみに自分は2年くらい仕事でTDDをやってきました。 やってきた中で下記のTDDの利点を感じることができました。 その時に気づいた最もシンプルなコード、クリーンなコードができる テストコードからコードを書く、と言うのはプロダクトコードの利用方法が考えられるのでとても有効に作用します。id:t-wadaさんもリファクタリングが一番重要と話されていましたが、テストコードがあれば安心してリファクタリングができます。 より高い品質のコードが書けるようになる これはt-wadaさんの話の中でもありましたね。なぜかと言うと、プロダクトコードが実行される時の前提条件を知ろうとすると、結構いろいろなコードに目を通すことになります。コードに目を通すことで優れた先人の知恵を見つけるこ
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
下限に合わせたプログラム設計はシステム開発を停滞させる - @katzchang.contexts
FxUG@北陸の懇親会で出た話題。 中規模以上のプロジェクトになれば、悲しいかな、テンプレにそったプログラムしか書けない人や、そもそもプログラムを書いたことすらない人が結構いたりします。10人もかき集めれば2〜3人、いや半分はそういう人だったり。リーダーさんは仕様検討とかで忙しいから、そういう初級者さんにプログラムの作成を頼らざるを得ないってのが現実です。 で、初心者さんにもわかりやすい設計のプログラムを量産していきましょう、となる現場はよくあります。なに、うちのところもそんなもんですよ。 でもそれで良いの？と、個人的には疑問を持っています。 初心者でも書けるように、テンプレートをコピーして使う。 コピペ駆動開発の副作用は周知の通り。 テンプレートが役立つのは限定的な場合。仕様が想定の範囲を超えればテンプレートを捨てなきゃならないけど、その判断を誰が下す？ 後々の保守しやすいよう、初心者で
設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージＩＤのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版２」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく３つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
エンジニアとして生き残るための、たった１つの真実 - Fight the Future
エンジニアとして生き残るための、たった１つの真実。 「生き残る」という言葉には2つの意味を持たせている。 老害エンジニアにならずに生き残る プロジェクトにつぶされることなく生き残る ではどうすれば生き残れるのか？ 大きなヒントがInfoQの記事にあった。 原則4:自分の仕事の仕方を常に疑う InfoQ: トップスポーツチームの監督に教わる秘訣 老害エンジニアにならないために 先日テレビを見ていたら、水素自動車の特集をやっていた。 ホンダの社長がこんな感じのことを言っていた。 「技術はほしいと思ってもすぐにできるものじゃない。だから今のうちから研究する。」 クラサバからWebへシステム開発の主軸が移ったとき、多くのエンジニアが追いつけなかった。 それはほしいと思っても技術がすぐに身につかなかったからだ。 昔COBOLができれば一生食うに困らないと言われていたそうだ。 だが、現実は違った。 自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
