営業日カレンダー

窓口業務システムには営業日カレンダーを設定することがあります。
定休日がxx曜日と決まっていると楽です。
理髪店は月曜日と隔週火曜日になっていますが、算出できるので、機械的に設定可能です。
祝日は固定日はよいのですが、春分の日,秋分の日は不定でした。これは不思議な日で、暦からは100年後でも算出できるのに、何時の日を祝日にするかは、毎年決めるらしい。
「前年2月第1平日付の官報で発表される。」とあり、法律上不定日なので、あらかじめ組み込んで置くことはできないことになります。
ハッピーマンデー法で適用日の範囲が時々、変わったりするので、自動化するのは無理があります。
博物館や動物園は、祝日と定休日が重なったら、次の営業日が振り替えになります。
年末年始の休み期間も浮動のようです。
定休日が曜日ではなく、3の付く日(3日,13日,23日)　のように昔ながらの習慣の店もあります。
昔の職人のように1日と15日の二日が休みの店はさすがに無いですよね。
営業日カレンダーの設定はある程度、人力による部分があります。
ボソ....「全自動で設定できる」...こんな仕様ゃ提案をした人は誰ですか。

携帯メーラの文字化け

HTMLだと、先頭にコード識別(CharSet)を書いておくと、ブラウザーが判断してくれます。
コード識別を書かないでも自動判断してくれます。偶に誤判断するようですが。
キチンと明記しているのに、文字化けすることってあるのかな。

これだけメールが飛び交っているのに携帯メーラーが文字化けする事があります。
UTF-８で統一すれば解消に向かうのでしょうが、S-JIS/EUCでメール発信することも多々あるようです。
受けるメーラーが的確に判断してくれれば良いのですが。

或る箇所からのメールはS-JISエンコードで発信されてました。私の携帯(AU) では正常に受信できてたので、意識しなかったのですか、Softbank携帯の人は、「文字化けして読めない」と言ってました。自動判定ができていないのか、SJISが不可なのか? まさかねぇ。 携帯メーラのDecodeって設定できないのかなぁ。キャリアの問題なのか特定機種の問題なのか?
ヘッダー部でCharSet指定していないと思うのですが、AUでは自動認識しているから、Softbankでも可能だと思うのです。
同じメールをGoogleメーラ(?)で読むと、Subjectは正常で本文が化けるらしい。(softbankでは、subjectと本文、共に化けるらしい)
送り手は、チャンと読んでくれていると思っているだろうから、特定の携帯で化けていると、マイナスですしね。
文字化け問題は解消するのだろうか。

携帯向けサイトは基本かもしれない

「携帯向けサイトはWebアプリの延長線だ」と高を括っていたら、落とし穴ばかりなのね。
Cookie/JavaScriptが使えない(もちろんAJAXも)のは既知ですし、機種によってレンダリングに差違があるのも既知です。
でもね、表示具合が異なっても、曲がりなりにでも表示して欲しいのです。DOCOMO/AUでは表示できるページがSOFTBANKではコンテンツエラーになったり、エミュレータではエラーになるのに実機では動作したり。
３会社以外も基盤会社があるし、同一会社でも複数の機種があり、全機種でテストは不可能です。
代表的な機種で動作すれば、OKと見なすしかないのでしょう。
最近は、iPhoneでなくても、フルブラウザー機種があるけれど、携帯向けアプリは、従来型を対象にするべきですしね。

　最初は、ASP.NETのサーバーコントロールを使用していたのですが、レンダリングのタイミングが合いません。結局、ClientScriptBlockを使って、自力レンダリングしています。
瓢箪から駒なのですが、レンダリングを自力で実装してみると、サーバーコントロールの動作がカッタルく見えてきます。不思議なものです。
ASP.MVCはサーバーコントロールが使えないそうですが、使わない事のメリットもありそうです。
Webアプリの基本は、HTMLコントロールだという基本を思い出させてくれました。便利な道具に慣れると、基本が愚かになるという実例ですね。

そうは、いうものの、同一キャリアなら実装しているレンダリングエンジンは同じなのに、機種によって動作が違うのは、どういうこと?

一回のトランザクションの量

気にしたことがなかったのですが、BeginTran()～Commit() の間に実行できるSQL文の量って、制限があるのでしょうか。
RDBサーバーの使用可能なメモリー量とRDBの作業領域の規定で決まると思います。
普通に使っていると制限を受けることは無いと思ってました。
バッチで数100万件の更新をRoleback()することもあるので尚更でした。

