「仕組み」の名前の考え方

名前に関する記事のタイトルがいまいちなのはさすがによくないので、タイトルを直した(2013/7/29)
---

最近ちょっと近くで話題になっていた「名前」の考えていきかたについて整理してみた。

ブランド名のように、独自性を持たせることを目的とするのではなく、後で呼びやすく混乱しないための名前付け。主に「それ」を知る人間同士がその物を識別するために使うための名前のガイドライン。「わかりやすい」「混乱しにくい」名前をつけるにはどう考えていけばいいか、というお話。

自分の立ち位置的に、ソフトウェア設計の視点が強くなってしまうが、仕組みを作る立場であれば似たような話になると思う。

経験がたまれば、更新するかも。

1) 文をそのまま使う

「これは何ですか？（何をするものですか？何をすることですか？）」と聞かれたと想定して、それで出てきた説明文をそのまま呼び名にすることを検討する。「何ですか？」の回答そのものなので、意図が伝わりやすい。長くなりがちだが、明快な説明ができる人間の命名であれば、短いことを上回るメリットがあることが多い。

確認ポイント

使う頻度は高くないか？

使う頻度が少ない（例えば、個別の機能のいちモジュール名だったり、年一回の事務処理の細かい手順のひとつだったり）のであれば、意図が伝わりやすいことのメリットが大きい。 しかし、毎日呼び合うような名前だと、短い名前をつけることを検討したあと、決定したほうがよい。 なぜかというと、ただ呼びやすいだけのあまり考えられていない（混乱しやすい・わかりにくい）名前で呼ばれてしまいやすくなるから。

一部の単語だけピックアップして呼び続けられたりしないか？ピックアップされても混乱はないか？

ピックアップしても区別できないから、本当に汎用な言葉がピックアップされることは少ない。例えば「顧客情報データ」を「データ」と略して呼び続けることは少ない。 しかし、文脈を共有すると選んで呼びやすくなってしまう語がある。例えば「クライアント」とか。 混乱がなければそれでもいいのだけど、混乱することがすでに想定できるのであれば、別の名前をつけてあげるのがよい。

そこから頭字語・略語はできるか？

これでつけてみた名前で、頭文字を取ったらいい感じに呼べる名前だったとか、略したら呼びやすかったりしたら、最初から略はこうです、という形で 明示しておくと混乱がない。一方で、その略語が他と同じ場合、かえって混乱を招くので、そもそも略していない状態でも他の呼び名を検討する。

2) 同じジャンルの意図することそのものの単語を使う

1) のそのまま使うパターンにマッチせず、意図した内容が既に一般的な名前として決まっている場合（「一般的に決まった名前」は以後、「定義された名前」とする）は、それを使うことを検討する。ずばりそのものということなので、ほとんどの場合良いが、安易に使うと大混乱を招くケースがある。

確認ポイント

元の語と明白に異なる意図を持っていないか？

新しくつける名前側が従で、定義された名前のほうが先に来ているようなケースでは、それが前提である以上、異なる意図は存在しにくいので、この名前付けパターンは良い選択である。 例えば、定義された名前が何かの規格で、その規格に乗ることこそ意図されたような場合であれば、それを名前につけるのは、受け取る側の意識付けの意味としても、非常に有効である。 しかし、定義された名前が従の場合、注意が必要である。「これこれはAで、あれそれはB…これってXYZって名前ついてるじゃん！」というケース。 こういった場合、一部の重要な部分が異なる場合がある。例えば、「定義された名前ではそれそれはCなんだけど、自分が考えるのはそれそれはDなんだよね…」といった感じ。 このようなことが名前付けの段階で明らかに分かっている場合は、その名前は使うべきではないことが多い。 なぜかというと、聞いた側は、名前が既に定義されているが故、その定義側の意図のほうを名前に感じてしまうから。 「俺のXYZはそうじゃないんだ！」といっても、最初はいいかもしれないが、よっぽどの強さがないと、元の語の意図を書き換えるのは難しいので、どんどんその意図は薄れて行ってしまう。

元の語に付加したい強い意図は持っていないか？意図を狭めたくはないか？

