自動車の「自」

前回のエントリーで、自動車の話がでました。
自動車の「自動」ってなんでしょうね。
駆動部分を機械(エンジン)で回転させるから「自動」「運転」「車」　ですかね。
単純に「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円のティッシュ販売機は純粋な機械式ですが、多くの自販機は、端末機能型になっているのでしょうね。
自販機自体が、機内の在庫を管理して、補充量を管理者にメール通知している...そうなっている気がします。

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

フロッピー改竄?

大阪地検で起こっているフロッピー偽造問題で、あれこれ言われています。
http://117vcc002.blog12.fc2.com/blog-entry-89.html などなど
マスコミは絵になる部分しか報道しないので、実態が見えないです。

・フロッピー内のデータの作成日が重大な意味を持つ

・作成日は特殊なソフトを用いないと更新されない

・作成日は簡単に変更できる/できない。

・作成日は特殊技術を持った人なら簡単に変更できる。

・作成日を偽造して、立件を図った。
うーん。的外しなメントが多いと思った。

世間一般の意識はそうかもしれませんが、情報提供者であるマスコミは、一寸詳しい人に確認してから記事にして欲しい。

そもそも、電子データの作成日に「証拠能力」があるいう前提がおかしい。意図しなくても、CPU日付を変えるだけで、どうにでもできるし、変更日より作成日を未来にすることも可能です。

写真に埋め込まれる日付にしても、カメラ側の設定で変わるのは、知れ渡っていますよね。
「編集が可能だから、ビデオ資料は証拠能力がない」としているのは法曹界ですよね。その法曹界がデータファイルの作成日を証拠能力ありとするのだろうか。
マジでそう考えているなら、寒いなぁ。
　もっとドロドロしたことを隠すために、作成日問題で目くらまししているのだろうか(そういった深読みは外れますが)

随時に変更可能な日付属性の一点だけで、有罪/無罪/冤罪が左右されたのでは、たまったものではありません。

「作成日はこのように改竄された」ではなく、証拠能力の高低や電子データの信憑性をキチンと伝えて欲しいと思った。
当の検事が、何の意図でこの行動をしたのが皆目判らない。事件を捏造するにしては、お粗末すぎるので、なんか闇問題を感じてしまう。

国内最高齢

今日は敬老記念日...敬老は常に意識すべきで特定の記念日にすべきでない...という話はさておき。
ニュースでは、「長谷川チヨノさんは、明治２９年１１月２０日生まれの１１３歳で...」と流れてました。
http://www.nhk.or.jp/news/html/20100920/t10014090391000.html

昨今の、行方不明高齢者問題で、「高齢者不明：長崎に２００歳」http://mainichi.jp/select/jiken/news/20100828k0000m040055000c.html

というニュースもあるので、「国内最高齢」の判定基準がよくわからない。>

生存確認できている人の最高齢ならば、生死不明 or 仮想生存の状態が把握できているとも言えそうです。現実には漏れがあったのでしょうね。ならは、113歳を最高齢と判定するのは無理がありそうな気もします。

実際に生存されてなく、死亡届が未提出なので戸籍上の生存なのでしょうが、とっても疑問。

戸籍上生存しているのなら、実在の国内最長老者の決定プロセスは、どのように判断したのでしょうね。

戸籍と住民票の二重管理の矛盾を感じますし、住民登録がしっかりしていれば、今年もあります国政調査の一部の世帯数確認は不要だとも思うのです。

縦割り行政の悪い面かもしれませんね。物議を醸すかもしれませんが、総背番号制にしてIDを発行したほうがスッキリすると思います。
年金制度で実質上、総番号になっているのだから、反対する根拠は薄いとも思うし、弊害よりも不備が引き起こす不公平感のほうが大きいように思います。

高齢者行方不明問題はスッキリしないし、親の死を悪用しているなら猶更後味が悪いです。死体の腐敗臭を誤魔化したというのも不思議だし......
いままで、問題視しなかったのも不思議。見ない振りをしていたのかなぁ。

内部クラスのStatic

C#やVBでネスト構造のクラス(内部クラス)を定義することがあります。そのとき、内部クラス内に静的メンバーを持たしたりします。

public class 外側
    {
        public class 内側
        {
            public static int a;
        }
    }

このスタイルが身についているので、 Javaで、同様にコーディングしたら、コンパイラに怒られました。


●エラー: フィールド a は static として宣言できません。static フィールドは、static またはトップ・レベル型においてのみ宣言できます
意味が理解できず、あちこち頁をめくっていくと、「内部クラスではStaticメンバーは使えない」ですって。
処理系が異なるので、「そんなものだ。」ですが、.net系とJava系でのクラスに対する思想の差を解間みた気がします。


C#をメインにしているので、情けないことにJAVAで書くと混乱してばかりです。JAVA7でプロパティ構文が入る...と楽しみにしてたのですが、どうなったのでしょうね。

漢和辞典 は語学辞典?

英和は「英語」=>「日本語」の変換辞書です。和英、日独、独日....各国とも対になってます。
なのに、「漢和」は有りますが、「和漢」はありません。「漢和辞典は漢字を調べる辞典」と漠然と理解してますが。字面から解釈すると、「漢語=>和語」の辞典になりますよね。

だとすると、「和語=>漢語」の辞典があってしかるべきでは。

漢語は今の中国語と解釈すれば、「日中辞典」「中日辞典」が、該当するのでしょうね。

「漢和辞典」は語学辞典でなく、「漢字」を調べるものでしょう。そのように習った記憶もあります。でも、先人の方が指摘されてるように、大陸生まれの漢字は掲載されてますが、日本生まれの国字の扱いは軽いようです。辞典編集者には「漢和辞典は漢文の理解用の辞典」という意識があるらしいのです。

でも、日常に接する「日本語としての漢字」を調べる時に使いたいというケースが多いと思うのです。そこで「漢和辞典」とは違う「漢字辞典」が最近は出回っているようです。

学生のころ、「漢文」の授業がありましたが、「漢語という語学」という意識はなかったです。「漢文読み下しの日本語」の授業でした。
「漢語」の学習でなく、活字である「漢文」を読むことが重要視されていたんですね。(漢文が素養だと実感しないのはなぜだろう?。)

「英語」も会話教育より「英文」を読むことを重要視しているのは、漢文の学習姿勢が根底にあるのか....と妙に納得。

つゆだくだく

(牛丼常連には常識ネタでなんでしょうね)
牛丼屋でオーダーするとき、「並み(大物でもよいのだけれど)」だけだと、汁が少ない時があります。(店や店員によって量は不定の様です)
汁を多く欲しい時は、「つゆだく」と言えば、多くついでくれます。

もっと多く汁が欲しいとき「つゆだくだく」「つゆだくだくだく」と発注すれば、お茶漬状態にしてくれます。
吉野家、松屋、なか卯、すき屋ともに共通なようですね。業界用語として定着しているのかも。

店員の復唱も「だくだく一丁」のよで。「汁多く」と発注したら「だくだく一丁」と翻訳してくれました。業界用語のようですね。

白黒画像をカラー化

白黒画像をカラー化
坂本竜馬の有名な写真のカラー版を見ました。適当に着色したのだろう...と思っていたのですが、どうも実際に近いらしい。
ググっていくと、カラー化技術の頁を見つけました。 ここ

昭和60年に考案した..とあるので結構昔からあるのですね。

探してみると、カラー化ソフトまで出回っていますね。Photo-Colorizer 2.0などからあるようです。

adobeの頁に 「白黒の画像をカラー化する」がありました。白黒写真から「色相・彩度」特性を抜き出せば、カラー化が可能らしい。

その昔、写真にFFTを適用して成分分析をしたことがありすが、似たような技術なんでしょうかね。違う特性かもしれませんが。
銀板白黒写真が「色相・彩度」を隠し持っているから可能なのかなぁ。RGBで保持するデジタル白黒写真からは無理な気がします。(根拠のない私見です。)

恐竜などの皮膚の色は想定できないらしいですが、特定できる日がくるかも知れませんね。

Cannon MX870

前回、プリンタが壊れた事を書いたのですが、必要に迫られて、急遽購入しました。

至急に必要だったので比較検討する暇がなく、使い慣れたメーカーが無難かなと安易な判断でMX870にしました。

買ってから驚いたのですが、無線ネットワーク対応で、結線なしに、家中のPCから共有できるではありませんか。
スキャナー機能も、プリンタイベントで、スキャナーを単独操作しても、PCがキャッチしてくれる(立ち上げておれば)。
PC非経由で、USBメモリに格納もしてくれる。

その他便利機能がいっぱい。これで、3万弱とは、安くなったものです。(ここのところ、買い物をするたびに「安くなった」と驚いてます。)

ただ、インクの種類が機種によって別々で、今回のは、320/321です。　インクの粒や粘性で、共通化するのは難しいのかもしれませんが、専用インクになるのは、どうも釈然としない。
各社共通規格のインクにすれば、インク単体も安価になるのになぁって思うのです。

携帯本体料金をが通話料で回収しているように、プリンター価格をインクで回収していると思えてなりません。本体が安価なだけに、インクが高く感じます。

プリンタ昇天

プリンタが突如「プリントヘッドの種類が違います。正しいプリントヘッドを装着してください」と表示して、使用不能に。
機種はCanon MP770です。機嫌よく印刷していたのに、紙がジャムったので、給紙部分を開閉しただけなのに。突如と意味不明なメッセージ。
　何度か初期化するものの改善しない。

ググってみると類似の報告はあるものですね。
参考

どうやらプリントヘッドが壊れたらしい。仕方がないのでプリントヘッドを購入しようと探したのですが、置いていない。通販にも該当品がない。
キャノンの頁を探していると、販売終了したらしい。ここ
どうすりゃいいのよ。と問い合わせると、修理依頼すると受け付けてくれるらしい。費用と期間を聞くと、部品代込で最低\12,000は要して、7日から10日掛かるとのこと。

\20,000前後で新品が買える時代に、約5年前の機種を\12,000費やして修理する価値があるか...ないだろうね。
報告記事をみていると、「プリントヘッド」は消耗品のように思える。これの部品販売を中止するなんて、なんか営業方針が見えない。

ダメ元で、プリントヘッドを洗浄してみた。出るは出るはこびりついたインクの山。インクジェットプリンタは、電源を入れた時、各タンクから噴射するらしく、印刷しなくても、インクは減って行きます。その時のインクがへばり付いているのかな。
小一時間かけて、綺麗にしました。いざ装着。ダメでした。同じエラーがでます。

諦めの境地。
プリンタは紙屑製造機と思っていて、極力印刷しないようにしてしてますが、ある程度は印刷しますし、コピー機としても使用する機会が多いので、壊れると困るものですね。

使えないと思われる「市民トイレ」

昔は、公園や街角に公衆トイレを見かけたものですが、最近では減っています。マナーの悪さや、風紀その他の諸々があり、維持に多大な工数が掛かるらしい。
嘆かわしいなぁ...という話は置いといて。
　神戸市や他の都市では、コンビニ等の開放型店舗のトイレを「市民トイレ」という名前の「公衆トイレ」にしています。
年間謝礼金が出るようですが、善意に基づいています。...なのに、トイレットペーパーの盗難が多いって聞きますね....ああ。
http://www.city.kobe.lg.jp/life/town/toilet/info05.html
閑話休題。
利用している電車の駅のトイレも、「市民トイレ」の文字が書かれています。しかし、このトイレ、駅校内なんですよ。
昼間は、駅員さんが常駐しているので、一言声をかけたら、使わせてもらえます。でも近くのコンビニも「市民トイレ」なので、わざわざ構内に入る人は少ないと思います。
夕方以降は無人状態になります。なので、構外の人は使うことができません。
　そもそも、駅のトイレは、半ば公衆トイレ状態なので、「市民トイレ」化する意味は薄いのではないかと思うのです。

トイレの入り口には、「市民トイレです。どなた様もご自由にお使い下さい」と書いてあります。
夕方以降は、無人の自動改札機が立ちはだかって、利用を拒んでいます。不合理を感じるのだが。

サイゼリア CM

イタ飯屋のサイデリア。有名なのに、テレビCMしないんですよね。「CMに投資するより、単価をさげる」と聞きましたが。該当記事はみつけられませんでした。

CMが流れていないのに、知名度は高く、人も結構入っているようです。
　料理単価も確かに安い。........下種の勘繰り.....マックもCMをやめたら、単価を安くできるのでは..とフト思った。

広告費用と効果と単価設定は、単純な計算では成立しないとは思いまずか、マックぐらい知名度が高くなると、CM量を半分にしても、差が出ないように思うが、どうなのだろう。

サイゼリアとは異なる業界のリフォーム関係の「サイデリア」という会社があり(倒産しましたが) こちらのCMが結構インパクトがあり、混同している人もいるようです。

類似名称を利用して、CM効果に結びつけたとしたら、凄い策士な気も....偶然なのでしょうね。
CM効果の金額換算って難しそうだなぁ。

ApplicationException は非推奨です

最近の納品物のソースに、ApplicationException が点在していました。
当初の.netでは、例外はカスタム例外を使うか、汎用的例外(ApplicationException)を使うようにガイドがありました。
FrameWork2 のとき、「潜在バグがあるから、Exceptionを使うように。」とお達しがあり、話題になったように記憶しています。
でも、この手の通達は徹底し難いらしく、知らない開発者もいたり、 FrameWork1.x 時代の保守から入ったりすると、浦島太郎状態になる人もいるようで、当然のように、ApplicationException　を使う人もいたりします。
で、何の不具合たったんだろう。忘却の彼方。
http://csharper.blog57.fc2.com/blog-entry-34.html
が上手く説明されていました。
　途中で非推奨になった技やツールなどは、知らなければ、使い続けることになります。我々が伝えるにしても限度があったり、開発標準がそのようになっていたら、補正ができなかったりします。
ASP.AJAX.Toolあたりも、JQUERYに移行し、非推奨になりましたが、意外と知られてなかったりします。
周知徹底って難しいのかも知れませんね。

エラーを握りつしちゃダメ

VB6システムは、まだまだ現役で、新規開発もあったりします。開発者の思いとは裏腹に。
当然なから、改修の仕事も時折発生するわけです。とあるシステム改修現場でのこと。

「納得できない妙な動作をしています」との訴え。

確かに、業務仕様とは異なる動作をしている。いままで動作していて、急におかしくなるときは、データに起因することが多い。
データを閲覧すると、想定外の規約コードや、桁オーバーの値がチラホラ。

エラーログにもエラー状況は書かれていない。異常データだから、落ちてもよさそうなのに落ちない。

内部仕様書をみても埒が明かないので、ソースを見ることにした。

　　　Public Property Let xxx(ByVal yyy As 区分)
　　　On Error GoTo ErrHandler
　　　 xx区分 = 区分
　　　　 Exit Property
　　　ErrHandler:
　　　End Property
関数やプロパティのすべてに on Error goto ErrHandlerが入っている。これはいい。でも

　　　ErrHandler:
　　　End Property
で握りつぶしている。そりゃないよ。半分ほどは、Logに書いているけど。
　　　ErrHandler:
　　　　　　　Log出力
　　　End Property

これじゃ、正常終了したのかどうか、いちいちログをみなきゃだめだし、ログにもかかれず葬られた処理があるかもしれない。
とりあえず、全部のErrHandler: のあとに、Log出力を咬ませた。
不具合が出る出る......いままで正常とされていたのも、実はおかしかった...というのも発覚。


開発元を捕まえて、文句をいうと、「当時の開発指針に則っています。」との返事。
開発指針には、「各関数には on Error goto ErrHandler を咬ますこと。」と明記はされているが、握りつぶせとは書かれてない!!!
「サラリーマン開発者はプロではないのか」と愚痴りたくもなった。

落ちないシステムは大事だか、不正データの対策は、安全に回避ルーチンに陥るのが望ましいが、結構考慮点が多岐にわたるので、工数増になります。
予算と工期がないとき、素直に落とすほうが、よほど後々のデバッグが楽になります。
どこで落ちたか、解る仕組みの実装するのがプロです。
不確か状態で継続動作するより、落ちたほうがマシと思うのだが。
(*)もちろん、Try catch処理の時も握り潰しちゃだめですよ。

9:00～9:59 6ch , 10:00～11:00 8ch

ビデオ予約で、１時間番組が連続して(他チャンネル)放送される時の予約設定の仕様の件です。

Video業界の共通仕様なのか、我が家の機種固有の仕様なのか、知りません。
9時代の6Chと10時代の8chを連続して録画したいとき、

9:00～10:00 6ch , 10:00～11:00 8ch と指示すると、「時間が重複してます。」と叱られます。

9:00～ 9:59 6ch , 10:00～11:00 8ch と指示すると、正常にOKになります。が。9:59:00～9:59:59の１分間が抜けるようです。

開始<= 動作 <=終了　と解釈しているようです。 連続帯で指定すると、終了1と開始2が同じ時刻指定になります。

開始1 <= 動作 <= 終了1

開始2 <= 動作 <= 終了2

どちらにも、含まれてしまうので、エラーとしているのね。その結果、１分間の録画不能時間帯が生じることに...

単純に
開始1 <= 動作 < 終了1

開始2 <= 動作 < 終了2

にすれば、問題は発生しないと思うのですが、なぜそうしないのだろう。
録画と録画の連続してチューナーの切り替え作ができないから、ワザとGapを入れているのだろうか。それにしたら、1分間のギャップは大きいような。

方向地名など

西xx,東xxという地名は至る所にあるのですが、命名のルールに基準はありません。当初はそれなりの理由があったのでしょうが、今見ると、適当に映ります。

神戸市に東灘区がありますが、字面からは、「灘地域の東」とよめます。しかし、「灘地方」とは、神戸東部、芦屋、西宮、西尼崎の一体です。
もともと、「灘区」が存在していて、本庄村他を合併するとき、「灘区」の東ということで「東灘区」にしたようです。

安易なネーミングは、後日混乱の元になるのは、プログラムにも通じるものを感じます。原住民には馴染みがあり、誤解することはありませんが、他の地域の人のなかには、誤解する人もいるそうです。
誤解といえば、「上越市」に行くのに「上越新幹線」を乗った人がいるらしいです。

こんなのもあった。大東西中の先生に言いたいことは

香西東町 ,香西西町,東葛西 西葛西 なども、「香西」「葛西」が大きくなったので、その地点を中心に東西南北を冠にしたのでしょうが、ややこしい。

「北広島市」は北海道...

大東市と東大阪市も、大阪市の東の意味..でも「大東文化大」は東京。

「西東京市」も最近できましたが、....


東西南北さんと書いて、「よもひろさん、ひがたさん」と読むらしいです。

字面はヤヤコシイですが、日常生活に支障がないのは凄いことだと、妙に感じる次第。
(*)以前類似のエントリーで「西中島南方」のコメントを頂きましたが、まさに安易。

本日は晴天なり

マイクテストでの常套句ですが、無線局運用規則で、試験電波を出すときに使用することになっています。
本来は「It's a fine day」で、そのまま翻訳してますね。

「It's a fine day」の発音には、英語の単語発音の殆どの要素が含まれてるとされています。
この発音の聞き取りやすさで、明瞭に伝わるかどうかのテストができます。

でも「本日は晴天なり」には、日本語発音の要素全ては入ってないので、マイクテストにはならないようです。

この手の用語は、意味を解さずに、直訳したものがあり、本意が伝わらなかったりします。

