学習用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年説があるように、同じ形態のままでは、長続きしないのが普通てす。社会的役割が終わったら、悪あがきせずに撤退するのが良いと思います。

上記のように何百年以上も続けられるのは、提供する仕事の業種が限定されているのが幸いしているのかも知れませんね。

のさ言葉

数回前の「探偵ナイトスクープ」で、「子供とその子供の会話が、異国語で意味不明だ」というのがありました。


「今の首相は?」が 「いぎまばのぼしびゅぶしびょぼうぶはば?」になります。

処理的には、直前の文字の母音を伴うバ行の音が間に入るという単純なものです

普通の会話の速度で、文字置換して発音していて、且つ相手の話を理解して、会話をしている映像がありました。

私も聞き取ってみたのてすが、文字を活字で起こさないと意味不明でした。若い人は同時通訳並にできるそうです。年の差を感じます。

　それで思い出したのですが、幼少の頃、「ノサ言葉」がありました。

http://plaza.rakuten.co.jp/kosuker/diary/200805210003/

http://plaza.rakuten.co.jp/1h9a5s3s0y8a2n6/diary/200706150000/

そのときは、この例のように、単語の第一音のみ「ノサ」が入る、単純なものでした。

「こんばんは」=>「このさんばんは」

これだけでも、普通に会話するまで訓練(?)慣れ(?)が必要でした。

同類の言葉遊びなんですが、単語単位でなく、音単位に挿入しているので、遙かに高度に進歩しているんだなぁ。と妙に感心した次第。

携帯向サイトは静的

#静的以外の要素は表示されないのは、判っています。...でも、愚痴りたい....


アプリの性質次第では、グラフやそのときの状態写真などを動的に表示したいことがあります。

売り上げ日報のグラフとか、その時点での貸し出し状況グラフや、盛況度合いの写真など。

PCサイトのWebだと、



としておいて、xxxx.aspx　内部でResponse.ContentType = "image/gif";　形式を吐き出してあげれば、容易く動的に生成できます。

でも、携帯からアクセスすると、表示されません。

事前に静的なFileを起こして、Url等で指定しないと、表示されません。静的Fileを差し替えることで、擬似動的に実行することはできます。でも、同時利用の時の潰し合いなど、排他考慮が必要になり、ヤヤこしくなります。

この動作は、携帯FullBrowserでも解消されていないようです。



JavaScript(AJAX含む)やCooKie不可なと、ペースの設計条件が異なります。

でも、「データエントリーを携帯でも行いたい」という利用者要望は、あります。

別物とすべきですが、なまじWebアプリの類なので、顧客説明が難しくなります。

アプリの形態は、DeskTop Apli/ Web Apli/ Batch Apliに大別されますが、 PC_Webアプリと携帯Webアプリは分離し４種類に大別したい気分です。

その上、キャリアや機種による制約も加わります。

　本来の業務仕様の部分の開発に要する工数は当然の工数ですが、個別の環境に合わせる作業は後ろ向き作業の感がするのです。

(ボソ)開発工数が予定の数倍要している私がいます....orz。

開発環境って進歩しているようで、進歩していないのかも知れませんね。

アップロード・コントロールの表示と動作可否

アップロードコントロールは、携帯内もしくは、PC内のFileの表示します。


そのコントロールの表示(テキストとボタン)の件です。

[参照(button)]と表示されるものだと。信じてました。

FireFox/IE では、そのようになります。



Operaだと、[選択(button)]

Google/Cromeだと [ファイルを選択]

Safariだと [ファイルを選択]

となります。TextBoxではなくラベルになり手動入力はできません。

携帯でも、キャリアによって違います。

Softbank : [select(button)]

AU : [Brows(button)]

となり、AUの場合、 ASPX部品の FileUpLoadで作成すれば、Enable=True状態ですが、File選択画面に遷移してくれません。

HTML部品の input type="file" で配置すると、Enable=Falseになり、使用不可です。

FileUploadの実装は各Browserに依存するのは仕様なんでしょうが、この違いは、嫌だなぁ。

操作マニュアルを作るにしても、全パターンを洗い出せないだろうし。