定義された名前は確かにずばりなんだけれど、もっと範囲を狭めておきたいという意図がある場合は、言葉を付加するなり、別の名前付けをするなりを検討すべき。 そうしておけば、広すぎて何を言っているかわからないという事態を避けられる。

3) 別ジャンルの意図することと関係のある単語を使う

文そのものでも、既存の言葉もない場合は、別ジャンルの近そうな言葉がないかを考える。メタファー/こじつけの世界。
一回目は聞いてもわからないが、わからない故、確認が必要となる。ゆえに、混乱を招きにくい。比喩になっているので、一回認識してしまえば、覚えやすい。

確認ポイント

選んだ言葉から受ける意図が、他の一面と衝突しないか？

単語の持つ意味は一面ではないことがあるので、ある面を見て比喩を選んでも、別の面で衝突している可能性がある。 例えば、固いイメージを与えたいからといって「フライパン」と名付けたとしても、冷たいという意図を併せ持つものだったりすると、「フライパン」の持つ熱せられそうなイメージと衝突するので、混乱を招く。

元のジャンルでその言葉は別の意味を持っていたりしないか？

比喩として使われていたりなどで、すでに使われていないか。強い意図を持ってジャンルの壁を越えてきているので、うっかりこの ケースで意図がバッティングすると、大混乱を招く。

4) 別ジャンルの全く関係ない単語を使う

3)に近いが、名前付けに意図がないので、さらにぱっと見/ぱっと聞きでわかりにくくなるが、混乱も小さくなる。
数が必要な場合に選ぶとよい。

5) 新単語を作る

どうしても困る場合は、新しい言葉を作ってしまうのもひとつ（文を略語化するのもこのパターンの一つなんだけど）。

決めた後の確認

似たような意図の語がすでに用意されていないか？それとの違いは何か？

最初にやるべきだけど、名前をつけることで明確になることもあるので、再度確認する。

似たような単語が既に使われていないか？

別の意図なのに、同じあるいは同じような用語が使われていないか確認する。

Azure WebRole開発で使われるIIS Expressの設定(applicationHost.config)を変更する

Azure WebRole開発で(設定で選択した場合)利用されるIIS Expressの設定を変更する方法がちょっとトリッキーなので記録しておく(Azure SDK 2.0向け…Azureはどんどん変わるので)。このブログでAzureが登場するのは初めてかも。

結論

c:\Program Files\IIS Express\AppServer\applicationHost.configを変更する。

うまくいかなかったら、下に書いた方法で調べるといいかも。

詳細

Web Roleのアプリケーションを開発する際は、開発環境でIIS Expressを使うかIISを使うかをクラウドサービスプロジェクトの設定で選べる。

この設定でIIS Expressを使用するを選んだ場合、IIS Expressが利用される。AzureのIISの設定は、 startup taskでappcmd.exeを叩く(いつもお世話になっているブチザッキさんのブログ)とか、Microsoft.Web.Administartion(NuGet)を使ってC#から変更するといった方法が使えるのだけど、IIS Expressの場合はIISではないので、この方法では設定が反映されない。

IIS Expressの設定ファイルはDocuments\IIS Express\config\applicationHost.config をいじれという情報がWebにある(例えばいつもお世話になっているブチザッキさんのブログ)ので、「これだ!」と思って変更するものの、反映されない。

そこで、Process Explorerでiisexpress.exeのコマンドラインを調べてみると、applicationHost.configの場所が明示的に指定されていることがわかった。

指定されているのがどう見ても一時的なパスなので、もしかして埋め込まれてたりして変えられないのかなーと思ってProcess Monitorで見たら、WaHostBootstrapper.exeがc:\Program Files\IIS Express\AppServer\applicationHost.config を読んで、上記の一時的なパスに書き込んでいることがわかったので、元のファイルを書き換えてみると無事反映された。

めでたしめでたし。
(自分の環境で、「IIS Web サーバーを使用する」で動くようにしろという話ではあるが)

PowerShell での Hyper-V Snapshot操作のまとめ

ポイント(＝罠)がいくつかあるのでまとめた。

Snapshotの一覧を得る

Get-VMSnapshot -VMName [machineName]

唯一なにも考えなくてもいいのがこれ。

Snapshotを作成する

Checkpoint-VM -Name [machineName] -SnapshotName [snapshotName]

