2009年2月22日日曜日

VAIO Type Pがほしい

http://www.gizmodo.jp/2009/02/vaio_type_p_4.html

VAIO Type Pがとっても欲しくなってきたんだけど、この記事を読んで再考中。。

Windows7が出るまで待った方がいいのか、Linuxを入れてまで使った方がいいのか..

2009年2月6日金曜日

マイクロソフト、Windowsでのエラーを自動修正するオプションを追加


いいですね。こういうの。うちの製品でもやるべきだな。

製品サイトに不具合やトラブル現象を記載するところまではどこでもやってて、うちでもやってるけど、修正スクリプトの自動実行までやってるところはあまりないですね。

提案してみようかしら。

2009年2月4日水曜日

涙ぐましい後方互換性

Life is beautiful: Windows95と地上の星

Windows95を出荷する際のMicroSoftの開発者たちの苦労話。
主要なサードパーティ製アプリケーションがすべて正常に動作するようにしたそうです。
レイモンド・チェンのThe Old New Thingと同じですね。チェンはSim Cityについて語っていましたが、中島さんはWin3.1用の教育ソフトですね。

弊社のパッケージでも、メジャーバージョンアップではデータ構造から作り直しをすることがよくあるんですが、下位バージョンを使っているユーザーさんのために、このリンク先のようなことは頻繁にやります。

旧版のデータ構造を消さずにそのまま残しておいて、旧版からの移行ユーザーの場合だけ、わざわざ旧版のテーブルを一旦作ってから新版のテーブルへバケツリレーのようにデータを転記したり(ユーザーさんが自前で作成しているI/Fプログラムへの配慮である場合が多い)、旧版のロジックをほとんどそのまま残して、特定のユーザーさん向けに特殊設定を出荷して、旧版モードでもとりあえず動くようにしたり(ユーザーさんが業務のやり方が変わることを望まない場合を考慮して)。

Windowsと比べるなんて恥ずかしいですけどね。規模が全く違いますし。。
ただ、規模こそ違えど、ユーザーが日常的に利用するアプリケーションを作っていて、それがバージョンアップ時の足かせ(言葉悪いですが)になっている感じが似ていて、心強くなりました。

特に、中島聡さんのブログは弊社と考え方が全く同じで、感動しました。毎日ひどい思いして開発しているけど、間違っていないんだなあと確認。

MicroSoftのこの伝統は、今も生きているようです。
本当はすごい「Windowsの互換性維持」:ITpro

でも、Windowsは好きじゃないけどね。。

2009年2月2日月曜日

エンタープライズソフトウェア企業というのはテクノロジー企業ではない

http://www.aoky.net/articles/paul_graham/notnot.htm

さきほどのFizz-Buzz問題に続いて、同じ青木さんの翻訳されたポール・グレアムのエッセイ。

読んでいてギクッとなった箇所を抜粋。
技術的に難しい何かをするスタートアップをやれるほど頭が良くないと思っているなら、エンタープライズソフトウェアを作ればいい。エンタープライズソフトウェア企業というのはテクノロジー企業ではないのだ。彼らはセールス企業であり、セールスでは努力がものを言うのだ。

ひどいなあ。。当たってるよ。

たしかにうちの会社もエンタープライズソフトウェア分野のベンチャーで、確かに技術的に難しいことはやってない。やる必要もない。

セールストークと、力技の会社だ。具体的なことを書くと社名がバレるので書きませんが。

せいぜい、100万オーダーの伝票を一瞬で照会したいとか、各社ごとに違う業務フローをパラメータ設定だけですべてフォローするとかくらいですかね。難しいのは。

前者はシステム開発としては大事で手を抜けないところではあるけど、特別技術的に難しいチャレンジがあるわけではないし、後者は極端な話、顧客の数だけプログラムを書き、巨大なif節で呼び出すプログラムを分岐させればいいだけ。(嘘みたいな本当の話)

っというわけで、ポール・グレアムにずばり言われてますね。。しかも2年も前に。。


どうしてプログラマにプログラムが書けないのか

http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm

上記の記事から引用(一部抜粋)。

開発者を見分けるための質問を作り始め、私が「Fizz-Buzz問題」と呼んでいる問題のクラスを考え出した。Fizz-Buzz問題の例はこんな感じだ。

1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。

ちゃんとしたプログラマであれば、これを実行するプログラムを2分とかからずに紙に書き出せるはずだ。怖い事実を聞きたい? コンピュータサイエンス学科卒業生の過半数にはそれができないのだ。自称上級プログラマが答えを書くのに10-15分もかかっているのを見たこともある。

僕はDelphiでやりましたが、3分くらいかかりました。。死にたい。。

あの命令をDelphiではどう書くんだっけ、とヘルプを見るのに1分くらい使ってしまった。。

アルゴリズムは一瞬で浮かぶけど、それを各言語の仕様に落とすときに混乱するなあ。

beginはどこに書くんだっけ、とか、セミコロンは入るんだっけ、とか、あ、間違って中括弧"{}"付けちゃった、とか。

うわ、間違って74バイト目に記述しちゃった! とか。(20代以下のプログラマーには何の話だか分からない)

あ、変数宣言するの忘れた! とか。(←最近Pythonで遊んでるのでやりがち)

ちなみにうちの会社のへっぽこプログラマーたちのほとんどは2分では終わらなかった。。ああ。。

特にひどいのは10分たっても終わる気配すらなく、さらに言うとロジックが間違っていました。

3と5両方の倍数でFizz、Buzz、FizzBuzzの3つすべてが出力される! という。。。orz