山本隆の開発日誌

引っ越しは無事に終わりました。 明日から通常通りの運営になります。

C++Builder好きの秘密基地さんで「Xerces3.0.0をC++Builder 2009でビルドする方法」が公開されていました。

定番のXMLライブラリXercesがC++Builderで利用できるのは嬉しい話です。

はconst wchar_t*でやりとりするみたいなので、そのままUnicodeStringが使えそう。でも、何か嫌な予感が。

とありますが、どうなのでしょう。

時間があれば試してみたいところです。

多次元のリストをそのままソートすると、先頭の要素を比較してソートする。
要素がリストではなくタプルでも同じ。

>>> a = [[5, 'x'], [2, 'b'], [3, 'z'], [1, 'd'], [4, 'y']]
>>> a.sort()
>>> a
[[1, 'd'], [2, 'b'], [3, 'z'], [4, 'y'], [5, 'x']]

先頭以外の要素で比較する場合は、cmpキーワードを使用する。
2番目の要素を比較してソートする例。

>>> a = [[5, 'x'], [2, 'b'], [3, 'z'], [1, 'd'], [4, 'y']]
>>> a.sort(cmp = lambda x,y: cmp(x[1], y[1]))
>>> a
[[2, 'b'], [1, 'd'], [5, 'x'], [4, 'y'], [3, 'z']]

Delphi and C++Builder 2009 Update 1がリリースされました。

インストールは自動アップデート機構で、簡単にできます。
C++Builder 2007から用意された「自動アップデート機構」は便利ですね。
隠れたヒット作だと思います。

このアップデートの実行には20分、あるいはそれ以上の時間がかかります。

とあります。
アップデートするときは、ご注意下さい。

このアップデートでは、約50件の問題が修正されています。

修正されたバグの一覧は、Delphi 2009 および C++Builder 2009 Update 1 バグフィックスリストで確認できます。

C++Builder 2009のofstreamの問題とその回避方法が「NRTTKR Blog日記のお部屋」で掲載されていました。

• C++Builder 2009 Update 1の問題解決…というか回避

fstreamにファイル名をUnicodeStringで渡すと問題が発生する模様。

ファイル名をAnsiStringに代入してからなら問題は発生しないそうです。

UnicodeString周りの挙動は、不安がつきまといますね。

マップ型のキーがないときの値の指定方法。

通常、存在しないキーにアクセスするとKeyErrorになります。

>>> a = {}
>>> a['k']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
KeyError: 'k'

get()を使用すると、キーがないときの値を指定できます。
オブジェクト自身は変更されません。

>>> a = {}
>>> a.get('k', '123')
'123'
>>> a
{}

setdefault()はキーがなければ、キーと値を設定します。
get()と違い、オブジェクトは変更されます。
キーがすでに登録されている場合は、何もしません。

>>> a = {}
>>> a.setdefault('k', 123)
123
>>> a
{'k': 123}
>>> a.setdefault('k', 456)
123
>>> a
{'k': 123}

「Python ライブラリリファレンス 3.8 マップ型」を参考にしました。

Delphi/C++Builder 2009 Japanese Hotfix 1がリリースされました。

以前フォーラムでご指摘いただきました日本語版固有のオプション設定に関する問題を修正するホットフィックスをリリースしました。

このような日本語固有の問題に対するホットフィックスの公開は、日本語環境に対するサポートが強化されているような印象を受け、嬉しく思います。

このホットフィックスで差し替えるファイル「coreide120.jp」と「delphicompro120.jp」は、「C:\Program Files\CodeGear\RAD Studio\6.0\bin」にあります。

ソフトウェアのインターフェースをよりよくする方法を学ぶために、本書を読みました。
ソフトが使いやすくなれば、顧客満足度を高めることができますし、サポートコストも削減できるからです。

この本『ヒューマンエラーを防ぐ知恵』は、学術的な考察よりも、現実問題としてヒューマンエラーを防ぐ方法を提供することに力点を置いています。
精神論で解決しようとするのではなく、実践的な内容で、役に立つ本でした。

『ヒューマンエラーを防ぐ知恵』で示されている15の防止策は、ソフトウェアのインターフェースを考える時の指針として活用させてもらいます。

この本の最後でお薦めされている4冊のうち2冊は、プログラマならおなじみの（もちろん私も読んだことのある）本でした。

NetBeansの6.5がリリースされました。
6.5ではPHPに正式対応したようです。

フリーで使えるPHPのIDEは、優秀なものがありませんでしたので、
NetBeansには期待してしまいます。