Checkpointを見つけるのは無理ゲーすぎる。しかもここはマシン名が-Nameなので注意。このverbいらなくない？

Snapshotに戻す (ロールバックする)

Restore-VMSnapshot -VMName [machineName] -Name (SnapshotName) -Confirm:$true

確認されたくないときは-Confirm:$falseをつける。

Snapshotを削除する

Remove-VMSnapshot -VMName [machineName] -Name [snapshotName] -IncludeAllChildSnapshots

-IncludeAllChildSnapshots がポイント。

Get-VMSnapshotしたものをRemove-VMSnapshotで受けたりもできるが、この4つの名前がわかればget-helpで戦えると思う。

MSBuild Launcher 0.2.1 リリース

MSBuild Launcher 0.2.1を出しました。

一部から希望されていたフォント設定と、MSBuild Launcher自体を管理者として起動する（＝管理者でビルドする）機能が登場。
前者は出力テキストを等幅に設定したいという妥当な話だけど、後者はMSBuild (Launcher)をコンソール出力つきコマンド実行ランチャーとして使うという、まがった使い方のためのもの。

たとえばこんなPowerShellとMSBuildファイルを書くと、特権で処理してその出力をMSBuild Launcherで出せる。繰り返し作業におすすめ。





以下のように、普段はエラーだけど、Adminボタンを押すと、"special work"が出力される。

WinDbgとSOS拡張でVSを使わずに.NETアプリをデバッグ - 異常終了時の調査

.NET Frameworkには「SOS デバッガー拡張」という機能があり、デバッガからCLRの状態を追いかけることができる。これを使うと、重いVisual Studioを使わなくても、WinDbgで.NET Frameworkのアプリケーションをデバッグすることができる。今回は、.NETアプリが異常終了したときにその状態を調べるという方法について。

この役に立たないダイアログも、価値のあるものになるはず。

設定編

1. WinDbgをインストールする

今回はWinDbgを使うことにするので、WinDbgをインストールする。WinDbgをインストールするには「Windows 用デバッグ ツールのダウンロードとインストール」にある通り、WDKあるいはWindows SDKをインストールすればついてくる。途中でコンポーネント選択の画面があるので、デバッガのみ選べば、他のコンポーネントをインストールしないことも可能。

2. 自動デバッガの設定をする

上の「役に立たないダイアログ」の「プログラムをデバッグします」で起動するプログラムを変更する。やりかたは「Configuring Automatic Debugging」に書いてある通り、レジストリキー「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug」にある「Debugger」文字列値を追加/変更し、以下のようにする。

"C:\Program Files\Windows Kits\8.0\Debuggers\x86\windbg.exe" -p %ld -e %ld -g

x64版Windowsの場合は、SOS拡張を利用するには、実行するアプリケーションと同じアーキテクチャのwindbg.exeを使う必要があるので、上記のキーはx64版のwindbg.exeに向ける。

"C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\windbg.exe" -p %ld -e %ld -g

x86版のアプリを起動したとき向けに、WOW64側のレジストリキー「HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug」の「Debugger」文字列値をx86版windbg.exeに向けておく。

"C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\windbg.exe" -p %ld -e %ld -g

一応、上記のパスにインストールされていた場合（＝Windows8 SDKでWinDbgをデフォルト設定でインストールした場合）に使えるregファイルを置いておいた。
x64用 / x86用

Visual Studioがインストールされている場合、Visual Studioのデバッガを使うようすでに構成されているため、注意が必要（上記の設定をするとこのダイアログからVisual Studioが使えなくなる）。

これで設定は完了。

実行編

MSBuild Launcher v0.1.1には、「存在しないエディタが設定されていると、異常終了する」というバグがあるので、これを例にする。なお、ポイントとなりそうな部分は勝手に太字にしてある。

基本的には、「SOS.dll (SOS デバッガー拡張)」を見てコマンドを選ぶことになる。

1. 異常終了＋デバッガ起動

MSBuild Launcherの「Settings」ボタンをクリックし、「Editor」テキストボックスに存在しないパスを入力する。その後、適当なmsbuildファイルを開き、「Edit」ボタンを押すと、異常終了し、上の役に立たないダイアログが出てくるので、「プログラムをデバッグします」をクリックすると、WinDbgが立ちあがる。ワークスペースを保存するか聞かれるので、Noを選ぶと、以下の画面になる。