日本付近を「極東」と言いますか、ヨーロッパから見て、 Far east なだけで、「日本付近」={極東」とするのは、視点が日本ではなくなります。
「6月の花嫁」も、 「June神」に由来するとか、6月は雨が少ないからとか、ヨーロッパ事情が隠れています。日本の６月は梅雨季節なので、日本での「６月の花嫁」は「幸せ感」が薄れそう。

日本人って中華思想に乏しいのかなぁ。

恐竜絶滅と隕石

恐竜の絶滅は隕石が原因...という説があります。
隕石落下による気候変動で恐竜が環境に対応できずに絶滅したという説です。

一部の子供向けの解説書に、恐竜が生息している地域に、空から隕石が降り注ぎ、逃げ惑う姿が描かれています。
直接隕石が恐竜にぶつかり滅んだかの先入観を植え付けられそうです。
この描画は良くないと思います。低学年向けだからこそ、変な先入観を与えてはいけないと思う。

隕石が、恐竜の個体数にぶつかるだけ大量に降り注いだら、地峡自体が壊れていそう。

瞬間に滅亡したとは考えにくく、環境変化に伴い、徐々に個体数が減って行ったと考えるべきでしょう。恐竜個人単位は天寿を全うしたのではなかろうか。

人類が滅亡するときも同様に個体的には天寿を全うすると思う。(核などの愚かな暴発の可能性は..あるにせよ)

「xxxx年に地球が滅亡する」という予言は何時の世もありますが、年単位の変化は殆ど起きなくて、100年から1万年単位で変わっていくものらしい。
それでも、宇宙単位の時系列では瞬間的な出来事です。ですので、一個人が滅亡の瞬間を目撃したり、遭遇することはありえないことでしょう。

「昨今の天候不順は滅亡の兆しだ」と不安を助長するような布教する人がいるそうな。昨今の天候不順が異常気象なのか、1000年単位でみればどうなのか不明です。悪化しているように見えるだけかも知れないし、もっと悪化するかもしれません。不明です。
それだからこそ、変な勧誘に惑わされない知恵が必要だと思うのです。

久々のLinux+ORACLE インストール

何年振りか判らないくらい久しぶりにインストールしました。そのときは、SlackWareで、かなり四苦八苦しましたっけ。

今回は、CentOS 5.5でしたが、簡単になりましたね。隔世の感です。GUIも充実していて、まるでWindowsアプリ・インストールの感覚です。

次にOracle 11gR2も導入しましたが、こちらも、Windows下に導入するのと全く同じ。(設定事が多少ありますが)

Liniuxのハードルも低くなったものですね。

「コンピュータ操作の基本はコマンドだ」と声高々に叫んでも、GUI画面の操作性の誘惑には負けました。「武士は食わねど高楊枝」は所詮やせ我慢か。(使い方、間違ってそうな..ww)

Orcle 11gR2もすんなりインストール完了。ところが、Oracle　クライアント接続でハマりました。

ODPのインスールはすんなり完了し、 SQL*Plusも繋がる。一安心。ところが、 VS2008/VS2010から Oracleに接続てきない。

PATHも(ORACLE_HOME)切っているし、tnsnames.ora　も切ってある。でも繋がらない。どうもの サーバー名と TNS名のバインドができていないらしい。

仕方がないので、 サーバー名に、TNS名を使わず、直接、TNS定義を記述したら、繋がった。

SQL*Plusでは繋がっているから、TNS定義は間違いないだろう。VSからは認識できない。繋がったからいいのだけれど、何故なんだけろう。

過去を振り返ってみると、 ORACLEのセットアップがトラブルなしに完了した経験がない。これもOracle文化なのかなぁ。

「仕組みを理解しないとインストールできない」という時代ではないのね。良いことなんでしょうが、なんか寂しさが残るのはなせなんだろう。

冷シャンプー

最近、理容店の店先で「冷xxx始めました。」という幟や看板をみかけます。遠目にみていて、「冷麺・冷やし中華始めました。」と認識し、店のサービスで食事を出すんだと誤認してました。
近づいてよく見ると、「冷シャンプー」とある。うん? 何者だ。ググってみると、はやっているみたいで、イッパイ引っかかる。知らなかっただけか。...orz


http://www.google.co.jp/images?q=%E5%86%B7%E3%82%B7%E3%83%A3%E3%83%B3%E3%83%97%E3%83%BC&oe=utf-8&rls=org.mozilla:ja:official&hl=ja&client=firefox-a&um=1&ie=UTF-8&source=univ&ei=w9xwTLecMIGKvgO9g7RB&sa=X&oi=image_result_group&ct=title&resnum=4&ved=0CDsQsAQwAw&biw=1037&bih=729


山形市で始まったらしく、「冷やし中華」のコピーを意識しているのですね。


効果の程は判りませんが、洗髪中は気持ちよさそう。毎日、家庭で洗髪するのは手間そうですね。
でも、低迷した現代で、ブームほ作り出した功績は大きいですね。ビジネスの種は尽きないのでしょうね。


http://ja.wikipedia.org/wiki/%E5%86%B7%E3%82%84%E3%81%97%E3%82%B7%E3%83%A3%E3%83%B3%E3%83%97%E3%83%BC


特に、特定商品を指すのでないのですね。単に「冷やしたシャンプーで洗髪するだけ」というのも該当するらしい。
ということは、「冷やしシャンプ」自体が商品ではなく、手法・方法 なんですね。ブランドの使用料(版権等)が発生するのかしら。

ポケットティシュ

貰えなくなって知る無料ポケットティシュの恩恵
ポケットティシュは貰うものだと思ってます。買うなんて想像もできませんでした。


でも、配っている地点を通過するから、溜まるんですね。最近通勤経路が変わり、所謂「繁華街」を通過しません。
そのため、まったく配っている人に出会いません。

なかったら結構困りますね。いままで無意識に彼方此方で使っていたこに改めて気づきました。
食後の一拭に使うし、なにかゴミの対処に使ってましたが、今はハンカチになりました。買うのもなんか抵抗があります。

「大阪のおばちゃんは、一度にイッパイ貰う」というのがネタになってますが、解ります。
　大衆ラーメン屋などは、ティッシュの紙箱をおいてますが、「大衆店」だから可能なんですよね。
捨てるほど貰っていた時期が懐かしい。
団扇も「貰うもの」だと思ってますが、貰えない環境になると、なんか物足りない。少し損した気分がしますね。<=オイ

羽のない扇風機

幼い子供がいて扇風機を回すと、気になってしかたがありません。
動物だと、回転部分に指を突っ込まないので、2～4歳程度の興味の対象になるのでしょうね。
羽以外の方式の扇風機は考えもしませんでしたが、出ましたね。

http://www.dyson.co.jp/fans/


価格はチト高く、安いクーラー並みなので、衝動買いとはなりませんが、考えることが違いますね。
ドライヤーの風の流れの研究の結果だそうです。
需要がありそうなので、数年後にはリーズナブルになるのを期待します。氷等を併用して令風機にできそう。


扇風機も安価になってます。リモコン付きでも数千円で買えます。これって凄いことなんですよね。

一昔前は、リモコン装置の送受信機を装着するだけで、万単位の費用が上乗せされていました。
いまや数千円家電にも標準で付く時代。リモコン周波数はOverlapしないのだろうか。
クーラーやTVなどは各社協定規約を結んでますが、扇風機や室内灯のリモコンは幾つか選択子があるだけですね。
一部屋に複数設置したら、被りそう。


クーラーより扇風機のほうが「体によさそう」な気がしています。(根拠はありませんが)
でも現代の仕事場(Office)は、空調が前提になっているようです。扇風機を回すと、紙類がバタツき仕事に支障がでそうですね。


昨今の熱帯夜で一般の家でもクーラーは欠かせません。扇風機を見直しても良さそうですね。

xxxx氏病かxxxx病か

ハンセン氏病、メニエル氏病、パーキンソン氏病、木村氏病　etc
以前は、発見者名+氏病 で呼称されていましたが、近頃では単に、ハンセン病、メニエル病、パーキンソン病、木村病と呼ぶようです。
　科学的法則では「メンデルの法則」といいますが「メンデル氏法則」とは言いませんね。
　命名規則に基準があったのかしら、なぜ医学のみ「氏」が付くのだろう。そして、なぜ付かなくなったのだろう。
　用語なので、自然の成り行きとは思えないので、だれかが指針を示したと想像はできます。
http://www.eonet.ne.jp/~libell/8meisyou.htm#nihondeno
ハンセン氏病に関しては、負の歴史から、何度か呼称変更が、当事者側から成されたようです。
その他の病床の「氏」も右に倣ったのかなぁ。
言語では「Hansen's disease」のように xxxの病気 なので、他の科学法則と同じですね。
「氏」は最初に、和訳した人の意図があったように見えるが、どんな意図だったのだろう。

トレイなしの食材販売

少し古い記事でず。http://www.ryutsuu.biz/commodity/b091716.html
西友が、肉などの小売の単位を、トレイパックでの包装をやめて、真空パックに切り替えたそうです。
後追い報道(ラジオ放送)によると、売上が倍増したらしい。　

・ゴミとなるトレイがない
・消費期限が伸びた
・価格が安くなった

良いことずくめの印象を受けるのですが、なんか腑に落ちない。

小規模小売店での販売は、石油系のトレイは使わなかった。新聞紙に包んだり、ラップで包んで販売していた。


大型スーパーが登場して、小分けしたパッケージを店頭に並べる必要から、トレイ梱包の商品が登場した。
上記の記事を逆読みすると、トレイ梱包する工程のために、消費期限が５日縮まり、価格が４０%高くついていることになる。
「以前のスーパーは安く販売する」という姿勢があったのだが、逆に割高の商品を売っていてたことにならないのか。

トレイ梱包することで、家庭に不必要なゴミを持ち帰らせて、家庭ごみ量産の一翼を握っていたことにならないか。
「レジ袋の節約」はよいことに聞こえますが、それの数倍のトレイを使用しているので、エコの定義じたいが納得できない。


真空パックで、消費期限が確保できるのは喜ばしいてすが、「トレイの使用量を年間約13 トン削減した」と言われてても、「いままで、それだけのゴミを家庭に押し付けていたの?」という印象しか残らない。


一時、百貨店の過剰包装が問題になったが、承知の上で購入している面もあります。
日常のスーパーでの買い物から生じる梱包材のゴミのほうは、否応なしに押し付けられるし、ゴミの分別に手間がかかります。


此の頃はスーパーの出口で、トレイ専用のゴミ箱を設置しています。精算後の顧客は、そこで、商品を解体して、持ち帰る姿を見かけます。

商品陳列だけの目的のトレイはなくしたらスッキリします。でも、少量ずつラップするのが難しい商品だと、量り売りすることになります。
量り売りにすると、店員の手間がかかって経費増になるのかな。でもトレイ梱包コストと比べると、差は小さいと思うのだが。

ブランド名は会社と共に

三洋と松下は創業者が、義理の兄弟です。
三洋は松下から独立して設立されました。言わば兄弟会社です。
それが０９年末に松下の子会社になりました。これも時代ですね。
その時のニュースでは、「SANYO」ブランドは残すとアナウンスされていた記憶があります。
それが一転して「SANYO」ブランドを無くすというニュースが流れました。


NECが ATマシンを出すとき、「(NEC)PC98は継続して製造します。」


ソニーがVHS製品を出すときは、「βマックスの製造は続けます。供給が止まることはありません」と言ってました。


　企業の言うことは「リップサービス」が多いなぁ。思うのです。
でも、会社が存続しているから、まだ救いです。

コニカミノルタ、サンスイ、ナカミチ......その業界で不動の地位を築いたのに、消えてしまったブランドも多々あります。
該当商品の愛好家にとって残念です。


Compaqは HPと一体になりましたが、ブランド名は残っているといいますね。


ORACLがMySQLを手中にしたとき「MySQLは残す」といってますが、数年後はどうなってるやら


サンマイクロシステムズがORACL傘下なってから、どうもJAVA周辺に元気さ感じられない。


MSに吸収されてからVisioの元気がない


　「ブランド名」は一企業のものだけでなく、ユーザーと共有してこそ価値がでると思ってます。
　会社の仕事はは利益追求だけでなく、社会還元も仕事だとおもうのですが.........「ブランド名」維持がこれに該当するかどうか判りませんが。

万能試験紙

「子供が夏休みの自由研究に使う」と言うので、万能試験紙を買ってくるように指示されました。
それが何者なのか、調べなかった私の落ち度はあるのですが。.....
「東急ハンズに売ってそう」という憶測だけで、出向いたのですが、店員に「万能試験紙ってなんですか」と逆質問に逢いました。
どうやらPH測定らしい。扱ってないとのこと。薬局に置いているのでは、ということで、薬局を数件回るが、どこも、「万能試験紙って何?}状態。
出かける前に調べときゃよかった。


http://www.kagakukan.sendai-c.ed.jp/yakuhin/yak/134.htm


上等なリトマス試験紙ではありませんか。なんでも試験できるような大仰な名前。商品名なんだろうか。
中学生が実験に使用するほど有名なものなんですね。私の時代にはなかったような。
　でも、常備している店がないのは、どういうこと?
市中の店に置いてなくて、仕方なく通販で買ったのですか、カードを用いないで、現金決済で1000円程度の買い物をすると、高くつくではありませんか。

(*)IT屋が言うのは御法度ですが、私はネットでのカード決済を信じていない。通販は現金引換え等にしている。
送料や手数料で 980円の買い物が2000円近くかかってしまう。

これって健全な状態なんだろうか。
そういうば、ビーカーやフラスコなど実験道具や材料を売っている店って、見かけなくなりましたね。どこで調達しているのだろう。

Linq2Entities と Linq2SQL

ADO.AdapterやADO.Updateが使う、自動生成されるSQLの冗長さもあって、OR Mapppigが嫌で、DataSet型を毛嫌いしていました。
しこしこSQL文を書いていました。それの延長線で、Linq2SQLも使いませんでした。
で、VS2010をいじっていく過程で、Linq2EntityとLinq2SQLを触ってみました。
「使えるじゃん」という印象です。Linq2SQL.Log で吐き出すSQLをみる限り、冗長性は改善されています。
joinなどが、言語側で記述できるのがよいですね。
でも、安易に書くと冗長なSQLを吐き出すので、結果のSQLの検証は必須なので、「SQLを知らなくても使える」とミスリードするのは疑問です。
逆に、より深い知識を要求されそうです。実行計画を見る場面も増えそうです。

Linq2Entitiesの棲み分けが見えません。簡単な動作テストしかしてませんが、Linq2SQLと Linq2Entityで差が見えない。
逆に、不便な点が目につきます。
・MsSQLに限定される。
・Linq2Entityを別プロジェクトで構築したとき、メイン側のapp.configに登録しないと、接続できない。
・同じプロジェクトで同じDBに対して、 Linq2SQLとLinq2Entity を同居させたとき、名称が重複してコンパイルできない現象がある。
等々。

当分は、Linq2SQLで十分かな。

都道府県コード

全国地方公共団体コードの大区分で
01:北海道 02:青森県～47:沖縄県まで規定されていますが、DB設計時に、このコードの名称に疑問を覚える。
県コードとか、地域コートとか称するならば、理解できるが、行政区分上、同格である地域単位の名称を「都/道/府/県」と4つアサインしいてるのが、不思議。
　明治初期、重要な地域を東京府、京都府、大阪府と「府」にしたのは、他の「県」とは別格扱いにしたかったからです。「道」の北海道は、幾つかの県を設置したものの開発が進まず、
一つにしたかったが、並みの県より大きいので「道」にした経緯があるようです。
でも、戦後は、都道府県は同格になりました。同格なので、すべて「県」にしても差障りはないとおもいます。名残で「都道府県」があるのでしょう。
でも、「都道府県コード」でなく、「行政コート」とか、「知事域コード」とかのスッキリした名称にして欲しい。
「都道府県コード」では、要素名が項目名を表していて、モッチャりしている感じがします。
{Ref]とか「Area」とか「州」とかのコード名称にして欲しい所です。
DB項目名が「都道府県コード」だと、 rec["都道府県コード"]="東京" となりますが、
DB項目名も「県コード」とするとrec["県コード"]="東京" となり、違和感が残ります。
同様に、、「市町村コード」も、スッキリした代名詞が欲しい。
　項目名として「都道府県コード」ほ「モッチャり」と感じるのは私だけかなぁ。

Framework4の控えめな型

新機能の影に隠れた感のありますが、新しい型に「BigInteger」があります。
有効桁数無限大(?)の整数型です。(例外はOverflowでなく OutofMemoryだそうです)
　使い道が思いつかないのですが、必要があるから実装されたと思います。
　高桁数のπの算出は手順が確立していますが、BitIntegerで計算すると
速度的にどうなるのでしようか。

ここに(http://msdn.microsoft.com/ja-jp/library/system.numerics.biginteger.aspx)
使用例がありますが、
ソースのなかに、
BigInteger number = BigInteger.Pow(Int64.MaxValue, 2);
BigInteger number = Int64.MaxValue ^ 5;
の二種類の形式がありました。
この行で XORを使う意図が見えません。VBでのべき乗が "^"なので、補正し忘れているように思います。

それはともかく、サンプルを作って測定しました。( Athron 64*2 4600+)
▼Code

BigInteger number1 = Int64.MaxValue;
BigInteger number2 = (BigInteger)Int64.MaxValue * (BigInteger)Int64.MaxValue;
BigInteger number3 = BigInteger.Pow(Int64.MaxValue, 2);

Console.WriteLine("number1[" + number1.ToString() + "]");
Console.WriteLine("number2[" + number2.ToString() + "]");
Console.WriteLine("number3[" + number3.ToString() + "]");
▲
▽結果
number1[9223372036854775807]
number2[85070591730234615847396907784232501249]
number3[85070591730234615847396907784232501249]
△

1000000回 Loopさせて、速度差Check
{
BigInteger number = Int64.MaxValue; '★
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i <= 回数; i++){number++;}
sw.Stop();
Console.WriteLine("bigInteger 所要[" + sw.ElapsedMilliseconds.ToString() + "][" + number.ToString() + "]");
}

対象の型を　 BigInteger, BigInteger? , Long , Long? , Decimal , Decimal ? に変えて実行


bigInteger 所要[251msec][9223372036855775808]
bigInteger? 所要[278msec][9223372036855775808]
long 所要[ 4msec][-9223372036853775808]
long? 所要[ 41msec][-9223372036853775808]
decimal 所要[ 45msec][9223372036855775808]
decimal? 所要[ 84msec][9223372036855775808]

さすがに、ネイティブな Long型が速いのは、予想通りでしたが、
decimal型の5倍程度のコストなのは、予想外に早かった。
逆に、各型のNull許容型の遅さも意外でした。

BigInt型はstring型と同様に、変更不能型で変更の都度、新しいインスタンスを作成されます。
そこで、文字型で同じ回数のLoop測定してみました。

{
string a = "";
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i <= 回数; i++)
{
a = i.ToString();
}
sw.Stop();
Console.WriteLine("string 所要[" + sw.ElapsedMilliseconds.ToString() + "][" + a.ToString() + "]");
}

結果
string 所要[267][1000000]

ILの掃出しコードをみてませんが、数値結果から類推すると、 Biginteger,BigInteger?, string
共に、同じような値なので、文字列として演算しているような感じがします。

不注意発言

豪雨などで安全維持のため鉄道が遅れるのは結構なことです。スイスの列車はスピード超過らしいので時間厳守よりも安全重視して欲しいです。
でも、人身事故(飛び込みや駅校内での接触)の場合は、不満やストレスが溜まります。
朝、始業に間に合わなくなったとか、帰りの終バスに間に合わなくなったとかだと嫌になります。「死んでまで他人に迷惑掛けるな」と思うほどです。