Pythonのアーリーアクセス版が公開されていますので、
次に対応する言語はPythonになりそうです。
これも期待。

『はじめてのPython ネットワークプログラミング』は、Python初心者を対象に、クライアント側のアプリケーションを作成しながら、ネットワークライブラリの使い方を学ぶ本です。

この本の良いところは、実際に使用できるアプリケーションを作成することです。
ライブラリの使い方を示すコードの断片を示すだけではなく、ちゃんと使用できるアプリケーションを作成します。
このことは、初心者が興味を持って学習していく上で、重要なことだと思います。

第1章Pythonのおさらいでは、Pythonの文法をコンパクトにまとめて解説しています。
前著『はじめてのPython』で学んだ読者が復習するのにちょうど良いでしょう。

第2章FTPとTelnetでは、FTPでファイルをアップロードし、Telnetでアップロードしたファイルを操作するソフトウェアを作成します。
いろいろな用途に使用できそうなプログラムなので、これを学んだ読者はいろいろとカスタマイズして楽しむのではないでしょうか。

第3章から第5章では、SQLiteとTkinterを使用したメール送信プログラムを作成します。
GUIアプリケーションは、目に見える形で使用できますから作るのも楽しいと思います。

第6章ではGoogle Newsをメールするスクリプト、第7章では簡易RSSリーダーを作成します。
いずれも興味を持って取り組める題材だと思います。

Amazonのレビューでは、勘違いをして購入した人による不当に低い評価がなされています。
この本が対象としている人にとっては、きっと役に立つ本です。

『BEST SOFTWARE WRITING』を読みました。
理屈ばっかりの眠たくなるような本ではなくて、良いストーリーで楽しく読むことができました。
示唆に富む話が多く、勉強になりました。

一つは、今更ながらJavaのチェック例外について。

『Thinking in Java 第3版』では、RuntimeExceptionをチェック例外を「オフ」にするためのラッパーとして使う方法を示した。 今ではそうするたびに、それが正しいことに思える。

IBMのdeveloperWorks Japanにチェック例外についての記事(Javaの理論と実践: 例外をめぐる議論)がありました。
チェック例外の利点は「例外がソースコードに文書化される」こと、 短所は「実装の詳細を不用意にさらけ出している」「不安定なメソッド・シグニチャー」等。
結局は適材適所かもしれませんが、文書化できればすべてチェックなし例外でも良さそう。
Javaに大きく影響を受けて作られたC#がチェック例外の機構を受け継いでいませんですし。

次に静的型チェックについて。

「テストされていないものは、壊れていると思え。」

コンパイラはテストの一形態にすぎないい、という考え方が面白く感じました。
大切なのは強いテスト。
コンパイルが通っただけではプログラムの品質は保証されません。

確かにその通りだと思います。
みんながちゃんとテストを書いてくれると動的型言語でも良いのですが。
開発環境のサポートなどを考えると、静的型言語の方がソースコードに情報が多い分、コード補完の機能など利点も少なくないように思います。
将来的には開発環境が賢くなると、静的型言語の利点が失われていくのかもしれません。

ちょっと脱線しますが、

もし静的型チェックがそれほど重要であるなら、なぜPythonで大きく複雑なプログラムを（静的型付け言語に比べてずっと少ない時間と労力で）構築することができるのか？

Pythonがしばしば「実行可能な擬似コード」と呼ばれる理由がわかるだろう。
これは擬似コードとして使えるくらいシンプルであるだけでなく、実際に実行できてしまうというすばらしい性質を備えているのだ。

Pythonに非常に好意的な意見だったので嬉しい文章でした。

XP(エクストリームプログラミング)について。

今日では、エクストリームプログラミングを実践していると主張しているプログラマたちの多くは、それをお気に入りのものを提供してくれるメニューみたいに扱っていて、彼らはその中から好きなものを選び（ドキュメントなし！イェイ！）、嫌いはものは無視し（テスト駆動開発、ペアプログラミング）、結果として、私たちが伝統的に「早撃ちプログラミング」と呼んでいるものに落ち着いている。

この文章には笑ってしまいました。
たしかに教典の中から自分に都合の良いものだけを選んでいて、都合の悪いものは無視しているケースが多いと思います。
テスト駆動開発とペアプログラミングの他に、ソースコードの共同所有やYAGNIもあまり実践されていないように思うのですが、どうでしょう。

『BEST SOFTWARE WRITING』のような面白いプログラミングの本がもっと出版されるといいですね。