2010年2月9日
前回鍵に関することを書いていて、思ったのですが、普通の鍵の合鍵は無制限につくれますね。
インテリキーや使い捨てキー(ホテルの鍵など、毎日変わるもの)は合鍵は作れないようです。しかし、
普通の家やマンションの合鍵は手軽に作れます。賃貸マンションやアパートなど、借り主が変わったとき、鍵を付け替えているか否か心配になります。
デジタルオーディオのように、n回までの合鍵を許す...となるとインテリキーになるので、高価になるのでしょうね。
車の合鍵も最近は、別オーダーしないと作れませんし、ドアの鍵穴が隠れていたりします。
「鍵の110番」や「鍵の救急」がビジネスになるのは、持ち主が鍵を紛失したり、閉じ込めたりする頻度が高いのでしょう。
他人が持ち主を騙ったり、なりすましたりして悪用するケースもあるようです。
解錠できるということは「鍵は安全ではない」となります。そのように認識していたほうが良いかも知れません。
意外な経験もあります。どこにでもある事務ロッカー(書類などを格納する棚式)の鍵を紛失して、鍵屋さんを呼んだのですが、格闘の末「開けられません・料金は要りません」となりました。
単純な鍵は、強いかも知れません。ロッカーを破壊されたらお終いですが....
2010年2月7日
外出時、施錠したか、コンロの火を消した不安になって心配する人がいます。
確認しに戻ると大抵は施錠してるし、火の始末もしている場合が多いです。
火は消していても、元栓を閉めたか否かが不安になったりします。
心配しだすときりがないのですが゛。
キーの部分に施錠/解錠の操作結果をマークする仕組みが有れば不安解消にならないか..と思いました。
IC.Tipの埋め込み実装で可能そうです。既に存在しているだろうと思いますが探し切れませんでした。
鍵やガスの元コックにIPが振られて、状態を発信するようになれば解消しますね。
今の実装技術の普及度の早さからみて、近い間に普及しそうな気がします。
歯ブラシにIPが振られていて、歯を磨いたか否か監視されたら嫌だなぁ。
それが、幸せなのか否かは別にして....個人的には機械任せにする不安のほうが高いのですが。
2010年2月6日
行政区分の町村は、どこかの郡に属していますが、行政単位の郡があるわけではありません。
明治期には郡役所が存在していて、それなりの意味があったそうです。
最近までは、同一県内に、同名の村が存在するケースがあり、区別する意味がありました。
(*)群馬県に東村が５カ所あったそうです。
最近の自治体合併でそれも解消されて、識別子としての意味もなくなりました。
律令制の名残として残しいと思うのですが、事務処理上は、冗長感が拭えません。
冗長性の排除が正解ではないし、冗長性は潤滑油として有用な事が多いのですが、郡の意味がよく判りません。
2010年2月4日
住所項目の保持や表記は、都道府県名から書くのと市区名から書くのと、どちらが多いのでしょう。
A: 東京都千代田区xxxx町yyyyy
B: 千代田区xxxx町yyyyy
C: 大阪府大阪市北区梅田1丁目
D: 大阪市北区梅田1丁目
E: 大阪府吹田市寝屋川市香里園
F: 吹田市寝屋川市香里園
感覚要素が強いので、正式な記述基準を作るのは適さないのかもしれません。
私は、政令都市(区を有する自治体)の住民は、県名を省く人が多く、非政令都市の住民は県名を書く人が多い印象があります。
私も、県名は省きます。
・市の名前は、原則として、全国ユニークです。(府中市と伊達市の例外があるので一貫性が有りませんが)
・町村の名前は、そのような原則はありません。
という仕様を鑑みると、市の時は、県名を省いても、情報欠落はありません。
尤も、郵便番号を書いていれば、市区名まで、省いても情報欠落はありません。(町域はユニーク性が一部ないので、怪しくなります。)
事務処理上は、不要でも、人がみて、どの自治体の人か一目でわかる為には、表示しておく必要があります。
でも、長くなると見にくくなるので、県名は避けたい思いがします。
県名を書く習慣のある人に言わせると「県名のない住所は不安定感で一杯だ。」そうです。
電話番号も xx(yyyy)zzzz式と xx-yyyy-zzzz と好みが分かれますし。
フリーダイヤルも 0120-xxx-yyy と 0120-xx-yy-zz に分かれているようです。
市内局番の'-'の位置は交換機の手順で決まると認識していますが、-の位置は利用者にとっては意味があるのかなぁ。
住所のはじめの空白は、宛名書きの意味で重要な要素になります。むやみにTrim()して格納すると、叱られることなったりします。
年賀状作成ソフトの宛名の印字位置調整機能やフォントサイズ調整機能は、よくできています。
事務教務アプリだったら、本質的でない仕様なので切り捨てられる要望ですが、それが命の商品なので、気配りの深さに感心します。
情報の保持は、デジタル的有意性だけでなく、感性の部分もあるなぁ。と思った次第。
2010年2月2日
初めての道を歩いていて、缶詰のラーメンの自販機を見つけました。思わず眺めていました。
大きさは350ccのジュース缶くらいでした。
ホットとコールドがあったのですが、購入しても、その場で食べるものなのか、食材として売っていて、自宅で調理するものか、判断が付きかねて、購入しませんでした。
なんか気になったので、ググってみるとありました。
http://www.fujitaka.com/rahmen/
お汁粉やコーンスープの自販機は時々見かけますが、味噌汁の自販機は見ませんね。と思っていたら、存在するようです。
http://news.ameba.jp/economy/2008/09/18034.html
何でもありますね。カップ麺などの食料の自販機は、テープル施設が伴っている施設に設置されていますが、上記の自販機は、ジュース自販機と同列においてあり、テープル施設はありません。
その場で、食べられるモノか否か判断できない。その場で食事するのは、違和感があります。といっても、「(道路上で)ジュースの立ち飲みOKで、ラーメンの立ち食いはNGという感覚」も崩れていくのかも知れません。
今度その前を通ることがあれば、試してみようっと。
2010年2月1日
以前、 επιστημηさんが、「Hashすげー」
で、HashSetの早さを報告されています。
C#でも 3.5から導入されいて、重複要素の排除などに重宝しています。
C#3.0以前で同様のことをするには Dictionary<object,object> で行えます。 KeyとValueに同値をセットすれば使えますが、Vの部分に冗長性が出ます。
速度コストが気になり試行して見ました。Value部の冗長性がないので、「コスト安であろう」 と勝手に期待してましたが...
▼▼▼テスト結果▼▼▼ AMD64*2:4600+ 2.4G
----------------------------------- mSec mSec
▼回数: 1▼ dict<int,int> : 0 追加数[ 1] Hash<int> : 38 追加数[ 1]
▼回数: 10▼ dict<int,int> : 0 追加数[ 10] Hash<int> : 1 追加数[ 10]
▼回数: 100▼ dict<int,int> : 0 追加数[ 87] Hash<int> : 0 追加数[ 87]
▼回数: 1000▼ dict<int,int> : 0 追加数[428] Hash<int> : 0 追加数[428]
▼回数: 10000▼ dict<int,int> : 2 追加数[499] Hash<int> : 2 追加数[499]
▼回数: 100000▼ dict<int,int> : 20 追加数[499] Hash<int> : 16 追加数[499]
▼回数: 1000000▼ dict<int,int> : 106 追加数[499] Hash<int> : 88 追加数[499]
▼回数: 10000000▼ dict<int,int> : 862 追加数[499] Hash<int> : 948 追加数[499]
▼回数:100000000▼ dict<int,int> :8653 追加数[499] Hash<int> :9196 追加数[499]
僅かですが、「Dictionary<> のほうが早い」場合もありますが、有意差はないようです。
内部の実装がどのようになっているかは、知らないのでずか、同じツリー構造で格納しているのなら、差はもっと小さいと思いますが違うのかな。
これくらの差なら、HashSetを使う価値はありますね。
NameValueCollectionクラスという、Dictionaryの同一キーに対する要素を複数保持できるモノがありますが、知られることなく埋没されていますね。
Dictionary< key , List<object>> で、同じ効果を得られるので、独自性が薄かったとも言えますが。
SortedDictionaryゃSortedList というのもあります。HashでKeyを格納しているので、Hash自体にSort機能は保有していると思うのですが、流用できなかったのでしょうか。
標準で付いているコレクションの種類が増加するのは、進歩なのですが、活用できずに、埋没しているのも散見するので、複雑な気分です。
テストソース
//private int 元ネタ個数 = 1000000000; // 90秒近く
private Dictionary<int, int> 元ネタDICT = new Dictionary<int, int>();
private HashSet<int> 元ネタHash = new HashSet<int>();
private string Report = "";
private void btn_開始_Click(object sender, EventArgs e)
{
for (int 回数 = 1; 回数 < 1000000000; 回数 *= 10)
{
測定(回数);
}
MessageBox.Show(Report);
}
private void 測定(int 回数)
{
Report +=Environment.NewLine+"▼回数:"+回数+ "▼";
Stopwatch sw = new Stopwatch();
//元ネタ作成
{
Random rnd = new Random(0);
sw.Start();
for (int i = 0; i < 回数; i++)
{
int j = (rnd.Next() * 100 ) % 1000;
if (!元ネタDICT.ContainsKey(j))
{
元ネタDICT.Add(j, j);
}
else
{
}
}
Report += Environment.NewLine + " dict<int,int> :" + sw.ElapsedMilliseconds.ToString() + " 追加数[" + 元ネタDICT.Count.ToString() + "]";
}
{
Random rnd = new Random(0);
sw.Reset();
sw.Start();
for (int i = 0; i < 回数; i++)
{
int j = (rnd.Next() * 100) % 1000;
if (!元ネタHash.Contains(j))
{
元ネタHash.Add(j);
}
}
Report += Environment.NewLine + " Hash<int> :" + sw.ElapsedMilliseconds.ToString() + " 追加数[" + 元ネタHash.Count.ToString() + "]";
}
}
2010年1月31日
外壁補修や白蟻退治、消火器などの訪問セールスは、怪しげな話が多い..とされていました。
昨今は、メジャーな会社も訪問セールスをするようになったようです。(何をもってメジャーとするかはさておいて)
「近所の家の外壁補修工事をしていて迷惑をかけてすいません。」という大義名分で訪問してきます。粗品まで準備するケースもあります。
工事そのものはご近所のことだし、お互いさまなので、問題はないのですが、それを口実に上手いこと、自宅の補修の話に引き込まれて、補修工事を勧められそうになります。
その話術は、見習いたい程に上手です。こちらも、言われるままでは、癪なので、質問を浴びせて向こうの事情を聞いて見ました。
会社の指導で、
・工事現場の家の周囲200mの家をローラー的に総当たりせよ。
・築10年以上の家に対して外壁工事の必要性を説いて、無整備の家は、見積もりをするように提案する。
・見積もりに至らなくても、家の電話番号は聞き出すこと。
となっているそうです。
新築の時も、周囲の家くらいしか挨拶しなかったと思うのですか、今は、それを口実に広い範囲の周囲に声を掛けているようです。
以前は、そんなことはなかったので、メジャーな会社も大変な状況になっているようですね。
不必要に、不安を煽って、不要な補修をすることになるケースもあるようです。メジャー会社であっても、信頼することは疑問です。
訪問セールスマンの応対だけでは、不良業者と通常業者の判断は難しいですが、すくなくとも、商談に持ち込まれないように注意して、複数の業者から合い見積もりを取るのは必要です。
不具合が生じてから修理するか、予防的に補修するかは難しい判断なのですが、昨今の状況では、セールストークの信頼度は落ちていく一方な気がします。
2010年1月28日
幼少の時に正誤を逆に覚えてしまったり、類似の用語を取り違えて覚えてしまうと、それが擦り込まれてしまい、いまだに戸惑います。
ハイチで大地震がありました。適切な救援を願うのみです。
第一報を聞いたとき、「タヒチ」だと思い込んでしまいました。カリブ海という地名を伴っているので、「なんか違うな」と思ったものの、「タヒチ」と間違ってました。
ラジオ情報では、以前、旅行者が「タヒチ」間違えて、「ハイチ」行きの切符を買って、現地に着いてから、慌てふためいた人がいたとか。
どうも、思い込んだ類似語は直らないてす。
聖書に「天まで届く塔を作ろうとして、神の逆鱗に触れ、多言語が生まれた」とありますが、それを「バベルの塔」ではなく「ハノイの塔」だと思い込んでいました。
積み重なった奇数個の棒とだるま式の駒の入れ替えゲームを「ハノイの塔」といいますが、それをも、聖書に起因したゲームたと信じてました。...w
そして、ベトナムにハノイがあると知った時は、そこが聖書に出てくる塔を作った場所だと、勝ってに思い込みました。
...他人に喋って恥を掻く前に、気付いたのですが、未だに、ハノイときくと、「バベルの塔」が頭に浮かび「いやいや、違うぞ、ハノイのことだぞ」と考え直すので、ワンテンポずれてしまいます。
数値を扱うときは「四捨五入が標準」だと思ってしまうのも類似の傾向かも知れません。小学校の初期に習うので尚更なのかもしれません。
処理的には偶数丸めやJIS丸めが誤差が小さくなるので、こちらを採用しているケースが多いです。
言語仕様に四捨五入が入ったのは、極最近のことです。
小さいときに、ピント外れなことでも、「これが標準だ」と教えられてしまうと、それが「常識」となって後々判断の邪魔になることもあります。
「その人固有の常識」なんて怪しげな物だという認識に立つのが大事なんですが...立てない人が何故か多い....
2010年1月26日
道路の信号は、車が渋滞し難いように、順当に走行できるように、信号の切り替わりのタイミングは計算されて、統制がとれているものだと、教習所で聞いたし、そのように思っていました。
最近の信号は、青信号延長スイッチが付いているのを見かけます。特定箇所の青信号の点灯時間を延長すると、該当道路の統制が狂うように思うのです。
それが起因で渋滞を招いたりしないのでしょうかね。テレビで渋滞の原因の瞬間の映像がありましたが、それは順当に流れているときの渋滞のようです。
信号に起因する渋滞がありそうに思うのです。
交通弱者を優先するのは当然で、そのために信号統制が狂うのは、構わないのですが、信号の切り替わりのタイミングはどのような基準で行われているのか疑問に思いました。
スクランブル式は歩行者に不利な気もしますし。90秒から2分も待たされる信号があったりします。
ロサンゼルスの信号は、道路の半分を渡った時点で「Don't Walk」と出て、嫌な思いをしました。信号の切り替わるルールって、どうなんでしょうね。
(*)大阪(梅田)には「あとn秒で変わります」と案内が出る信号があります。
2010年1月24日
「餃子の王将」は全国展開のチェーン店ですが、関西には二種類の王将があります。
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&rlz=1T4ADRA_jaJP350JP350&q=%e4%ba%ac%e9%83%bd%e7%8e%8b%e5%b0%86%e3%80%80%e5%a4%a7%e9%98%aa%e7%8e%8b%e5%b0%86以前は、共に単なる「王将」と称していましたが、商標問題で一方は「大阪王将」と称するようになったようです。
創業者は親戚ですが、ライバル意識を感じます。
類似の話に、一澤帆カバンがあります。
http://www.google.com/search?q=%E4%B8%80%E6%BE%A4%E5%B8%86&rls=com.microsoft:ja:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7ADRA_ja近親者が同業種を起業したら、敵対意識が生じるのでしょうか。
丸紅と伊藤忠も親戚会社ですね。
松下と三洋も創業者は親戚ですがこちらは、「仲が良い」という印象があります。
親戚会社でも屋号が異なっていれば、消費者は混乱しませんが、タイトルの「王将」は区別がつかない人もいます。
数年前に問題になった「吉兆」も数社の別法人ですが、同じ屋号なので、同一視されるのは仕方ないでしょう
車のディーラーも複数系列があって、扱い車種が異なりますが、顧客からみたら、同じトヨタや日産なのに「何が違うの?」という思いがします。
なんか、錯覚というか、相手のネームバリューを利用した営業という意識を感じます。
法人の命名も難しいものだと思った次第。