数分程度の遅れは多々あることなので、あまり問題視されません。
　最近は、気象がおかしく連日の猛暑日の為か、「急病人がでましたので遅れました。」・「乗客の介護の為遅れました。」とかで遅れることが多くなったようです。
不調ならは通勤途中で倒れる前に、休みましょう。休める体制でないって? 急に倒れるほうが迷惑を掛けると思います。
健康上の問題なので自己の健康状態には気を付けましょう。

閑話休題。
家族が(学生)JRに乗車していたとき、急病人がでたらしく、乗っていた電車が10～20分遅れることになったらしい。
車掌は「急病人がでましたので遅れました。」とでもアナウンスすべきでしょう。ところが、車掌は
「急病人のせいて遅れます。」とアナウンスしたらしい。これはダメでしょう。
心無い一般乗客が、そのように思うのは勝手ですが、車掌等のサービス提供者側の人は、狭い範囲とはいえ、公共の場での発言なので影響があります。
そのとき居合わせた友人たちの間で。「あ! 言っちゃった。本音が出たんだよね。」などと話題になったようです。
本人が気づいたのか、お咎めがあったのかは判りませんが、その後の、車内アナウンスの量が、極端に減ったらしい。

Option Strict off化はなんとかして欲しいな。

DLR-Dynamic型がC#4.0/VB10 から導入されました。IronPythonやIronRuby との連携が話題になっていて,動的言語連携向けだと思って、あまり調べてませんでした。
それだけではないのですね。既存の資産との相性もよさそうです。
動的メンバ-/メソッドの追加・更新も、トリッキーさがなく実装できるので、スクリプト言語並みに使いやすそうです。
リフレクション経由でメソッドを操作することが多いのですが、それが簡略できます。それだけでも Dynamic型の恩恵は大です。
いままでは、
var bf = BindingFlags.Public | BindingFlags.Instance | BindingFlags.InvokeMethod;
var inst = Activator.CreateInstance(型);
inst.GetType().InvokeMember("メソッド", bf, null, instance, new[] { 引数,,, });
のように記述していましたが、
dynamic inst= Activator.CreateInstance(型);
inst.メソッド();
これでOK。普通のメソッドCallの感覚です。

C#だとインスタンス.xxx の Dot以後の部分は、インテリセンスが働き、アーリーバインドされます。VBでStrict ONだと同様です。
でも、Dynamic型の場合は、存在チェックが動作せず、遅延バインドになります。
この区別はよくできています。

ところが、VBで Dynamic型を使うには、 Option Strict をOffにする必要があります。これが不満。
Linqで使う動的クラスなどでも Strict offにする局面がありました。

厳密な型定義は、潜在バグ回避に有効な手段なので、Strict ONを徹底させています。旧VBの Strict off文化が薄らいできたのに、Off文化が復活するのは嫌。
C#並みにDynamic型のみ遅延バイディング対象にし、Dynamic型以外は、事前バインド必須にすることができなかったのだろうか。
C#ができているのだから方策はあったと思うのだが。

携帯カメラ1000万画素時代

下手なデジカメより画素数が多い。
レンズ等の要因でデジカメと対比するのは無意味なんですが、「そこまでするか」という感じ。
携帯で写真を撮らない人にとっては、まったく無意味な機能なんです。
カメラなしの携帯はを見つけるほうが難しいし、あっても他の機能も貧弱だったりするので、宝の持ち腐れ状態になります。
一頃の「0円携帯」ができなくなったせいか、高機能携帯が幅をきかせているようです。単機能で安価なものを見つけにくい時代。
フィルムカメラは画素数では表現できないのですが、強いて換算すれば、2000～3000万画素だそうです。
画素数だけで言えば、デジカメはスティールカメラと同格になったと言えるのしょうね。
「デジカメは玩具だ。本物のカメラとは表現力が違う」といわれたようですが、500万画素を超えた製品からは、言っている本人が区別できないようです。
何時の世も、台頭する製品は、旧製品愛好家から非難されます。しかし非難していた人が霧散していくのが世の常です。
・PCが登場したときも、「PCは玩具だ。」
・カセットテープが登場した時も「オープンテープの足元にも及ばない。」
・オートマチック車が登場した時も「車はミッション車が本物だ。」
権威者ほど超え高々に叫んでましたが、牙城が崩れたのは周知の事実。
　古い技術に固執すると取り残されてしまう厳しい現実があるのでしょうね。
デジカメが実用に耐えているし、要件をみたしているので、フィルムカメラは、オープンデッキ同様にマニアの物になるのでしょうね。
量販されないので、ますます高くなるのかも。マミヤ645とかハッセルのように給料数か月分でも買えない....orz;
でも私には、携帯にカメラやテレビは要らないんだがなぁ。

パソコンショップも厳しいそう

神戸市内の、パソコンショップが消えていく。
数年前にツートップが閉店し、今年4月にドスパラが閉店しました。
残っている、ショップはパソコン工房くらいでしょうか。
ヤマダ電機などの量販店は、ショップ印象が薄く親近感が湧きません。
ソフマップも最近は量販店的になって遠ざかっています。
パソコンショップだと結構無茶な組み合わせを言っても検証してくれるので助かっていました。
閉店されると残念です。
Windows3.1全盛のころ、DOS/Vショップが雨後の竹の子のように彼方此方に出来てましたか、どうなったのでしょうね。
　先日、職場の開発機が不調になり、代替えすることになったので、新調してくれるのかと期待したら、
「数年持てば、良いし、業務開発に支障のない性能で十分」ということで、「中古機」(Pentium4 3.2G?) を調達することになりました。
「えー、いまどきPen4?」と思ったのは内緒です。
でも、使ってみると、結構使えるし、事務アプリの開発には、全然差しさわりがないし、ストレスも感じません。これが結構格安。経理の人は、「開発機は消耗品で十分。クラウドで構築するより、中古機を消耗品購入するほうが安い」とまで言ってました。
妙に納得。
　6コアや、4コア*HyperThreadに目が行きますが、冷静になって考えたら、チト反省。゜
「事務アプリの開発」という分野では、今のPCはオーバースペック状態なのかもしれまんね。
とはいうものの、 4コアでHyper-V を走らせたいな....と思っている私。

公園のごみ箱

都心部公園の現象かもしれませんが、ごみ箱がない公園が結構あります。
ごみ箱を設置すると、家庭ごみを捨てる人がいるらしいです。
家庭ごみの廃棄は、コンビニや駅でも問題になるほど深刻らしいですね。
住民のモラルが低下したのかどうかは分かりません。一説によると、分別ゴミ方式にしてから増加したらしい。
分別してゴミ出しするのが面倒で、駅に捨てる輩もいるとか。
飲料水の自販機の横には缶やペットボトルのごみ箱を併設していますが、そこに一般ごみを突っ込む輩もいるとか。
　「モラルが低下した」という意見もありますが、ごみの分別という制約が敬遠された結果かも知れません。
ごみ回収が有料化になれば、もっと公共の場所に捨てる人が増えるのは想像できます。
ごみ処分場で適切に自動分別できる仕組みを構築したほうが、よいように思えます。
　「欧米では徹底している」と言われますが、実状は日本と似ていて、ルール違反者に悩んでいるようです。
分別しなくて処理できる仕組みや、ごみ自体を少なくする流通材(トレイや袋類)を検討するのが大事だと思うのです。
以前の市場では、なんでも新聞紙に包んで売買してました。とくに弊害はなかったです。新聞紙に包むスーパーがあってもよさそうな。

SetCompatibleTextRenderingDefaultとApplication.EnableVisualStyles()

最近は、GDI＋自体が話題になりませんが、Winodws(Desktop)アプリを作成するとき、IDEが勝手に生成してくれます。
Program.csの中を覗くと書かれています。
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
「なんのこと」と質問がありました。
おまじないのように扱われることが多いのですか、理由があっての記述です。
http://msdn.microsoft.com/ja-jp/library/system.windows.forms.application.setcompatibletextrenderingdefault.aspx
FrameWork 1.x時代にGDI+が注目され、コントロールのテキスト描画もGDI+で実装されていましだ、パフォーマンスとロケールの問題で不利になり、GDIで描画するために (False) にすることにした経緯があります。

当時のパフォーマンス差を測定したとき、差があったかどうか忘却したので、再度検証してみました。
(*)記憶に残ってないのは、差がなかったからだと思う。



public partial class Form1 : Form
{
string z = "kkkkkkkkkkkk....................kkkkkkkk";
int Max = 20000;
Stopwatch sw = new Stopwatch();
public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
sw.Reset();
sw.Start();
for (int i = 0; i < Max; i++)
{
label1.Text = z;
}
sw.Stop();
label2.Text="所要時間["+ sw.ElapsedMilliseconds.ToString() + "]";


}
}

Application.SetCompatibleTextRenderingDefault(false); //GDIモード
と
Application.SetCompatibleTextRenderingDefault(true)； //GDI＋モード

で測定したところ、殆ど同じでした。

巷に転がっている情報では「text描画のパフォーマンス向上のため TRUEにする。」となっています。
でも、最近のグラフィック回りが進んだのか、差がでません。なんか説得力に欠けます。
　速度以外にどんな不具合があったのが、資料が見つからないので不明ですが、どんな不具合だったのでしょうね。
これと、同時に生成される、
Application.EnableVisualStyles();
も、「Windows XPスタイルの外観に変更する」ためと説明されてますが、XP自体が過去の物になりつつある昨今では、説明力に欠けます。
「XPスタイルの外観」云々自体に意味がなくなりつつありますし、外してみても差を感じませんでした。
この二つの行は、過去の名残として、おまじない扱いとして残り続けるのでしょうか。

甲類と乙類

徴兵検査では、甲種合格、乙種合格等があって、甲乙丙..は序列語でした。
通知簿も昔は、甲乙丙でした。
以前の酒には、特級酒、一級酒、二級酒がありした。でも、これは品質ではなく、アルコール度数での分類なので、品質と一致していない実態がありました。とは言うものの、階級的に扱われていました。
現在、焼酎に、甲類、乙類という分類があります。
http://www.glico.co.jp/osake/osake_skind01.htm
　甲類は 連続式蒸留且つアルコール度数36度未満
　乙類は 単式蒸留且つアルコール度数45度以下
の分類です。
　36度未満と、45度以下のように、未満と以下の両方が登場するのが、解せないのです。
　連続式蒸留で度数40度や、単式蒸留で50度の焼酎は当てはまらないの? なと疑問が残る基準です。

さらに加えて、乙類焼酎のみ「本格焼酎」を名乗ることが許されています。
甲類、乙類は等級ではない。と言いますか「本格」と名乗ることで暗に等級を意識させるキャッチコピーに感じます。
　「甲類より劣るものでない」という意味で「本格」を名乗らせているようですが、それが逆に等級を意識させている気がします。
意識の問題でしょうが、序列を意識させない区分名って、見当たらないものですね。

小さすぎて不便

SDカードはMicroSDカードが主流になりました。MSD専用USBアダプターはコネクター部分だけのサイズになってます。
2Gカード + アダプターでも2k\以内で揃います。
　安価で手軽なんですが、小さすぎて不便です。。MicroSDカード自体に字を書き込む領域がないので、複数枚のカードを使い分けるとき識別できない。
　持ち運ぶとき、小さすぎて、紛失してしまう。何度が紛失しました。
　MicroSDカードにストラップを付けることができないです。コネクタ型のUSBアダプターにストラップを付けるとかさばってしまう。
結局、通常のUSBメモリーを持ち運ぶほうが楽だと思ってます。

携帯などで複数のMSDカードを使い分けている人を見ると、どのように識別しているのか興味津々です。(聞けないけれど)
電卓なども、一時、カード型電卓が流行りましたが実用面から、ある程度の大きさをもったサイズが売れているようです。
携帯電話も技術的には、もっと小さくできるのでしょうが、これ以上小さくすると、ボタンが押せなくなるでしようね、
携帯用のミニ人生ゲームやミニ碁盤もありますが、使用感はよくないです。
MP3フレーやーは多々ありますが、小さい機種はどうも使いにくい。一つのボタンに複数の機能をもたせすぎて、操作順序が理解しきれない。
IPod/IPhoneなどのApple製品はよくできていると思うのですよ。この操作性を生み出す力量の差ってどこからくるのでしょうね。「ユーザーの立場に立て」と言うけでは無理でしょう。経験の蓄積の差なんでしょうか。
Appleアプリは作って地獄、使って天国といわれましたが、最近はどうなんでしょうね。

ソートは "Order by" なのか

勉強会の懇親会で話題になったのですが、データをソートするアルゴリズムを知らない開発者がいるとか。
「Order byでソートできるのだから、アルゴリズムを知る必要がない」と発言する人もいるとか。
確かに、簡単にソートできるのですがね。
ソートロジックは、バブル、クイックなど多種あります。各種のロジックを知る必要はありませんか、せめてバブルソートは書いて欲しい。ロジックを考えるのは楽しい事なのに。　今時の開発者は実利効果でコーディングするのかなぁ。
　ソート順序が変わっても、カスタムソートで対応できるので、ますますアルゴリズムを知らなくても、作れてしまう。
確かに、アルゴリズムを知らなくても、開発仕事はできる時代です。「知らないから困る事」は起こらないかも知れません。
(視点を変えたら)エンジンの知識やFF/FR/RRの区別がつかなくても、日常の運転に支障はないです。その意味では、知識は不要かも知れません。でも運転のプロではないですよね。
　「開発者はプロでは無くなった」と見るか、「プロでなくても開発できる」とみるか、「プロは開発に直接必要な知識で仕事する」と見るか...その他の見方もできそうです。

仕事に直結しない知識かも知れませんが、技量の基礎力になると思うのです。
でも寂しいなぁ。開発の醍醐味を知らないのは勿体ない。
　と拘っている私は、五月蠅い親父に映るのだろうか。

開店準備の行動

一般人相手のお店は、朝10:00開店が多いようです。
携帯電話の店も10:00開店が多いようです。仕事の都合で、9:55分頃に、複数社の携帯ショップの前を定期的に通過します。
開店準備で、店員さんが幟旗(下部に水タンクのある固定式)を店前に出しているのですが、ある系列のショップでは、手で抱えるようにして、道路に移動させています。他系列のショップでは、ツンとすました美人系の店員さんが、靴で蹴飛ばしながら移動させています。
(*) 幟旗　このようなモノ: http://www.noboribata.com/?gclid=CJ_Ysvu28KICFQowpAodFE8Rlg

　若い人の目には、違和感ないかもしれませんが、古い私には「悪い行儀」に映ります。店長らしき人もその場に居るようですが「行儀が悪い」とは思っていないのでしょう、黙認してるのか?。
　サービス業は見えにくい箇所の心配りが、勝負を決すると思うのです。 私はそのショップに入る気は無くしました。
プログラムも起こりえないと思われる箇所のエラー対策をキチンとしていると信頼度が高まります。その処理は一度も実行されずに寿命が尽きるかも知れません。発生しないからと判断して、手抜きすると、不思議にそのエラーは発生するのですよね。
逆に、対策をしたエラーは滅多に発生しない。一種の保険ですが、誰かが見ていて事象を操作しているのでしょうね。

上記の店員さんは、2ヶ月経たない間に居なくなっていました。どうなったのでしょうか。

ホットイチゴ／バナナ

飲料自販機の大抵は、コーヒー・紅茶・ソフトドリンクですが、
紙コップ式の自販機のなかに、屡々珍しいモノがあったりします。イチゴミルク(ホット・アイス)やバナナミルク(ホット・アイス)が見かけたことがあります。バナナは、あるメーカーの社内休憩所で、イチゴは、駅のホームで。
ポタージュやお汁粉は少ないですか、複数箇所で見かけますので、需要があるのでしょう。
喫茶店などでは、品揃えで置くのはわかりますが、紙コップ式の自販機で常設して採算とれるのかなぁ。
疲れているときは、甘ったるいものが欲しくなるので、私は飲みますが....類似の人が多いから設置しているのか。
潜ってみると、本物のバナナ自販機が渋谷にあるそうな。http://www.youtube.com/watch?v=DkRS_zq4oB0
こちらは、バナナ朝食ブームの一環かも。

グリーン車は旧一等か旧二等か

クハxxxx :1文字目の「ク」は運転台付き車両です。モータ付き車両は「モ」になります「モロxxx」など。
でも...今回テーマにしたいのは、二文字目の「ハ」や「ロ」です。
この「ロ」は「イロハ」の二文字目で、二等を意味します。「ハ」は三文字目で三等を意味します。
現在の乗客を乗せる車両は、「ロ」か「ハ」の二種類です。「ロ」が今のグリーン車に相当し、「ハ」は普通車に相当します。
　三階級制を廃止で１等を廃止した時、、分類記号である「イ」を廃番にしました。
　それが鉄道マニアも含めた常識でした。
最近、出版された鉄道関係の本に、「グリーン車(昔の一等車両)」「普通車(昔の二等車両)」といった記述があります。　3階級あった時は、運賃自体も一等運賃、、二等運賃、三等運賃と同時に、特急料金も、一等特急料金、二等特急料金、など分かれていました。
ややこしくしているのは、1960年～1969年の10年間は、一等を廃止し、二等級制にしました。そのため。
その時の一等車両が今のグリー車だと言うのを「間違い」とは言えません。
しかし、それまでの３等級制の時代が長かったので、「グリーン車は旧二等車両」という表現が自然です。
公式分類でグリーン車を「ロ」で表現しているので、グリーン車を「昔の一等車両」と表現するのは、誤認・誤解を与える表現になります。
　これも、「コード体系(運用・表現)が不整合を起こしている」と思うのです。
初級者向けに書く文なら、注意して表現しないと、誤認されるなぁ....と思った次第。

２種類の表音文字

平仮名は草書体から派生、片仮名は漢字の一部から派生。このように教わります。
戦前までは、公式文書は、漢字と片仮名の文で書いるのが多いです。学校で習うのも、「サイタサイタ」のように片仮名から学びました。
法律の文が片仮名交じりなので今の人には読みづらいです。「平仮名文字」の読む速度と、「片仮名文字」の読む速度差も大きいです。
　そこで疑問に思うのです。「表音文字(音節文字)」は何故二種類あるのだろう。一種類だけでも、機能は足ります。
片仮名は西暦８００年位、平仮名は西暦９００年位に作られたようです。100年の開きがあります。
片仮名では不十分な事態や不便な事が出てきたので、新たに作ったのか。
でも、今の感覚で見ると、既に存在する「片仮名」と同類の表音文字である「平仮名」を創出する価値が見えない。
「現行の表現形式(片仮名)」が不便なので、「新表現形式(平仮名)」を作ったのだったら、現行は破棄するのが自然。片仮名が消滅して、平仮名が残るのが自然だと思うのてず。
でも、両方残っています。不便なので創出したのではなさそうですね。

コンピュータ言語が、年々増えていくのと同じで、適用場面が異なったのだろうか。日本以外で、複数の表音文字を持っているのはあるのだろうか。不思議だ。

相撲..国技..騒動?

