2008年9月30日
#
Google をやめて、Live Search を IE7 のデフォルトサーチエンジンにしてみる。
…なんだ、意外と使えるじゃないか。
2008年9月29日
#
有名な法則があります。
まず、「時は金なり」より、「時間＝金」であります。
次に、「知識は力なり」より、「知識＝力」が成り立ちます。
最後に、物理学の基礎ですが、「仕事＝力×時間」であります。
この三つの式は、その簡素さながら、驚くほどに豊かな示唆を含んでいます。
最後の式を変形すると「時間＝仕事÷力」となり、この「時間」と「力」に、前述の式の「金」と「知識」を代入すると、「金＝仕事÷知識」となります。
ここから、「同じ仕事をするのなら、知識が少ない方が、得られる金は多くなる」ことが導かれます。
また、この法則は、別の事実も示します。
第三の式を「知識＝仕事÷時間」という形に直してみましょう。
この式は、「仕事を短時間で片付けるほど、得られる知識は多くなる」ことを表します。
すなわち、「社員教育と称して、給料をもらいながら勉強させてもらえるのならこれに勝ることはないけれど、そんなことをしてくれる会社は極めて希有なので、とっとと仕事を終わらせて余った時間で勉強した方が、より多くの知識を得られる」ということになります。
加えて、「時間＝仕事÷知識」ですから、「知識が増えるほどに、仕事にかかる時間は減り、それによってより多くの知識を得られる」という好循環が待っています。
しかし、忘れてはなりません。
時間と金はイコールであり、従って、時間が半分になれば金もまた半分になるのです。
ここからは、「仕事を短時間で片付けるなんてもってのほか、時間をかければかけるだけ金は儲かる」という事実も浮かび上がってきます。
要するに、余暇を捨てて時間を残業につぎ込むことが、金を稼ぐ道だということです。
「仕事＝知識×金」なのですから、仕事の総量が同じなら、知識と金はトレードオフの関係にあるのです。
繰り返しになりますが、「金＝仕事÷知識」から、前述の好循環には、「知識が増えるほどに、得られる金は減る」という裏側があることがわかります。
知識をとれば貧乏になり、金をとれば馬鹿になります。
世の中、知識では食っていけないということです。知的労働って何でしょうね？
まぁ少なくとも、会社からこんなエントリを書いている俺は、明らかに拝金主義の「痴的労働者」だということは明らかなようですが。
ちょっと間が空いてしまいましたが、連載第２回です。
今回は、前回作ったメッセージ リソースを使うコードを紹介します。
前回までで、以下のようなプロジェクトができているはずです。
これに、ソース ファイルを追加しましょう。
ファイル名は MsgRes.cpp とでもしておきます。
で、いきなりですが中身を公開します。
#include <windows.h>
#include <stdio.h>
#include <locale.h>
#include <tchar.h>
#include "MsgRes.h"
int _tmain()
{
setlocale( LC_CTYPE, "japanese" );
LPTSTR msg = NULL;
DWORD result = FormatMessage(
FORMAT_MESSAGE_FROM_HMODULE | FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, MSGID_SAMPLE_0001, MAKELANGID( LANG_JAPANESE, SUBLANG_DEFAULT ),
reinterpret_cast< LPTSTR >( &msg ), 0, NULL );
if( result != 0 )
{
_putts( msg );
LocalFree( msg );
}
setlocale( LC_CTYPE, "english" );
result = FormatMessage(
FORMAT_MESSAGE_FROM_HMODULE | FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, MSGID_SAMPLE_0001, MAKELANGID( LANG_ENGLISH, SUBLANG_DEFAULT ),
reinterpret_cast< LPTSTR >( &msg ), 0, NULL );
if( result != 0 )
{
_putts( msg );
LocalFree( msg );
}
return 0;
}
はい。みんな大好き FormatMessage です。
GetLastError が返すエラーコードを文字列化するのにしか使ったことがない方も少なくないと思います。
今回は、第一引数に FORMAT_MESSAGE_FROM_HMODULE を指定し、第二引数に NULL を指定しています。
この場合、呼び出し側プロセスの EXE モジュールのハンドルを指定したのと同じことになります。
MSGID_SAMPLE_0001 は、前回 MsgRes.mc で定義し、メッセージ コンパイラによって MsgRes.h に書かれているメッセージ識別子です。
続いて言語識別子を指定しています。これは MsgRes.mc の LanguageNames で指定した値です。
言語識別子を変えることで、同じメッセージ識別子でも違うメッセージが取得できているのが分かると思います。
本題は以上です。以下、ちょっとしたオマケ。
メッセージ コンパイラが生成した MsgRes.rc を開いてみると、以下のような、なんともそっけないコードになっています。
LANGUAGE 0x11,0x1
1 11 "MSG_JA.bin"
LANGUAGE 0x9,0x1
1 11 "MSG_EN.bin"
これでは何だかわからん！ という方のために、もう少し読みやすく書き換えてみます。
ただし、このファイルはもう一度メッセージ コンパイラを実行すれば上書きされてしまうので、別のリソース ファイルを作りましょう。
MsgRes.rc を一旦プロジェクトから除外し、新しいリソース スクリプトを MsgRes2.rc とでも名づけて作成しましょう。
そうしたら、リソース ビューで MsgRes2.rc を右クリックして「リソース ファイルのインクルード」を選択します。
出てきたダイアログに、以下のように入力しましょう。
LANGUAGE LANG_JAPANESE, SUBLANG_DEFAULT
1 MESSAGETABLE "MSG_JA.bin"
LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT
1 MESSAGETABLE "MSG_EN.bin"
これで、言語も、メッセージ リソースだということもわかりやすくなりますね。
ただし、リソース コンパイラは MESSAGETABLE というキーワードを理解しますが、Visual C++ のリソースエディタは理解しません。
というかそれ以前に、このダイアログで入力した内容は、リソース ビューに表示されません。
このダイアログを使わずに、MsgRes2.rc を直接書き換えても、リソースの種類は "11" と表示されるだけです。ちょっとさみしいですね。
次回は、挿入シーケンスの使い方と、エラー コードに対するメッセージを定義する方法を解説します。
2008年9月26日
#
たまに、議論（とまで行かずに言い合いとか罵倒合戦の場合もあるが）をしている Blog を見かける。
そういうのは――こう言うと言い方がまずい気もするが――ちょっと困る。
コメントで議論するのはいくらでもやってくれていいが、自分の Blog で持論を展開し、トラックバックで持論間をつなぐというのは、どうも好きになれない。
なぜかと言うと、第三者から追いにくいからだ。
顔を突き合わせての議論なら流れが追えるし、多人数が参加する場合は議長が調停することもある。
Blog にはそれがない。
Blog は時系列でつけられ、その一部が日記に、一部が議論になることから、発端が分かりにくい。
検索で議論を見つけても、その検索にヒットした Blog の主が言いだしっぺだとは限らない。
二人が交互にエントリを書き、互いに相手の最新のエントリにのみリンクするなら単純だが、実際にはそうではない。
一つのエントリが複数のエントリにリンクすることは珍しくない。
あらかじめ会場を区切って行わないから、ホットな話題には際限なく人が流れ込み得る。
その中には同じことを言っている人もいるだろうし、傍目から見れば結び付けられるべきところが結ばれていないこともある。
誰かがまとめサイトを作ってくれる場合もあるが、そうでない場合も多い。
斯様な諸々によって、現在の Blog というツールは、議論に使うには向いてないのではないか、と思うのだ。
しかし、だから Blog で議論をするなと言う権利は俺にはないし、あっても言いたいとは思わない。
今の形が向いていないのならば、では議論に耐えうる――もちろん、当事者たちにとってだけでなく、第三者が読む議事録として――ためには、どのような改良を加えればよいのか、という方向性で見ていきたい。
とネタを振って、自分では何一つ案を出さずに締めくくる。
2008年9月19日
#
何回か、メッセージ リソースというものを取り上げます。
メッセージ リソースとは、アイコンやバージョン情報と同様、exe ファイルや dll ファイルに持たせることができるリソースの一種ですが、Visual Studio のリソース エディタで作成できないため、あまり知られていないものではないかと思われます。
メッセージ リソースを作成するためには、まず、そのソースとなるメッセージ定義ファイルを書きます。
これを、Windows SDK に付属しているメッセージ コンパイラ（mc.exe）でコンパイルしてバイナリ形式に変換し、それをリソースに埋め込みます。
なお、Visual C++ 2008 Express には、メッセージ コンパイラが付属していませんので、別途 Windows SDK をインストールする必要があります。
メッセージ定義ファイルの書き方や、メッセージ コンパイラの使い方は、MSDN Library の Message Compiler のところに書かれています。
MSDN では、イベント ログ関係のページとして書かれているところからもわかるように、メッセージ リソースの主な用途はイベント ログです。
そのため、この連載でもイベント ログについてとりあげますが、それは連載の終盤になる予定です。
その前に、次回以降で、イベント ログ以外の使い方を紹介します。
では、早速作ってみましょう。
まず、Visual Studio を立ち上げ、VC++ で新しい Win32 コンソール アプリケーション プロジェクトを作成します。
ウィザードでは「空のプロジェクト」を選びましょう。
次に、ソリューション エクスプローラのリソース フォルダに、メッセージ定義ファイルを追加しましょう。
カテゴリには出てこないので、とりあえずテキスト ファイルを選んでおきます。
拡張子は何でもいいですが、ここでは .mc としました。
そのファイルを開いて、以下のような内容を書き込みます（VC++ 上では色分けはされません）。
;// コメントはヘッダー ファイルに反映されるので、C++ 形式で書く必要があります。
MessageIdTypedef=DWORD
LanguageNames=(
English=0x0409:MSG_EN
Japanese=0x0411:MSG_JA
)
MessageId=0x0001
Severity=Informational
Facility=Application
SymbolicName=MSGID_SAMPLE_0001
Language=English
This is Message Resource Sample.
.
Language=Japanese
メッセージ リソースのサンプルです。
.
次に、ファイルのプロパティを開いて、ビルド方法を設定します。
Visual Studio はメッセージ リソースをビルドする方法を知らないので、自分でコンパイラの設定をしてやる必要があります。
とりあえず、以下のようにすればよいでしょう。
設定したら、ソリューション エクスプローラでこのファイルを右クリックして「コンパイル」を選びます。
終わったら、同じフォルダに、MsgRes.h、MsgRes.rc、MSG_EN.bin、MSG_JA.bin の4つのファイルができていることを確認してください。
これらのファイルを、プロジェクトに追加しておきましょう。MsgRes.h はヘッダー ファイル フォルダに、それ以外はリソース ファイル フォルダでいいでしょう。
それでは、先ほど記述したファイルの内容を解説します。
- コメント
- .mc ファイルに書いたコメントは、ヘッダー ファイルに反映されます。
MsgRes.h を開いてみると、一番上に、.mc ファイルに書いたコメントがあります。
そのため、.mc ファイル中でも、それを意識してコメントを書く必要があります。
- MessageIdTypedef
- MsgRes.h を見ると、
#define MSGID_SAMPLE_0001 ((DWORD)0x40000001L)
という記述があるかと思います。
この (DWORD) が、MessageIdTypedef=DWORD で指定したものです。
MessageIdTypedef=WORD とすれば、生成されるコードは #define MSGID_SAMPLE_0001 ((WORD)0x40000001L)
になります。
- LanguageNames
- 言語名を定義し、言語識別子とファイル名を関連付けます。
言語名は、その後のメッセージ定義で使用しています。
ファイル名は、メッセージ コンパイラが生成する .bin ファイルの名前になります。
- MessageId
- メッセージの識別子です。
Severity と Facility を上位ワード、この識別子を下位ワードとしたものが、実際のメッセージ識別子になります。
その値は、MsgRes.h に書き込まれます。
以降、メッセージ識別子に関する話が出てきますが、MsgRes.h に構造が書かれているので、それを見ながらだとわかりやすいと思います。
- Severity
- メッセージの重大さです。
この値は、メッセージ識別子の上位 2 ビットに反映されます。
標準では、成功=0、情報=1、警告=2、エラー=3 となっていますが、SeverityNames ステートメントを使うことで、自分で名前を定義することもできます（2 ビットしかないため、値は 0 ～ 3 しか使えません）。
今回は、メッセージ識別子の上位 2 ビットが 01 なので、0x4000～ になっているわけです。
- Facility
- メッセージのファシリティ値（日本語ではどう言えばいいんでしょう？）を指定します。
この値は、メッセージ識別子のビット 16 ～ 27 に書き込まれます。
標準では、Application=0 のようです。他に何が定義されているのかはわかりません（MSDN の記述は間違えているようです）。
FacilityNames ステートメントを使うことで、自分で名前を定義することができます。こちらは、任意の 12 ビットの値を使えます（たぶん）。
- SymbolicName
- MsgRes.h に定義される値の名前です。
- Language
- LanguageNames で定義した言語名です。
- メッセージ本体
- メッセージの本体を記述します。
最後に、ピリオドだけの行を置くと、メッセージ本体の終端を意味します（ピリオドはメッセージ本体に含まれません）。
複数行書くことも可能です。
次回は、このメッセージを使う方法です。
2008年9月18日
#
MSDN Library for Visual Studio 2008 SP1 が公開されましたね。
で、何気なくリリース ノートを見てみたところ、Microsoft Synchronization Services for ADO.NET オンライン ブックと SQL Server Compact 3.5 オンライン ブックおよびサンプルは別途ダウンロードせよ、と書いてあります。
ところで、上記の Synchronization Services ドキュメントは v1.0 のものですが、v2.0 も既にリリースされています。
Microsoft Synchronization Services v2.0 は Microsoft Sync Framework に含まれており、SQL Server 2008 をインストールすることでも使用可能になりますが、ドキュメントはインストールされません。
Microsoft Sync Framework ドキュメントは別途ダウンロードする必要があり、この中に、Synchronization Services for ADO.NET 2.0 のドキュメントも含まれています。
chm なので MSDN Library に統合することはできませんけどね。
2008年9月15日
#
俺は、いわゆる典型的な「生涯一技術者でいたい」ような人間で、マネジメント方面のキャリアパスはごめんだと言い張ってきた。
だが、最近になって、そっちの方もちょっといいかなぁと思うようになった。
相変わらず、納期交渉だの予算折衝だのという殺伐としたことはさっぱりやる気がないのだが、マネジメントとはそういうもの以外にもあるだろうと思うのだ。
というのはつまり、開発チームのマネジメントである。
プロジェクトを遂行するために最適な人材を選んでチームを組み、時には周りから不要だろうと言われる人間やポストも自分が必要だと思えば取り入れ、その他いろいろ、自分がマネジメントすることによって開発者の能力を十全に発揮させることができて、それで素晴らしいコードが出来上がるならば、それは、素晴らしいコードを自分で書きたいという欲求の延長線上にあるのではないかと思うのだ。
さて、昨今、「アーキテクト」という立場が脚光を集めている。
従来のキャリア階層では、（仕事の流れという意味で）上から、マネージャとかアナリストがいて、その下にSEがいて、その下にプログラマがいるという感じになっていた。
SEという立場の定義も様々で、技術職に含める場合も含めない場合もあるだろうが、それを含めるとしても、仕事が上から落ちてくる中で、それまでは営業的だったのが、突然、このあたりから技術的なことが登場するわけだ。
アーキテクトというのは、そのもう一段階上から、要するに要件分析とか顧客折衝の段階から、技術的な見地から関わる立場である。
要するに、従来は非技術的な人間だけがやっていたことの一部を、技術の人間にもやらせようという動きであると思う。
ならば、チームマネジメントにも、技術分野と非技術分野があってもいいだろうと思うのだ。
そうした技術分野のチームマネジメントというのも、なかなか面白そうではないかということである。
2008年9月12日
#
Windows Vista から、フォルダを Shift を押しながら右クリックすると「コマンド ウィンドウをここで開く」というメニューが表示されるようになりました。
これを、Shift なしで常時表示させる方法を見つけましたので書いておきます。
方法は簡単。
レジストリ エディタで、HKEY_CLASSES_ROOT \ Directory \ shell \ cmd および HKEY_CLASSES_ROOT \ Directory \ Background \ shell \ cmd キーの中の Extended という値を削除するだけ。
ちなみに、Diretory \ shell はフォルダ アイコンを右クリックしたときの、Directory \ Background \ shell はフォルダ ウィンドウの何もないところを右クリックしたときのメニューです。
さて、まだ未確認ではありますが、動詞キー中に Extended という値があると、それは Shift キーを押したとき限定のメニューになるっぽいですね。
これはいろいろ応用できるかもしれません。
2008年9月11日
#
いや、謎でも何でもなく、俺が送ってくれと頼んだものなのだが。
英語。
英語の Word ファイルが３つ来た。
これがまた、ライセンス関係の文書なもんだから、一応はしっかりと読まないといけない。
翻訳サイトには正確な訳は期待できないにしても、参考としては大いに使えるのだけど、この Word 文書、一部のフォームを除いて保護されているので、コピペができない。
うーむ…これでは読めないじゃないかぁ。
2008年9月9日
#