各社独自仕様を付加するのは、喜ばしいことですが、基本機能は統一して欲しいな..と思った次第。

外国人と箸

最近、寿司ブームとかで、世界各地に寿司店が増えているそうです。時折TV番組で各地の寿司店の様子が放送されますが、何れも箸を使いこなして食べています。


映像だけなので、実態は不明なのですが、画の外部ではフォークで食べているのかも知れませんが。

(素直に解釈して)寿司を食するために箸の使い方をトレーニングしたと思うのです。

箸はそこそこ練習すれば、年齢に関係なく身に付くものでしょうね。日本人は子供の時から箸を使っているのに、下手な人が目に付きます。俳優さんも握り箸の人がいますしね。

「日本人が外国人に箸で負けてどうすんだ。」と言うつもりはないのですが、鍛錬が足りないなぁと感じます。

別の見解で「箸は、中国・日本独自の文化だ」という意見を聞いたりしますが、未経験者が短期間の練習で習得できるものを文化と称するのは、引っかかりを覚えます。

「フォークとナイフの正式マナー」といっても近世ヨーロッパに登場したもので、それ以前は手掴みだったので、怪しいものです。

歴史は箸のほうが古いから、文化と言えなくもないか。道具として見たほうが良いように思うのです。

サーバーラックの破棄は勿体ない

昨今の規模の大きいサーバーはラック型が多いです。30Uのラックになると、ラック自体も結構な値段がします。


ラック込みで一式を購入するとき、経理上ば一式を減価償却の対象にしているケースもあります。

償却期間が到来し、サーバーを入れ替えるとき、ラックマウント型サーバだけ入れ替えれば、無駄はないのですが。

最初にラック込みで購入しているから、ラック本体も償却対象になり、ラックも入れ替えないと、書類上面倒な事になるそうな。

そのような理由から、ラック込みで一式入れ替えの案件になったりします。入れ替え前の製品は廃棄業者による廃棄証明が必要なケースもあります。

ラックは耐久消費財級で高価で丈夫です。100万円近くする物もあるとか。廃棄処理すると50円/1Kg程度なので、2500円程度になります。

ラックを破棄するなら、払い下げて欲しいと懇願しても、情報機械一式なので廃棄して、廃棄証明が必要なので「不可」とされています。

民間なら融通も利くのでしょうが、公共では無理なのでしょうね。

経理上の減価償却制度は、書類上の処理なので、現実は何かと無駄な事態を招きます。経年変化しないものは、耐久品扱いにすれば、無駄も減りますが、書類が煩雑になる。

開発機器は能力的に数年単位で更新したい場合もありますが、5(4)年間は使い続けることを強いられたりします。

最近は、10万円を切る機種でも充分開発に使えるので、消耗品として購入するケースもあるようです。

経理上の処理の仕組みや制約は詳しくないのですが、「無駄より、書類処理が優先される」という印象は残りました。



話は脱線しますが、マウントサーバーをラックに設置するレールは、時期やメーカーによって設置方法が異なるんですよね。

困ったことに、レールがキチンと填らずに途中で筐体からはずれる事故が起こったりします。1U規格として統一するときに、レールの規格も統一して欲しかったと思います。

ラックの後ろの配線は、柳状態になりがちですが、電源は必須なのだから、ラックに電源配線を組み込んでおいて欲しいとも思います。

for文のループ変数のiは、iterationのi (?)

うーん。javaの人から聞いたのですが、そうなんだろうか。


私らFortran世代の人は、ループ変数などの整数変数は i,j,kがデフォルトです。

(最初の文字がi,j,kは整数変数という具合に型が決まってました)

未だに、ループ変数は,i,j,kの一文字変数を使ってます。

　ですので string i; double j; などの文をみると違和感を感じます。



Fortranを知らない人が「iterationのi」と聞けば、納得しそうな説ですが、(?)感がします。

でも、語源説って、そういうモノかも知れませんね。

元ネタを知らないときは、知っていることで、理由付けするので、異説が登場するのかも知れません。

安・近・短なヘアカット