郵便番号CSVデータ(約12万件)の取り込みを私の環境下で動く8種類のRDBで行いました。
(*)数値を明示すると、規定に抵触するので、目安数字を記します。


SQL server 7.2分
MDB 8.1分
Oracle 10g 7.5分
MySQL inno 7.2分
Postgres 6.8分
SQLite 5.6分

数千件の時とは異なり、SQLiteが早い結果になりました。Postgresも優位。大量データに有利な作りなんでしょうか。

DB2 は SQL0964C　のエラーが出て、Abendしました。メモリ不足で続行不能になります。 30000件前後でアウトでした。
　　　　　　　　　　「トランザクションログがいっぱい」のようです。

Firebird は40000件前後で unable to allocate memory from operating system　が出て、落ちました。

デフォルトのまま使用していると、限度があるということでしょうか。
SQL Server/Oralcleでは、なにも考慮しないで、使っていただけに、少しショックでした。
大量件数のバッチが途中で転けることになったらエライことです。実データ量での動作確認は必要ですが、
SQL Server/Oralcleでトランザクション量の限界テストって、どのあたりまで、考慮するのでしょうね。
ログを自動拡張していると、制限なし...ですね。
以前のOracleだと、ログのサイズ制限があって制約があったようですが、今は無い..ですよね。
ログ制約は押さえないと駄目ですが、デフォルト使用で、30000万件程度で落ちるのは、不親切な気もします。

森伊蔵はありませんが、松露はあります。

前回のコメントで、お茶で身代を潰す話がでました。それで思い出したことがあります。日本酒店で見かけたコピーです。
私は、味音痴なので、高い酒も安い酒も区別が付かないので、アナザーワールドの世界なのですが。
「森伊蔵」は高いらしい、1本1～2万円台もあるそうです。
「松露」や「越乃寒梅」の売価をググッてみると、数千円のようです。
(もっと高級バージョンがあるのかもしれません。間違っていたらごめんなさい)

ネットのカタログから察すると、森伊蔵の価格帯は、違う品種のようです。匹敵する他のメー柄は見つけられませんでした。
聞き酒のできる人にとっては、垂涎なんでしょうね。
　「越乃寒梅」が高級品だと聞かされていたので、想像するほど高く無かったので、意外でした。

このキャッチコピーでずか、 意外性があって面白いと受け取りました。
言ってみれば、「2万円の商品はありませんが、5000円の同様な商品はあります。」と言っている感じがして、くすぐられました。
この場合。「松露」に対して、失礼にあたる気もしますし、「森伊蔵」を崇めているような感じも受けます。
比較広告の一種なんでしょうね。

電気ケトル

最近、電気ケトルなるものが流行らしい。1リッタ程度の小型のものを見かけます。比較的安価で、数分で沸騰するので便利です。
でも保温機能がないので、都度湧かすことになります。
湯沸かし機能付きの電気ポットと比べるとどうなんでしょう。保温に費やすコストと都度必要量を湧かすコストの差よりも、数分の待ち時間に耐えれるかどうかが基準になりそうに思います。因みに私は、電気ポット派です。

話は変わって、普通のガス火にかけるタイプのヤカンですが、先日、買いにいったのですが、安価なヤカンを売っている店って少ないですね。500円前後でありそうに思ってました。
売っているのは2000から4000円の上等なヤカンばかりでした。アルマイト製の大衆向けヤカンはどこに売っているのだろう。
見て回った店には置いてませんでした。　さすがに100均では扱ってませんね。
どこに売っているのかと、ググってみると、思い違いしていました。
　　http://www.ezoya.co.jp/goods/yakan.html
アルマイトやかんでも、そこそこの値段がします。私が勝ってに、「ヤカンの価格は安いものだ」と思っていたみたい。
ヤカンが3000から4000円するのだったら、電気ケトルは安く感じますね。

(*) スーパーで700円で笛吹きケトルがありました。相場の値段ってよく分かりません。

メジャーRDBは快適(?)

.net.言語で元データがクライアントにあり、RDBに追加する時、
接続.open
Begin.Transacton()
while(!eof())
{
1件read().
insert 文発行
}
Commit()
切断