昨今の相撲問題..ニュース番組が「国技」と連呼するのが気になって。
「国技」という用語に定義がなく、一般的に、伝統文化的に浸透しているモノを称したり、国民の間に人気のあるモノを称したりします。
相撲に関しては、違うようで、両国に相撲館を造ったとき、「国技館」と命名したことに由来するようです。言ってみれば、「自称国技」ですね。
それをマスコミが「国技」と連呼するので、「日本古来の由緒ある国技」と認識する人が出てくるのでしょうね。
　「相撲協会」が公益法人で、「大阪プロレス」が営利団体というもの、根拠が不明確。
相撲は単純格闘技でなく、神事の面があるので、他のスポーツ協会と同等にするのは、無理があると思うのです。
勝負時間より、前の儀式が長いというのも他にはないでしょう。
心技体が揃うのが理想でしょうが、強い事が主題の外人力士を導入した時点で文化が変わるのは不可避でしょう。
神事性とスポーツの公正平等性が共存するのか相反するのかは判りません。
しかし、古来からの興業文化の根っこには、アウトロー性が匂うでしょう。それを知った上で文科省が公益法人に指定し、放置していたとも見えます。
今回の騒動。報道する側も知っていながら、初めて知ったように報道しているように見えるのです。
出来レース感がして、スッキリしない騒動です。

一次電池と二次電池

単純な違いは、充電可能な電池と、充電してはいけない電池です。
構造上、充電と放電か繰り返し可能な電池を二次電池といいます。
マンガン電池やアルカリ電池は充電ができません。
　一次電池の充電行為は、危険と教わりました。(何故危険なのかは亡失しましたが。)
最近、「マンガン、アルカリ電池に充電できる機械」なるものが市販されています。
個人的には、眉唾視していますし、可逆反応できないはずなので、使い切った電池が復元できるとは思えません。
でも、堂々と売られているのをみると、販売店やCMの信頼度ってどうなの...と思います。
以前書きましたが、マイナスオゾン生成機(名称を書くと語弊がありますが)など、効果の測定できないものを、効果があると書くのは疑問に思います。

二次電池は、充電頻度や回数で寿命が大きく変わるのは、携帯の影響で多くの人に浸透したようてす。
一次電池を使い捨てするより、二次電池で充電するほうがエコなのかどうかは資料がないので判りませんが、一次電池のほうが長く使えています。
なので、私のMPプレーヤーは一次電池式を使っています。(強引な結論ごめん)。

４原色テレビ

色(光)はRGBの配合で決まります。(透過度を考慮してaRGBとすることもありますが)
CRTもRGBをベースに作られいます。
S信号やコンポジット信号など実装手段は幾つかありますが、原理は同じです。
テレビは映像信号と走査線の組み合わせで、RGB要素をONして再生します。
　シャープが４原色テレビを投入してきました。RGBに加えて、黄色が要素として加わるようです。RGBYとでも言うのですかね。
YはBの補色の関係なので、同列に扱うという発想はコロンブスの卵。
黄色や金色の発色が鮮やかになると言われてます。R+Gの黄色と Yとどのような違いがあるのでしょう。
金色や銀色は、波長があるのでなく、金属の光沢に依存する色なのでRGBから生成するのは厳しいと思っています。
それが、「黄の原色を加えることで可能になった」というのが不思議。
さらに不思議なのは、金色など、従来方式だと表現できなかった色の再生。
従来のTVの再生は、走査線等のRGB信号に帰着するのに、特定の領域が金色だという情報をどこから取得するのだろう。
デジタル情報として埋め込まれているのなら、４原色対応ソフトになるので、それはないだろう。
RGBY４原色方式が普及すると、 アプリで遣われている 32万色COLORの RGBの世界は変わるのだろうか。

歩と步

正字が「步」、俗字が「歩」とされます。
新字体は「歩」で一般使用されます。新字体のほうが画数が増えてます。
一説によれば、字体のバランスが新字体のほうが良いからだとか。
漢字の正字というのは、いたって俗物っほくて、文部科学省(旧文部省)が発表した、「字体表」に基づいているかどうかで決まるようです。
「字体表」を印刷したときのフォント字体にも影響されるので、恣意的な部分が残ります。
文科省の意志次第で、字の画数が変化する訳ですよね(?)
戸籍登録の漢字がその人の本字と言われても、使用制限で使えない字があります。俗名で使いたい字を使っている人もいます。
その場合も含めて、姓名判断などに用いる画数の根拠って何よ...ということになりませんかね。
血液判断的な遊びの話題程度ならいいですが、真剣になられると対処に困ります。

風呂屋が空

PK戦での結果なのでもう、何も言えません。名勝負でしたね。
後半戦から観戦しようと思い、23:45まで風呂屋に行ったのですが、なんとガラガラ。
いつもの23:00台は結構混むのですが、サッカー恐るべし。
民放の中継なのにCMが入らないのも凄いですね。放送権料が高額なのにCMが少ない.....収益判断は難しいのでしょうね。
「炭坑送りはない」というニュースが流れるほどに、盛り上がるものですね。

小売店の営業時間

大型書店の営業時間が軒並み、22:00時までになった時期があります。
でも、効果がなかったのか、21:00に下降修正した店もあります。
22:00閉店の店でも、21:50頃から追い出しモードに入って、追い出しアナウンスを流す店があります。
その一方で、22:00閉店の店でも、22:00になっても、軽い閉店アナウンスも流さず、客が却って気を遣ってしまう店もあります。
店に対する印象に差が付きますね。
コンビニも24時間営業から、深夜休業に変わる店も出てきました。
24時間営業や遅くまで営業する事のデメリットもあるのでしょうね。商売敵の店と同じ営業体制にするだけが勝負はないですね。
違うサービスで勝負する時代に突入したようです。心理要素を擽るのは、効果が大きいですが、そこに気づくのはなかなか難しいです。

コード化って処理を合理化するんだよね?

「文字コード技術入門」等の資料を読むにつれ、漢字コードの怪しさに往生感を抱きました。
コード化は、システムを見える化するためのもの.....だったよね。
データにコードをつけるのは、一元化したり、グループ化したり、特性区分けしたりして、システム上扱いやすい代名詞化することです。
上記の本や、漢字をコード化するときの紆余屈折というか、苦悩が伺えます。
JIS X 201-xxxx(年) JIS X 0208-xxxx(年),,第一水準、第二水準、補助漢字、第三水準、第四水準....
ここまでは、コードの意味で理解できました。でも、漢字表、漢字字体表、関係で異字体を包摂とする字、別コードを割り振る字があったり、
もう、基準がワケワカの世界。一度決めた字コードを途中で入れ替えるなんてコード化の意味を無くす行為に見えます。
　電子データは将来に渡って復元できるのがメリットなのに、いまの体系だと、電子データを作った時の、漢字コードを把握しておかないと、復元できない。
所轄官庁が、文部省、通産省、法務省(地名、人名関係) に跨っているのも影響しているのかもしれませんが腑に落ちない。
CJK統合漢字の異字体セレクタを導入したのなら、包摂関係をやめて、異字体登録すれば、スッキリすると思うのですがね。
対処療法でコード化したようで、他のコード体系に変換すると不可逆モードに陥るのは理屈は判るがコード体系として納得ができない。
開発者が右往左往している現状をみると、「だれの為のコード化なんだ」とボヤキたくなりますね。

数字<英字 とは限りません。

オープン系開発者は、文字コードのベースが ASCIIコードの人が多いので、無意識の内に数字<英字と反応するようです。暗黙知になっている人もいます。
'0'<'9'<'A'<'a' です。
でも、汎用機で使われている EBCDICコードでは '英字'<'数字'です。 'A'<'0'です。
これが小さな騒動になったりするので、暗黙知に差があると怖い。
商品コード順のリストなどで、コードが英数字で構成されているとき、ソート結果の順序が、汎用機での出力結果と、Open系での結果や、Excelでのソート結果では、並び順が異なります。
互いの事情を知らない人が互いに「バグだ修正しろ」と争いになることが、時々あります。最近は聞かなかったのですが、汎用機開発をしている人と話をしていると、最近でも有るそうです。
エンドユーザーにとって、並び順は重要なので、処理系が異なって順が変わるのは、処理機械の勝手であって、ユーザーには無関係です。
アウトソーシングで汎用機システムをオープン系に載せ換えたとき、英字<数字になるように、カスタムソートで 処理したようです。
Oraclと MS Sqlの nullのソート順も違いますね。
コード体系がいろいろあるのは構いませんが、文字種の大小関係は統一して欲しかったなぁ。
ASCII,EUC,JIS....は根がasciiだから文字種大小は同じなのでしょうね。
カナ拡張EBCDICはもっと悲惨で
　'ﾃ' < 'a' <'i' <'ﾄ' < 'ﾊ' <'j' <'ﾙ' <'A' <'0'
となっています。英字、カナ混じりのコードの表はどのように処理しているのだろうか。
私が汎用機をしていた頃は、混合項目は作らなかったので、問題化しませんでしたが、今もそうなのかな。
EBCDICコード系をみる度に、「策定者は(将来のことを)深く考えなかった。」と思えてしかたがありません。

つけ麺

最近、「つけ麺」を看板にする店が増えました。
「つけ麺」自体は結構昔からありましたから、何かを切っ掛けにブームになったのでしょうね。
ラーメン店に多いようですか、「つけそば」「つけうどん」の店もあります。
原型は「ざるそば」「ざるうどん」な気がします。ソーメンかも知れません。
つけ汁は性質上、濃い目に作らないと、味バランスがとれません。
汁に鴨などの具を入れて食べる形式が受けるのかも知れません。
食後に、そばつゆや、生姜湯が出る店もあり、それを加えて、汁を飲み干すので、トータル的にカロリー摂取量が多くなり良くない結果に....なりそう。
ラーメン屋のつけ麺は印象が薄いのですが、「鴨しん」という鴨汁のつけ麺はお気に入りです。「そば、うどん、ラーメン」が選択できるのも良い。多分ブーム以前から有るので、便乗じゃないよ...
http://r.tabelog.com/osaka/A2703/A270306/27018815/

アソッカーになっていたかも知れないサッカー

FIFA Ｗ杯が盛大に盛り上がっています．このゲームは、フットボールと称する地域が殆どだとか。
数カ国だけが、サッカーと称しているそうです。
サッカーと称するようになった謂われは、Association Football (協会式FootBall)から。
Association + er(人)= Assocer => Soccer となったらしい。
最初のAをとばして、Soccerとなるのは、不自然に感じるのは、日本人だからか。日本なら Assocerとなり「アソッカー」になっていた気がする。
母音始まりの省略形を嫌がったのかな。
　 FootBallと同種のスポーツがある国(アメリカ等)では区別するために、「サッカー」と称して区別するらしいですが、
日本で「フットボール」と称するスポーツは他にあるのだろうか。蹴鞠をフットボールと称していて、それとの区別?
単にアメリカが「サッカー」と称していたかららしい。
　用語を取り入れる時、あまり考えてなさそうなのは、どの業界も同じなのかも。

元号法とレシート

国旗及び国歌に関する法律が1998年、元号法が1979年となぜか法律整備が後追いするようです。
これが右翼思想に映る問題はさておき。元号法があるけれども、年号表記は、和暦／西暦何れも可能です。融通が聞いて良いですね。
度量衡の場合は、「一国一制度であるべき」という思想があり、メートル法以外の尺貫法などは禁止されました。物差しの販売も禁止されてました。
これはメートル文化の浸透には一役買いましたが、尺貫文化の衰退という犠牲が伴いました。アメリカのようにメートル法が普及しないのも問題かも知れませんが、文化の在り方も関係するので、即断できません。
今回、趣旨はそれではありませんで。....
先日、領収書／レシートを整理して気付いたのですか、市役所など公機関の年号表記は、元号法もあるので、和暦だと思い込んでました。
でも、住民票などの書類を貰ったときのレシートは 10.05.xx と印字されていました。西暦表記でした。
　意図的なのか、無意識なのか判りませんが、なんか一貫性がないような気もして複雑。
表記基準を徹底することの難しさなのかも知れませんね。

こうして、事実が隠れていく。

数回前のエントリー「キーボードの配置」で 安岡孝一氏からコメントを頂きました。
http://blogs.wankuma.com/ognac/archive/2010/06/08/189868.aspx
著書「キーボード配列 QWERTYの謎」の紹介があり、興味があり、早速読みました。
歴史的背景や、ASCII/JISの記号類の配置の差にまつわるメーカーの思惑など実に面白いです。
(氏が高名な方とは知らず、失礼しました。)
「QWERTYの配置は、使用頻度と打鍵アームが絡む事の回避の結果」はガセネタだという話は、都市伝説の発生メカニズムみたいな趣でした。
この説は、高名な方も主張しておられるとのこと。根拠を確認しないで、不確かな情報を受け流すのは、有名・無名に拘わらず、犯しがちな事ですね。他山の石です。
アームで打刻する機構が生まれる以前に配置はあらかた決まっていたようです。なのて、上記の説は前提が崩れています。

巷の雑学本や雑学番組も眉唾ものな項目が多いのは、以前から気になっている所でした。
諸説が幾つかあるのに、故意かどうかは知りませんが、信頼度の低そうな説を取り上げていることもあり、校正機構が働いていないように思うのです。
娯楽本、娯楽番組だから、構わないのかもしれませんが。

自分で確認しないで、「本に書いてあったから」「テレビで言っていたから」と信じる風潮は、昔からあります。
研究者でなければ、自分で確認するにも限度があります。
手書きより活字を信頼する気持ちも否定し難いです。
うーん。結局、自分が納得するかどうかなんでしょうかね。

辛抱も仕事のうち(?)

数回前のエントリー「ラジオ体操って、そう見えるの? 」で頂いたコメントで、
>会社にわけの分からない拘束をされるのは誰でも嫌じゃないですか？
>（わけが分からない内容であっても、まぁ反社会的というわけでもなく正等な労働対価が支払われるなら、(波風立てずに生きていくには)拒否はしないかもしれませんが、私なら気持ちとしては嫌ですね。非生産的な無駄は、結果として自分たちの給料を押し下げますし）
がありました。同意するのですが、考えました。
我々は、仕事をして報酬を頂いています。自分の思考、思想に合致した仕事に就いている人は少数だと思うのです。
職業プログラマは、比較的、自分の思いに叶った職種に就いている人だと思います。でも、不平不満は皆無ではありませんよね。
人間関係のギクシャクはどの社会にもあるので、省きます。
ラジオ体操や社歌、説法じみた教育的訓話の拝聴などを強要されることに、不条理感を持つ人がいるのも事実です。
でも、それが会社文化なら従うのが労働者だと思います。嫌なら退社する自由もあります。拘束も労働の一部だと思うのです。
で、上記の目に見える「拘束」ならば、話は単純なのですが、我々開発者には、もっと不条理な拘束があります。
「開発標準」「コーディング規約」等とよばれる規約です。
理にかなった、開発効率に貢献している規約ならば意味がありますが、どう見ても不条理な規約があります。
・コボル時代に策定されたような内容「変数の事前定義と広域化」「テータテーブルは横持ち」「一画面1exe」
・開発者水準を下に合わす内容「継承は用いない。」「Joinは用いない」「ジェネリック禁止」
・化石みたいな社内フレームワークの強制...net.Frmame Work 1.x当時に策定された F/W が生きている。
等々、開発者にストレスが貯まる現場は、多々あります。
それらに比べたら、社歌やラジオ体操なんて、数分間の辛抱なので、些細なことだと思えます。

最近は、それに加えて、セキュリティ問題で、USBやインターネット接続もママナラナイ現場もあり、不条理環境は拡大しているようにも思えます。
それを不条理と感じている私が「セキュリティ意識が欠落している」とも言えるので、上記の主張は、天唾かも知れませんが。

Widthその後

ひらがなって表音として完璧ですね


http://blogs.wankuma.com/naka/archive/2010/06/14/190172.aspx

Width の発音はウィドゥス その３

http://blogs.wankuma.com/carbonara/archive/2010/06/14/190161.aspx

英辞郎

http://blogs.wankuma.com/rti/archive/2010/06/14/190168.aspx



発音記号は統一されたモノだと思っていました。軽く裏切れた感かします。

発音記号が的確でなくても、許容範囲で表現できるから、普及してるのだと思います。発音記号がなければ、もっと混乱しそうです。

一種の表音記号的役割があるのかも知れません。



聞く人が、どのように聞こえるかは、別の問題で、聞いた人が、聞いたママ発音記号を記述したら、その時点でずれてきます。

発音記号の校正責任者は限定されたほうがよさそうです。



「かな」は表音記号だと言われてますが、そうでしょうか。日本語にはアナウンサー向けのイントーネション辞典はありますが、発音記号に相当するものがありません。

カナに発音記号の意味を持たせるには無理があります。

発音表記にはルールがあり、「こんにちは」の「は、わ」問題や、長音の表記問題や、「ん」の扱いなど細部に渡ります。

おおじ=>オージ=>大路

おうじ=>オージ=>王子

は、表記上、区別がつきますが、音では区別がつきにくい。音引きはカタカナしか適用しないのもヤヤコシイ。

「がぎぐけご」は濁音と鼻濁音の二種類ありますが、表記上の差はない。

戦前の旧仮名使いでは、「カ」「クワッ」で分けていた。

でも、

てふてふ = >ちょうちょ

そうでせう => そうでしょう。

のように、発音とは無関係の約束事で表記されてました。丸暗記していたらいです。



Aluminiumなど xxxniumuという物質は多いです。「アルミニウム」と書きますが「アルミニュウム」「アルミニューム」と揺れ表現があります。

アルミニュウムtが表音に忠実な気がします。

外国語を母音が5つしかない日本語で表記することに無理があるので、誤差は目を瞑るしかないでしょうね。



だれかが仰ってましたが、 Aさんが「幅」の意味でWidthを「ｳｲﾝｸﾞ」と発音したとき、聞いた人が「ウインド」と聞いて「幅」と理解すれば、意志が通じます。

私の見ている「赤色」がBさんは(私にとっての)緑に見えているかも知れません。でも、ともに「赤外線に近い色」と認識していれば、意志は通じます。(違う色に見えているか否かの証明はできないらしいですね)

これらの意志疎通は、局所ローカル範囲ならば、充分だと思います。

でも、交流の範囲が大きくなり、方言要素が入ってくると、雑音要素が入るので、意思疎通に齟齬が生じるのではないでしょうか。

ある程度の広域の範囲ないでは、同一発音であるほうが、都合がよいと思います。



同じ単語が、業界内方言のように、独立している現象は、興味深いです。それも文化かなと思います。

でも、 Width をワイドとは読めない....拘っている私

メーカーの都合?

FIFA W杯が始まりました。番組の提供を見ていると、キリンとコカコーラが並んでいる。


商売上、同一業種が同一番組の提供はしないモノと思っていました。どちらも、飲料メーカーなので、競合するのではと疑問が沸きました。

　キリンは、ビールメーカーで、コカコーラはビールを作っていないので、競合相手ではない。だからOKだそうです。

?でも、キリンの飲料ってあるよね。......それらはキリンビバレッジの製品で、キリンビールとは無関係と見なすそうです。

一方で、キリンビバレッジはキリングループでキリンの看板であり、一体であるとも言っているようです。

商売上の方便のようで、適当に使い分けている感じを受けますが、まっ良いか。

ラジオ体操って、そう見えるの?

春は新入社員が目立ちます。先日も電車の中で大きな声で会話していました。(女性二人。勤め先が別の友人のようです。)


車内で大声を発すること自体、マナー違反ですが、それはさておき。

「うちの会社、毎朝、朝礼のとき、ラジオ体操するんだよ。軍隊みたいでしょ。」

「それくらい何よ。うちなんか、朝礼の前に、ラジオ体操して、巻物を読んで、社歌を斉唱するんだよ。夕方も終礼があるんだよ。よっぽと軍隊チックでしょ。」

ラジオ体操が軍隊に映るの?

理解に苦しむ感覚。体育系でなくても、部活なんかで規律は身につくと思うのですが。規律に無縁で社会に出てきたのね。