2. SOS拡張のロード

上記の状態になったら以下の通り入力する。

0:000> .loadby sos clr

これは「clr.dllの横にあるsos.dllをロードする」という意味。今回のケースではすでにclr.dllがロードされているので、特にメッセージなく終了するはず。なお、「clr」とするのは.NET Framework 4の場合で、.NET Frameworkの2.0/3.xの場合「clr」は「mscorwks」とする。

今回のケースとはずれるが、ロードされていない場合、例えば起動直後の場合、

0:000> sxe ld clr

としてclrのロードで止めるよう設定して

0:000> g

で進めたあと「.loadby～」を行うか、「.load」で直接DLLの場所を指定してもOK（この場合、.NETのバージョンやアーキテクチャに注意する）。

0:000> .load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll

これで、SOS拡張がロードされた。

3. Exceptionの内容を表示する(!pe)

「CLR exception - code e0434352」が出ている通り、Exceptionが発生しているので、最後のExceptionの内容を表示する!pe (!PrintException)を実行する。

0:000> !pe
PDB symbol for clr.dll not loaded
Exception object: 0000000003078d10
Exception type:   System.ComponentModel.Win32Exception
Message:          指定されたファイルが見つかりません。
InnerException:   
StackTrace (generated):
    SP               IP               Function
    00000000001BD130 000007FEEB0CCBF3 System_ni!System.Diagnostics.Process.StartWithShellExecuteEx(System.Diagnostics.ProcessStartInfo)+0x4a3
    00000000001BD220 000007FEEB0CD03C System_ni!System.Diagnostics.Process.Start(System.Diagnostics.ProcessStartInfo)+0x3c
    00000000001BD260 000007FEE9BD1C51 PresentationCore_ni!System.Windows.EventRoute.InvokeHandlersImpl(System.Object, System.Windows.RoutedEventArgs, Boolean)+0x271
    00000000001BD490 000007FEE9BB8BBC PresentationCore_ni!System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject, System.Windows.RoutedEventArgs)+0x15c
    00000000001BD520 000007FEE91EC26D PresentationFramework_ni!System.Windows.Controls.Button.OnClick()+0xad
    00000000001BD590 000007FEE914B868 PresentationFramework_ni!System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(System.Windows.Input.MouseButtonEventArgs)+0x148
（中略）
    00000000001BE9D0 000007FEE85486DF PresentationFramework_ni!System.Windows.Application.RunInternal(System.Windows.Window)+0x12f
    00000000001BEA40 000007FEE8547CEB PresentationFramework_ni!System.Windows.Application.Run()+0xbb
    00000000001BEA90 000007FF0015024F MsbuildLauncher!MsbuildLauncher.App.Main()+0x12f

StackTraceString: 
HResult: 80004005

これでもう「System.Diagnostics.Process.StartWithShellExecuteEx」を呼んだ結果「System.ComponentModel.Win32Exception」が発生し「指定されたファイルが見つかりません。」というメッセージが出ていることがわかった。MSBuild Launcherにおいて「System.Windows.Controls.Button.OnClick」から「System.Diagnostics.Process.Start」を呼ぶところなんて限られてくるので、もうわかったも同然なのだが、もう少し調べてみる。

4. スタックのオブジェクトを一覧する(!dso)

今回の場合「InnerException」がnoneなので、そこは調べられない。SOS拡張では、!dso (!DumpStackObjects)で、スタックのオブジェクトを一覧できるので、表示してみる。