とするのが一般的です。(バルクInsertにすべき...と突っ込まないでね。)
Transactionを噛まさず、都度Commitすれば、遅くなるのは想像できます。その差を知りたくてテストしてみました。
郵便番号のCSVファイルを使ってのテストです。例によって、3000件でのテストなので、荒っぽい結果ですが、傾向は判ります。
規定で、具体的に数値を公表することはできないので傾向の報告になります。
私の環境下で、操作可能な RDBは SQLServer2008,MDB, DB2(9.5),Oracle(10g), MySQL(5.1),PostgreSQL(8),SQLite(3),Firebird(2)の８種類あります。
MySQLはテーブルモード(Heap,InnoDB,MyISAM)によって、「トランザクションの有効無効がある」とあるのですが、差違は無いようです。

都度コミット　　トランザクション下
･SQL Server 12秒 9秒
DB2 12秒 9秒
MDB 12秒 12秒 差なし:
ORACLE 12秒 10秒
MySQL5_HEAP 98秒 10秒
MySQL5_InnoDB 99秒 10秒
MySQL5_MyISAM 93秒 10秒
PostgreSQL8 12秒 10秒
SQLite3 177秒 9秒
Firebird2 18秒 12秒

興味深い結果となりました。 MDBは、Transaction効果は薄いらしい。
MySQLは 非トランザクションだと、異様に遅くなる。
トランザクション下では、Firebirdが少しコスト高ですが、他は差が小さい。
Oracle/SQL Serverはメジャーだけに、速度面も優位ですね。
私的には、 SQLiteやMySql_Heapがもっと快速に動くものと期待していたのですが、期待外れ。コスト安なら、活用すべく習得しようと思っていたのですが、
MSSQL/Oracleで十分なようです。
学習意欲が萎えたのは内緒です。
#題字に快適と書きましたが、もっと早くなって欲しいです。

DateTime2の使い道

以前に書いたのですが、SQL ServerにDateTime2型が増えて、100ナノ秒単位の捕捉が可能になりました。(Windows2008等のサーバーOS下で)
嬉しがっていたのですが、不具合が起こりました。
いままでは、ありがちな楽観的排他制御なんですが、
　　 事前に元データを取得して DataSet(dt) に取り込んでおく。
　　　SQL= "update TABLE set xxx=xxx where 更新日時=@元更新日時"
para meter設定で @元更新日時 = dt.rows[n]["更新日時",DataRowVersion.Original]
ur.ExecuteNonQuery(sql, para, CommandType.Text);
のような処理で対処していました。

この、["更新日時"]の型を　DateTime型からDateTime2(7)に変えて、代入する値を、sysDateTime()でセットするように変えました。
すると、この Update文が成立しません。更新日時=@元更新日時　が不成立です。
型にDateTimeに戻すと、成立するので、どうも型の動作に問題がありそう。
DataRow()に取り込んだとき値は丸められるのでしょうか、Debug.printで見る限り同値でした。
結局、排他用には使えなさそう。となると、DateTime2()の使い道は狭まるのだろうか。
「排他制御は、TimeStampを使え」ということでしょうが、他のRDBと協調したいので、使いたくないのが本音なのですが...

星形ネジ

ネジのトップの形状は、-や+ が多いです。なかには、星形のものや六角の凸型のものもありますね。
六角ネジは、ドライバーがフィットしないと、噛み合わないので、ねじ山が潰れることが無いので好きです。
一般的には、-ネジが安定しているようです。
+だと、フィットしないドライバーで無理して回して、ネジ山を壊すことが起こるようです。
星形ネジの製品に直面したことがあります。ブレードサーバで、HDDなどの機器を装着する部分の覆いが星形ネジでした。
現場では、星形ドライバーがなく。「なんで工具が付いてないんだ。」と文句を言ったものです。
ホームセンターで調達したものの、サイズがフィットせず、噛み合わせが悪い。ネジ山を潰しそうでヒヤヒヤものでした。
現場に適したドライバーが存在しているとは限りません。一般的でないネジを使用していて、ユーザーに脱着を要求する製品には、フィットしたドライバーを添付して欲しいものです。
ソフトでもハードでも、顧客が適切に対処してくれる事を期待して作成すると潜在バグを生む事になります。
ネジ山を潰してからでは遅いです。

　DELL等の最近の製品は感心します。 DVDなどのデバイスの装着にビスを使ってないのですね、アタッチメントを操作するだけで脱着できます。
便利な仕組みになったものです。
　HDDやFDDなどで、インチネジやミリネジを使い分けていたのは、昔話になるかもしれませんね。

ホッチキスの虫