巻物読んで、社歌を歌うのは、あの会社の系列で結構有名な行事です。電車内で大きな声で話していたら、何か言われるよ。

ラジオ体操と軍隊を同列に扱うのは、軍隊を甘く見過ぎているのでしょうね。自衛隊の立場がはっきりしないまま、６０有余年。

すっかり平和慣れした結果の現象なんでしょうか。

採用しなかった理由

前回のエントリーで、「採用しなかった理由」に対してコメントもいただきました。


モノを作ったり、規格や約束事を決めるときは、一つ一つ原案を積み上げていきますが、その際、採用する案と採用しない案が出ます。

「xxxxの理由で採用する。」という決定プロセスは明文化され残りますが、採用されなかった事案に関しては、明文化されても、細部の理由は残っていないことが多いです。

失敗した理由を分析して、防止に努めるのは常道てすし、バグつぶしの現場では、バグ標に原因と対処を記載させることで、バグに対する意識を高める効果があります。一種のノウハウですね。

採用しなかった理由も、ノウハウなので、蓄積していけば、財産になると思うのです。

担当者の感性で却下したり、利権が絡んでの不採用だっら、理由が書けないから、無理か。

利権がらみで採用した時も、怪しげな採用理由をつけるから無理か。

残しておきたい情報は残らないものかも知れませんね。

キーボードの配置

日本国内では、119キー,112キー等ボタンの数が異なるキーボードがありますが、基本配置は統一されています。


記号の配置はJIS配置のようですね。

国外では、83,84,101,102キー,,,109キーがあります。記号類の配置は米国配置が多いようです。

PC黎明期は、記号類が米国配置のキーボードがあり、結構使い込んでました。ATキーボードが普及したとき、使いにくくてストレスが貯まったものです。

JIS配置のキーボードを接続していても、日本語以外のOSで稼働させたとき、キーボートは米国配置で動作します。

(このような局面では)JIS配置に慣れきった今は、記号入力時にストレス一杯になります。

JIS配列を決めたとき、なぜ、AlphabetはQWERTY配列を踏襲したのに、記号類を異なる配置にしたのだろう。

同じ配置にしていれば、多くの人の人がストレスを感じなくて済むのに。

漢語が好き?

入力欄の文字を消す、=> 消去する


コンボ(ラジオボタン)で選ぶ=> 候補から選択する。

など、和語が熟語に校正されたりします。



「熟語」+「する」という用法が好まれているのかな。

必須項目から空欄のときの警告では、「xxx欄を埋めて下さい」が「xxx欄が空欄です。」「xx欄が無効です。」に校正されたり、

「xx欄が不適切です」というメッセージになったりします。

「空欄」は判りますが、「無効」「不適切」では、何がどのようにダメなのか判りにくいです。

確かに、和語は「やぼったさ」がありますが、意味を伝えるには、向いているように思うのです。

和語全体が嫌われている訳でもないようです。

「終了確認(Yes or no)」　という確認メッセージを出すと、「本当に終了しますか?(yes or no)」に校正されます。

以前にも書いたのですか、未だに、「本当に終了しますか?」が上から目線に感じます。

単純に「終了確認(Yes or No)」「登録確認(Yes or No)」のほうが、当たり障りがないと私的には思います。



「全ての項目を埋めて、"次へ"ボタンを押してください。」が「全項目に入力後に、"次へ"ボタンを押下してください。」になります。

和語で表現すれば、長くなるので、間延び感が出るので、嫌がるのかもしれません。

歴史的にみると、漢語は男が書くモノ、カナは女子供が書くモノ、という時代があった影響もあるかも知れません。

背景もあり、和語 < 漢語 という意識が働いているのがも知れませんね。　なんか自虐史観に通じるものを感じるのは変でしょうか。

知らずに落ちた、大きな落とし穴

RDBで、大文字小文字を区別しない、同一視するという、動作は、各レコードの項目のリテラル値の事と認識していました。


とある、SQL ServerのRDBは、 Create DataBaseの際の照合順序が Latvian_CI_AIになっていました。

私は、Create tabble時の項目名と、　Select/Insert/Update の 項目名の　大文字小文字を変えて書くことがあります。

文脈で強調したいときや、次ぎの処理でキーワードになる項目は、、すべて大文字にし、付随項目は小文字で記述したりして、 書き分けています。

これが、仇となりました。

この照合順序「Latvian_CI_AI」で作成したデータベースは、項目名の大文字、小文字を区別するのです。



create Table test ( ID char(3) ,id char(3))



の文が、エラーにならず、正常にテーブルが作成できます。もちろん

insert into test(ID,id) values('xyx','abc')

も実行できます。結果は、



select ID , id from test

ID id

1 xyz abc



となります。



一方で、.netのDataTable等は、項目名の大文字小文字区別はしないので



DataTable dt = new DataTable();

cmd.CommandText = "select ID,id from test";

SqlDataAdapter oda = new SqlDataAdapter(cmd);

oda.Fill(dt);

dgv.DataSource=dt;

と記述すれば、 ID と idは同値になり、 select文の idは、id1と項目名が補完されて、 DataTableが作成されます。



ID id1

1 xyz abc



となり、 SQL文



object ID = dt.Rows[0]["ID"];

object id = dt.Rows[0]["id"];

object id1 = dt.Rows[0]["id1"];

で確認すると、 IDと idは同値、 id1に　"abc"が入ります。

つまり、 SQL文が "select ID,id from test"　であっても、 "select ID,id as id1 from test" と解釈されます。

うーん。許されていいのかなぁと少し思うのです。



C系言語のmember名は大文字小文字区別しますが、 VB系などの言語は区別しません。

DataTableなどの、DataBase系の部品も、区別しません。　それなのに、接続先の SQLサーバーの構成次第で区別するというのは、一貫性を崩しているような感じがして、シックリきません。



無知だった責任と、Create Table時の項目名を使っていないことの責任も、私のにありますが、このようにする必然性ってあるのかしら。

また、照合順序の指定が、なぜ、項目名に影響するのか不思議でした。

Org : オルグ

元ネタ http://blogs.wankuma.com/carbonara/archive/2010/06/01/189633.aspx


シリーズにする意図はないのですが、どうも気になって。

変更前のFileをBackupも兼ねて、拡張子.ORG を付けて保存をします。

この .ORGを　「ドットオルグ」と発音する人がたまにいます。

以前の意見でもありましたが、、自国風の読み方だからOK だとしたいのですが。

マクドナルドをマクドとするのは発音通りなので、OKとしています。

「ドットオリジ」ならまだしも、「オルグ」にするのはどうも。

ローマ字読みするにしても、省略形の子音Ｒをル、Ｇ をグとして、オルグ....

「ドットオーグ」なら理解できる。



オルグってあるのか調べると、organize/organizer　で社会運動/学生運動に関連ありそうでした。

発音を重視しないためか、スペルを無理から読もうとして、変な読み方をするようですね。

測るの意味のMeasure もメジャーが定着しているとむ思いきや「ミーシュアー」と言う人がいました。

この延長線でいくと、Knightを「ｸﾅｲﾄ」とよんでもおかしくないのか、 Know はクノーか。

vac･cine　がワクチンなのはドイツ語のVakzinからなので、納得。

中国はChina で日本語読みすれば、シナになりますが、、支那　と書けば、差別用語云々と言われたりします。

こういう、思想性は理解しがたい面がありますが......

一貫性のない省略発音は、どうにも感が拭えません。

痒いところに手が届かない

Excelで報告書の雛形を作っておいて、言語アプリで項目を埋めて報告書を仕上げる業務フローは多くあります。


タイトル欄、内容欄、規定値、入力欄など、項目の性質は幾つか種類に分かれます。

例

　　　　タイトル欄　=> 製品名

　　　　内容欄　　　=> ハイブリット電球

　　　　規程最大長　=> 135mm

　　　　個別実測値　=> (実際に測定して、Excelシートに記入)

(*)製品規格通りに生産されたかのチェックシートとして使用



内容欄と、規程最大長は 言語で埋めて、個別実測値欄のみ入力する仕様です。

入力欄は個別実測値のみなので、規定最大長などの個別実測値欄以外はロックしたいです。

これが、一筋縄はできない。

そもそも、EXCELのセルロックの手順がスッキリしない。セルの属性で「保護」頁に「ロック」のチェックボックスがあるのだが、何故か。デフォルトでチェックが入っている。

ても、シート保護しないと、有効にならない。



言語でシートの項目に値を埋めていくのは　ADO.NET の Excel-Provider を使えば、 excel.object を介さずにできるので、便利です。

(*)Excel objectは、異常時にタスクが残ったりするので、、いろいろ回避策が必要なので、使いたくない。

でも、予めシート保護していたら、項目書き込みができないのです。雛形レベルでシート保護はできない。

言語で、項目を埋めて、シート保護して、ユーザーに公開したい。

シート保護のステートメントをマクロで組み、(ActiveSheet.Protect,ActiveWorkbook.Save)

これは、 Excel Objectを介して、それほコールする。(xlApp.run("SheetHogo"))

どうにか、動作はしているが、スマートとは言えない。

VSTOを使えばスマートになるのかも知れないが、Visual Stdio 2005だと、ライセンスがない。

言語で埋め込むのでなく、ExcelマクロがDBを見に行って埋め込んで、自分でロックするのかな。

でも、VBAでDataアクセス処理は書きたくない.....(我が儘だなぁ)

ありがちな業務フローだと思うのだが、他の人はどのようにしているのだろう。

温故知新

6,7年ぶりにVBAアプリの開発をした。


旧のADOの使用方法など、忘却の彼方で、

・ RS.Open sql ....

など接続型のアクセスなど、思い出すのに半日近くかかってしまう。....orz

・function abc()

abc=戻り値

End function

メソッド名への代入が戻り値..なんて、当時は、疑問を感じず使っていたのに、忘却している。

エラー対策を on error で行うのが如何に面倒なのか思い知る。

いまや、データにメソッドが付いているのが当然なので、型からメソッドを検索という思考回路が確立しているので、

Replace(a,b,c) やtrim(x) など、文字列関数の引数が文字列...という事すら、戸惑ってしまう。

うーん。当時は、それが当たり前で、常識のように使っていたのだが、より便利なものが登場すると、「捨て去るのは早い」ということか。

型にメソッドが付いていない事が、不便だったとは、まさに温故知新。

今の環境が当然と認識しがちですが、昔の手法の不便さが見えたら、今の理解も深まる。

VS2010が目新しいが、何時、陳腐化するのかなぁ。 .net1.xは陳腐化したが、4.0のベース文化は2.0なので、VS2005は当分現役のようだ。

それだけ完成度が高いということか。でも。

Excelワールド(VBAワールド)は廃ることがなさそうなので、VBA文化(VB6文化?) は残り続ける感じがる。(ボソ:積極意欲はない)

メッセージの管理

とあるシステムで。


(*)文化の違いなので、批判ではなく、私的に合点がいかなかった事項。

小規模システムならば、直接リテラルを記述するのもアリと思ってますが、そこそこ大きくなると、メッセージにIDを振って、ProgramからはメッセージIDで表示するのが定番です。



このメッセージIDの振り方にローカルルールがあるようです。

一般的には、 ID構成が 種類 + 応答+ 連番 + 表示文字列 になっているのが多いようです。

　　　種類 : 情報/警告/エラー

　　　応答 : OK/ OKCancel/ YesNo....

　　　連番 : 1～

　　　表示文字列: データ更新します。いいですか......



あるシステムのルールでは、表示文字列の読み仮名をベースに連番を振るようです。

あ: 01000番台 い: 02000番台 .....お: 05000番台

か: 11000番台　き: 12000番台 .....こ: 15000番台

: : :

わ: 9100番台



「データ登録します。」だと、"で"なので　ID=34001: となります。

「DBに接続できません」でと、"ディービーに接続"と読みる、　ID=34002か振られます。



最初の登録時に文言に依存してIDが決まる。

でも最初に設定した文言が不適切で、文言修正したい事は、よくある話です。

「更新しました」を「修正しました」に直すのもありそうです。このばあい、15000番台がら22000番台に変わることになり、

プログラムの引用箇所の修正も発生します。

ロジック以外の要因でソースに手を加えるのは、抵抗感があります。デグレの原因にもなります。

不具合誘発よりも、番号管理を優先にしているようで、本末転倒に映ります(私的にですが)

顧客IDの付け方も、同様の読み方ベースで付けているシステムがあります。結婚や合併で名称が変わったらどうするのでしょうね。

コボル全盛期には、変数名台帳、関数名台帳などを作って、それらを用いた管理が、進捗管理だと錯覚している管理部署がありました。

その文化で育った人には、リファクタリングは、悪魔の誘惑に見えるそうです。



関数名や変数名、顧客IDなんてアイウエオ順で単純管理できるものではないので、管理対象ではないと主張しているのですが、既存ルールを変えるとこまで行かないのは、力のなさかな。

知らなかった。C#の文字列加算など

Dim str as string = "[" + 4 + "]"


は,strict onの時は、コンパイルエラー。 offのときは、実行時に型エラーで落ちます。

Dim str as string = "[" + 4.ToString() + "]" と書くとOKですし、字面も納得です。

C#だと

string str = "[" + 4 + "]"; と書いても、エラーにならず、実行できます。



恥ずかしながら、いままで知りませんでした。VB同様に "[" + 4.ToString() + "]";と書いていました。

コンパイル解釈が良くできているとみるか、基準が甘いと見るかは意見が分かれそうですね。

でも、脳内コンパイラーがNG信号を発して、不安定感があります。

ほかにも、勝手に制約があると思い込んでいる事項がありそうです。



汎用デリゲートは、　Func<>,Action()だけだと思っていたら、MethodInvoke,やPredicate　があるを先日知りました。

再度入門書を読み直す必要があると思った次第。

牛丼業界明暗

低価格化した、すき家、松屋は黒字、価格堅持した吉野家は赤字らしい。


280円対380円の差は大きかったようです。

吉野屋は、食券制度に反対で食後精算のスタイルを続けると明言していますね。

帰り際の精算の時に、店員がキチンと挨拶するのが、基本だそうです。立派な接客方針だと思います。

立派さでは、100円の価格差を克服できなかったという訳でしょうか。

挨拶や接客は期待してなく、安いほうがよいという顧客が多いのでしょうか。



吉野家のメニューからカレーが消えましたが、使用している伝票には、カレーの欄があります。

聞いたところ、伝票は大量に作ってしまったので、使い切るまで再印刷しないそうです。これも地味な努力ですね。

松屋は、味噌汁が標準で付いてくるので、割安感があるのが強みでしょうか。

そうかと思うと、あるラーメン点では、チャーシュー1枚80円で、ラーメンを注文するとき、「チャーシュー何枚にしますか?」と尋ねられます。

(*)「要らない」と言ったら、嫌な顔をされたような、気がしましたが....

チャーシューは分厚いのですが、80円/1枚は高いような。

デフレは未だ続きそうですが、外食産業はもっと二分化が進むのでしょうね。

Width ウィズ? ワイズ?

プログラム言語は書き言葉なので、発音を軽視しても困らないのですが、気になります。


Widthを「ワイズ」と読む人に時々出会います。面識が数回以下の時は、指摘するにも気が引けます。

(wídθ, wítθ)ウィズに近い。

ワイズと発音するのは、どこに由来するのだろう。どうやら、靴業界らしい。

http://amatoboss.blog31.fc2.com/blog-entry-783.html

一方で、ワイズ読みを肯定している記事もあります。

http://blackwatch.seesaa.net/article/16406122.html

いったん、広まると、誤読も正常になるのか。日本だけでしょうか。足幅のWIdthと Wideが混乱したのか?

Hidden はhídn(ヒドン)ですが、 ハイドンと呼ぶ人がいました。hideの過去分詞だといってもハイドンはね。...

heightは、「ハイト」か「ハイ」か判断つきかねますね。[háit]なのでどちらもあり得そう。

いままで出会ったなかで、極めつけは

goto xx のことを 「ゴートー xx」と読んだ人。　　ネタだったのか、マジだったのか、不明ですが。まじめな会議上での出来事でした。

SilverLight3.Tabcontrol の多段タグの動作

のように、タグ頁を配置しメニュー代わりにHyperLinkLabelを使っています。こういった利用は多いと思います。
タグ頁が増えると、一段に収まらず、二段以上に分離されます。
二段になると、HyperLinkLabelが消えるのです。


全ての頁から消えるならば、動作が一定していますが、消えない頁もあります。


バグなのか、仕様なのか判断できない。
でも、リンクの表示のみが消え、他のコントロールだと消えないので、不具合バグでしょうね。

SilverLightを業務で使う時、DBとの連携はWCFを介す必要があり、また、開発時に、２プロジェクトが連携するのが、業務Webアプリの開発のネックな気がします。
慣れてないので、業務Webの開発は、従来のasp.netの方が開発能率が高い。慣れて同列にして、比較評価したいですね。

サラダ煎餅の「サラダ」って何

サラダ油は、ドレッシングやマヨネーズの原料となるもので、日本独自のものらしい。


サラダは、野菜に調味料を加えた料理のことらしい。

野菜サラダというくらいだらか、野菜以外のサラダがあるのかな。

あった。「卵サラダ」、「ツナサラダ」、「ハムサラダ」、「マカロニサラダ」 (出典) http://ja.wikipedia.org/wiki/%E7%94%9F%E9%87%8E%E8%8F%9C



サラダ煎餅のサラダがますます解らない。Saladとsoltが同じ語源なので、塩味のことを「サラダ」と称する説もありました。

サラダ味とも言いますが、サラダ油自体は、塩味がしない。なんだろう。適切なページがあった。

http://www.union-net.or.jp/cu-cap/saradaaji.htm

せんべいと塩の「つなぎ」がサラダ油だったのか。説得力のある説。



浅草名物の「電気ブラン」もそうですが、「名は体を表さない」的な商品名は多そうですね。

ゆず入り調味料

ゆず胡椒、ゆず七味など、ゆずが入った香辛料が発売されています。


ゆずの香りが強い為か、胡椒や七味の辛さが消えてしまうようです。

純粋の胡椒や七味の倍くらい振りかけても、辛さが薄い。

味覚の感じ方が違うので、そのような錯覚をするのでしょうね。

辛くないからといって、多量に使うと、体に悪そうです。

上記のモノは粉末状ですが、練り辛子みたいな、練りゆず胡椒が売ってました。

探してみると、液体ゆず胡椒 がありました。

http://item.rakuten.co.jp/hakatameisan/10000246/

最近、香辛料の種類は増えました。大きなスーパーに行くと、1つのラックが全て香辛料だったりします。

世間の人は使い分けているのだろうか。私には、とても使い分けできません。...orz;

地中海付近やインド等のスパイス・ハーブが一般化したのも一因なのでしょうね。

食べ慣れないので、和食や洋食にどうも合わないと思うのは慣れの問題か。

ハープディーの種類も多いですね。

従来の日本の香辛料は種類が少なかったのかなぁ。

胡椒、山椒、七味、わさび、辛子、くらいしか思い浮かばない。

個人情報保護(?)で不便な目～本籍って

(*)私の本籍地は現住所とも、育ちも無縁の所で、2代前の親族が住んでいた場所です。


本籍地を記憶していない私が悪いのですが、それは棚に上げます。....ww...

本籍地は運転免許証を見れば判るので記憶するつもりも有りませんでした。



所要があって、役所に戸籍謄本を取りに行きました。

本籍地を記入しようと、運転免許証を出すと、欄が空白!!

　数年前から、本籍地は起票しなくなったらしい。更新時に言われたらしいが、すっかり忘却。

さぁ、困った。自分の本籍地を知る術がない。