0:000> !dso
OS Thread Id: 0x1208 (0)
RSP/REG          Object           Name
r15              0000000002e69448 System.Windows.Input.NotifyInputEventArgs
00000000001BCE68 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCF08 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCF50 0000000003074ca0 System.Windows.EventRoute
00000000001BCF68 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCF80 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCF98 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BCFA0 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BD030 0000000003074ca0 System.Windows.EventRoute
00000000001BD048 0000000003078db0 System.Text.StringBuilder
00000000001BD080 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BD090 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BD0B0 0000000003074ca0 System.Windows.EventRoute
00000000001BD0B8 0000000002e69448 System.Windows.Input.NotifyInputEventArgs
00000000001BD120 0000000003078c40 Microsoft.Win32.NativeMethods+ShellExecuteInfo
00000000001BD130 0000000003078d10 System.ComponentModel.Win32Exception
00000000001BD168 0000000003078360 System.Windows.RoutedEventArgs
00000000001BD1D0 0000000003078c40 Microsoft.Win32.NativeMethods+ShellExecuteInfo
00000000001BD1F8 0000000003078860 System.Diagnostics.ProcessStartInfo
00000000001BD200 0000000003078360 System.Windows.RoutedEventArgs
00000000001BD210 0000000003078b28 System.Diagnostics.Process
00000000001BD220 0000000003078b28 System.Diagnostics.Process
（略）

太字の 「System.Diagnostics.ProcessStartInfo」オブジェクトを見ればもうすこしわかりそうなので、表示してみることにする。

5. オブジェクトの内容を表示する(!do)

オブジェクトの内容を表示するには、!do (!DumpObj)コマンドを使う。引数には、先程の「System.Diagnostics.ProcessStartInfo」のオブジェクトアドレスを指定する。

0:000> !do 0000000003078860
Name:        System.Diagnostics.ProcessStartInfo
MethodTable: 000007feeab807a0
EEClass:     000007feea86a628
Size:        128(0x80) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007feeb866738  4002fc9        8        System.String  0 instance 0000000003078808 fileName
000007feeb866738  4002fca       10        System.String  0 instance 0000000003078aa8 arguments
000007feeb866738  4002fcb       18        System.String  0 instance 0000000000000000 directory
000007feeb866738  4002fcc       20        System.String  0 instance 0000000000000000 verb
000007feeabb2ae8  4002fcd       68         System.Int32  1 instance                0 windowStyle
000007feeb86d450  4002fce       6c       System.Boolean  1 instance                0 errorDialog
000007feeb873318  4002fcf       60        System.IntPtr  1 instance                0 errorDialogParentHandle
000007feeb86d450  4002fd0       6d       System.Boolean  1 instance                1 useShellExecute
000007feeb866738  4002fd1       28        System.String  0 instance 0000000000000000 userName
000007feeb866738  4002fd2       30        System.String  0 instance 0000000000000000 domain
000007feeb87e6d0  4002fd3       38 ...rity.SecureString  0 instance 0000000000000000 password
000007feeb86d450  4002fd4       6e       System.Boolean  1 instance                0 loadUserProfile
000007feeb86d450  4002fd5       6f       System.Boolean  1 instance                0 redirectStandardInput
000007feeb86d450  4002fd6       70       System.Boolean  1 instance                0 redirectStandardOutput
000007feeb86d450  4002fd7       71       System.Boolean  1 instance                0 redirectStandardError
000007feeb873738  4002fd8       40 System.Text.Encoding  0 instance 0000000000000000 standardOutputEncoding
000007feeb873738  4002fd9       48 System.Text.Encoding  0 instance 0000000000000000 standardErrorEncoding
000007feeb86d450  4002fda       72       System.Boolean  1 instance                0 createNoWindow
000007feeb887510  4002fdb       50 System.WeakReference  0 instance 0000000000000000 weakParentProcess
000007feeab80948  4002fdc       58 ....StringDictionary  0 instance 0000000000000000 environmentVariables

「fileName」が使えそうなので、さらに表示してみる。

0:000> !do 0000000003078808
Name:        System.String
MethodTable: 000007feeb866738
EEClass:     000007feeb3eed68
Size:        86(0x56) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String:      C:\Windows\invalid-notepad.exe
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007feeb86c620  4000103        8         System.Int32  1 instance               30 m_stringLength
000007feeb86b160  4000104        c          System.Char  1 instance               43 m_firstChar
000007feeb866738  4000105       10        System.String  0   shared           static Empty
                                 >> Domain:Value  00000000002dafa0:0000000002a11420 <<

これで、「C:\Windows\invalid-notepad.exe」という文字列がfileNameに入っていることがわかった。これでは実行できそうもない。