「ＱＢハウス」という散髪屋さんを彼方此方で見かけます。駅構内にも有ります。


10分で1000円が安いか否かは判りません。普通の散髪屋さんは30分ほど要して約3000円なので、差がないような..

一式で800円という店や、美容院でも一式2000円の店があったりして、格安店は増えているようです。

従来の店は、顧客が減っているし、常連客も、頻度が減っているらしいです。(月一回だった顧客が2ヶ月に一回になった等)

この分野の顧客管理の目的は、「顧客拡大ではなく、顧客が逃げるを防ぎたい」になっています。

情報を提供し続けるために、何を発信するかも重要な要素ですが、特定の店の常連になるのを嫌がる顧客もいるとか。

安・近・短は昨今のデフレ以前からあるので、経済の在り方や商売って判りにくいものです。

あ゛

最近、漫画等で、緊迫感等の表現で「あ゛～、お゛」等があります。


私は、カナ入力なので、問題はないのですが、ローマ字入力では、どうするのでしょうか。

濁点だけの入力って.....くぐってみると、

http://bizmakoto.jp/bizid/articles/0608/18/news050.html

がありましたが、面倒臭そう。

　そもそも、表記自体が誤りですが、表記文化として価値はあります。将来は市民権を得るかも知れません。

「ゑヱゐヰ」は失われたのですが、一部で生き残っています。こちらも、表記文化でしょうね。



ATMのデータ入力や、本屋の本検索機もカナ入力がメインのようです。カナ入力も結構使われています。

こちらは、５０音表での入力だからでしょうね。画面に、ソフトキーボードが出てきて、ローマ字変換になる機種もあるようですが、利用度は低いようです。

ローマ字入力は、ブラインドタッチが前提なのかもしれませんね。

合鍵

前回鍵に関することを書いていて、思ったのですが、普通の鍵の合鍵は無制限につくれますね。


インテリキーや使い捨てキー(ホテルの鍵など、毎日変わるもの)は合鍵は作れないようです。しかし、

普通の家やマンションの合鍵は手軽に作れます。賃貸マンションやアパートなど、借り主が変わったとき、鍵を付け替えているか否か不明確です。

デジタルオーディオのように、n回までの合鍵を許す...となるとインテリキーになるので、高価になるのでしょうね。

車の合鍵も最近は、別オーダーしないと作れませんし、ドアの鍵穴が隠れていたりします。

　「鍵の110番」や「鍵の救急」がビジネスになるのは、持ち主が鍵を紛失したり、閉じ込めたりする頻度が高いのでしょう。

他人が持ち主を騙ったり、なりすましたりして悪用するケースもあるようです。

　解錠できるということは「鍵は安全ではない」となります。そのように認識していたほうが良いかも知れません。

意外な経験もあります。どこにでもある事務ロッカー(書類などを格納する棚式)の鍵を紛失して、鍵屋さんを呼んだのですが、格闘の末「開けられません・料金は要りません」となりました。

単純な鍵は、強いかも知れません。ロッカーを破壊されたらお終いですが....

鍵を施錠したか...薬罐の火を消したか..

外出時、施錠したか、コンロの火を消した不安になって心配する人がいます。


確認しに戻ると大抵は施錠してるし、火の始末もしている場合が多いです。

火は消していても、元栓を閉めたか否かが不安になったりします。

心配しだすときりがないのですが゛。

　キーの部分に施錠/解錠の操作結果をマークする仕組みが有れば不安解消にならないか..と思いました。

IC.Tipの埋め込み実装で可能そうです。既に存在しているだろうと思いますが探し切れませんでした。



鍵やガスの元コックにIPが振られて、状態を発信するようになれば解消しますね。

今の実装技術の普及度の早さからみて、近い間に普及しそうな気がします。

歯ブラシにIPが振られていて、歯を磨いたか否か監視されたら嫌だなぁ。

それが、幸せなのか否かは別にして....個人的には機械任せにする不安のほうが高いのですが。

郡....不思議な存在

行政区分の町村は、どこかの郡に属していますが、行政単位の郡があるわけではありません。


明治期には郡役所が存在していて、それなりの意味があったそうです。

