自動車の「自」

前回のエントリーで、自動車の話がでました。
自動車の「自動」ってなんでしょうね。
駆動部分を機械(エンジン)で回転させるから「自動」「運転」「車」　ですかね。
単純に「automobile」の直訳かな。「自分で動く」になるので、「自動」か。この場合の「自」は機械本体を意味しますね。

では、自転車は? 勿論、自転する車ではない。、ペダルを人力で漕ぐので、「人力」車?
立たそうとしても、自ら転ぶから、自転車?
人が転がす車だから、この場合の「自」は操縦者か。
手動扉の「手」は操縦者のことですね。
タクシーの「自動ドア」は? 運転手が手動で開閉しますが、乗客にとって自動ドアです。この場合の「自」は利用者か。でも利用者が動かしていないしなぁ。
開発していて、「フラグを手動でセットする」といった会話をしますが、コーディング時点では、キーボードから手動で入力しますが、フラグセットは自動です。

会話で出てくる「自分はxxxです」の「自分」は一人称です。でも、大阪周辺では、二人称としても使います。
「自分なぁ。こんなことしたらアカンやん。自分だったら、しないよ。」これて意味が通じるから不思議です。
この場合の「自」は?
自然にの自は「ひとりでに・勝手に」かな。ならば、自動車は、勝手に動く車? 適切に動く車が欲しい..となりますね。
無意識に使い分けてますが、納得できる説明に出会わないなぁ。

脱線しますか、販売代理店は、代理で販売する店。 なのに、旅行代理店は代理で旅行に行ってくれる店ではない。
この使い分けって、説明可能なんだろうか、まず、動作があって、それを表現する用語が生まれたのでしょうね。個々の辻褄を考える余地はなかったのでしょうね。
閑話休題

自動読書機なんて、完成しても面白くないだろうな。
仕様書を書けば、自動コーディングする機械は、昔から試行錯誤されてますね。
ストーリー原案を話せば、自動作文機が執筆してくれる?........欲しくないなぁ。

冷蔵庫は二重表現?

一般文章でも、仕様書の文書でも、「二重表現(重複表現)」はおかしいとされます。
でも、二重表現が全てダメかといえば、そうでもない。それに関しては、別途エントリーします。
二重表現で彷徨していると、「冷蔵庫」って二重表現がありました。
どちらも意見も、それなりに説得力がありますね。
そもそも、「冷蔵庫」で一つの語とて認識していたので、語の構成要素を分解したことがありませんでした。
「洗濯機」「掃除機」は、「xxxする機械」なのでわかりやすい。なぜ、冷やす機械だから「冷蔵機」にならなかったのか。
テレビ受像機、空調機、録音機.....機が付くモノが多いなぁ。
　初期の冷蔵庫は、電気製品ではなく、上部に氷を入れて、下部に「冷やして貯蔵するもの」を入れました。下部が(倉)庫ですね。
なので、「冷貯蔵」庫=>冷蔵庫 .....こじつけ御免。
洗濯機や掃除機は、電化する以前の相当品と電化後では、機能・動作が異なるので、xxx機となったのでしょうか。
冷蔵庫は、電気化以前、以後も機能・動作が同じなので「冷蔵庫」のまま残ったのではと類推。

電気冷蔵庫はありますね。ガス冷蔵庫と識別する必要からでしょう。
電気テレビとはいいません。電気に限られるからでしょう。
電気照明器具は電気スタンドって言いますね。ガス灯があったからでしょうか。
浅草に「電気ブラン」があります。電気とは無縁ですが。
ある程度の命名規則はあるようですね。

文字列列挙体がほしい

public enum 仕訳区分
{
出金=0,
入金=1,
振替=2,
}
など、区分値が整数のときは、 enumが重宝します。
でも、区分値が文字のときは、使えません。新規設計ならば、区分値を数値で設計できますが、既存のコード体系が、文字コードで構築されているケースは、如何ともできません。
次のような列挙体が欲しい。

public enum 仕訳区分
{
出金="O",
入金="I",
振替="C",
}

周囲のソースを見ると
const string 仕訳区分_出金="O";
const string 仕訳区分_入金="I";
const string 仕訳区分_仕訳="C";

const string 性別区分_男="M";
const string 性別区分_女="F";

のように、xxx区分の要素を平面的に列挙しているケースが多い。
でも、xxx区分で一塊だから、同格列挙するのは、引っ掛かります。
そこで、
public class 文字列_列挙体
{
public string Value;
public 文字列_列挙体(string _value)
{
Type t = this.GetType();
BindingFlags bf = BindingFlags.Static | BindingFlags.Public;
foreach (FieldInfo f in t.GetFields(bf))
{
if (_value == (string)f.GetValue(this))
{
Value = _value;
return;
}
}
throw new Exception(this.GetType().Name + "に含まれない値[" + _value + "]でインスタンス化されました");
}
}
を作ってみました。
public class 仕訳区分 : 文字列_列挙体
{
public 仕訳区分(string value) : base(value) { }
public const string 出金 = "O";
public const string 入金 = "I";
public const string 振替 = "C";
}

使用例

仕訳区分 sk = new 仕訳区分( 仕訳区分.入金);
MessageBox.Show(sk.Value);

カスタム属性で実装する手もありますね。
どちらにしても、野暮ったさが残ります。

文字列Enumが欲しい!!!

バックシャン

古い人との会話のなかで、「バックシャン」という単語がでました。