ホッチキスは商品名でステープラと言うのが正確らしいです。ても一般的にはホッチキスで通りますね。
ホッチキスの針ですが、私の地域ローカルでは「ホッチキスの虫」とか「ホッチキスの玉」と言っています。

文房具を買うとき、売り場に行っても必要なものを買うだけで、ジックリ眺めたことがあまりなかったです。
最近は、100円ショップの文房具コーナーも品数が豊富で、改めてゆっくり回ると、楽しいですね。様々なものがあり、「100円で元取れるの?」というのもあります。
ホッチキスのコーナーに「カラー針」なるものがありました。メタリックカラーになっていて、６色くらいバリエーションがあります。
銀色の針以外を使っても、実利は薄いですが、なんか楽しい感じがしますね。

ホッチキスといえば、急いで使う事態に陥った時に限って、針がなくなっていたりします。マーフィー則でしょうか。
使い切ったことに気づかず、放置しているんですね。
これって、使い切った事を通知する仕組みを実装すれば、「便利では」と思うのですが.....。
アクションを起こした結果を認知して、アクターに通知するのは難しそうですが、最後の1本を使った時点で、戻らないようにすれば、通知できそうな気もします。
データアクセスでも、Openしただけでは、 EOFか否かの判断ができず、1件目をアクセスして初めてEOFか否かが判る、仕様のものがあります。
「先行読み取りの仕組み」ってあれば便利ですが、実装はコストが掛かるのかも知れませんね。

交通巡視員と原付

私が知らなかっただけでしょうが、原付にも駐車禁止で摘発されることがあるようです。
昼休み、ほっつき歩いていたら、交通巡視員が駐禁摘発している現場に出会いました。
車両が見あたらないので、何しているのかなぁと思って、近づいてみると、電柱横に、自転車と並行してとめてある原付に対して、証拠写真を取り、切符を切っている様子。
原付は放置自転車の撤去と同様に撤去されても切符は切られないから、なんか理不尽さを感じました。
「その周りは、駐車違反が激減した地区なので、巡視員は対象を原付にした」とまことしやかな噂まであります。ノルマの有無は知りませんが、原付といえども放置できない時代になったようです。
自宅前の道路に停車している場合、どうなるのでしょうね。自宅前で駐禁になると辛い人が多く居そうです。

索引張っていても遅くない

RDBのテーブルにデータを挿入するとき、索引があると、索引の更新にコストが生じて遅くなる。
大量に挿入するとき、索引を外すのが良いとされます。
でも、どれくらい遅くなるのが資料がありません。

気になっていたので、確認してみました。(SQL Server 2008 + Win7 Memory 3.2G)

テストしたテーブルは

CREATE TABLE 市索引付
(
県ID VARCHAR(2) NOT NULL,
市ID VARCHAR(3) NOT NULL,
市名 NVARCHAR(64),
CONSTRAINT PK_CITY PRIMARY KEY (県ID, 市ID)
);
CREATE TABLE 市索引無
(
県ID VARCHAR(2) NOT NULL,
市ID VARCHAR(3) NOT NULL,
市名 NVARCHAR(64)
);
で、データは3363件用意しました。数回試行した結果は

索引付: laptime [00:00:10.3907784]秒
索引無: laptime [00:00:10.4113862]秒

誤差を考えると、差はないとみていいでしょう。索引に対して、SQLサーバーの最適化が進んでいると言えそうですね。
3363件で約10秒なので、1件あたり0.003秒となり、妥当な数字だと判断しています。

「xxxすると遅くなる」というのは多々聞きますが、確認しないで、鵜呑みするのは危険そうですね。

複数の索引をはっていたりすると、差がでるのでしょうね。

DB2の2byte文字

最近、RDB上の文字列は、nvarcharで画一的に規定して使っています。それで不具合に直面したことがないので、ユニコードがそれだけ汎用性が高いということか。
DB2のTableを見ることがあって、戸惑ってしまいました。nvarcharとかが見つからない。データベース作成時に"USING CODESET"で指定するらしい。
他のRDBみたいに、型規定での使い分け、は無理のようです。
1byte文字系はchar()で、2byte文字系はGraphic() となっていて、半角全角を区別する文化が根強く残っています。
当初、2byte文字をGraphicと見なしていたのでしょうが、名前を是正するチャンスはなかったのでしょうか。このままだと、ずっとGraphic()の名前のまま続きそうです。
DB2は、EBCDICコード系の分野もあるので、Shift in/out 付きの文字列を扱う場面もあるので、他のRDBとは違う事情もあります。
でも、graphic()のサイズを graphic(1～174) で規定してかつ、半角全角混在して代入したら、char()との扱いの差はどうなのか?
動作確認できる環境がないので、なんとも言えないのですが、データ型表を眺めているだけでも、いくつか疑問が沸いてきます。書籍も少ないですしね。