　窓口に相談すると、住民票に本籍地が記載されいるので、住民票を取れば判る....と言われたが、そのために、住民票を取るのも釈然としないなぁ。

他に手がないので、住民票を取り、再度、謄本の申請をしました。



　本籍は、戸籍のカウント単位として設定されたらしいが、現住所と無関係で、どこに設定してもよい。

皇居の住所を本籍にしている人もいるとか。



　差別問題で本籍を表面化しないようになったようですが、日常生活で本籍を意識することはないし、左右されこともありません。

選挙権等も、現住所が意味を持ちます。

　あちこち、ググってみても、「戸籍の管理」という意味合いは書かれててますが、事務処理上の戸籍の意味が見えない。

同一住所を本籍とする世帯が　幾つ、幾万世帯あっても、よいようなので、「戸籍を管理する」意味が見えません。

「本籍」制度って空洞化しているのでは？　と思った次第。

住民登録と一対にして、戸籍も世帯単位にしても、不具合はないのでは？

海外赴任でも、住民票は残しますよね。普通に生活していれば、どこかの自治体に登録する筈なので、住民票を戸籍謄本機能を持たせれば良いと思う。

戸籍は国籍の証明になるか、住民票はならない...と指摘されそうだから、住民票に国籍欄を設置すれば、良い話。

謄本や抄本といった、難解用語も時代を感じ。　全部か一部かの違いですね。

　何か他に、気付かない、重要な意味があるのだろうか。

Sleep祭り(?)

http://blogs.wankuma.com/jitta/archive/2010/05/08/188819.aspx#FeedBack


http://blogs.wankuma.com/episteme/archive/2010/05/08/188833.aspx

その他。



事の発端は置いといてて。

Sleep(1000)の測定結果がいろいろあがっています。

何れも約1000mSec経過後、処理を再開という面では揃っているのですが、Sleep()のexit条件である、経過mSecは「1000mseecを超えた時点」ではないのね。

結果をみると、Windows OSの時刻カウンタが 15mSecなのでね、998～1014の範囲でExitしているようです。

これって、脱出判定の要素自体、15mSecでバウンドされているのかなぁ。

1000mSec以下でExitする仕様が、どうもスッキリしない。1000msecを超えた時点..としたら 1002～1017msecでexitするので、誤差が大きくなるからでしょうか。

「目覚めよ」イベントの発生はスレッド/タスクコントローラが行っているのでしょうから、そこの判定単位の問題かな。



高解像度タイマーで計測すれば、1msecでもSleep()可能なんでしょうが、仕様変更になるからできないのかも。

Client系のOSでのSQL Serverの Timer値も、15msec単位ですし。



ついでに気になったのは、Sleep(1000)で、最大でも 1013msecで目覚めているようですが、1100msecで目覚めても、仕様通りな訳ですよね。

他のスレッドやタスクの状況で変わるのでしょうが、 sleep(1000)が 1200msecなどの、大幅に遅れて目覚めるような、テスト環境って作れるのだろうか。

ノンプリマルチタスクで無限ループにすると、目覚めることすらできないと思う。 Sleep()で遊ぶのは難しそうです。



今回のSleep()騒動は、精密ドライバーが必要な場に、大工道具のドライバーを持ち込んで、且つ使い方が間違っているようなもので、なんともはや....な思いでした。

しかしそのお陰で、気にとめていなかった、Sleepの奥深さを知ることができて、良かったです。

お疲れ様でした。

現状の状態を考慮しないメッセージ

夜間や不在時に電話を転送するサービスがあります。


(事務所のサービスの例)

xxxx# を押すと「サービスを開始します。」とガイドがあり、転送モードになります。

yyyy# を押すと「サービスを停止します。」とガイドがあり、転送モード解除になります。



転送サービスの開始と停止の操作なのだから、「転送サービスを開始／停止します。」とすぺきでは?　と思うが、

電話操作する人は、転送モードを操作しているから、不要だとも言える。

それはさておき。



現状が非転送モードのとき、転送開始を押すのが正常系操作だが、

現状が転送モードのとき転送開始を押したり、非転送モードのとき、転送解除を押すことも、あり得ることなので、異常系とは言えないでしょう。

現状の状態に無関係に、「サービスを開始します。」ゃ「サービスを停止します。」とアナウンスされる。



利用者の立場では、現状態がなんであっても、「開始する」かか「停止する」かが問題なので、このアナウンスは適切だ思う。

アプリの場合はどうだろう。既に、objectが状態Aになっているときに、「状態Aになれ」と命令を発したとき、「すでに状態Aになっています。」とガイドするシステムがあるようです。

「すでに状態Aなので、あなたの操作は間違っているよ。」と指摘されているようで、UIとして、どうだろうか...と思った次第。

システム利用者にとっては、状態の仕組みを意識させないほうがよいと思う。

開発者向けのメッセージの場合は、状態を意識したメッセージのほうが、不具合追求には便利です。

ということは、メッセージは、純粋利用者向けのメッセージと開発者向けのメッセージ(デバッグ等の追跡用)の使いわけがいることなのでしょうかね。

その類の追跡用メッセージは完成度が高まると、実行されないステートメントとして残ってしまうことになり、コードカバレッジの面で、問題にする人もいるようです。



携帯やデジタル家電が普及し、一般人も、機械の動作モードを認識している昨今、メッセージの表現は、なおさら難しくなりますね。利用者側に立ったメッセージがよいとは思うのですが。

中身の見えるゴミ箱

今年四月中旬に阪神電鉄の各駅のゴミ箱が、透明なアクリル状のスケルトンな物に置き換わりました。


写真がないかなぁと、ググってみると、ありました。ネットはありがたいですね。

http://blogs.yahoo.co.jp/kyone8020/archive/2010/4/12 の中頃。

　関東では、多いらしいですが、関西は馴染み薄だったので、興味津々です。

家庭のゴミ出しも透明な袋でないと、処理してくれないようです。

　心情的には、中身が見える状態で捨てるのは、家の中を見らている気がして、抵抗感があるのですが。

中身が見えないと、適切な分類をしないとか、対応外の物を捨てるとかがあるらしい。

駅の場合は、テロ行為防止の意味もあるのだとか。

　数十年前の公衆電話は、不透明なボックスでしたが、中で良からぬ行為をする輩が居るとかで、透明な公衆電話になったとか。

　そのときも、透明化には抵抗する世論があったらしいが、慣れると抵抗意見も消えていったようです。

スケルトンのゴミ出しも、直ぐ慣れるのでしょう。

ゴミ出しマナーを個々人のモラルに期待しないで、ルールや仕組みでカバーするのは、寂しい思いがしますが、他に妙案がありませんしね。

ゴミが見える状態の風景は、....うーん...

「こだわる」にこだわってなかった。

「拘る」と書くことも多かったのですが、これだと「かかわる」と読めてしまう。


それだけでなく、「こだわる」は「つらまらいことに固執する」というマイナス表現だそうです。

漢字表記でなく、ひらがな評議が良いようです。

言葉は生きているので、最近の用法では、「細部にこだわる。」「勝ちにこだわる」も肯定する方向のようですが、知らなかったのは不覚..orz;

ソースコードにこだわる。変数名にこだわる。...といった表現は、眉を顰める人がいたのですね。

　「やばい」が「すごい」の意味で使われている昨今、急速に、用語の意味が変わっているように、思えますが、

昔も、これくらいのスピードで、意味が変わっていたのかも知れませんね。

コマーシャルで「おいしさのこだわり」等の表現が流れているので、変化速度は、早くなっているとは思いますが。

流行っても、すぐ廃る用語もあるので、定着するかしないかは不明ですが、廃れない誤用は、受け入れる土壌があったのでしょうね。

シートベルト未着用で捕まった

「捕まった」と表現している時点で、反省感より「運が悪かった」感が勝っていて、自己チュウなんですが。


自宅前の路地から50m先の大通りにでるまでの間の出来事でした。

合流地点で信号待ちしている間に、自転車にのった警邏の人に呼び止められて切符を切られました。

どう考えても、仮のお巡りさんは隠れていたように思う。

違反したのば、事実なので反省しないと、いけないのですが、不運感しか残らない。

これでまた、ゴールドが遠のいたので尚更です。

そう言えば、路地の入り口の電柱に隠れるように止まっている原付警邏を見たことがあります。シートベルトや携帯電話をチェックしていると見ています。

　一旦停止違反の検挙も隠れているお回りさんに検挙された...というのを聞きます。

隠れて検挙するより、堂々と立っていて、注意を喚起したほうが抑止力が高いと思うのです。....これだと、反則金のノルマが達成できないか。

　道交法違反は、他の犯罪のような罪悪感が乏しいので、無くならないのでしょうね。飲酒運転は一般犯罪にしたほうが効果があるように思う。

捕まった本人は「反省」するよりも「運がなかった」程度にしか思わないので、一罰百戒の見せしめ効果も疑問があります。



　タイヤが動く前にシートベルト着用するのが本来だそうです。皆様、気をつけましょう。

携帯サイトの対象基準

キャリアによって、ブラウザーのタグ解釈が異なり、表現が異なることは、幾度となく書きました。

は、 GroupBoxの外枠罫線のような、の表現になります。

を用いたページや、.text(わんくまブログ等)のright menu/left menuも、罫線矩形が表示されます。

携帯で該当ページをみると、AU/Softbank携帯だと、綺麗に罫線矩形が出ますが、docomo携帯では表示されません。

句でbackgroundColor指定しても、docomo携帯では、表示されません。



表示されないのは、仕方ないのですが、携帯サイトを AU/Softbankに合わせるのか、Docomoに合わせるのか悩ましい所です。

dococmoに合わせてると、AU/Softbankでは物足りなく見えます。

AU/Softbankに合わせて作成しても、dococmoで不具合なくされるからAU/Softbankに合わせるほうが良いのか。

ItalicやBoldも無視されたりします。

携帯サイトは制約が多すぎる....また愚痴になってしまった...orz

改めます.....ってなんだ。

最近、金融機関からセールスの電話が多く、電話を取り次ぐ機会も多々あります。


指名のあった人が不在のときは、当然ながら「xxxは席を外してます。ご用件を承ります....」となるのですが、

先方は、「そうですか。では、改めます。失礼しました。」と切ってしまう。

何時の頃からか、「改めて電話をかけ直します。」を省略して「改めます。」で済ますようになった。

金融機関なんかは、電話の受け答えの教育はしっかりしていると思っていただけに、がっかり感があります。

　電話を書けた方なだけに、なおさらですね。

電話の相手名を訊くときも、「失礼ですが。」の一言で済ませる人がいます。電話を受けた方であっても、

「失礼ですが、どちら様でしょうか」と言うべきでは。

等々愚痴っていたら、最近は、上司やお客様に電話して不在のとき、「xxxは不在です。」と言われたら、「では、コールバックお願いします。」

平然と、コールバック依頼する人がいるとか。

　失礼さの感覚が変わってきているか、きちんと教える人がいないのか。

「千円からお預かり...」「...でよろしかったでしょうか」「..になります」などの接客用語よりも根が深いと思うのです。

偽タバコとバールのようなもの

2007年の漢字は「偽」でした。食品偽装や耐震偽装の話でも、ありません。


「偽 +　固有名詞」は固有名詞の偽物を表すのが自然だと思うのです。

偽札は、お札の偽造です。偽称 ,偽善 ,偽悪などもそうです。

某国が行使していると報道されている、偽タバコ、偽ドル札。　この「偽タバコ」が引っかかります。

海賊版CDは偽CDとは言いません。偽メーカー品は、偽ブランド品と言います。

偽タバコはタバコの偽物(タバコの葉以外の植物で作ったタバコのようなモノ)でなく、「マイルドセブン」というブランドタバコの偽物を作っているんですよね。

矛盾のない言い回しは不可能なので、目くじら立てるほどでも無いのですが、なんか引っかかります。

偽タバコよりも「偽マイルドセブン」と表現するほうが自然と思います。固有商品名が入るのがマズイのかな。



強盗のニュースなどで、「バールのようなモノでこじ開けた」と読み上げていますが。バールのようなモノは、「バールでは無い」と断言した事になりませんかね。

この話題は、清水義範氏が小説に書いてます。http://homepage1.nifty.com/eien/list/bun_06.htm

ても、「バールのようなモノ」以外の言い回しって、思いつかない。目撃者がいないと、「バール状のモノで」と断言できないし....

バールという名詞を使わず、「何かでこじ開けて」でよいと思う。

マイナスイオン

数年前にマイナスイオンがブームになったとき、引っかかるものがなく、受け流していました。


マイナスイオン　= 陰イオンだと解釈してました。

今の定義では、正負イオン/陰陽イオンとは、無関係のもので、和製英語らしい。

本来の陰イオンのことを Negative Ionと言わずに Minus Ionと表現する先生がいましたので、話をヤヤコシクしています。



マイナスイオン発生器が健康グッズの販売品目なので、軽はずみなことは、言えないのですが、ググッて得られる情報は、芳しくないのが多いようです。

マイナスイオンの定義が、見えてこない。発生メカニズムもはっきりしない。

効能書きの根拠は、どうなんでしょう。

紅茶キノコと同様の類な気がします。健康に益がなくとも、損が無ければ良しとしましょうか。



石綿のように、長期間使用した結果、「害がありました。」では洒落になりません。

携帯の微弱電波もそうですが、無害の証明は難しいので、なおさらです。



「マイナスイオン」はマーケティング用語に分類されるのですね。

キャッチコピーの難しさかな。

申請書は不親切

今話題の子供手当の申請用紙が来ました。


自治体によって形式が異なるとは思いますが。でも、申請案内が不親切。

送付する封筒が入っていたが、切手の欄は、受取人払いでなく、「切手を貼ってください」と書いてある。何円切手か書いていない。

しかも、定型より大きい封筒だったので８０円なのが不安。



振り込み先の口座欄がふるので、家内の口座を書いた。ところが、世帯主(私)の口座名と違うので、書類不備にされた。

・世帯主の口座に限定するなら、その旨を書いて欲しい。

・切手の貼り付けが必要なら、何円切手かを書いて欲しい

・適切な記入例を添付して欲しい。

と愚痴っていたら、老年者のバスのチケットなどの申請も、判りにくいらしい。

書類に記入して役所に持って行っても、一回でOKになったことが無く、不備をしてきれ、何度か提出し直しさせられる。

申請者の立場にたった、申請サンプルをつくるのも、大事なガイドだと思うのだが。

申請形式を理解しない利用者に責があるのかなぁ。...お役所仕事な気もする。

世知辛さが加速

冷え切った景気の回復は何時になるのだろう。仕事を求めて右往左往......はさておき。


立ち食い店やラーメン屋などファストフード店のサービスも、見直しが行われているようで、トッピングに影響が出始めました。

・いままで、無料で提供していましたトッビング類を有料とさせて頂きます。

・無料キムチですが、従来、カウンターに常設してましたが、ラーメン等の食事の配膳時に容器をお持ちします。

・開店以来、ネギの入れ放題を維持してきましたが、諸般の都合で、入れ放題を止め、調合時に入れさせて頂きます。

という張り紙や運用変更の店。



・食堂で、すり生姜のお代わりをしたら、「二杯まで」と言われ、有料でもいいから、「もっと欲しい」といったら断られた。

・生姜、ごまが入れ放題の店でも、付属のスプーンが小さくなって、多くは入れにくくなった。何回も入れるのは抵抗あるしね。

・ニラやニンニクの供給容器の中身を常に 1/3程度にして、多く取らないように心理操作

という、涙ぐましい店。



・本日、生卵無料サービス..という天丼屋があった。

翌週、訪れると潰れていた。



寂しく、ギスギスした世相になったものです。

(ﾎｿ)あ、私ってトッピング目当で店を選択してたんだ。....

アイスランドの火山噴火と天明飢饉

アイスランドの火山噴火は、桁違いに大きいようです。EU各国の飛行機が止まってますが、想像力が追いつかない位です。


早期の復旧を望むばかりです。

報道をみていくと、天明の飢饉と関連があるらしい。天明飢饉は 1782年～1788年に起こった近世最大の飢饉です。

浅間山の噴火が引き金になったと記憶していたのでずか、1783年から1785年にかけて、アイスランドで大規模爆発があったらしい。

成層圏に達した灰が各地の日射量を減少させたらしい。同時期に浅間山の噴火があったので、尚更日射量が減り、飢饉の規模が増大したらしい。

世界規模で影響がでるものですね。アイスランドの噴火と浅間山の噴火とは、因果関係がないのでしょうか。

「関連付ける資料がないので、関係はない」とするのでしょうか。



昨今、地震が世界各地で発生しています。同時期に噴火するのも、地球規模で何らかの因果関係があるように思えてなりません。



　不遜な例えですが。碁を打っているとき、左上の局面が右下の局面に影響することがあります。初級者の時は、そんな影響が皆目見えなかったですが、最近見えるようになりました。これも経験の蓄えの致すところですね。

局地現象に見えることでも、世界規模でみると、違った法則が見えそうに思う。

連動して、浅間山や富士山が爆発したら、不況嵐どころではない嵐になると思う。なんとか無事に収まって欲しいものです。

辣油

桃屋 ラー油が、品薄になるほどの人気らしい。


http://www.zero-upone.com/rakuten/list/%E6%A1%83%E5%B1%8B%20%E3%83%A9%E3%83%BC%E6%B2%B9.html

商品名は「桃屋の辛そうで辛くない少し辛いラー油」で、「どっちやねん」と突っ込みたくなる名前。

しかも、。香辛料ではなく、おかずのラー油らしい。

　一般的な辣油は液体状のものが多く、餃子やラーメンに垂らすものだと認識してました。

一部の中華料理店の辣油は香辛材料が下部に沈殿していて、それをすくって、添加することはありますが、この沈殿物を"おかず"にしようとは思ったことがありません。

「おかずのラー油」ってどんなんだろう。



ラー油は辛い香辛料という、意識があるので、価値観を変えるためにも、食べてみたいが、品切れで店頭に登場していない。

品物がないのに、人気が高いというのも、解せないのだが。



無臭ニンニクというのもあるらしい。　臭みがあってこそのニンニクなのに、「臭わないニンニクなんて」という思いも強い。

「辛くない明太子」もある。

http://r.tabelog.com/fukuoka/A4001/A400102/40006583/dtlrvwlst/886968/



食材のありかたに、定義は無用なので、どんな形で登場しても良いのですが、別の名前で投入しても良かったのでは? と思う。

個人的には、「ネギ」が引っかかっています。大阪のネギは、ほそい、緑の部分を指します。トッピングの追加ネギは、この部分がでます。

東京ては「ネギ」は太く、下部の白い部分を指すらしい。鍋も、白ネギです。

　ネギと称してますが、別物の感覚です。違う名前にして欲しいくらいです。

マナー? 資源の問題?

学校給食でパック牛乳の飲み方が問題になっているらしい。


http://news.goo.ne.jp/hatake/20100412/kiji4314.html

パックの角を開けて、口飲みするか、ストロー突き刺し居飲むか。

「どうでもいい」といえば、そうなんですが。なんか気になる話題です。



「ストローという資源の無駄遣い」と「口のみはマナーが悪い」という点が問題視されているようです。

ストローを使うのが、「マナーかがよい」という意見は確かにオカシイ。

口のみが「行儀が悪い」というのも、一方的だと思う。

　缶ジュースなどは、クチ飲みを前提としています。

私たちの時代の給食は、牛乳瓶で口飲みしていました。行儀悪いとは言われなかった。

コップに移して飲むのがマナーだとしても、給食に牛乳用のコップを提供するのもね。

