突然ですが、ブログというものを導入しました。 レンタルしているサーバで使える MySQL のバージョンの都合で、 やや古い WordPress 2.8 を使っています。
導入の動機は単純で、 自力で HTML を書いて更新していく作業が手間と感じるようになったからです。 ただ書くならこれまでの方法で良いのですが、 履歴を取る作業まで入れるとナカナカに煩雑です。 エディタで文章を編集し、 ブラウザで確認し、 履歴ページに文章をコピーし、 両方を FTP ソフトでアップロードします。 履歴ページが大きくなってきたら、 手作業で履歴ページを分割します。 これは結構に手間だったりします。 ブログシステムを使ってしまえば全作業をブラウザで行うことができます。 なにやらすぐに「クラウド」とか聞こえてきそうで嫌な感じですが、 日記更新の手間軽減については間違い無くブログの方が有利とは思っていました。
さて、ブログを導入したことで更新頻度が上がるのか。 結局のところ更新頻度は書く人のやる気に依存するので効果なんて無いよという声も聞こえてきそうですが（苦笑）、 手間が減ってくれればより更新する気になりやすいことに間違いはありません。 様子見、といきましょう。
Windows の API でプログラム的にスクリーンリーダーが起動しているかどうかを判定する機能があるそうです。 初めて知りました…ちょっとショックです（苦笑）。 とはいえ細かいチェックができるわけではないので役に立つかどうかは不明ですが、 頭の片隅に入れておこうと思いました。
最近めっきり更新していませんでしたが、一応生きています（苦笑）。 さて、デスクトップアプリの開発者として最近感じることを一筆。 とうの昔にソフトウェアの「機能」に価値が無くなったように思う昨今、 求められるのは「何が実現できるか」ではなく「どのように実現するか」だと思います。 要するに、 並大抵の機能であればフリーソフトの組み合わせで実現可能な今、 ソフトウェアを作るのであれば「機能」以上の価値が必要です。 使いたい、使い続けたいと思わせる魅力が必要だと思います。 そうした魅力の一つとして、 おしゃれなアニメーションを使ってリッチなユーザエクスペリエンスを提供する、 そんなケースが昨今増えています。 こうした話に長いこと私は無頓着でいましたが、 あるとき使った Google の Windows 用 Picasa が提供する視覚的アニメーションに対して強い危機感を持つようになりました。 Picasa は Web アプリではなくデスクトップアプリだったからです。
私のメインフィールドであるデスクトップアプリの世界では、 派手なグラフィックアニメーションが一般的ではありません。 もう少し厳密に言うと、 フレームワークやプラットフォームのレベルでアニメーションのような視覚効果が提供されていません （皆無ではないと思いますが）。 ではアニメーションを付けることができないのか、 というと当然そんなことはなく、実現できます。 ただし、アニメーションのための処理を自分で実装する必要があります。 その場合に、私にとって一番の心配事になってくる 「ハードウェア（GPU）の機能を使わないと処理が重たくなってしまうのではないか？」 という点について、少し時間を使って調査してみました。
結論から言うと、あまり GPU を使うメリットはありません。 「Flash （9 以前）が GPU を使っていなかった」 という話を出せば、多くの方が納得できるのではないかと思います。 実際に単純なアニメーションを高速に動作させるプログラムを作って動かしたところ、 現在のPC性能では大した負荷になりませんでした （もちろんデスクトップアプリで使われるような小規模のアニメーションに限った話）。 どうやらアニメーションに対して感じていた危機感は、 結構な取り越し苦労だったようです。
以下、参考リンクです。
ペプシの新作です。 味はあずき。Azuki なのです。 私としては買うしかない。 しかしながら期待をはるかに上回り、意外においしい。 すこし驚きました。 もう何本か買うことになりそうです。
本日、自作ライブラリのアップデート版を公開しました。 アップデートしたのは日本語文字コードを自動判定する C# クラスである Sgry.EncodingAnalyzer と、INI ファイル形式を扱う C# クラス Sgry.Ini です。
Sgry.EncodingAnalyzer は今回フルスクラッチで一から設計・実装しました。 再設計の目的は処理の高速化で、 また BOM コードが無い UTF-16 のテキストデータも検出可能になっています。
Sgry.Ini には微修正を行いました。 ファイルをロードするときに非共有モードで開いていたため、 これを修正して共有モードで開くようにしています。
これらのライブラリをお使いの方は、 ぜひアップデートをご検討ください。
拙作のテキストエディタエンジン Azuki では Sandcastle というツールを使ってドキュメントを生成しています。 Sandcastle はよくできたツールで、 javadoc のようにソースコードからコメントを抽出して API リファレンスを生成する機能に加えて 「普通の文書」も最終的に生成されるドキュメントに混ぜることができます。
普通の文書をドキュメントに混ぜられることには、まじめに考えると大きな意味があります。 API リファレンスはライブラリやフレームワークが用意するクラスやメソッドの仕様を説明するものであり、 クラス間の関係や設計思想といった「概念説明」や使い方を説明する 「チュートリアル」といった情報を説明するものではありません。 そこで、プロジェクトによっては全般的な概念を説明する文書を「別に」用意することもあります。 別個に文書を提供すればもちろん情報は伝わるので問題解決・・・と言いたいところなのですが、 自動生成する API リファレンスと文書のスタイルを同じように整える手間がかかる、 両方が HTML でない場合は相互にリンクできないといった問題が残ります。 こうした問題は、 そもそも概念説明やチュートリアルといった文書が混在するドキュメントを自動生成できる環境があれば最初から起こりません。 Sandcastle には、その機能が備わっています。
さて、そんな Sandcastle ですが、今まで解決できず困っていた問題を一つ解決しましたので備忘録。 Azuki のドキュメントではドキュメント全体の表紙ページを概念説明 (conceptual content) の文書として作成しようとしています。 そこから概念説明やチュートリアル、API リファレンスへのリンクを並べようと考えているのですが API リファレンスへのリンクを conceptual content の文書から張る方法が分からなかったのです （特定クラスの仕様ページへのリンクなどは分かっています）。 Sandcastle のプログラムソースや XSLT、付属の XML Scheme などを調べたところ、 やっとのことでリンクを張る方法を見つけました。 無理矢理っぽいですが、 externalLink 要素を使って API リファレンスのトップ（名前空間の一覧ページ、R_Project.htm） への「外部リンク」を作成し、ただし linkTarget 子要素に _self を指定します。 これで HTML 形式でも CHM 形式でも別のウィンドウを開くことなく名前空間の一覧ページへリンクを張れます。
見つけたことで喜んでここまで日記を書いたのですが、
改めて linkTarget をキーワードに検索すると・・・
ずばりそのものの答えがフォーラムにありました。
悲しい（苦笑）。
Linking from conceptual help to namespaces summary
本日、記事 「C# からコールバック関数を使う C の関数を呼ぶ」 を更新しました。 先日 creeper さんからお知らせいただいた有用な情報を追記し、 またこれを機会に若干の修正を加えています。 以前より無駄な言葉が減って読みやすくなったと思います。
昨日、近日発売(?)する東芝製のスマートフォン T-01A の内覧会に行ってきました。 そこで思ったことなどなどを綴れ書きします。
T-01A は OS として Windows Mobile 6.1 を採用したスマートフォンです。 人により注目する点は違ってくると思いますが、 私の場合は「性能」です。 というのも、現在 Windows Mobile 向けの開発をしていると 「性能の制約」 をどうしても感じてしまうからです。 なお私の開発検証機は Advanced/W-ZERO3 [es]、通称アドエスです。 2007年発売の品ですので T-01A とはまったく世代が違います。 そういう意味でこれらの性能比較については Windows Mobile を取り巻く環境の進化と考えた方が良いでしょうね。
さてはて、そんなことを思いながら用意されていた評価機に触ったところ・・・ うーむ、速い。ものすごく速いです。 アドエスで毎日感じている「モタり」はまったく無く、 また画面を描画するときの「チラつき」もまったく感じません。 正直に言って、完全に予想を超えています。 知人の一人が残念ながらアドエスの使用をやめてしまった理由は 「普通のケータイと比べてしまうとモタりがどうしても気になる」ということでしたが、 これだけの性能があればそういうことも無くなるだろうと思いました。
主観だけで「速い」とか「モラらない」とか言っていても信憑性がイマイチだと思います。 で、アプリを持ち込んでも良いということでしたので、 Azuki (Ann) で性能を少し計測してみました。 およそ一万行のテキストファイルを読み込ませて折り返し位置を全域で計算させたところ、 アドエスで 30 秒かかるのに対して T-01A では 3.5 秒程度という結果でした。 使わせていただいた T-01A は評価機であり、 計測条件も整えていませんので本当に参考程度でしかありませんが、 まあ「体感できるレベルで高速」と言って良さそうです。 うむ。時代は進む。
最後に、T-01A とは話がそれてしまいますが今回の内覧会でおもしろかったのは、 aplio というフリーソフトです。 これは Windows Mobile 用の簡易パッケージ管理システムのようなもので、 WindowsCE FANのソフトウェアライブラリから情報を取得して、 アプリごとに必要なパッケージを自動的にインストールしたりできるそうです。 さすがにまだ時間がかかるとは思いますが、 将来は debian の apt や RedHat の rpm に並ぶような存在に成長することを期待しています。
最近めっきり更新できなくなっていましたが、本日久々の更新です。 本日の更新内容は、C# 用の文字コード推定ライブラリ Sgry.EncodingAnalyzer のバージョンアップと、 INI 形式ファイルを扱えるライブラリ Sgry.Ini の公開です。
実は今回公開した Sgry.Ini というライブラリ、 2006 年に作って以来ずっと個人的に使い続けてきたライブラリです。 なかなか公開のチャンスに恵まれず今の今まで公開できずにいましたが、 ようやく公開できる形を整えることができました。 やはりチャンスに恵まれないと「やろう」と思っていてもナカナカできないものですね。
さて、今回から Sgry.EncodingAnalyzer と Sgry.Ini の両方ともマジメな単体テストを実装しており .NET Compact Framework でもテストが通ることを確認しています。 また両方ともクラス一つで、ソースコードも一つです。 したがってどちらもライブラリのソースを既存プロジェクトに追加するだけで使えます。 C# で日本語文字コードの自動判定を行いたい、 または C# で INI ファイルの入出力を GetPrivateProfileInt などの API を P/Invoke していてパフォーマンス不足に悩まされている方には これらのライブラリが役に立てるかもしれません。 ご興味のある方は次のリンクからどうぞ。
Azuki を更新してバージョン 1.2.2 を公開しました。 キーワードベースのハイライターに共通するバグを修正しています。 1.2 系をお使いの方はお手数ですがアップデートしてください。
さて、先日 Azuki を紹介してくれているサイトが無いかと検索していたところ、 嬉しいことに２つほど見つけることができました。 読んでみると・・・ ふむふむ、どうやらドキュメント類が基本的に英語であること、 ワードラップ機能（というより日本語の禁則処理）が無いことが特にイマイチと。 なるほど、参考になります。
ワードラップ機能については、 実は最初から認識はしていたものの Azuki をプログラムソース編集用に設計していたので、あえて実装せずにいました。 これを機会に考えてみるもまた良し、ですね。
ドキュメントの言語については、 ふむ、これはちょっと前から私が関心を寄せている問題の一つですね。 主に API リファレンスのような詳細設計ドキュメントの話ですが、 現在の主流はソースコードに書いたコメントをドキュメントとして抽出する方法です （ドキュメントをソースに埋め込む、という言い方が正しい）。 この方法についての詳細は割愛しますがソースコード中に書き込むという点が重要でして、 私はソースと別個にドキュメントを記述してメンテナンスするつもりはありません。 ですが、そうするとドキュメントを複数の言語で書こうとすると困ったことになります。 ソースファイルに複数言語で同じ内容の説明をずらずら書こうものなら猛烈に読みにくくなりますから（苦笑）。
実際、世の中にあるほとんどの API ドキュメントは一つの言語で書かれています。 もちろん Apple や Microsoft、Sun といった OS などの API リファレンスを書いている例はあります。 彼らがこの問題をどのように解決しているのかは気になりますね。 一番ありえる方法は、 ソースには英語でドキュメントを書いて API ドキュメントを生成し、 それを手修正で翻訳する方法ですが・・・ HTML などの形式で出力されたドキュメントの翻訳版をメンテナンスする作業はかなりの負担になります。 というのも多くのツールが生成する HTML はまさに 「機械生成」という感じでメンテナンス性が低いので・・・（泣）。
もちろん理想のドキュメント生成環境が無いのなら、作れば良い。 とはいえ、その暇があるなら Azuki や AiB Tools のメンテをすべきと思い、 もやもやしている近頃です。
ところで。 12月3日、ついに Python 3.0 がリリースされました！ 仕事場ではちょっとした作業や検証用に Python 3.0 をベータの頃から使っていましたので嬉しい限りです。 そして気が付いたら11月27日に IronPython 2.0 も RC2 になっています。 こちらも近いうちにリリースされそうですね。 楽しみです（笑）。
beyerdynamic の MMX 300 MANUFAKTUR を買ってしまいました。 せっかくの円高ですしね（笑）。 送料などなど含めて 285 ユーロ・・・およそ 3 万 4 千円弱でした。
MMX 300 ヘッドフォンにマイクが付いた製品、 つまりヘッドセットで、ゲーマー用として売られています。 日本の店頭では beyerdynamic のヘッドセットは見たことがありませんでしたが、 高級ヘッドフォンが欲しかったことに加えて PC でボイスチャットする環境が欲しかったので、 ヘッドセットにしました。 名前の通り、 配色や素材などを部品ごとにカスタマイズできるのも楽しく良かったです（笑）。
気になる音質ですが、 さすがは beyerdynamic、これがすこぶる良い。 そろそろエージングも進んできたと思うので、 暇ができたら兄が持っている SENHHEISER HD 600 と聞き比べして遊んでみようと思います。
昨日、C# で作ったテキストエディタエンジン Azuki を 1.2.0 にバージョンアップしました。 今回はシンタックスハイライト関連の機能を強化して、 もっと「まし」なサンプルアプリケーションを同梱することにしました。 ちなみにサンプルアプリケーションの名前は Ann です。 Azuki で作るって言ったらやっぱり Ann ですよね？ :)
本日、FolderLibrarian というメタ情報で大量の Web コミックを管理するソフトウェアを公開しました。 次のリンクから FL のページへ移動できます。 ご興味のある方はどうぞご覧ください。
実際のところ、FL の開発は 2005 年から行っていました。 最初は身内だけで使っていたのですが、 少し前に siotsu 氏に「公開すれば？」と言われ、 まったりダラダラと公開準備を進めて公開したのが本日・・・ということになります。 なお「身内だけ」とは言いましても実際は C# の勉強をかねて作ったソフトなので、 実装上の手抜きも無くちゃんと動きます。 もし身内以外の誰か一人にでも役に立てば幸いですね。
Mosh Pit On Disney というアルバムを買いました。 目当ては、Andrew W.K. のミッキーマウスマーチです（笑）。 正直、聴いている中で頭に浮かぶ映像は某ネズミではなく、 びしょ濡れで鼻血を流すアンドリュー兄貴の顔ですね。
テキストエディタエンジン「Azuki」をやっと正式リリースしました。
バージョン 1.0.0 を公開です。
思っていたより長い道のりでした・・・が、
まあその分、自己満足感もひとしお（笑）。
もし 興味がある方は、
Azuki のページご覧ください。
本日、Azuki 1.0 beta 1 を公開しました。 1.0 はシンタックスハイライトに対応しています。 Advanced/W-ZERO3 [es] で使った場合、 自己満足できる程度の速度でシンタックスハイライトできています。 興味のある方は Azuki のページ へどうぞ。
Azuki プロジェクトのページを別のサーバへ移転しました。 移転先サーバは、SourceForge.JP です。 Azuki に対してある程度広くフィードバックを得たいと考えた末の結論です。 ちなみに新ページは http://azuki.sourceforge.jp です。 まだ工事中という感じですが、 とりあえずサイトとして一応の体裁は整ったのでご報告まで。 さて、あとは水面下で進めてきた 1.0 の開発が終わったので、 公開の準備を進めていきます。 特に Azuki はライブラリなので API ドキュメントをしっかり整えないと・・・。
本日の備忘録。 ssh でログイン時に 次のようなエラーが出た場合の対処についてです。
# ssh user@server Permission denied (publickey)
エラーの意味がよく分からなかったので検索したところ、 ChallengeResponseAuthentication というオプションを yes にすれば良いという情報を見つけました （情報源のブログ）。 これは、コマンドライン実行時でしたら次のようなコマンドで指定できます。
ssh -o ChallengeResponseAuthentication=yes user@server
また、/etc/ssh_config や ~/.ssh/config に次の一行を加えても大丈夫です。
ChallengeResponseAuthentication=yes
チャレンジレスポンスというのはセキュリティを高めた認証方式の一種です。 パスワードから作ったハッシュ値をそのままサーバへ送信せず、 まずサーバから送られてきたフレーズ（チャレンジと呼ぶ）を、 たとえば「パスワードの後ろに結合した上でハッシュ化」し、 その結果を送信します。 こうすると、万が一にクラッカーに盗聴されて総当たり攻撃でハッシュ化する前の文字列を見つけられたとしても、 その文字列は「パスワード＋チャレンジ」です。 文字列のどこまでがパスワードでどこからがチャレンジなのかはクラッカーには分かりません （もちろんパスワードが Yamamoto2008 といったものだとすぐバレますが（苦笑））。 さらにチャレンジは定期的（たとえばログインごと）に変更されるため、 この区切り位置はなかなか分かりにくいものになります。 以上のような方法でパスワードをばれにくくしているわけですね。
この仕組みは普通パスワード認証の話として出てきます。 一方今回は公開鍵暗号方式の SSH なので、 どう使っているのか少し興味がありますね。
今日、 EQUATEC Profiler という .NET アセンブリ用プロファイラを試してみました。 無料で使用、ダウンロードできます。 私にとって驚きだったのは、 アセンブリファイル（.exe や .dll）を指定すると型情報を抽出して自動的に 「プロファイル処理埋め込み版」 を生成してくれることです。 ソースコードに手を加えるどころか、 ソースコードが無くてもプロファイリングができるとは思いませんでした。 また、実直な機能と UI で使いやすい点も嬉しいところです。 アセンブリファイルを指定してボタンを一つ押すだけでプロファイリング版が生成できますし、 プロファイリング版の実行後に所定フォルダに出力されたログは、 付属のビュワーで「開く」だけでリスト（というより表）＋グラフ表示ができます。
.NET Compact Framework のアセンブリに対応しているというのが最大の特徴ですが、 .NET Framework のアセンブリに対応していないわけではありません。 またソースが不要なので、 他人の作った .NET アプリケーションのプロファイリングも可能でしょう。 暇で仕方ない人の遊びとしても使えるかもしれません（笑）。
→ 参考：InfoQ - .NET Compact Framework向けEQATECコードプロファイラー v. 1.2に新機能追加
C# 製のテキストエディタエンジン「Azuki」 をバージョンアップして 0.9 にしました。 念願の折り返し表示機能を筆頭に、機能を追加しています。 いまだにマニュアルすらない状況ですが（苦笑）、 興味のある方は次のリンクからどうぞ。
さてさて本日、 ついに今まで水面下で開発を続けてきた C# 製のテキストエディタエンジン「Azuki」 を公開しました。 専用のページを作っていますので、 興味のある方はそちらをご覧ください・・・非常に未完成な感が否めませんが（苦笑）。 なおライセンスは zlib ライセンスですので、 Azuki を使うソフトは Azuki の使用を明示する義務すらありません。
C# 製のテキストエディタエンジン、 ということですが探してみると C# から使えるエンジンの選択肢はあまり無いのが現実です （これについては当サイトの記事 「C# から使えるテキストエディタ部品」 も参照くだされば幸いです）。 正直に言うと、C# で使うエンジンの最有力候補は SharpDevelop のエンジンだと思います。 しかし SD のエンジンは全部が C# で書かれてはいるものの、 ところどころで Win32API を呼び出していたり .NET Compact Framework に無い機能を使っています。 これは Windows で使うぶんには別段何の問題でもありませんが、 実は私（と友人の siotsu 氏）の中では Windows Mobile で動くテキストエディタを作りたいという思いがありました。 そうこうしながら結局フルスクラッチで新しくエディタエンジンを作るに至った、 というわけです。
機能としてはまだ未完成で、バージョンも 0.8 です。 とはいえ内部構造、描画系、その他基本的な機能はほぼ完成しており、 サロゲートペア対応も含め日本語処理も実装済みです。 内部のデータへのアクセスはがっちりと単体テストでいじめ抜いていますので、 まず問題は無いと思います。 そんな話よりマニュアルをさっさと書けという声が聞こえてきそうですが（苦笑）、 ちゃんとマジメに作っているということだけ主張して今日の一言は終わりにします。 最後に一言。 完成には siotsu 氏の協力が必要不可欠でした。 この場を借りて感謝します。
備忘録。 NAnt を使って .NET Compact Framework 2.0 (以下 CF2) 用のアセンブリをビルドする方法。 NAnt では生成するアセンブリの対象フレームワークを選択できます。 方法の一つは、ビルド時のコマンドラインオプションで指定する方法です。 もう一つは、NAnt スクリプト中でタスクごとに対象フレームワークを指定しておく方法です。 私が使っている後者の場合、 通常は task 要素の子に次のタグを書くだけで良いはずです。
<property name="nant.settings.currentframework" value="netcf-2.0" />
しかし私の環境ではエラーが表示されて動作しませんでした。 ちなみに私の環境の OS は Windows Vista (x64 Edition) で、 Visual Studio 2008 (Academic) をインストールしています。 表示されたエラーは 「CF の SDK がインストールされていない」 というもので、 少し調べてみたところ NAnt が読みに行くレジストリキーが私の環境に存在しないことが原因と分かりました。 というのも、NAnt の bin フォルダにある nant.exe.config の中に、 明らかに「ここのレジストリを読みに行く」という設定項目があるからです。 具体的には次の部分です（長い部分は ... で省略しています）。
<framework
name="netcf-2.0"
...
sdkdirectory="..."
frameworkdirectory="${path::combine(installRoot, 'v2.0.50727')}"
frameworkassemblydirectory="..."
>
...
<project>
<readregistry
property="installRoot"
key="SOFTWARE\Microsoft\.NETFramework\InstallRoot"
hive="LocalMachine"
/>
...
<fail if="...">
The .NET Framework 2.0 SDK is not installed.
</fail>
</project>
...
</framework>
さて、これをちゃんと動くようにする方法です。
結論から言うと、NAnt.exe.config の三カ所を書き換えれば動くようになります。
まず framework 要素の frameworkdirectory 属性の値を
「コンパイラがあるパス」にします。
続いて、同じく framework 要素の
frameworkassemblydirectory 属性の値を
「参照する CF のシステムライブラリがあるパス」
に設定します。
最後に、
CF SDK がインストールされているかどうかをチェックしている部分をコメントアウトします。
具体的には、XML 要素をフォルダに見立ててパスで表すと
framework/project/fail
で指せる要素をコメントアウトします。
以上で、私の環境では無事に CF 用のアセンブリがコンパイルできるようになりました。 最後に私の環境での NAnt.exe.config の抜粋を掲載して終わりとします。 私の環境は x64 Edition なので多くの人はそのままでは使えないと思いますが、 参考になれば幸いです。
<framework
name="netcf-2.0"
...
sdkdirectory="..."
frameworkdirectory
="C:\Windows\Microsoft.NET\Framework64\v2.0\v2.0.50727"
frameworkassemblydirectory
="C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE"
>
...
<project>
<readregistry .../>
...
<fail if="...">
The .NET Framework 2.0 SDK is not installed.
</fail>
</project>
...
</framework>
補足。 そもそも CF 用のアセンブリを生成するには、 CF 用のシステムライブラリ（System.Windows.Forms.dll など） を参照するよう設定してコンパイルするだけであり、 コンパイラはデスクトップ用と共通です。 つまり CF 用のビルド環境構築に必要なのはコンパイラのパスと、 参照するシステムライブラリのパスだけで良いはずですね。 今回 2 カ所のパス指定を書き換えたのは、これが背景にあったということです。
一つ新しいログ | 一つ古いログ