国境は"コッキョウ" or "くにざかい"?

川端康成「雪国」の冒頭「国境の長い トンネル を抜けると雪国であった」は教科書にも載っているので殆どの方がご存じでしょう。
さて、冒頭の国境のヨミはどちらでしょう。私は無意識に「コッキョウ」だと思っていました。
「くにざかい」と読むべきだという話があります。http://www.asahi-net.or.jp/~qm4h-iim/k020322.htm
「コッキョウ」だと国際的な国境を意味するので不適切だとの論です。
件の小説の舞台は、上野国・越後国の国境なので「くにざかい」であるべきだそうです。

川端康成氏存命の時から、川端研究者が存在していて、読み方問題が討論されていたようです。
当時の研究者か、作者本人に問い合わせた話を、高島俊男氏の本で読んだ記憶があります。
それによると、「読み方までは考えていなかった。コッキョーでいいのでないの」と答えられたそうです。
　ということは、作者本人の意図を無視して、ギャラリーが「くにざかい」であるべきだと主張していることになりますね。
国語の入試で「作者はなにが言いたかったのか」の設問に当の作者が間違ったという話もあります。
物事の決まり事や、ルールが当事者の意図とは違う視点て決められしまう例ですね。

「漢字での表記は規定するが、読み方は規定しない」という文化があるのかもしれませんね。
戸籍でも読み方は書かない、住民票で補足項目として読み方を記載しているたけだ。とも聞きます。
会話は、口語なので、読み方重視だと思うのです。でも、欧米人が単語のスペルを確認して話をするように、漢字を確認しながら会話をすることもありますね。
昔の武士の名前は分かっているが、読み方が不明なのもあるようで、なんか不思議な感じです。
　普遍的な読み方が存在しないので、alphabetのように発音記号の採用は不可能なんですね。
ふりがなを付けるべきだと思いますか、一方でフリガナを付けるのは「子供じみて見える」との意見もあります。

フリガナを付けないのは格好が良く見えますが、それと「大人じみている」こととは直結しないでしょう。
フリガナをつけて、誤読を抑制するほうが良いと思うのです。そうしないと、誤読バグを生み、後になってそのバグは大きくなって手を噛まれることになりかねません。

作者にとって読みは明白なんでしょうが、明記されていないと、後日作者と無縁のところで解釈論争が発生し、不毛論争になります。
開発作業も同じですね。
作成当時は、明白な処理分岐であっても、後日追跡すると、「なんで、こんな分岐があるの」というのがよくあります。これが、「動くから弄るな」となり、いつまで足を引っ張ることにもなります。
明白なことほど、明記する必要がありますね。

参加したくない祭り

祭りは参加したくて、うずうずするのですか、昨今のインフルエンザの祭り状態には巻き込まれまいと気を付けたつもりでした。電車の車内感染は不可避ですね。
でも,,,,罹患しました。咳が出始めて半日で39度5分まで発熱しました。
医者に行くと、A型インフルエンザです。と言われました。 A型の判定はできても、新型か否かは判別できないらしいですね。
毎年、11月に予防接種するので、ここ10年くらいはインフルエンザとは無縁でした。
今年は、予防接種が間に合わなかったのね。
　今回初めて、リベンザを処方してもらったのですか、これは、吸入薬なんてすね、ロケット状の薬を破って吸入器で吸うのですが、なんか頼りない。
薬が吸い込まれている実感が伴わないのです。でも、回復しているから効いているんですね。錠剤の方が、精神的に安心感がわきますが。
　9月、10月に予防接種が可能な体制か整っていれば、ここまで悪化することはなかったと思うのですが、できなかったのでしょうね。
小中高校は、学級閉鎖、学校閉鎖が相次いています。春先の学級閉鎖の穴埋めは、夏休みを短縮して補完したようですが、
今の時期の閉鎖の穴埋めは、冬休みを削るのでしょうか。不安な噂が流れています。
卒業式が1ヶ月延期になった高校もありました。
　早く沈静化することを望みます。