牛乳瓶の直飲みはOKで、パックの口飲がNGというのは、理不尽に思う。



　そもそも、論点が違うのでは? と思えてきました。

牛乳パックは、口飲みを前提としてなさそうです。それを無理に開封して、飲ますと、コボす児童が増加して、

コボすほうが行儀が悪いという事になって、ストロー提供となったようです。こちらの説のほうが、説得力を感じます。

　

食べながら歩くのは、マナーが悪い...とされますが、大阪での繁華街のたこ焼きや、一銭焼き(キャベツ焼き)は、立って食べるのが原則だし、

立ち食い店などは......

マナーや行儀は、評価する人の視点如何に依存するということか、基準点は浮動性の高いものなんでしょうね。

行儀やマナーは、TPOに併せて使い分けることでは、なかろうか。　

祟るから放置?

大阪市の西天満地区に、龍王大神 という神社(祠?)が、あります。


http://shogen.ti-da.net/e730218.html

この頁の写真のように、道路上に存在します。車道の端なので交通の障害にはならないようです。

　木を切ろうとした人が不幸になったとかで、残ったようです。

この手の話は、彼方此方にあり、阪急服部駅には、エキナカ木があります。

http://matsuyakilintei.osakazine.net/e73285.html



西宮市には　「動かせばたたり」という岩が、道路の真ん中にあります。

http://doranekota.com/shinsai.html の二段目

神戸市灘区にも類似の木が道の真ん中にあります。



これらの扱いって心情的なものが大きいので、難しいのでしょうね。

お地蔵さんが公道にはみ出して存在していたりしますが、固定資産税の扱いはどうなんでしょうか。

祟りがあるから、課税していない....んな訳ないですよね。

「祟り」があるから、移設できないのか、「祟りを怖がる人」の反対運動が大きいから移設できないか。面倒だらか放置しているのか。

実体は知りませんが、信仰心の乏しい私は、邪魔感が先立ちます。

　鶴岡八幡の御神木も倒れる時代です。祟りの在り方も変わっているのでは、と思うのです。

両国橋

東京に両国駅があります。そばには、隅田川が流れているので、そこが、国境(武蔵と下総)だと思っていました。


武蔵と下総は、東京と千葉に相当しますが、現在の県境は江戸川なので、オカシイ感じがします。

Wikipediaによると、両国橋ができたとき(1659年or1661年)、隅田川が国境であったが、その後(1686年)、国境が変更されたそうです。

この、国境変更は後日談もあるようです。

http://www.mars.dti.ne.jp/~opaku/hakken/06/ore24.html

現在でも、県境や市境の変更となると、騒ぎになりますが、江戸時代と言えば、封建政治なので、領土感覚はシビアだったように、思ってしまいますが、簡単に変更できたのでしょうか。

国境線や国境警備隊がいる訳ではないので、出入りの制約は少なかったのでしょうね。

(*)アラブ諸国やアフリカの国境も地図上では線が引かれているが、現地では境目が不明確で、出入自由だとも聞きます。国境の位置に拘らない人々も居るということでしょうか。

　上記の記事で知ったのですが、荒川って変遷があって、戦国時代に綾瀬川ができ、荒川放水路という人工河川もできたようです。

大阪の新淀川も人工河川なんですが、大がかりな人海戦術の土木工事だったんでしょうね。素人の感覚ですが、城作りよりも大きい公共事業だったような。

考えたら、川がを国境になっているのは多いですが、川が氾濫して川筋が変わることもあるわけで、その場合、国境は川に従うのでしょうが。該当国同士の争いの有無は?

両国橋は、完成して、25年ほどで、両国橋で無くなったんですね。実体は無くなっても名は残ったという事でしょう。

「親切」なのか「要らぬお節介」なのか

Web画面の店舗紹介等で郵便番号や電話、Faxを表示することは多々あります。


昨今は、PCブラウザーと携帯ブラウザーの垣根が小さくなっていて、両方兼用の画面を作ることも多いです。

携帯ブラウザーは妙に気が利く仕様になっていて、html上ではリンクを張っていない項目でも勝手にリンクが張られたりします。

・553-00xx 大阪市福島区xxxx

・電話 06-6448-xxxx

・FAX 06-6448-yyyy



と表示させると、06-6448-xxxx , 06-6448-yyyy の項目が、電話発信のリンク項目に置換されます。

なぜか、郵便番号の 553-00xxにも反応して、電話発信リンクになります。

　Fax番号や郵便番号に反応するところを見ると、数字+ '-' に対して自動的に反応しているのでしょうね。

でも、この動作って、画面を設計した人の意図とは違う画面になるので、「要らぬお節介」感が強いです。



因みにIPhoneでの現象で、手持ちの機種のFullBrowserでは起こりません。

これから出てくるスマートフォンでは、どうなるのでしょうね。



(以下はいつもの愚痴....)

特定キャリア特有のタグがあり、文字モードの切り替えなどが可能なようですが、面倒です。

外部CSSは諦めましたが、Docomoの特定機種では、body句に書いたCSS句が解釈されずに、テキストとして表示されるのは、悲しかった。

Docomoは　Folder名に漢字が有ったときDecodeしていても リンク自体が死ぬようです。

数年後には、解消されてほしいな。

携帯サイドのUpload～再び

携帯端末でのUploadコントロールの動作は不定です。ボタン自体が無効になる機種があります。


PC並に動作するか否かは、機種依存のようです。キャリア限定でないようなので、ブラウザーエンジンの制約ではなさそうです。

しかし、携帯で写した画像などをUploadする要望は無視できません。回避策として、

　1:Mailerを起動して、mailto文を用いて、特定のAddressに送信してもらう。

　2:Mailer Checkerプログラムを定期的に走らせるか、送信後、起動して貰う。

　3:該当メールアカウントにメールが到来していれば、Uploadデータと見なして、同封されたデータを処理する。

動作はするのですが、Uploadの種類が増えた時、どうするかなど、スマートでない。



　商品画像の更新、スタッフ画像の更新、店舗画像の更新など違うマスターに連動する画像をUploadするとき、困ります。

件名で識別させると、入力値の正当性がCheckできないですし、該当しない件名に書き換えられることも起こります。

また、件名を初期値設定してMailToを起動するとき、特定のキャリアだけ、違う文字コードにEncodeする必要があったりして、面倒です。

そこで、mail Accountを複数用意します。商品画像Upload.Address, スタッフ画像Upload.Address , 店舗画像Upload.Addrssと受け皿を作り、

各々のAccountに到来したメールを、該当するマスター更新に結び付ける.......これも、スマートとは言えない....

無闇に mail.Accountが増えるので、管理対象が増えて、雑用的な作業量が増すばかり。

　Mail.アカウントも資源の内です、使い捨てAddressや、無闇に増えたAccountの無駄は多いと想像できます。

ネットが普及するに比例して、使い捨てのリソースも増えていくのでしょうね。

uploadコントロールの動作もそうですが、CSSの適用状況も統一する気はないのでしょうかね。

システム化の進歩とは裏腹に、開発現場は、益々泥臭くなっていくというか、後戻りしている気がします。

銭湯もメンズディ・レディスディ

銭湯もメッキリ数が減りましたが、残っている店の営業努力は感心します。


「xxx温泉」を名乗る為に、敷地内をポーリングして、源泉を掘り出してます。

不幸にも、源泉が出なかった店は、看板を「xxx温泉」から「xxx湯」に変えたようです。これらは、商標表示の法改正に基づく影響と聞きます。

源泉を流用して、足湯の場を作り、足湯5円のサービスがあり、井戸端会議の場になっています。

地元の銭湯は、410円なのですが、今月から定期的に、「メンズディ・レディスディ」を設けるそうです、当日は約半額の210円になります。

従来は、老人の日とか子供の日などイベント日に半額セールがありました。

スーパー銭湯では、以前から「メンズディ・レディスディ」はあったようですが、一般銭湯では、初めて見ました。

上記の店は、そこそこ大きい銭湯なので、年中無休で営業して、支店もあります。スケールメリットがあるから実践できるのかも知れません。

個人経営の店も頑張っていて。土日は、早朝から朝風呂をしています。休日も月2回しかない店もあります。休みの日も掃除をしているようです。

休みなしで、働いている姿を見ると、こっちが励まされます。

加茂･鴨

京都には、上加茂神社と下鴨神社があります。


葵祭で有名な賀茂祭は賀茂神社両社の祭事です。

なのに、社名は 「加茂」と「鴨」で異なる字を用います。

対称美の眼でみると、不安定でなりません。なぜ字が異なるのか、明解は見つけられませんでした。

側を流れる川の上流が加茂川と呼ばれ、下流が鴨川と呼ばれていたので、その習いで「上加茂」「下鴨」になったとも言われています。



旧国名に、下総、上総、上野、下野など、上下が付くものや、越前、越中、越後など前後が付くものがあります。

当初は、分かれていなかったが、行政上分離したほうが利便性が高まるとして分離したらしいです。

京都に近い方を「上」「前」にしたのは解りますが、前後と上下の使い分けが不明です。

「丹後」はありますが、「丹前」はありません。丹波を但馬と丹後に分離したとも言いますが、前後にしなかった理由はなんでしょうね。

同例。陸前、陸中があるが陸後がなく、陸奥があります。

でも、陸前、陸中等は、律令制の国でなく、明治時代に定義した旧国名なので、何故感があります。



不思議がっていたら、面白い頁をがありました。

http://www.mars.dti.ne.jp/~opaku/hakken/06/ore28.html

前後国は、漢読で、下総、上総、上野、下野はかずさ、しもうさ、こうずけ、しもつけ、と和読みであるところから、分離した権力者は別だったのでは？

というものです。

ネーミングルールの適用は、開発現場では問題になりますが、地名などのネーミングルールって不思議。

昨今の複数地名の合体地名は、同意しかねますが、年数を経ると馴染んでくるのでしょうね。

紀尾井町や東京都大田区　は合成地名ですが、合成感は薄いですね。

六曜

前回、カレンダに関して書いたのですが、六曜の事が気になって、突いてみました。


六曜とは先勝、友引、先負、仏滅、大安、赤口のことで、6日周期で巡る曜日のようなものです。



六曜が神秘的に移るのは、周期性が途絶えるからだそうです。旧暦の一日の六曜日が決められて、以下順繰りに配置されます。

とうぜん、月末と月初の曜日の連続性が途絶えます。

http://koyomi.vis.ne.jp/directjp.cgi?http://koyomi.vis.ne.jp/reki_doc/doc_0410.htm

算出式は 　（旧暦月 ＋ 旧暦日）÷ ６ ＝　Ａ　余り　Ｎ　　で、余りの Nが六曜に当たります。



友引に葬式を出さない、結婚式は大安で、...などと縁起担ぎの種にされますが、仏教とは無縁のものです。(仏滅の仏とは無関係)

血液型占いと同程度のもので、軽口話には良いですが、行動の判断基準にはしないほうが良いかと思います。

仏滅の結婚式が安かったりしてありがたいですが、、友引は斎場が休みになるのは、問題です。

この問題は、「暦注」問題とされ、明治期にも、「暦注みたいな迷信の使用禁止」令が出されたらしい。

　いくら、お上が禁止しても無くならないのは、世間が占い性を要求しているのでしょうね。

現在の会社行事でも、大安を気にしたり、営業のプレゼンに行くのに、先勝、先負に拘る人がいます。

本気で信じている人もいれば、嘘だと解っているが気持ちの問題だと自認している人もいます。

「無意味な事だ」と棹を差すと波風が立ちます。一種の潤滑油になっているので、意見を言わないのが良いのかなと思ってます。

(*)縁起の悪い日に、価格が下がる..という現世利益を享受してます。他にも逆利用させて貰ってます.........後日竹篦返しがあるのかなぁ。

日本文化は、ナンバー数が馴染んでいるのも

月の名前は、1月2月...12月ですし、日の名前は、1日、2日,,です。


和名の正月、如月,葉月等もありますが、ナンバー月を用いる例が多いようです。

月単位の閏月制度があり、閏三月,閏十二月というものもあります。

固有名詞を当てはめるよりも、電算的で、合理性を感じます。先見の明があった?(たまたまかも)

January,Febrary....の名前だと、別途テーブル化するか、列挙体を介するので手間です。

一週間の曜日は、処理上、第一曜日、第二曜日、第七曜日で判断してますが、Sunday/Monday...の文字列が絡むと煩雑です。

日本に昔から曜日の概念が入っていれば、1曜日、2曜日、7曜日 となっていた、だろうな。と勝手に想像したのですが、....

なんと、曜日の考えは、平安初期に空海らが伝えているのですね。(Wikipedia)

http://ja.wikipedia.org/wiki/%E6%9B%9C%E6%97%A5#.E6.97.A5.E6.9C.AC.E3.81.B8.E3.81.AE.E5.B0.8E.E5.85.A5

「七曜は煩わしくて不必要とされ」とあるように、面倒なので嫌がられたようです。

六曜は先勝、友引、先負、仏滅、大安、赤口です。旧暦だと、循環していたようですが今の暦では、の周期でなく、途切れるようです。

理由は、「旧暦の毎月1日の六曜は以下のように固定されている。」だそうです。

http://ja.wikipedia.org/wiki/%E5%85%AD%E6%9B%9C

西洋は、october==10月　という矛盾が残ったまま現在に至ってます。

「7月8月に皇帝の名前を挿入したからずれた」という説もありますが、実際は、第一月(年の初め)がmarchだったから、辻褄が合っていたようです。

それが、年の初めをJanuaryにしたとき、octoberのまま放置したらしいです。

　西洋思想は合理的だと、よく耳にしますが、どこの地域の文化も合理性がありますね。

「ついてない」4連発

ここ数日は、気温が冷え込みましした。セータを洗濯に出してしまったので、寒い思いをしていました。(この時点では、嫌な気はしなかった)


先日(26日)に遅い昼を食べにてました。(13:00頃)

お気に入りの「付け麺屋(鴨)」に半月ブリに行ったら、ラーメン屋に衣替えしている.予兆が無かったのに、何が有ったのだろう。

次にお気に入りのカレー屋に行くと、「白御飯がなくなりました。炊き上がるまでオーダー停止です。」....うーん。販売予測が外れたのだろうか。

寒いなか歩いたのが発熱を促進したのかも知れませんが、夕刻から咳が出始めてで、発熱の事態に。



「携帯サイトのアプリでUploadコントロールが動作しない」.......と相談を受けたとき、誤判してしまいました。

携帯サイトではUploadコントロールが機能しない機種がある...のは知られたことで、Fileをメールに添付して送信するのが回避策なんです。

しかし、失念してしまって、ソースデバッグ動作に突入して、同じように「なんで動作しないんだ。」と頭抱えてしまった。

帰宅時、(始発駅で)電車に乗る寸前に扉が閉まって閉まった。

運命や定めなど大がかりなものでなく些細な事ですが、重なると、なんか、神頼みに走りそうな気になりますね。

きっと、トイレに入ったら紙がないんだろうなぁ。厄払いだと自認して、好転に変えようっと。

坂本龍馬と司馬遼太郎

昨今は龍馬ブームです。大河ドラマも順調なようで何よりです。


水をさすのですが。

司馬遼太郎が「龍馬がゆく」を書いてから龍馬人気に火が付いたようですね。それ以前は、無名の人だったらしい。

明治初期でも、無名だったらしいので、龍馬の貢献度は不明ですね。

「歴史は勝者が作るもの」なので、徳川幕府関係者を過小に評価し、維新に協力的な人を過大評価する....この事を考慮しても、龍馬が無名だったと言うことは、貢献度が少なかったのか?

「新撰組は、ゴロツキなアウトロー集団に過ぎない」との見解もあります。そもそも、幕府側の自前の軍隊が貧弱なので、外人部隊を編成しないと間に合わなかった事情もあるようです。

歴史小説史観や歴史ドラマ史観に囚われてしまうのは、良くないなぁと思いますが、虚構を楽しむのも娯楽なので、どっちつかずです。

乃木希典は愚将だったらしいですが、軍神となり祭られてます。203高地で亡くなった家族は、納得できないと想像します。

歴史は活字からの知識なので、事実が見えてきません。



貢献度と評価は別次元で判断したいですが、益を被る人の地位によって評価が左右されがちなので尚更です。

ITシステムでも、評価の高さと、貢献度(利益誘導度)は別ですものね。

主観的評価は無い物ねだりなのだろうか。

MapPath()とBitmap.Save()の挙動不審

二つのメソッドの挙動不審が重なって、深胃落とし穴にはまり、連休が飛びました。


事の発端は、在る画像をUploadしたあと、サイズ調整して、指定のフォルダーに格納するという単純なWebアプリです。

VS2008のIDEで開発Webサーバーで稼働確認して、順調だったので、本番機に移行したところ。

「GDI+ で汎用エラーが発生しました」と出て落ちる。



GDI+は癖の強いモジュールです。

同名のFileに上書きするときにも、同様のエラーがでます。(*)適切な例外メッセージにならんのか..www

.save直前に、該当Fileを消すようにしてます。

Image.FromFile(file) を実行すると、Fileがロックされ、次のステップの Image.save(file) で、同様のメッセージがでます。

なまじ、そのことを知っていたのが仇となり、MemoryStram上で展開して、saveしてみたが、同様に落ちる。

Folder/File名に漢字があると不味い、とかいろいろ怪しげな情報も転がっていますがどれも該当しそうにない。

メモリーリークなのかと、思いましたが、どうも違う。



該当箇所は、image.save(MapPath("./images/該当FILE.JPG")); です。問題ない....として他を検討していましたが、念のため

string str = MapPath("./該当FILE.JPG");

[debug.確認] =>LogFileに書き出し。

image.save(str);



と変えて、 [debug.確認]の箇所で、 str値を確認しました。

なんと。

開発Webサーバーの下では 「d:\WebApli\client\xxxx\images\該当FILE.JPG」 となっていて、問題なく動作します

本番機の元では「d:\WebApli\images\該当FILE.JPG」と存在しない値にり、落ちます。



MapPath()の "./"の解釈が"~/"と同値になっているのかなぁ。　開発Webサーバーと通常サーバで解釈が異なるのも釈然としません。

"./"をとっても、デフォルトFolderの解釈がことなるようです。

image.save(MapPath("~/client/xxxx/images/該当FILE.JPG")); と アプリルートから指定にすれば、上手く動作します。



