悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 最近、古いクライアント・サーバー（C/S）型のシステムを、Web システムとして作り変えるという仕事が多い。現在の機能をそのままに、Web ブラウザから使えるようにしてくれ、という依頼である。 こういった場合に注意すべきは、新しいシステムの設計が既存のシステムの設計に「引きずられてしまう」ことである。この問題は、特にユーザー・インターフェースについて顕著だ。既存のシステムを使い慣れたユーザーからは、「今と同じ使い勝手にしてくれ」という注文がなされる。また、設計者の中にも、既存のシステムとなるべく同じ設計しようとする人がいる。そのほうが全く新しい「画面」を設計するよりも、楽だか
Joel Spolsky / 青木靖 訳 2006年4月11日 火曜 若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。 過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。 彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。 １年もたつと、彼の慎ましい生計を1年支えられるくらいの蓄えができた。それで贔屓にしてくれるアルザス人へのコンサルティング仕事の後、食料品店の上にある自分のアパートの陽の当たる部屋にコンピュータを据え付け、選りすぐったツ
富士通の黒川社長が東京証券取引所の一連のトラブルに関して、「契約内容を超えた負担には応じられない」と言い切ったそうである。当然の発言であり、もっと早く言ってもよかった。東証のシステムトラブルについては、発生当時、私もいろいろと意見を述べた。いま改めて考えてみるに、あの一連のトラブルはITベンダーとユーザー企業との“取引の近代化”に大きく貢献したといえるかもしれない。 東証の当時の社長やCIOが責任を取って退任し、新体制が発足して久しい今、東証の対応を今さらあげつらうつもりはない。ただ、11月のシステムダウンの際、事故当日の記者会見で東証の出席者の「損害賠償も辞さない」と発言したのを聞いた時、心が冷える思いがしたのを思い出す。その日は、ある大手ITサービス会社の人と話したが、彼の感想も「あれじゃ、富士通さんもたまらないだろうな」だった。 原因が分からない段階で損害賠償を口にするのは、無茶苦茶
id:goldenport:20060508:1147055688にも書いたのだけれど、最近ドメイン・モデルに興味を持っている。 DOAからインスパイアされたこともあり、ドメイン分析段階のドメイン・モデルの具体度と設計段階のドメイン・モデルとの関係について考察を進めているのだけれど、そのような観点で『Domain-Driven Design: Tackling Complexity in the Heart of Software』をチェックしている。 ドメイン分析の段階では、ユースケース用のラフな概念モデルを作るのが汎用的な手法ではあると思うのだけれど、DOAのように最初の段階で詳細な論理モデルを作るアプローチも、企業システムというスコープで考えれば、なかなか魅力的な選択であると思うようになった。もちろんこれは、かなりの部分がパターン化できるという見込みによるものである。 Domain-
データ、UI、業務手順の「3要素」をとらえる：分析設計技法「三要素分析法」集中講座（2）（1/3 ページ） 「三要素分析法」は技術者とユーザーとの意思疎通と開発現場での実用性を重視した業務システム向けの分析・設計手法だ。今回は3要素の関係とそれぞれの図式を見ていく。 前回「ユーザーと共通理解できる“システム観”が必要だ」では、「三要素分析法」が業務システム向けに最適化された分析・設計の枠組みであることを説明しました。そこでは、システム要件を分析・設計した結果は「データモデル」「機能モデル」「業務モデル」の「業務システムの3要素」として図式化されること。また、システム開発においてはそれらの論理要件のほかに、利用される実装技術や組織上の特性といった「物理要件」の影響を無視できないこと。結果的に、3要素が「データベース」「プログラム」「ユーザー」としてプロジェクト固有の形を取りながら実装されるこ
Webアプリケーションのユーザーインターフェイス[3] UCD＝利用者中心設計のプロセスとは？ ソシオメディア 上野 学 2005/8/9 「ユーザーにとっては “ユーザーインターフェイス”こそが製品そのもの」「ユーザーが選びやすいフォームのカタチを考えよう」に続き、連載第3回は、ユーザーインターフェイスデザインの上流工程に着目して、利用効率が高くユーザーが目的を十分に達成できるシステムを作り上げるのに必要な、プロジェクト初期の取り組みについて考えていきます。 まず前提として、システムを利用するユーザーは何らかの目的を持っている、ということを意識することが大切です。ユーザーインターフェイスを評価するうえでは、この目的がどれぐらいスムーズに達成されたかという視点が重要になります。個々の画面がどれだけ論理的にデザインされていたとしても、そのシステムを利用した結果としてユーザーが本来の目的を達成
巻頭言 商用コンピュータが世に出てきてから、早50年以上が経過しています。 当初は、科学技術計算分野での電子「計算」機として生まれたコンピュータも、今では事務処理、意思決定支援、通信関連、娯楽等、さまざまな分野で利用されるようになり、真の情報処理機械と言えるまでに成長してきました。 また、ハードウェア性能は爆発的に、ソフトウェア開発手法もそれなりに進歩を続けています。 しかし、こういった進歩により劇的な周辺環境の変化が引き起こされ、ある時代にソフトウェア開発の真実であったことが、現在では間違いとなるような逆転現象も起こってきているのです。 例を挙げると、メモリが高価な頃は、1バイトでもメモリを節約するようなコーディングが優れているとされ、分かりやすさは二の次にされていました。 しかし、今や組み込み系以外では、こういったコーディングは「可読性を下げる悪習」と考えられていま
第14回 Webアプリケーションセキュリティの常識：知ってるつもり？「セキュリティの常識」を再確認（1/4 ページ） Webアプリケーションの脆弱性のほとんどは、開発時のささいなミスから生じる。Webアプリケーションの攻撃から保護するには、専門家によるペネトレーションテストが有効だ。 最近、Webアプリケーションに存在するセキュリティホールが注目を浴びている。Webサーバのセキュリティ対策というと、一般にファイアウォール、IDS（不正侵入検知システム）、ウイルス対策などがよく知られてきた。しかし、Webアプリケーションへの攻撃に対しては、これらの対策だけでは不十分である。 一般的に広く使われているWebアプリケーションであれば、IDSのようなもので特定パターンを検知して、攻撃を防ぐことは可能だ。しかし、Webアプリケーションのほとんどが独自に開発されたものであるため、一般的なパターンを検知
ホーム xdocdiff -TortoiseSVNでWord, Excel, PowerPoint, pdfのdiffを見れるようにするツール- English page ■概要 バージョン管理ツール、TortoiseSVN でWord、Excel、PowerPoint、pdf、OpenOffice.orgのファイルを管理するときに、 それらのリビジョン間のdiffを表示できるようにするツールです。 もし TortoiseSVN でのバージョン管理は行っていないが、これらの種類のファイルを比較し 差分を見たいのであれば、xdocdiff WinMerge Plugin をお試しください。 ■ダウンロード (Ver1.1.5a) プログラム: xdocdiff115a.exe (526k) インストーラ（xdoc2txt 1.35を同梱） xdocdiff113.zip (43k) xdo
Looking for JotSpot? You'll love the new Google Sites Google Sites, a new offering from Google, makes creating a team site as easy as editing a document. Use Google Sites to centralize all types of information — from videos to presentations — and share your site with just a few people, your entire organization, or the world. Learn more and sign up for Google sites Existing JotSpot customers: mi
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネット(株) が運営する国内シェアNo.1のドメイン登録サービスです。
マインド･マップをご存じでしょうか？ 最近、日本でも新しい「メモ技術」として注目されるようになってきた記法です。この記事では、このマインド・マップという記法が、ITの現場でうまく使えないだろうか、というアイデアを紹介します。特に、IT分野で標準化されているUMLをうまく補完するツールとして、要求分析という上流工程をまず取り上げたいと思います。 「顧客の言葉を集めること」の難しさ ITシステム開発において要求分析を行う場合、現在ではUMLを使ったオブジェクト指向による概念モデリングや、ユースケース分析が主流になってきています。しかし、UMLには強い制約（記法の意味と文法）があり、誰でもすらすらとまとまるものではありませんね。特に、顧客へのインタビューを行う場面では、その場でUMLにまとめるというのは至難です。そこで、顧客との対面場面ではとにかく「顧客の言葉を集める」ことに徹し、それをメモ（イ
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Swebok に尽きるかな．ウォーターフォールモデルとかPMBOKとかCMMとかCMMIとかRUPとか，その手の「何とか標準」などは大抵は論外だ．そう言ったものが「役に立つ」「きっと適用できる」と主張する人達もたしかにいる．しかし面白いことに奇妙な偶然が見られるのだ．役に立つと主張する人はソフトウエア開発経験が全く，或いはほとんどなく，下手をすると"hello world"さえも書いたことが無い*1．逆に優れた開発者で役に立つと主張する人はまずいない．なんとも奇妙な偶然だ． 以前，とある企業の方々と話をしたが，彼らは興味深い意見の持ち主だった．書類重視でウォーターフォールモデル，低レベルプログラマの大量投入による大量生産．おそらくは『上流行程神話』の信奉者．品質もメンテナンス性も全てドキュメントでなんとかし
http://www.martinfowler.com/bliki/Swebok.html 今月は IEEE による SWEBOK（ソフトウェアエンジニアリング知識体系） のレビュー月間である。これは、我々の専門分野についての知識体系を定義しようという試みで、ライセンス化へ向けての土台となるものだ。 いつもならこういった類のものは無視することにしている。いくつもの IEEE 標準が出されたが、それらは決まって商業ソフトウェア開発者たちに無視されてきた。そういったものは学術的であり、大規模な政府プロジェクトに関わるものだった。ビジネス側の人間は「政府」と「効率的」を同一視していないのである。 しかし、Cem Kaner はこのことを真摯に受け止めている（彼の判断には敬服しているところだ）。彼は blog の中でこう言っている。 SWEBOKがライセンス試験の根拠となるというのであれば、SWE
システム要求仕様書の書き方 IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Def
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
