風呂屋が空

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アクセス処理は書きたくない.....(我が儘だなぁ)

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