*.aspx/*.html のデフォルトパスの認識は、.net言語, Javascriptでも差違がありますし、CSS,includeの指定の仕方でも異なります。

include先のフォルダーに基準が変わることもあり、ヤヤコシイことこの上ない。

しかし、開発Webサーバーと本番サーバで結果が異なるのは、納得できないなぁ。

ICカード乗車券

ICOCA、SUICA, PiTaPa,PASMOなどがあります。


首都圏、関西圏でJR/私鉄問わず改札/出札で精算してくれます。

自販機でも使えて、お財布代わりになってます。

関西の鉄道は、相互乗り入れ区間が限られているので、三社線以上に跨ることは、ないと思います。

考えられるのは、山陽=>阪神=>近鉄=>京都地下鉄 がありますが、利用する人はマニアだと思います。



関東では、「ICカードによる精算は４社以内に限られる」と聞きました。

http://www.jreast.co.jp/suica/use/auto_pay/others/sf.html

のルール2に明記されています。



理由は明記されてませんが、算出パターンが膨大過ぎて、システム化できなかったらしい。

自動精算システムの開発時のテストパターンは乗継会社が１社増えることに二乗になるようで、５社以上のテストケースを出すコストを考えた末に、システム化を諦めたらしい。

単純に考えたら、テストケースは少なそうですが、我々の気付かない想定ケースが多いのでしょうね。



将来、ICOCA/SUICAの地域壁が無くなって、全国カードにする話も聞きますが、何社の乗り継ぎができ、テストパターンの洗い出しが可能なんでしょうか。

システムが成立するには、テストケースを洗い出せるのが前提です。

関東のように、例外処理で手動精算扱いにするのかなぁ。



(*)追記 :よく考えたら、あるものですね。

山陽=>阪急=>大阪地下鉄=>近鉄=>京都地下鉄=>京阪　の６社のパターンがありました。

関西のICOCAの案内では、４社以内の限定明記は見あたりません。どうなるのでしょう。ゲートが閉じて「ピンポン」になるのか?

誰か試してみませんか。

明治期、電源周波数の差を問題視しなかったのか

日本は、東西で50Hz,60Hzの二種類存在する珍しい国です。


一昔前の家電製品は。交流モーター等の関係で、各周波数専用の機種でした。

最近は、インバーターなどの普及で、特に意識しなくてもよくなりました。

　なぜ、二種類存在するようになったかは、輸入先が、ドイツ製の50Hzとアメリカ製の60Hzの発電機だったから。

というのは、広く知られた雑学です。

　でも、疑問は残ったままです。いくら明治期初期だといえ、東西で別の周波数でインフラを整備すると、弊害が大きい。

鉄道の線路幅は、当初、不定だったようですが、共通インフラを意識してか、狭軌で統一したようです。標準軌に改軌したかったようですが、時遅しでした。

同じように、「インフラは国内で統一すべきだ」という意見があったと思うのです。

統一される前に、購入して、地域単位で普及してしまって統一不可能になったのかも知れません。だとしたら初期のインフラ計画が甘かった?

中央政府の御威光が薄かった?

東海道新幹線は、関東地区でも60Hzに周波数変換して走らせてますし、両地区を通して走る列車は、周波数変換設備が必要になったりします。



交流電化地区と直流電化地区というのもあって、境目はデッドセクションを設けて対応してます。通して走る列車は両方に対応した車両です。

こちらは、列車の製造費と、輸送量と発電所の建設費の兼ね合いで、二種類混在するのは、理解できます。



鉄道敷設は、慎重で私鉄免許の審査も当初から厳しかったようで、インフラには慎重だった面があります。

それだけに、50Hz,60Hzの二種類のインフラ投資を許した背景が理解できません。

単純に、「何も考えて無かった」というのかも知れませんが。

携帯ブラウザーのタグ解釈

(*)何回目かの愚痴...


携帯サイトのアプリを作っていて、キャリアによって表示結果が違うのは毎度のことですが。...www

cssは外部cssにすると適用されないケースもあります。Header部分に直に書ことで適用できます。

しかし、キャリアによって適用されないタグがあるようです。

div,img,pなどのBlock句は　 position: absolute;　で自由に位置が変えられ指定です。

sofbank携帯だと、問題なく反映されます。しかし、 AU携帯だと、div句に対しては有効ですが、

img,p,span句に対しては無視されます。background-color も無視されます。

つまり、CSSを適用するには、

句を必要があります。

img句で Width/Heighを使って(stretch等の)サイズ変換することは良く使う手ですが、それが使えない......

PC向け頁と共通化を計っているので、この制約は辛い。

ToMailで、携帯メーラーを起動し漢字文字列を初期値設定するとき、softbank機以外はSJISエンコードしないと文字化けします。

PC向けでも、FireFoxを対象にするときは、SJISエンコードの必要があります。文字コード問題は規約がことなると、何時までも対応を強いられます。

同一頁をPC用と携帯用で切り分けるために、div句のvisualをon/offしてますが、

AGentで相手の機種をみて、処理を変えないといけないので、局所的に煩雑になります。



Page.Requestで画面情報を取得できるのだから、動的にHTMLを吐き出した方がスッキリ書けるような気がしてきました。

後ろ向きな対応がいつまでも必要な分野..あぁ..

特定扶養親族控除

今回の確定申告で知った悔しい控除。


年齢が16歳から23歳までの子供が適用される控除です。

本人、配偶者、子供の控除額は一人38万円だと思ってました。

初めて、確定申告したとき、税務署員から、そのように聞きました。

その後数回、その額で、記入・提出して、そのまま受理されました。

今回、提出した時、「係員から額が違うよ。もっと控除できるよ。」と指摘を受けました。

特定扶養親族控除を適用すると38万でなく63万円が控除されます。税額で12,500円も違ってきます。

「今までも適用できてたの?」ときくと、「あなたの場合、2年前から該当する。前年度の分は修正申告できる。それ以前は諦めろ」と言われた。

確かに「確定申告の手引き」に明記してあるので、読み取れなかった私の落ち度です。IT屋らしからぬ失態です。

でもね。「提出時に見逃すのはどうよ」という思いは残ります。「だまされた。」と口走ってしまいましたが、「そこまでチェックできなかったのですしょう。」と軽くあしらわれました。

知らないと損するというのは事実のようです。しかし全を知るのは不可能です。

税務署の担当者でも誤るようなので、該当する手引き書の理解は必須です。

(ボソ)もっと解りやすく書いて欲しいなぁ。

鶴岡八幡大銀杏倒壊

先日の天候不良により、鎌倉・鶴岡八幡宮の大銀杏が倒れました。


「公卿が源実朝を暗殺する時に隠れていた木」とされています。

でも、大銀杏の樹齢は1000年程度で、当時は、細い木なので隠れることは無理らしい。

「他に1000年級の銀杏が有って、倒れた木は二代目」という説もありますが、その根拠は乏しいそうです。

木陰に隠れて暗殺したというのは、後付の話らしいです。でも良くできた話です。

歴史上の出来事は、事実なのか後世の挿話なのが判断は難しいですね。勝者の都合で歴史が綴られるのでデフォルメが掛かるので尚更です。

講談話が、実話として一人歩きするし。教科書に載っているから事実とは言えないし。真贋の基準も思想が入るので個人では限度を感じます。



でも、御神木でも倒壊するし、地震で神社本殿が潰れるし、仏壇の下敷きになって不幸になる人もいれば、仏壇が支えになって無傷だった人もいます。

偶然の出来事なんでしょうが、神仏が絡むと割り切れないモノがありますね。

　先日のチリ地震は、来る地震の予兆かも知れないし、津波騒動は、天が与えた「予行演習」の気がします。真摯に受け止めた人が少なかったらしいので、なんか不安が残ります。

老婆心で済めば良いのですが。

(*)どこかで、神仏の存在を信じているのかも知れません。

偽札

1万円札の偽札が発覚したそうです。


通券番号ば同一で、透かしは薄い印刷だが、フォトグラフは相当凝ったものだったとか。

新券発券当時は「偽造不可能」がうたい文句だったのですが、イタチごっこになるの宿命ですね。

しかし、偽札を作るコストってどれ位なんでしょう。単純にみても数万円以上掛かっているように思いますが。

この手の犯罪は、情報犯罪と同類で、利益を目的とした犯罪でなく、自分の技術の誇示が大きなウエイトを占めるので、撲滅は難しいのでしょうね。

商品券や切手、印紙....金銭に代わる紙は多々ありますが、偽造防止策はどこまで取られているのでしょうね。

紙幣の偽造は勿論ですが、商品券などの金券の偽造の防止策ってどうでしょうね。素人目にはあまり効力が薄いように見えます。

信用経済って危うい土台に立脚しているのかも知れませんね。

地域単位の祝日法改正案

地域単位で大型連休を分散させる案のようです。問題や効果云々はさておき、業務システムへの影響はどうでしょうか。


システム開発は、社会ルールにあわせるもので、開発効率でルールが決まるのは主客逆転だと思っています。

しかし、地域によって休日が変わると、業務ルールに矛盾が生じるので、システム化は難しくなりそうです。

全国規模の会社で出張を考えたとき、発地の当日が休日でも、着地の当日が平日のケースは、休出になるのか否か。

全国拠点長会議は、休出になるのか否か。JRの長距離列車や飛行機は、休日ダイヤになるのか否か。

全て平日扱いにすれば、問題が少ないのかも知れませんが、休日は個人に帰属するので調整が難しいでしょうね。

カレンダーや制度などは、一国一制度を前提として行動しているので、それが変わると、システムへの負荷は大きいそうです。



江戸時代は、金貨、銀貨、銭と三つの通貨基準がありましたが、それなりに落ち着いていたので、吟味すればシステム化は可能でしょうが、面倒そうです。

世界のカレンダーは1週間７日制ですが、1週間5日制の地域があって、且つ勢力が均等していたら、面倒でしょうね。

州税(消費税)が不統一のように、県によって税率が変わると、システムは難しくなます。

　現行のシステムは、単純なルールに立脚して構築されているのかもしれません。。

商品別消費税の可能性が高いので要注意です。昔の物品税は個々に税率が設定されていたので、昔のほうが複雑だったのかも。

新型インフルエンザワクチン予測等

最近、新型インフルエンザの話題はメッキリ減りました。


一部報道によると、ワクチンが余ってしまったらしい。

http://sankei.jp.msn.com/life/body/091227/bdy0912272337003-n1.htm

国民の一部しか接種できないとか、接種の優先順位とか騒いでいたのが嘘のようです。

「罹患しても大したことない」と判断したのかもしれませんね。でも、安心すると、竹篦返しが大きそうです。　

当初、二回接種が必要だったのが、1回で良いようになったし、国内では生産不足なので、輸入するようになったし。

それが一転、余ってしまってワクチンの処理に困っているらしい。非先進国に分配してあげればよいのに、有料で輸入したモノを他国に分配するのはできないと聞く。(ラジオ情報)

ワクチンの有効期間が切れて、廃棄処分になったら、なんとも勿体ない。



なんか、国の予測と現実との乖離は大きいようです。

(*)先週のチリ地震の津波予報は、大袈裟すぎだとの批判があるようですが、(こちらは)備えあれば憂いなしです。避難率が低いのがなんとも..ですが。

何年か前に、米の不作で米を外国から輸入したものの、人の口に入ったのは少なかったらしい。安い米を輸入したからだという説も有りますが。

1980年代は、「これからは情報処理の時代だ。2～30年後は、数100万人の情報処理技術者が不足する」と予測されてました。

それが、今は、技術者不遇の時代...あぁ。

医者不足を予測して、各地に医学部をつくった結果、医師の配分がアンバランスで、過不足地域差、科目差が拡大した。

教員も弁護士も余りぎみだとか。

教員も法曹も大学院大学制にして、門戸を狭めようとしているように見えます。

予測が当たらないのは、不可避なのか思慮不足なのかは、わかりません。政策を批判するほどの論拠も有りません。

ても、振り回される人々がいるのが実際なので、困ります。当事者の自己責任というのは違うように思うのです。

でも、ブームに乗って、関連学部に進学して、就職時にブームが去って「こんな筈じゃ無かった」というのは自己責任かな。

それだけ、要素が多すぎて、予測できないのが本音なのかも。世渡りも難しい時代になったものです。

HDDやUSB3

裸族のお立ち台など、裸のHDDが刺さる台があります。


SATAになってコネクタ部が単純になったので、ATAの時の抜き差し型より安定しそうです。

数社から類似品がでていました。なかなか便利そうです。

暫くのHDDの容量UPが滞っていたと思いきや、一気に増えました。1.5T , 2.0Tも安く出回ってます。

USB3インターフェースも何時の間にか登場しています。 USB2の10倍の速度 (実測値は不明)なので楽しみです。

私の用途ではUSB2/HDDで充分な速度なんですが、食指が動きます。

「adaptec/scsi」などはメッキリ聞かなくなりました。コンシューマなSCSI製品はもうないのかなぁ。

大規模ストレージの世界で、iSCSIが使うことがあります。こちらの世界は、桁が違うようで、

従来、1block 16Tbyteの単位だったBiosが, 1Block 1000P(ペタ)byteになるそうです。



ここまで、大きく、高速になると「データは蓄積するもので、削除するものではない。削除処理は不要だ。」という設計思想が、出てきそうです。

日々のトランザクションデータや中間データなどで、不要になったデータをを如何に削除するかは、大事な設計点です。

確かに、削除を考慮しなければ、設計は楽かも知れません。でもゴミが増幅することになるので、マナーが悪いと思っています。

でも、処理速度のアップで、不要データ増幅による悪化が隠れてしまうので、マナーの悪いシステムが増えそうな予感がします。

(*) プログラムでも、下手なロジックでも速度悪化が目立たないので、品質的に(?)なモノが目に付きます。

マナーが悪くても、実運用上は問題化しないので、この種の問題は、改善しないのでしょうね。

万歳三唱に作法はある？

http://mainichi.jp/select/seiji/news/20100213ddm005010090000c.html


http://blog.livedoor.jp/tokisaewasurete936/archives/921379.html

この記事によると、

「首相は万歳の仕方を身につけておくべきだ」と主張したことに対して、「公式の作法はない」と回答したとのこと。

神社参拝には「一揖二礼二拍手一礼一揖」(一部の神社は別作法)という作法があります。

http://webmania.jp/~rerasiu/other/sanpai.html

でも、万歳は作法になり得るのでしょうか。馴染まない気がします。

上記の根拠は「過去に万歳三唱令なる法律が存在した」に基づくのかも知れませんが、そもそも「万歳三唱令」は怪文書らしい。

http://ja.wikipedia.org/wiki/%E4%B8%87%E6%AD%B3%E4%B8%89%E5%94%B1%E4%BB%A4

もっともらしいデマは信憑性を持ち、信じる人もいるのでしょうね。

　質問主意書は、相当の費用(税金)と時間がかかる政治行為です。万歳作法云々の質問が悠長な質問に思えてなりません。

閣議で、万歳三唱の所作が真剣に討議されているとしたら、なんか違うのでは......

かってのバブル期だと、ゆとりの答弁で済んだのでしょうが、昨今のピリピリした時代に、「そんな答弁している場合か」と思ったりします。

政治の実態って見えないだけに、不思議な世界です。

チリ地震

昨日(2月28日)津波警報が終日出てました。


(今のところ)日本国内では人的被害が出なかったのは幸いでした。

今回、初めて津波の実態が解りました。今までは、なんとなく、津波は通常の波の大きいもので、一過性のものだと思ってました。

ニュースで津波による海面上昇の様子を早送りで放送してましたが、それをみると、波ではなく、全体的に海面が上昇するのですね。誤認してました。

危険率の高低に関わらず、警報を出すのは良いことだと思います。

(*)沿岸の中継で、「津波を見に行っている人がいる」と言ってましたが、事が起こると多大な迷惑を掛けますので自重してほしいものです。



今回、疑問に感じたのですが、発生直後のニュースではM8.2と聞いたと自認してます。その後、M.8.6になり、新聞はM.8.8と出てます。

今、ラジオのニュースではM8.6と言ってました。

　マグニチュードって共通基準じゃないの?



http://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B0%E3%83%8B%E3%83%81%E3%83%A5%E3%83%BC%E3%83%89 (Wikipedia)

にあるように、算出する計算式は数種類あります。

モーメント・マグニチュードを使うことが多いそうです。

そこでも、疑問があります。この計算式の各項目や深度を測定する機械はどのように配置しているのでしょうね。

関東大震災はマグニチュード7.9ですが、当時、測定器具は存在していたのでしょうか。

古い地震は? とググってみると。(出典:Wikipedia)

　　599年5月28日 大和国（奈良県）で地震。 - M 7?

　　679年 筑紫国（福岡県）で地震。 - M 6.5～7.5

　　684年11月29日 白鳳南海地震 - M 8.0～8.3、

とありますが、Mx.x の根拠はなんでしょうね。記録に基づく推定なのか、地層のズレによる推定なのか。

津波予想時刻もかなり、差違があるようで、まだまだ算出するには力不足なのでしょうね。

他人事ではありません。明日は我が身です。地元で何時起こっても良いように備えておきましょう。

学習用Oracle11g

初音 玲さんの記事 http://blogs.wankuma.com/hatsune/archive/2010/02/23/186368.aspx


にもありますように、学習用のOracle11g が無償でダウンロードできるようになりした。

今までは、 Oracle 10g XEを用いていました。11gを触れる機会がなかったので、大いに有難いです。

早速、インストールしました。

インストールの事前チェックで引っかかって怒られました。

「あんたのOSでは動作保証しません云々」....

　OSはWindows7 / Athron64*2です。



この段階で、CheckBoxにOK-Checkを手動でセットすれば、インストール続行できます。

無事稼働しました。満足なんですが、知らないと、引っかかったまま諦める人も出そうです。



この種類の警告表示は難しいのですが、Oracle製品のUIは、親切さに欠け、未経験者には扱い難い、と昔から思っています。

自分なら、どのようにするか、と考えたら難しい事が解りました。

・製品以後に出るOSは上位互換が原則だろうから、警告した上で、インストール続行をデフォルトとする。

・未検証OSの動作保証は不可能なので、インストール中断をデフォルトにする。

どちらも理がありそうで、結論がでない。



知らない人を拒否する印象のするOracleと知らなくても適当に使えるMsSQLの差は、育ちの違いからくるのでしょうか?

(*)DB2も異次元の感じが強いですし、MySQLはサンマイクロ=>Oracleに移管されましたが、５年後、どうなっているか見えない。

　RDBの今後の姿が楽しみですね。

アップロード・コントロールのデフォルト値

Webアプリでローカルデータをアップロードするときに使うコントロールですが、初期値を設定したいという要望が屡々あります。

Webアプリはサーバー側で動作するので、クライアントの環境を知る由がありません。

というよりも、セキュリティ上からも、できないのでしょう。

　基幹業務をWeb化することが多くなるにつれて、WebアプリでローカルFileを操作したいという要求も出てきます。

これもセキュリティ上できません。

ても、理解を得にくいです。ActiveXのセキュリティ問題も最近は話題にならないので、問題意識を持たないユーザーが増えているのも理由のようです。



　アップロードFileの限度も標準で約4Mbyteです。(ASP.NETだとWeb.configの設定で変更できますが、限度があるかと思います。)

でも、これも理解を得にくい制約です。

システム上の理由は顧客は無縁であるのが理想ですが、柵は残りそうですね。

金剛組～世界最古の会社

知らないことは山ほどあるのですが、これもその一つ。


この会社は578年創業で社歴、1432年です。

http://www.kongogumi.co.jp/

http://ja.wikipedia.org/wiki/%E9%87%91%E5%89%9B%E7%B5%84

うーん。確かに古い。聖徳太子が四天王寺を建立するとき、百済から呼び寄せた匠集団が発端だとか。

2006年に破綻しかけるも、再生されたようです。ここまで古くては。途切れなくてほっとしますね。

江戸時代創業の呉服屋等の話は聞きます。室町以前の創業の例は

本家　尾張屋（おわりや） 1465年創業

川端道喜（かわばたどうき）1503年創業

などの和菓子屋がありますが、こちらは個人商店の面が強そうですね。

次に古い創業は 鍋屋バイテック 1560年創業 です。

と思っていたら、法師 が 718年創業の世界最古のホテルだそうです。

　資本社会の会社組織とは別次元の組織なんでしょうが、人の集まりと仕事(サービス)の提供という面で共通しているようです。

同業者組合である「株仲間」とか、金融機関である「頼母子講」とか、貨幣経済の仕組みは、発達していたのですね。



企業30年説があるように、同じ形態のままでは、長続きしないのが普通てす。社会的役割が終わったら、悪あがきせずに撤退するのが良いと思います。

上記のように何百年以上も続けられるのは、提供する仕事の業種が限定されているのが幸いしているのかも知れませんね。