・
MECSUtils ver1.41
過日、リリースしました。
・
最初に言っておく事が...
「藤井さん、ゴメンナサイ...m(_ _)m」
・
MECSUtils ver1.42
リリースしました。掲示板の件です。TrimNullTerm() も追加されています。
・
MECSUtils ver1.45
リリースしました。1.43 / 1.44 も途中でリリースしましたが、現在は 1.45 がリリースされております。マッピング変換系の関数については、今後も仕様変更があるかもしれません。
・
"しこりのようなもの"
先日来、右耳の付け根に "しこりのようなもの" ができていて、痛みはなかったのだけれど 「ゴロゴロして気持ち悪いなぁ...」 と思っておりました。
スクスクと日々順調に成長していた "しこりのようなもの" ですが、ある日触ってみるとちょっとしたカサブタのようなものがありまして、「ゴロゴロの上にカサブタかよ~」 と思いながらも、カサブタを剥がしたら何やら水分が。「こりはもしかして?」と思って "しこりのようなもの" を触ったら 爆裂 しました。
爆裂した内容物は血と "形容しにくいデロデロの液体" でした。まだ膨らみがあったので爆裂した付近を絞ってみたら、さらにデロデロが出てきました。血しか出ないようになるまで絞ったら、スッキリしました...そりゃ、痛かったけどさ。
耳の近くなので、絞ると "ぶきゅるっ!" みたいな生々しい音がよく聞こえて嫌だったなぁ...。
・
第16回 エンバカデロ・デベロッパーキャンプ (1日目)
うわーっはっはっは。他のセッションにも気になるのがあるけど、自分のセッションの準備で正直それどころじゃねぇー (w
・
第16回エンバカデロ・デベロッパーキャンプ参加方法
簡単な参加手順。
・
カントリーマアーーーーーーーム!!(白あん)
タイトルに深い意味はありません。とりあえず、担当セッション終了っと。
【1E】セッション参加者の方はセッション前/中で添付資料を DL されたと思いますが、資料は私の喋りなしでも成立する内容になっています (してあります)。セッションした内容の後にさらに資料が 9P あります。加えて言えば、Extra セッションの後の Extra セッション (課外授業) もあります。実は "全部で 91P" あります。
あれでも、端折ったネタは数知れずなのですよねぇ...ま、その辺はそのうち DL 可能になるであろう、フルサイズの資料で垣間見て下さい。
・
下校チャイムと電車
チャイムはそれほどでもなかったかもしれないけれど、電車は参った。何せ、会社の真横 (僕の席の真後ろ) を単線ではあるけれど線路が通ってるからなぁ...今朝に至っては、線路工事やってたし。
まるちぷる・たいたんぱー!!
ってやってた時は「今日はどうなるんだろ...」ってマジで思った。まぁ、それ以上に 「アイツはどこからセッションやってんだ?」 と思われたであろう事は想像に難くない。
・
回線ダウン
セッション前に、邪魔が入らないようにと会社の電話回線を切った (もちろん、会社は了承済) つもりだったが、間違って "通信回線を切った" 焦った焦った (ひかり電話なのです)。
・
PowerPoint と Live Meeting と PDF と
それぞれ、微妙に表示が異なるのがアイタタタ...だった。全部画像にしてしまえばいいのだろうけれど、"文字列をコピーして検証" みたいな芸当ができなくなるし、拡大縮小に弱いのでそれは嫌だった。むしろ、環境依存で文字が正しく表示されない事の実証ができたとも言えるが、心底心臓に悪い。
・
第16回 エンバカデロ・デベロッパーキャンプ (2日目)
【2E】で、いきなり自分の名前が出て来て焦る焦る(w
・
総括
初日は自分のセッションの準備でいっぱいいっぱいだったので、他の方のセッションを聞けなかった(聞く余裕がなかった)のが残念です。
担当セッションは、やっぱり "時間超過" コレに尽きます。スライドが多いためタイムラインは事前に用意してありました。手元に時計がなかったので、Delphi 2010 で大きく見やすいデジタル時計を 5 分で作ったりもしました。それでも超過したのは...大人の事情(?)です(w
スライドが意図しない文字になっていたのは、焦りました。画面のラグを少なくするため、PowerPoint 形式ファイルを スライドショー形式の ppsx に変換して Live Meeting に食わせて Live Meeting 形式に変換してありました。デモとかをやらないのであれば、"アプリケーション共有で PowerPoint 自体を共有するより高速動作する" からです(恐らく色の劣化も少ない)。
しかし、これが裏目に。フォントが勝手に置換されてしまうため、意図しないフォントで描画されてしまい、全然説明になっていない文字になっていたりしました。EMF 変換してEMF をスライドに貼るべきでした (Office のテキストを EMF 変換する方法)。配布された PDF 資料も、PowerPoint とは若干違う見え方をしますね...。文字コードのセッションとしてはこれは非常にマズかったと反省しています。
2日目は余裕で観れました。「ほほー」「なるー」とつぶやいてしまうのがアレでしたが (w
セッション担当者側からすれば Live Meeting はコツさえ掴めば非常に使い易いですね。参加者リストや Q&A ウィンドウ、音声/ビデオウィンドウは一旦フローティングさせて左右もしくは下にドッキングさせておくと、視認性がよくなって Good でした。チャットウィンドウだけはフローティングで別画面に置いてましたけど。
今後もこのライブ形式は継続して欲しいです。私のように田舎住まいだと、デブキャン参加自体が難しいですからね。それと、セッション中にしか語られず、資料には書かれていない情報があったりするのも承知していますから、後で資料だけ読んでも不明瞭な箇所がある事には若干の不満を持っていました。それでも、要点は書いてあるのでデブキャン資料は重宝しているのですがね...。
・
資料
一昨日/昨日のセッションの launch.rtc を保存しているヒトは、それをダブルクリックし Live Meeting に接続して資料を DL する事ができます。右上の方にあるノートみたいな白いアイコンからどうぞ。
資料 DL 有効期限は 1 年ですが、幾ら何でもそれまでにはエンバカデロのサイトから資料が DL できるようになると思います。
・
Office Live Meeting 2007 の資料
こんなもんです。
・
5 分で作った時計
超低機能で場所も覚えません (w
テンパりながら作ったのがどんなモノだったか見てみたいヒトは こちら からどうぞ。ファイル名は当初 "Project1.exe" だったのですが、流石に名前だけは変えておきました。
・
続・5 分で作った時計
実質、8 行しかソースないですもん。FormatDateTime() の書式をソラで覚えてるヒトにはチョロイと思います。タイプが早いヒトなら 3 分で作っちゃうかもですね。
|
フォームにはラベルとタイマー貼ってあるだけ (w
一応、断っておきますと、体裁整える前の "とりあえず動くもの" を作った所要時間が 5 分です。フォームの色とかフォントの色の調整は後でやりました。それでもトータル 10 分あるかないかですけどね。
・
第16回デベロッパーキャンプ資料ダウンロード
ダウンロード可能になりました。合わせて、Tips の方も更新してあります。
私の担当部分ですが...セッション内容が自分としては不本意なデキでしたので、お詫びの意味を込めて追補資料を付けておきました。セッション資料ではなく、"軽い読み物として手頃なページ数" になっていると思います (苦笑)。
セッション資料/追補資料のいずれも、前半部分は文字コードの話なので Delphi 以外の言語にもそれなりに役に立つと思います (新人くんに、「とりあえずこれ読んどけ」程度には)。ただ、それでも文字コードの話としてはプロローグに過ぎず、自分で調べたり試行錯誤する必要はあるとは思います。
後半は Delphi 固有の処理...セッションのお題でもある "Delphi での文字コードハンドリング方法" です。C++Builder とはちょっと事情が違う トコもあります。
・
Migrating Legacy Apps to Unicode-enabled Delphi 2010
さて...先日、デベロッパーキャンプが開催されたばかりですが、来る 3/24 に Cary Jensen 氏による Web セミナーがあります。
"Migrating Legacy Apps to Unicode-enabled Delphi 2010" という、どっかで聞いたようなお題になっておりますが、類似セッションをやった身としては、どんな切り口で Unicode アプリケーションへのマイグレーション方法が語られるのか興味深々だったりします。既存アプリケーションの Unicode 化に興味のある方は参加してみてはいかがでしょうか?
・
Vote して欲しい QC (セッション絡み)
文字コード絡みの QC は結構ありますが、Vote して欲しいものが幾つかあります。
追記:
早速の Vote 感謝です。なお、"Quality Central Windows クライアント (Delphi に付属)" からだと、一気に 10P Vote できます。
・
仮想 PC ネタ
とりあえずいくつか。
・
Virtual PC for Windows 7
Windows 7 で "XP Mode" を実現するためのもの。
・
Sun VirtualBox
"Virtual PC" の VHD が使える。但し、VirtualBox で使う前に、"Virtual PC" 用の追加機能をアンインストールしておく必要がある。Vista / 7 が実用的な速度で動作する。
・
VirtualBox でネットワークを普通に使う。
普通にやったらゲスト OS からネットワークが使えても、ホスト OS からゲスト OS が見えない。
・
VHD のコンパクション
以前に書いた記事 (2009/01/18) をどうぞ。
・
実機の HDD から仮想 HDD (VHD) を作る
2 つの方法があります。
・
VHD の管理
Virtual PC 2007 の VHD を VirtualBox や "Virtual PC for Windows 7" へ持っていくと、Virtual PC 2007 に戻しても使えない事があるので、原本としての VHD は Virtual PC 2007 形式で保管するといい。
・
複数の OS を管理している場合
FAT32 の OS 未インストール VHD を用意し、すべての 仮想 OS でマウントできるようにしておくと便利。Windows なら D: にしとくとか。
・
プリンタ/複合機ネタ
とりあえずいくつか。
・
Fuji XEROX DocuPrint C2110
USB 接続の場合、アプリケーションからの連続印刷を行うと、最初の一枚しか印刷されないという現象が起きた。スプールの様子を見てみると確かにスプールはされるのだか、最初の一枚以外は取り消されるような動きをする。解決方法は、
・RICOH IPSiO G系 (ジェルジェットプリンタ)
"ERR990" が発生し、指示通りに電源再投入を行っても治らない。解決方法は...
・
BROTHER MyMio
Vista / 7 でスキャナが正しく動作しない。解決方法は...
・
Canon LBP系 (モノクロレーザー)
Windows 7 とかで網掛けが真っ黒に塗り潰される。解決方法は...
・
ね?
講師プロフィールは伊達じゃないでしょ?。
・
地デジキター!
TV 買いました。SHARP LC-32DS6-B。ついでに SHARP BD-HDW43 も買いました。てーか、今日が設置日。
・
駆け込み?
「今月末でエコポイントが終わるから」とかそういう軟弱な理由ではありませんで、前の TV はイカれる寸前で "電源投入後、5 分しないと映らない" という
という状況でしたから。色も赤みが出て補正も効かなかったし。
・
チョイスの理由
32V のフルHD って意外に少ない。選択の余地は少なかった。しかし、いきなりの出費なため、そう高額なものは買えない。そのクセ、奥様のご要望のためレコーダはダブルチューナー機となったのよねぇ...はい、頑張って働きます...orz
・
キッティングの方
相当お年を召した方でしたが、商品知識がスバラシかった。パソコン系の設置に来るヒトは頼りないヒトが多いので (...いあいあ、自宅のパソコンの設置なんて頼んだ事はないですよ。お客さんトコに立会った時の話です) 少々侮っていたのですが、"商品についての言葉のキャッチボール" が完璧でした。マジ、スゲェ!!「アンタ、昔は何やってたんだい?」と尋ねたくなる衝動に何度か駆られました。
・
リモコン番号重複
アナログで使っていた DVD レコーダも SHARP 製だったために、リモコンがカブってしまい 2 つのレコーダが同時に動作しやがんの。マニュアル読んで、古い DVD レコーダの方のリモコン番号を変更した。この DVD レコーダは VHS テープも観れる (もちろん DVD への変換も) ので、まだ捨てられない。
・
パソコン系の設置に来るヒトは頼りないヒトが多い
お客さんから電話があった(from 東京)。光回線に変えたのだが、ルータがうまく設定できないという。取り付けに来ていた業者さんと電話でやりとりしていたが、話を聞く限りでは DNS がうまくいってないっぽい。
|
業者さん...ドンマイだ。
・
Web ページを簡単に改ざんする方法 (嘘)
・
熊本・八代市で化学製品のプラントなどがある工場で火災発生
えーと、
|
|
|
|
...そりゃ、アタシの母校だよ!!
・
BSoD 0x00000116
Vista /7 で発生する。相性だと割り切って、他のグラボ試した方がいいかも。現時点での原因究明は時間の無駄のように思える。"Microsoft Update カタログ (要IE)" で、Microsoft のドライバを検索し、インストールしてみる。コレでも、メーカー最新ドライバでも症状が改善しないならアキラメロン。デュアルディスプレイ環境で起きやすいようだ。
・
Windows Vista 起動時にプログレスバー表示から先に進まない (でもセーフモードでは起動する)
解決方法。
なお、IPv6 を無効にする解決方法を採る場合には devcon を叩く必要はない。
・
Migrating Legacy Apps to Unicode-enabled Delphi 2010
3 つのセッションがありますが、日本時間だと 25 日以降です。
・
エコポイント
先日「駆け込み云々...」と書いたが、平成21年度第2次補正予算成立に伴ない、エコポイント制度は 2010/12/31 まで延長 になっている模様。
"エコポイント申請書の簡略化" とかも盛り込まれているが、確かに現行の申請書は分かりにくいと思う。ま、エコポイント制度自体が分かりにくいのだけれども。
・
RAD Studio 2010 Migration Center
Delphi 2009 / 2010 へ移行するための資料が揃っている...つーか、Migrating Legacy Apps to Unicode-enabled Delphi 2010 のリンクから飛んでこのページの存在を知った。
このページでは、"Delphi Unicode Migration for Mere Mortals" がダウンロードできる(右上にある)。38 ページの PDF なのだけれどもスライドではないので、かなり内容は濃い。"Delphi in a Unicode World" と合わせて読めば Unicode アプリケーション移行の大筋は理解できると思う。
あえて注文を付けるなら、両者とも "サロゲートペアを結合文字列の類と同一視している" フシがある事だ。もちろんそんな事は明言していないし、サロゲートペアと結合文字列は別のトピックにはなっているのだが、"具体的にどうやってサロゲートペアを扱うか?" というのは触れられておらず、結果的に「1 文字が複数のエレメントで構成される事があるから注意ね!」で終わっている。ElementToCharLen() や UCS4String という単語が出てくるには出てくるのだが、この辺りの解説が欲しいトコロだ。
え?「お前も説明してないだろ」って?やだなぁ、"Delphi 2009 と Unicode : 番外編 (サロゲートペア) " という BDN の記事内に、RTL のみで作られた Copy_S() というコードポイント単位で文字列操作するサンプルもあるし、何より、MECSUtils があるじゃないですか。
・
ちなみに。
Marco Cantu 氏の "Delphi 2009 Handbook" では、"コードポイントを扱う方法" 的な解説があるが、それでも充分だとは思えない。
そういえば、"Delphi 2009 Handbook" の中で TUTF32Encoding というエンコーディングクラスのサンプルがあるが、折角なので totonica 氏の UCS4Encoding と何が違うか述べておこう。
簡単に言えば TUTF32Encoding はサロゲートペアが含まれる文字列では正しく動作しない。TUTF32Encoding 自体にバグがある訳ではなく、内部で UnicodeStringFrom(To)UCS4String() を使っているのが原因。先日も書いたが、この関数にはバグがある。UCS4Encoding は、UnicodeStringFrom(To)UCS4String() ではなく、ConvertFrom(To)Utf32() を使っているため、サロゲートペアを含む文字列でも正しく処理できる。
・
Migrating Legacy Apps to Unicode-enabled Delphi 2010
12:00 のリアルタイムは無理だったので、23:00 の再配信を視聴。再配信な上、現地では午前中なために参加者はそれ程多くはなかった。基本的には "Delphi Unicode Migration for Mere Mortals" を踏襲している。ただ、非常に気になった事が一点だけある。
UTF-16 のエレメントは 16bit で、1 WORD なのだけれども、セッション中では "Code unit(s)" という語句で語られる。UTF-16 の 1 エレメントをバイト単位で表現しているのだ ("Code unit = 2 バイト" というニュアンスになっている)。"UTF-16 をどうしてもバイト列で考えたいらしい" が、サロゲートペアやコードポイント、結合文字列の理解が難しくなるので "Code unite(s)" という言い回しはやめた方がいいと思う...UCS-2 / UCS-4 に於いてなら意味は通ると思うが。
あと、Unicode へのマイグレーションというお題なのであれば、AnsiString 系の話はもう少し短くてもよかったように思う。むしろ、その分の時間を Unicode 関連に充てて欲しかったかな...正規化とかフォント関係とか。それでも、"やはり他のヒトのセッションというのは非常に参考になるものだな" と思った。
なお、セッションのスライドは http://cc.embarcadero.com/item/27646 からダウンロード可能となっている。
・
Delphi Books By Country
Cantu さんの本は日本では売れてないらしい...つーか、ハンドブック系の "PDF の売上" で、しかもここ 3 ヶ月の事じゃん。
2009 / 2010 の正規版ユーザは PDF 版が DL 可能だし、それ以外のユーザがあえて PDF 版を買うとは思えないんだけど...?PDF 版をどこから買えばいいのかも判りにくいし。
・
Migrating Legacy Applications to Unicode-enabled Delphi 2010
ちょっとだけ揚げ足取りを。不快に思ったら今回の記事は読み飛ばして下さいね。
・
結合文字列は 2 つのコードポイントで表されるとは限らない
|
・
UTF-8 には 3 バイト文字もある
|
・
UTF-16 のエレメントは WORD 単位で考えるべき
|
なお、"Code Unit" とは Unicode で "符号単位" を意味し、UTF-8 であれば、8bit、UTF-16 なら 16bit、UTF-32 なら 32bit が "Code Unit Size" となる。Delphi では 文字構成要素を "エレメント" と記述しているが、"Code Unit" と "エレメント"、"Code Unit Size" と "エレメントサイズ" は同義である (エレメント数ではない)。
この後にサロゲートペアの話が続くのだが、UTF-8 の説明との整合性を取るには "UTF-16 encodes code points using 2 or 4 bytes." と記述すべきかもしれない。もちろん "バイト" という表現には賛同しかねるけれど。
・
UTF-32 のエレメントは DWORD 単位で考えるべき
|
・
理解できる?
|
BDN の記事である "文字列とエレメント" や "Delphi 2009 と 文字列型" をちゃんと読めば混乱は起きないと思う。なお、"エレメント" という概念は、Delphi の RTL で使われているもので、Unicode 用語ではない。但し、用語として "エレメント" を用いると ANSI もまとめて説明できるので話が早い。
・
これは Typo です (後に出てくるソースコードでは正しいので)
|
|
・
全体的に
"バイト" という表現が多いように見受けられる。UTF-8 であればそれでも構わないのだが、UnicodeString (UTF-16) で "バイト" という表現はいかがなものかと思う。
|
英語が堪能なヒトの見解が聞きたい。
・
"Code Unit" と "Element"
"Code Unit Size" の単位はあくまでも ビット数であり、バイト数ではない。以下の表は Unicode.org の資料 を改変したものである。
Name | UTF-8 | UCS-2 | UTF-16 | UTF-16BE | UTF-16LE | UTF-32 | UTF-32BE | UTF-32LE |
Smallest code point | 0000 | 0000 | 0000 | 0000 | 0000 | 0000 | 0000 | 0000 |
Largest code point | 10FFFF | FFFF | 10FFFF | 10FFFF | 10FFFF | 10FFFF | 10FFFF | 10FFFF |
Code unit size (Element size) | 8 bits | 16 bits | 16 bits | 16 bits | 16 bits | 32 bits | 32 bits | 32 bits |
Byte order | N/A | <BOM> | <BOM> | big-endian | little-endian | <BOM> | big-endian | little-endian |
Fewest bytes per character | 1 | 2 | 2 | 2 | 2 | 4 | 4 | 4 |
Fewest elements per character | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
Most bytes per character | 4 | 2 | 4 | 4 | 4 | 4 | 4 | 4 |
Most elements per character | 4 | 1 | 2 | 2 | 2 | 1 | 1 | 1 |
"エレメント (Code Unit)" で説明すると楽なのに。"バイト" で説明するから "Fewest bytes per character" なんてのが必要になってしまう。「"バイトで表さないと UTF-8 のデメリットが見えてしまう" から UTF-8 推進派がわざわざバイト数表記にしている」 とか陰謀説を妄想しちゃったり...もちろん、そういう理由じゃないのだろうけれど。
結局の所、処理単位は "バイト" ではなく "エレメント (Code Unit)" なのだから (UTF-8 なら "バイト" でもいいだろうけど) ソースコードでの説明はエレメント (Code Unit) で行った方がいいと思う。
何を問題視しているのかと言うと、"RTL での実装と異なる説明をしているから" である。UnicodeString はバイト単位で処理されている訳ではないのだから、"バイト" という単語を簡単に使うべきではないと思う。D2009 で最初に使われた "エレメント" という概念を 「ANSI も Unicode もまとめて説明できる...うまい事を考えたなぁ」 と感心しただけに、ドキュメントやセミナー等のセッションで、未だにバイト単位での説明が行われる事に対しては 「何でそうなるの?」 という気持ちになってしまう。
ちなみに、"エレメント" という言葉を借りないと、ANSI と Unicode で言い換えが発生してしまう。"Code Unit" で統一してもいいのだけれど、本来は Unicode の用語なので ANSI に対して用いるには適さない場合がある。
BACK | 古いのを読む | 新しいのを読む |