---
と、このような感じで、異常終了時の例外情報を調べるくらいならわりと簡単にできる。.NETプログラマなら覚えておくのがおすすめ。

本当は、AppDomainの中を旅するだけの機能もついているのだけど、それはまた機会があれば。

Loqui 0.5.5リリース/LoquiのISO-2022-JP半自前変換の仕組み

Loqui 0.5.5を出しました。受信時に行なっていたISO-2022-JPの半自前変換を、送信時にも行うようにしました。ただし、受信時と異なり、「半角カナ」などの文字は、エラーにします。

これもまたSolaris用で、Solaris iconvでUTF-8からISO-2022-JPに変換すると、IRCNet的に困ったエスケープシーケンスをつけてしまうことへの対応です。Solarisで起きる現象については、この一連のスレッドにまとまっています（もう少しするとopensolaris.orgがなくなるので消えてしまうのですが…）

GNU iconvではこのようなことがないので、Linuxユーザの方は今までのままで大丈夫です（0.5.5からLinuxでも自前になるので、かえってあやしいかもしれません。うまく変換できていたのにいかなくなったケースがあれば教えてもらえると助かります。）

さて、せっかくなのでずっと前から実装されていた半自前変換について書いておこうと思います。UTF-8⇔ISO-2022-JP変換をする人の参考になれば。（パフォーマンスはよくないし、ISO-2022-JP-2004なども視野に入れるとやることが増えるので、対応できるケースは限られるのですが…）

Loquiの半自前UTF-8⇔ISO-2022-JP変換

Loquiでは、アカウント設定の「コード」の「一覧から選択する」で「Japanese」を選んだ場合、あるいは「ロケール情報から自動判定する」を選んで「ja_JP」から始まるlocaleで利用している場合、（ただのiconv呼び出しでない）ISO-2022-JP向けの文字コード変換ロジックが動きます。

この変換ロジックはいわゆる「半角カナ」や機種依存文字（の一部：NEC特殊文字(13区)）を受信しても化けずに表示させるためのものなのですが、ざっくり言うと、「iconvが失敗しそうな文字は自前で変換」「そうでない文字はiconvに変換してもらう」（半自前変換）という処理になっています。ただし、以下の図のような、ちょっと変わった流れをしています。

Gtk+(2以降)は、画面に表示するためにUTF-8を要求するのですが、日本語でIRCを使おうとすると、ISO-2022-JPを使っていることがあるので、この場合ISO-2022-JPからUTF-8に変換しないといけません。pureにISO-2022-JPのバイト列が来るならGLibのiconv wrapperでさくっと変換するだけで良いのですが、先の「半角カナ」があったりするので、手を入れないといけないわけです。

まぁ、変換処理を自前で持とう、という話になるのですが、ISO-2022-JPは漢字にJIS X 0208という文字セットを使っているのに対し、UTF-8はUnicodeなので、基本的には1文字1文字の変換テーブルを持つ必要があり、いろいろな意味でちょっとつらいです。そのため、「特殊な対応が必要な文字だけ自前で変換し、そうでないものはiconvに変換してもらう」というアプローチを考えます。

ところが、そうすると1文字1文字変換する必要がでてきますが、困ったことにISO-2022-JPは「ここからJIS X 0208の漢字だよー」といったような、文字セットの呼び出しがあり、コンテキストに意味をもったエンコーディングなのです。そのため、ISO-2022-JPのバイト列のままiconvに渡そうとすると、特殊な文字が入ってきたりこなかったりして、状態の管理がちょっとしんどくなります。

そこでどうするかというと、いったんISO-2022-JPからEUC-JPに変換します。EUC-JPでもJIS X 0208を使っているので、ISO-2022-JPからは計算式的に変換できる一方で、EUC-JPはISO-2022-JPと異なり、持続する文字セットの呼び出し（コンテキストの永続的変更）がない（次の文字だけ変更というのはあります）ので、状態の管理が簡単になります。これが上図のようなちょっと変わった流れをしている理由です。

詳しく知りたい方は、loqui_codeconv_tools.cを見てください。

ちなみに、Loquiはこういった言語ごとの特殊ロジックとlocale名の対応テーブルを持っています。10年以上に渡り、日本語以外に使われたことはないのですが…

余談