最近までは、同一県内に、同名の村が存在するケースがあり、区別する意味がありました。

　(*)群馬県に東村が５カ所あったそうです。

最近の自治体合併でそれも解消されて、識別子としての意味もなくなりました。

律令制の名残として残しいと思うのですが、事務処理上は、冗長感が拭えません。

冗長性の排除が正解ではないし、冗長性は潤滑油として有用な事が多いのですが、郡の意味がよく判りません。

県名の有無

住所項目の保持や表記は、都道府県名から書くのと市区名から書くのと、どちらが多いのでしょう。


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()して格納すると、叱られることなったりします。

年賀状作成ソフトの宛名の印字位置調整機能やフォントサイズ調整機能は、よくできています。

事務教務アプリだったら、本質的でない仕様なので切り捨てられる要望ですが、それが命の商品なので、気配りの深さに感心します。

情報の保持は、デジタル的有意性だけでなく、感性の部分もあるなぁ。と思った次第。

ラーメン缶自動販売機

初めての道を歩いていて、缶詰のラーメンの自販機を見つけました。思わず眺めていました。


大きさは350ccのジュース缶くらいでした。

ホットとコールドがあったのですが、購入しても、その場で食べるものなのか、食材として売っていて、自宅で調理するものか、判断が付きかねて、購入しませんでした。

なんか気になったので、ググってみるとありました。

http://www.fujitaka.com/rahmen/



お汁粉やコーンスープの自販機は時々見かけますが、味噌汁の自販機は見ませんね。と思っていたら、存在するようです。

http://news.ameba.jp/economy/2008/09/18034.html



何でもありますね。カップ麺などの食料の自販機は、テープル施設が伴っている施設に設置されていますが、上記の自販機は、ジュース自販機と同列においてあり、テープル施設はありません。

その場で、食べられるモノか否か判断できない。その場で食事するのは、違和感があります。といっても、「(道路上で)ジュースの立ち飲みOKで、ラーメンの立ち食いはNGという感覚」も崩れていくのかも知れません。

今度その前を通ることがあれば、試してみようっと。

HashSetのコスト

以前、 επιστημηさんが、「Hashすげー」http://blogs.wankuma.com/episteme/archive/2009/12/06/183571.aspx


で、HashSetの早さを報告されています。

C#でも 3.5から導入されいて、重複要素の排除などに重宝しています。

C#3.0以前で同様のことをするには Dictionary で行えます。 KeyとValueに同値をセットすれば使えますが、Vの部分に冗長性が出ます。 速度コストが気になり試行して見ました。Value部の冗長性がないので、「コスト安であろう」 と勝手に期待してましたが... ▼▼▼テスト結果▼▼▼ AMD64*2:4600+ 2.4G ----------------------------------- mSec mSec ▼回数: 1▼ dict : 0 追加数[ 1] Hash : 38 追加数[ 1] ▼回数: 10▼ dict : 0 追加数[ 10] Hash : 1 追加数[ 10] ▼回数: 100▼ dict : 0 追加数[ 87] Hash : 0 追加数[ 87] ▼回数: 1000▼ dict : 0 追加数[428] Hash : 0 追加数[428] ▼回数: 10000▼ dict : 2 追加数[499] Hash : 2 追加数[499] ▼回数: 100000▼ dict : 20 追加数[499] Hash : 16 追加数[499] ▼回数: 1000000▼ dict : 106 追加数[499] Hash : 88 追加数[499] ▼回数: 10000000▼ dict : 862 追加数[499] Hash : 948 追加数[499] ▼回数:100000000▼ dict :8653 追加数[499] Hash :9196 追加数[499] 僅かですが、「Dictionary<> のほうが早い」場合もありますが、有意差はないようです。 内部の実装がどのようになっているかは、知らないのでずか、同じツリー構造で格納しているのなら、差はもっと小さいと思いますが違うのかな。 これくらの差なら、HashSetを使う価値はありますね。 NameValueCollectionクラスという、Dictionaryの同一キーに対する要素を複数保持できるモノがありますが、知られることなく埋没されていますね。 Dictionary< key , List