温故知新

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先の大通りにでるまでの間の出来事でした。

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

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

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

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

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

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

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

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

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



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