0.5.5を出してこの図を描こうと思ったら、いつのまにか横道にそれてました。

LibreOffice用カラーテーブルを作った

[2014/12/14追記] LibreOffice 4.2以降では、12色になったことによってこの8色版はまだらになってしまいます。12色対応版をどうぞ。

LibreOfficeは、もうちょっとした表や図を作るには十分なのだけど、デフォルトだと色が選択しにくい。いくつかプリセットがあるもの、どうもしっくりこなかったので、自分で作った。

ダウンロードはここから: https://github.com/sunnyone/locolor/raw/master/sunnyone.soc

作ってみたはいいものの、使い勝手がいいかどうかはまだわからない。

特徴

色相と明度/彩度の2軸で選択可能

デフォルトのカラーテーブルは一部そういう部分もあるものの、表で見たときけっこうまばらなので選びづらい。

順番に並んでいるカラーテーブルもあるのだけど、横8列であることを意識して作られていないので、まだらになってしまっている。

同じ色は縦に並んでいる（似通った濃さは横に並んでいる）

LibreOfficeは一番上のスクリーンショットの通り、2通りの色選択のUIがあり、リスト形式の場合は表の横の順に8つ出てくる。つまり、表の横1列が表示される。オフィスソフトで色を選択するときは、色相よりも先にトーン（濃さだとか）が決まっていることが多いので、同一トーンのものが一画面に出てくると選びやすい（はず）。

使い方

一時的に試してみたい場合は、適当に図を挿入して、右クリック→「領域...」でダイアログが出てくるので、「色」タブからフォルダのアイコンをクリックして出てくるファイル選択の画面でsunnyone.socを選べばOK。

デフォルトの設定にしてしまいたい場合は、LibreOfficeをいったん閉じたあと、configのディレクトリ（最近のWindowsならC:\Users\(Username)\AppData\Roaming\LibreOffice\4\user\config）のstandard.socをバックアップした後、入れ替えればOK。

作りかた

上の配色が気にいらない場合でも、このカラーテーブルの作りかたは参考になるかもしれないので、一応書いておく。

1. 色相を選択する

マンセル環から色をチョイスする。マンセル表色系の色相は、5色とその間の5色、さらに倍…という感じなので、8色はちょっとつらいんだけど、がんばって4色＋補色を選んだ。

2. 彩度/明度を選択する

マンセル表色系では、色相によって最高彩度が違うのでしんどいのだけど、概ね横の三角形の形をしているので、三角形の頂点を決めたあと、間の点を機械的に選んだ（実際はマンセルの等色相面はいびつな形をしているので、本当はない色があるかもしれない）。

詳しくはレポジトリに置いてあるシートを参照。

3. Color::Model::Munsell::Utilを使ってマンセル値からRGB値に変換

マンセル表色系に対応しているライブラリはけっこう少ないのだけど、PerlのColor::Model::Munsell::Utilは対応していたので、これで変換した。
マンセル値は直接RGBにはできないので、テーブルでCIE-XYZに変換して、そこからsRGBに変換している（はず）。
出力はLibreOfficeで使っている簡単なXMLにするだけで、完了。

詳しくはリポジトリに置いてあるスクリプトを参照。

Q&A

なんでPCCSじゃないの？

色彩＋トーン（彩度・明度）という考え方は、まさしくPCCS向けなのだけど、PCCSは（恐らく）物の色向けで、かつトーンの名前が人の感覚でつけられているので、RGBの世界に持ってくると、この手の世界になじみがない自分にはちょっと違和感があった。なので、類似した感じのマンセル表色系で色をチョイスした。

↑これが、「v2」というvトーンの赤、つまりvividなred (4R 4.5 / 14)をRGBに変換した色なんだけど、画面で見るとにぶく見える気がするのよねぇ。

機械的に計算するならHSVのほうがいいんじゃ？

できたあとに思った。実験してみてないのだけど、高明度の色は、HSVで機械的に出したほうがきれいな薄い色になったんじゃないかなーと思ったりもする。

が、マンセル値にしておけば、表記が人の理解できる範囲になると思うので、これはこれでいいかなと思っている。

なんで色を選ぶUIが2種類あるの？

ひとつだったらもう少し作りやすかったのに…