自動車の「自」

前回のエントリーで、自動車の話がでました。
自動車の「自動」ってなんでしょうね。
駆動部分を機械(エンジン)で回転させるから「自動」「運転」「車」　ですかね。
単純に「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等)、日本では殆ど見かけなくなりましたが、他国では、使われているらしい。

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

VB6の.net化

VB6の設計のまま、単純コンバージョンで.net化することの是非は陳腐化したテーマです。

私は、.net思想で設計し直してこそ意味があるので、単純コンバージョンするならVB6のまま使い続けるのが良いと思ってます。

以前の職場を訪問した際、「VB6のシステムをDOT.net化したから見て」といわれて、拝見させてもらった。

ツールを介してコンバージョンしたとのこと。

VSに付随のコンバージョンツールは、ある程度はコンバートしてくれますが、手作業部分は結構残ります。

「手間がかかっただろう」と質問したら、「金はかかったが、手間は殆どかからない。VB6の.NET化はもう怖くない。」と鼻高々。


Code Architects 社（イタリア）のツール 　ここ　

を使ったそうです。(結構な値段らしいです)

　マイグレーション率は高いですね。 Label/TextBoxなどもVB6.OCXをそのままコンバージョンしてくれるので、殆ど手を加えずにコンバージョンしてくれます。



Form上のコントロールは、VB6のコントロールをラップして、実装しています。 旧OCXは プロパティ定義も含めて xxx.VBLibrary.dll の形でWrapされるようです。

.net化後にプロパティ変更等のデザイン改変はとても手間がかがり、.net化後に改変するのは、避けたい.....そうです。

それって変なんじゃない。システムに改変は付き物です。なのに成果物が改変し難いって。VB6をラップするだけなので、.netを被ったVB6じゃん......と心で思ってましたが。

それはともかく、見事にラップしているのには、驚かされます。ツールの完成度と製品性能は高いと思います。(私には無縁ですが)

マイグレーション後の成果物をエンドユーザーに「.net化しました」って納品するのも、どうかと思う。ミスリードだと思う。当の開発業者が「.net化した」と信じているなら猶更まずい。



VB6の新規案件もあるくらいです。VB6は、VB6のまま使い続けましょう。

戸惑う自販機

昼休みによく行くショッピングアーケードの休憩所の紙コップ式ジュースの自販機でのこと。

該当金額を投入して、選択ボタンを押したが、出てこない。アレ! 、ボタンはまだ点灯しているので、

再度押してみたが、出てこない。

おかしいなぁと思いながら、よく見ると、赤ランプが点灯しているのだか、

よく見るとランプトップに「売切」の文字がある。品切れでした。他の商品を選びましたか、

戸惑ってしまったのは私がドジだからか。

　近くのペンチに座って昼食をしていたら、一人が「あれ。出ないよ」と叫んで、

直近の店の店員に「でないやんか」と苦情を言っている。

店員は「当店の管理物ではないのですが。どういう状態でしようか。」

(一見して)

「品切れてますね。他を選んで下さい」とガイドしていました。

その人は「わからへんやん」とブツブツいってました。 (私だけじゃなかったと安堵)

３０分のあいだに、4組の人々が、「出ない」と直近の同じ店員に、苦情を言っている。明らかに迷惑そう。



UIに問題がありそう。



売価が複数ある飲料水などの自販機(80円、90円、100円等)は、投入額が、売価を超過した時点で、購入可能ランプが点灯します。

この購入可能ランプが、赤●ランプになっています。商品選択ボタンの左に配置されています。

売り切れの場合は、商品選択ボタンの右がわの赤楕円ランブが点灯しますが、ランプトップに小さく「売切」と刻印してます。

しかし、ぼやっとみてたら、識別できないものです。

問題点は・・・購入可能ランブも売り切れランプも共に、赤ランプを用いていることですね。

赤は、禁止や中止や録音などの、注意の必要な行為の場面に用いることが多いです。

一方で、「あたたかい飲料」を赤、 冷たい飲料を青(給湯器もそうですね)と識別します。

通電状態は、緑の機種と、赤の機種の両方ありますね。

「赤」に複数の意味を持たせるのは、混乱すると思いますが、統一はできないですね。

売り切れ状態は、赤ランプ点灯でなく、グレイアウトするなど、他の表現が適していると思った次第。

タバコ、そこまでするなら全面禁止したら?

タバコが値上げになって数日経ちました。愛煙家の方々いかがお過ごしでしょうか。

「健康の為吸いすぎに注意...」という申し訳程度の文言掲載の日本とは対照的に、
ここやここのように、汚れた灰の患部を印刷するそうな。
現物の写真が見つけられませんでしたが、テレビで一部紹介されてましたが、かなりエグイ写真でした。

まるで害虫扱いです。そこまで警告するなら、準麻薬扱いにして、禁止したほうがよいように思います。

吸わなくなって数十年経ちタバコとは無縁なので、猶更そう思います。ポイ捨てや寝タバコによる火事も無くなるし。

税収という大人の事情がありそうですが、病気予備軍を作り、税を徴収している....と見るのは穿った見方なのか。



そばで吸われると結構煙たいし、歩行タバコの人と並列に歩くと、辛いものがあります。食堂で食後の一服をされると、食事が不味くなります。
喫煙の自由を奪うのは、我儘でしょうが、迷惑行為に思う人が居るので限定された、喫煙場所で吸って欲しい。(お願い)

タバコの自販機

(前回、前々回のエントリーが継続中なんですが、ネタの時期が今日なので)

ちなみに、私は吸いません。社会デビュー時に禁煙...ウニュウニュ。

今日からタバコが値上げされます。上げ幅が大きいので、この機会に禁煙する人もいるとか。

大量に買っている人がいるそうですが、賞味期限が切れると、明確に味が落ちるようです。乾燥具合の影響なんですかね。

店頭販売なら人を介するので、値上の作業は少ないです。
各所に存在するタバコ自販機の値上げは、個体事に人的作業で設定していくものだと思ってました。以前の値上げのときは、その作業に時間差があり、値上げ当日でも、値上げ前の価格で買えたらしいです。
でも、今回は、0:00丁度に一斉に値上げするそうです。自販機のプログラムに組み込まれていて、マイコン処理か、タイマー処理で値上げ処理がされるそうです。
個別に張り出している価格表は新旧表示のままでした。(近くの自販機では)

駅の50円のティッシュ販売機は純粋な機械式ですが、多くの自販機は、端末機能型になっているのでしょうね。
自販機自体が、機内の在庫を管理して、補充量を管理者にメール通知している...そうなっている気がします。

そこまでしなくても......人から仕事を奪うなよ...と思わないでもない.....複雑な今。