なんのこと? 確認するタイミングを掴めず，お開きになりました。

「朝シャン」かあるから、その類だろう。

散髪屋では前向きシャンプーなので、「フロント・シャンプー」

美容院では仰向けシャンプーなので「バック・シャンプー」....だろうっと勝手に解釈した。



ググってみると、面白いページを見つけた。    日本語俗語辞書

なんと、Back + schon  ( 英単語 + ドイツ語単語) の和製英語(?)で。　「後姿のみ美人」のことらしい。対語に「トイメンシャン」があるのが面白い。

当時の用語では「モガ」「モボ」しか知らなかったので、新鮮でした。(モガ:モダンガール、モボ:モダンボーイ)

でも、英単語+ドイツ語単語で合成語を作るなんて、当時のほうがセンスがよかったのかもしれませんね。

俗語は、何時の世も、生まれては消えて行きます。流行したから生き残るとは限りません。生き残る要因ってなんでしょうね。

MDBはx86下で使える

前々回のエントリーで頂いたコメントを追試しました。

プラットフォームターゲットの指定は
C#では、 ビルドの頁に　「プラットフォーム ターゲット」欄があります。
VBでは、コンパイルの頁の「詳細コンパイルオプション」の副頁を開くと「ターゲットCPU」欄があります。

同じ .NET言語なんだから、用語を統一してほしいな......はさておいて。

頂いたコメントに準じて、確認しました。(Visual studio 2005 VB)
Dim conn As New System.Data.OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=.\test.mdb")
conn.Open()
Dim da As New System.Data.OleDb.OleDbDataAdapter("select * from 名簿", conn)
Dim ds As New System.Data.DataSet
da.Fill(ds)
MsgBox(ds.Tables(0).Rows.Count)
conn.Close()

「x64」「Any CPU」下では
・Microsoft.Jet.OLEDB.4.0' プロバイダはローカルのコンピュータに登録されていません。
が出ます。WOW64が働らいていないのか思い、手動で　C:\Windows\SysWOW64\msjter40.dllを参照すると
・C:\Windows\SysWOW64\msjter40.dll' への参照を追加できませんでした。ファイルにアクセスできて、有効なアセンブリであること、または COM コンポーネントであることを確認してください。
となります。

「x86」下では、ご指摘のように動作します。

VB6の開発環境がないので、確認できないのですが、 MDBを使っているアプリを走らせると「データベースアクセスに失敗しました。」と出る。
アプリで出しているメッセージのようなので、詳細は判りません。
VBAで
Set db = OpenDatabase("C:\AccessVBA事典\Sample.mdb")
と書くと、動作する。

VBAは x86なので　納得です。 x64.dllは呼べない。

ということは、x64OS下のx64下で、MDBを使うには、X86モードで開発してリンクするか、VBAを介して使うことになりますね。
そこまでして、使う意義があるかどうがてすが、MDB文化の資産って、多いようです(私ま回り)。異なるDBに置換する工数を考えたら、、MDBを使い続けるほうがマシか。
8G/16Gメモリを実装した機械も出回るようになった現在、 x86資産が足枷になるのも、時の流れながれか。
Itaniumは何時の間にか消え去っています。xeonも、あまり話題になりませんね。Itaniumモードで作成したアブは、どうなるんでしょうね。

黒カレー

阪神地区は、沖縄出身者が多いためか、沖縄料理店が点在しています。
先日入った店に「沖縄名物・黒カレー」というのがありました。
ルーが真っ黒で、見かけは、うーん。良くは見えない。
味は、癖があるが、酸味のつよい、南地方の香辛料がキツかった。
でも、これって名物なのかなぁ。以前の沖縄料理店では、見かけなかった気がします。
同じ店に、「名物七味」という液体七味がありました。これも初見でした。沖縄名物なのかなぁ?

VB6の寿命?

前回、VB6の.NET化に関して書いたのですが、頂いたコメントが気になったので、確認しました。

VB6の標準コントロールをOCXのように書いたのは、間違いでした。Winsockなどのコントロールは ActiveXですね。

件のツールは、 Text,label,Pictureboxなどの標準コントロールも、Wrap.dllに抱えこんで、エミュレート(?)しているようです。

閑話休題。

　VB6はいつまで残るか...VBAが残る限り、VB6文化として残る..という見方は同意です。

VB6自体は、64bit環境でも動作するとのこと。まずは安泰か。

過去に関わったVB6絡みのアプリの多くは、MDBを使用していました。

昔書いたのですが、MDBは 64bit OSでは動作しません。ということは、 VB6が動作しても、アプリは動作しない。WOW64を介せば、使えるとの記事もあるようでずか、どうも芳しくない。

Accessが動作するのだから、なんらかの方法はありそうなのに、対応しないのも解せない話。

ということは、x64_OS時代になる頃が寿命ということでしょうか。

そういえば、 ACCESSは　VSTOの対象外ですね。

私の周囲では、 Excel.VBAに負けないくらい、MDB文化か根付づいています。MSが笛吹くほどには、MSSql(MSDE)への置換は進まないようです。

「MSSqlを導入するには、当PCに常駐ミドルウェアを導入する必要があるが、 MDBだと、コピーするだけで良いので便利」という意見に押されているようです。

XBase系のデータベースは(dBase等)、日本では殆ど見かけなくなりましたが、他国では、使われているらしい。

一度、普及したら、覆すのは難しいのは、世界共通なのかも。