人並みに年末挨拶

今年は、波乱の多い年でした。
プロジェクトが途中分解してしまい、次が決まらない初めての待機期間もありました。
下半期には仕事が増えるいう噂を信じてましたが、反対に減っている現実。政権が変わることで逆に冷えてしまったようです。
今では、「後数年は悪化し続ける」と云う人が増加している現実。うー。寒。　皆様も風邪を召さないように気を付けて下さい。
　それにしても、大手Sierが内製モードに入ったけれど、人の管理スキルは高いけれども、開発スキルが不足して、品質に悪影響しているという、現場の悲鳴が聞こえてくる昨今です。
IT業界だけ発展することはあり得ません。ITは産業の縁の下の道具に過ぎません。基幹業務が発展してこそのIT業界です。
一介の開発者が叫んでも時代の流れは変わらないかもしれませんが、叫ばないと尚更変わりません。
開発スタイルが大きく変わりそうなIT業界なのに、受け入れる社会構造が不調ならば、真価を発揮ないで終焉するかも知れません。
　技術史とはそういうものかも。時代の景気の歯車と噛み合わ無ければ、良い物でも日の目をみないのかもしれません。
逆に、劣っているものでも時代の波に乗れば、スターダムに乗れます。技術者は、時代を読む目も必要だと思います。
来年は少なくとも前に進む事を願います。

CodeDom プロバイダ型....を読み込めませんでした

asp.netアプリをコーディング中に、
「CodeDom プロバイダ型 "Microsoft.VJSharp.VJSharpCodeProvider, VJSharpCodeProvider, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" を読み込めませんでした。」
というエラーが出て、コンパイル不能状態に陥りました。
　File/行/列の各欄がブランクのエラー報告なので、システム設定周りだと思い、調査する事に....
おかしなことに、同じソースを実行しても、上手く動作するときも有ります。

このプログラムは、ソース生成器の機能を持つのですが、特定データを処理した後のコンパイルで上記のメッセージがでて、コンパイル不能に陥ります。
うーん。謎は深まる。Compilerが読み込めない状況って、何だろう。
ソースの生成先は、同じアプリと同じ仮想フォルダー(~/data/temp/)に作成する仕様になっています。
データに依存するのでは...と追跡してみると。 「xxxx.java] と言う名前のFileを吐き出した後に、不能に陥ることが判りました。
だから 「VJ-compilerが読み込めない」になるんだ。原因は納得。
ソース生成器として、「java」ソースを書き出すときは、要注意です。
プロジェクトフォルダー以外のフォルダーに書き出せば回避できますが、レンタルサーバーの場合は、それもできません。
折角、クラスモジュールは{App_Code}で一本化しているのだから、データ用に {App_Data}を設定しておいて、その下では、拡張子は不問としてくれたら、スッキリするのですが。

それ以前に、aps.net(2008)は VB/C#の二種類しかないので、 .javaを言語ソースとみなすのは、不合理だと思う。
(*)このことで、数時間潰れたことは内緒です.....orz;

染料と顔料

インクジェット・プリンターの中には、黒インクを二種類搭載していて、染料と顔料の二種類を使い分ける機種があります。
染料と顔料の違いは、大雑把に言えば、粒の大きさの違いで、水に溶けて同化している染料と、溶けずに粒子状で存在する顔料ということになります。
(*)違いはわかるのですが、二種類搭載する必然性の説明にはなりません。感覚的には、RGBインクと同様に1種類の黒で良いような気もします。
色で染めるのだから「染」料= 染料は判ります。でも、粒が大きい材料=>「顔」料となるのが判らない。顔が大きいのではなさそうです。

陶器と磁器も、土を焼いて作るのは同じですが、
バクテリア作用でねばり気をおびた「陶土」を焼いて作るか
細かく砕けた石が、バクテリアなどの作用で粘土質になった「磁土」を焼いて作るかの違いがあります。
でも、粘土質になったものを「磁」土とするのが判らない。
「磁」がつくと「電磁波」が浮かび、波動物理や磁石/磁力を連想してしまいます。

顔料と「顔」、磁器と「磁力」は無援です。でも字面は共通です。あー・ややこしい。

牛丼の味

世の中デフレだそうで、ファストフードが混んでます。
仕事関係の人と吉野屋に入ったとき、その人が「牛丼は吉野屋に限る。なか卯や松屋の牛丼は食べれない」(固有名詞ごめんなさい)と宣います。
私は、すき家も松屋も吉野屋も美味しさの違いが判りません。指摘されたら、味が違うような気がしますが、目隠しして利き飯(?)したら区別が付かないです。
その人は、言い当てる自信があるそうです。
　300円と比較すれば、何れの牛丼も美味しいと思うのです。今は潰れて存在しませんが、大阪には「ビックリラーメン」なるものがあり、1杯180円のラーメンチェーン店がありました。(価格でビックリから命名)
7～900円のラーメンと比べると貧弱ですが、180円として味わうと、美味しかったです。
価格を基準にして、コストパフォーマンスで判断する私、安いだけでは食べない人、同じ帯域の商品なら質で判断する人(これが普通か)
物の評価基準は複数あるのだなぁ。と改めて思ったしだい。
(*)その前に、吉野屋、なか卯、松屋、すき家、各店牛丼が同じ味に感じる私の味覚に問題があるかも知れませんね。

LEDテレビとLED電球

薄型テレビは液晶型とプラズマ型の二種類だと、思っていたところに、LED型薄型テレビのCMが目につきました。
LEDは発光型の半導体なので、液晶に変わるものかと早合点しそうになりましたが、液晶のバックライトにLEDを使うという話なのね。
なので、液晶型の性能に依存するのでしょうね。
LED型電球も普及期に入りかけてますが、単価は結構高いです。吹き抜け天井の電球の交換に手間が掛かるので、LED型に変えれば助かるんでしょうが、価格面で二の足を踏んでます。
いままでの経験から、普及すれば価格が低下すると思われますので尚更です。踏ん切りを付ける時期は難しいですね。
LED電球は10年以上持つと言われていますが、製品ができて、日数が経っていないのに10年持つと言えるのかなぁ。
写真のCMで100年プリントというのがむありました。
このようなxx年間大丈夫というCMは、実測値でないので、データ的にはそうでしょうが、信憑性が伝わらないのは私が捻くれているからか?
電球の寿命は当たり外れが多く、同時期に交換しても半年で切れる球や3年持つ球もあります。幸運・不運があるのでしょうね。
でもLED電球は魅力的だなぁ。

先行の貨物列車が遅れたので当列車は６分遅れています。

JRに乗ったとき、5～10分ダイヤが乱れてました。そのとき社内放送で、タイトルの放送がありました。
「なんか、違うぞ」という感じがしました。(*)私の個人的な感覚なので、同意の方はいないかもしれません。
この言い方だと、遅れた責任は「貨物列車」にあるように受け止めたのです。「貨物列車」はなんらかの理由で遅れたのでしょう。
降車駅の掲示板によると、ある踏切が故障か無謀横断で降りた状態になって解除できなかったようです。
「貨物列車」は濡れ衣を着せられたと感じたのです。

車両内で子供が暴れているとき「暴れちゃ駄目。隣のおじさんに怒られるよ」と叱っているのも違和感があります。
「xxxだからyyyしてはいけない」「xxxだからyyyになった」と因果関係を明確にするべきでしょう。

本屋もポイントカード

最近はポイントカードやマイレージカードを取り入れた店が増殖していますね。
カード類が増えて管理仕切れない現実です。
大阪駅前の旭屋がポイントカードを採用しました。1%還元のようです。
Book Oneでは5,000円以上の買い物で喫茶店での飲み物券が貰えます。これだと5%還元ですね。(原価でみれば違いますが)
ジュンク堂では10,000円以上でコーヒーが飲めます。2.5%還元になりますね。損得で見れば飲み物が有利ですが、現金が貯まるほうが良いのかも。
ポイント還元は、東京文化だと聞きました。大阪文化は、現金値引きでした。大阪本拠の家電量販店でも現金値引き交渉が有ったのですが、ボイントの店になってからは、値引き交渉が減ったとか。
この面でも、大阪文化が衰退するのかなぁ。
ボイント制度は、リピート客や囲い込みが狙いなんでしょうね。ボイント蓄積したカードが使わないで眠っているのも多々ありそうです。その分も収益計算しているのかな。
そういえば、携帯普及以前にテレフォンカードが氾濫していたとき、使わないで死蔵されたカードが多数あり、結果としてNTTの収益になったとか。

本の価格は再販制度で決められいます。これ自体の廃止論や是非論はありますが、価格維持を前提としている制度の元の本屋さんで、
ポイントカードを発行が、再販制度を崩す「蟻の一穴」になる危惧はないのでしょうか。
大型書店が乱立していますが、共倒れにならないのが不思議です。街角の小さな本屋さんも健在ですし、不思議な業界に見えます。

郵便番号簿のBulk Merge 取り込みと、 都道府県コード表作成のまとめ

数回に渡って郵便番号CSV　Fileから47レコードの 都道府県コード表を作成するコストを書きました。
その都度、テストに使ったDBサーバーやクライアント端末が異なっていて、結果に一貫性がなかったのと、発端になった非推奨ソースがイビツだったことによりスッキリしない部分がありました。
今回の纏めでは、郵便番号CSV全件(郵便番号の重複を解消した自前の補正後データ: 118822件)を入力とします。

①全件作成
A:Bulk Merge で全件作成
MERGE INTO z_郵便番号 A USING OPENROWSET( BULK '補正郵便番号.CSV' ,FORMATFILE = '郵便番号.fmt' ) B
ON A.郵便番号 = B.郵便番号
WHEN MATCHED THEN UPDATE SET A.全国地方公共団体コード = B.全国地方公共団体コード,.....
WHEN NOT MATCHED THEN INSERT VALUES ( B.郵便番号 ,..........);


B: 言語でLoopで回す
StreamReader sr = new StreamReader(CSV-file)
while (true)
{
string text = sr.ReadLine(); if (text == null) break;
項目移送()
Insert文実行()
}
sr.Close();





② なければ挿入式で 47行の都道府県表を作る


結果: Debugモード Releaseモード
①
A: 5秒 5秒
B: 91秒 89秒

改めて、Bulkモードの早さに驚いてます。約18倍の差。
言語で回せば 91秒/118822件= 0.76 mSecなのでそこそこの速度。
Bulkだと 5秒/118822件= 0.042mSec...これは早い。　挿入更新をバッチ化する価値は高そう。(トランザクションの関係で別も問題は発生しますが)
DebugモードとReleaseモードの差はないようです。


②-A
発端となったソースロジックでなく、テスト用に書き換えました。
StreamReader sr = new StreamReader(CSV-file)
while (true)
{
string text = sr.ReadLine(); if (text == null) break;
try
{
Insert文実行()
}
catch{} ;/重複例外握りつぶし
}
sr.Close();

Debugモード Releaseモード
5492秒 395秒

以前と同様に高コストでしたが、 Relaseモードはまだましですね。Debugモードでの例外扱いが、如何に高く付くかが判りました。

②-B Select文で自前制御
StreamReader sr = new StreamReader(CSV-file)
while (true)
{
string text = sr.ReadLine(); if (text == null) break;
try
{
int rc=(select Count(*) where ユニーク条件)
if(rc==0)
{
insert文実行()
}
}
}
sr.Close();

Debugモード Releaseモード
77秒 70秒

なぜか、DebugモードとReleaseモードに差がでました。
②-D のストアード利用より、低コストの結果がでたので以外でした。



②-C 自前でチェック用Hashで制御
if (!自前で重複チェック_DICT.ContainsKey(名))
{
自前で重複チェック_DICT.Add(名, 名);
Insert文発行()
}

Debugモード Releaseモード
2秒 2秒



②-D ストアードでノーマル処理:(挿入のみで更新はしないので Select文で判断)
StreamReader sr = new StreamReader(CSV-file)
while (true)
{
string text = sr.ReadLine(); if (text == null) break;
try
{
declare @cnt int;
select @cnt = count(*) from J01_都道府県表 where 都道府県コード=@cd and 都道府県名称=@名称;
if @cnt=0
begin
insert into J01_都道府県表(都道府県コード,都道府県名称) values (@cd,@名称)
end
}
}
sr.Close();

Debugモード Releaseモード
131秒 129秒

②-E ストアードで例外期待処理:
StreamReader sr = new StreamReader(CSV-file)
while (true)
{
string text = sr.ReadLine(); if (text == null) break;
try
{
BEGIN TRY
insert into J01_都道府県表(都道府県コード,都道府県名称) values (@cd,@名称)
END TRY
BEGIN CATCH
NOP
End CATCH
}
}
sr.Close();

Debugモード Releaseモード
175秒 172秒

ストアードの例外コストは低そうです。


こうやって見ると、データの特性によって、手法の在り方が変わるので、教科書的正解って見つからないのかも知れませんね。
RDBに任すのが正解とは限りませんね。ロジックで最速化を図った上で、DB操作するのが良いようです。
可読性が悪くなるという意見も聞こえて来そうですが。

Bulk merge 報告

前々回のエントリーで宿題状態になっていた Bulk Mergeのコストの件です。
結論から書くと、「想定したテストケースでは、Bulk Mergeを適用できない」でした。

Bulk Mergeの書式は、

MERGE INTO 都道府県 A USING OPENROWSET( BULK 'd:\wk\都道府県.csv'
,FORMATFILE = 'd:\wk\都道府県.fmt' ) B
ON A.code = B.code
WHEN MATCHED THEN UPDATE SET A.name = B.name
WHEN NOT MATCHED THEN INSERT VALUES ( B.code , B.name);

です。直感的に理解できます。
(*) create table 都道府県
( code char(2) primary key,
name varchar(10)
)
とします。

CSV Fileの書式をFORMATFILEで指定してあげる必要があります。
当初、この書式を手作業で作成するものだと思っていて、手間取ったのですが、よくよく読むと、bcp機能でテーブルから自動作成してくれるではありませんか!!

bcp __検証.dbo.都道府県 format nul -T -c -t "," -f d:\wk\都道府県.fmt

これで、Bulk Mergeの準備は整いました。いざテスト。GO。

一意キーエラーで落ちる!!
なんで、落ちるの?、重複すれば置換してくれるのではないの?。

最小データでテストしてみました。

　　11,東京
　　22,大阪
問題なくOK.

　　11,東京
　　22,大阪
　　11,福岡
重複キー違反で落ちる....なんで???

bulk Mergeの元データ(CSV)内に重複キーのデータがあるときは、重複エラーを起こすようです。
なので、「郵便番号CSVから都道府県表を作る」というシナリオが成立しませんでした。
便利な構文でも制限はあるものですね。久々にハマりました。

視点を変えて、純粋に Bulk mergeのコストを計ろうとしたのでが、郵便番号CSV_Fileは 癖の強いデータでして、郵便番号がユニークじゃないのです。
地域名が長すぎる行は、複数行に割って格納されているので、このような構造になっています。
まずは、Bulk Mergeで使える CSVに整形するところからやって、後日エントリーします。

売捌所

郵便切手・印紙・売捌所「xxx商店」という店を見かけました。ビジネス街の端っこですが、ほっとした感じがしました。
字面にレトロな響きがあります。店の様子からは切手や葉書の類の販売専門の個人商店のようです。
一昔前は、「大型スーパーが小売店を潰す」というので反対運動が有りました。でも結局は、寂れた商店街が増えてます。
コンビニ効果が大きいのか、経営改善なのか、売り場の大きな酒屋さんは、コンビニに転業する所もあります。
ファストフード店に転業してる小さ目の店もありました。
個人宅レベルの「なんでも屋」「よろず屋」さんを見かけなくなりました。
大資本系列の店が増えると、個人では歯が立たないというのが、現実なんでしょうか。
街角の「たばこ屋」さんが潰れないのが、妙に疑問に思うのです。

駄菓子屋さんや、小さな化粧品屋/薬局など、商売が成立するのか疑問に思える店が、以前はあちこちにありました。
そんな時代が「安定して良い時代だったなぁ」と回顧に浸るのでありました。
深刻な不況で開発仕事自体が減っている昨今ですが、売捌所のような店が残っていて欲しいなぁ。

ストアードでも例外期待は駄目

前回、例外を期待したコードのコスト高を書きました。
「ストアードにすぺき」とのコメントをいただきました。
ストアードでかいても、例外を期待したコードを書いてしまうと同じですね。
テストしてみました。今回も前回と同様、郵便番号.CSV (約12万行)から 都道府県表(47行)を作るものです。

①例外を期待した場合( してはいけない)

Create PROCEDURE [dbo].[#県名登録_例外] @cd varchar(2), @名称 varchar(10)
AS
BEGIN TRY
insert into J01_都道府県表(都道府県コード,都道府県名称) values (@cd,@名称)
END TRY
BEGIN CATCH
update J01_都道府県表 set 都道府県コード=@cd,都道府県名称=@名称
where 都道府県コード=@cd and 都道府県名称=@名称;
End CATCH

結果:①117 秒


②select文で判断
Create PROCEDURE [dbo].[#県名登録_非例外] @cd varchar(2), @名称 varchar(10)
AS
declare @cnt int;
select @cnt = count(*) from J01_都道府県表 where 都道府県コード=@cd and 都道府県名称=@名称;
if @cnt=0
begin
insert into J01_都道府県表(都道府県コード,都道府県名称) values (@cd,@名称)
end
else
begin
update J01_都道府県表 set 都道府県コード=@cd,都道府県名称=@名称
where 都道府県コード=@cd and 都道府県名称=@名称;
end

結果:②:29秒

③update文の結果で判断
Create PROCEDURE [dbo].[#県名登録_非例外_a] @cd varchar(2), @名称 varchar(10)
AS
declare @cnt int;
update J01_都道府県表 set 都道府県コード=@cd,都道府県名称=@名称 where 都道府県コード=@cd and 都道府県名称=@名称;
set @cnt=@@ROWCOUNT;
if @cnt=0
begin
insert into J01_都道府県表(都道府県コード,都道府県名称) values (@cd,@名称)
end
結果③27秒

まとめると
①117秒
② 29秒
③ 27秒

.net言語(C#/VB)での例外処理した場合の比率は 36:4406で、 122倍のコスト高でしたが、
T-SQLでの比率は 29:117 で 4.03倍なので、言語に比べたら低い結果となりました。
それでも4倍高くつくので、例外を期待するのはやめたほうがよいでしょう。

select文をなくすことで、2秒の差がつきました。削減効果が小さいとはいえ、処理が減るので良いですね。

知恵を絞れば、もっと早くする工夫があるのでしょうね、既存のソースを引用するときは、チェックが必要です。

例外に依存するロジックは駄目ですよ

あるシステムの処理が遅いというので、追跡してみました。
元になるデータを順次読み取り、対応するデータが無ければ追加、有れば、更新という単純なものです。
最近のSQL Serverにも Oracle並の Merge文が可能になったので、便利になりました。このシステムでは、自力で処理していました。
遅い原因の一つが次のようなものでした。
while(!eof(元データ))
{
　　try
{
sql実行(update TABLE set xxx=@xxx , yyy=@yyy where ユニーク条件)
}
catch()
{
sql実行(insert into TABLE (xxx,yyy) values (@xxx,@yyy) )
}
}

業務要件の動作はしますが、駄目でしょう。
(*)これでもソースレビューは合格したらしいので、レビュワーな何をみているのでしょうね。

int cnt = sql実行(Select count(*) from TABLE where ユニーク条件)

if(cnt==0) sql実行( insert into TABLE (xxx,yyy) values (@xxx,@yyy))
else sql実行(update TABLE set xxx=@xxx , yyy=@yyy where ユニーク条件)

とすべきでしょう。(排他処理は省いてます)

駄目だと決めつけてますが、「行儀が悪い」というだけでは、根拠が薄いので、コスト確認してみました。
(例によって)郵便番号CSVデータを用いて、郵便番号CSVから都道府県表を作ります。

元になる郵便番号CSV
自治体コード5桁 都道府県名　市区名
01101,"北海道","札幌市中央区"
……………………
47382,"沖縄県","八重山郡与那国町"

このCSVデータは12万行あります。これを順次読み取り

都道府県表
コード 都道府県名
01 北海道
……………………
27 大阪府
……………………
47 沖縄県

の47行を作ります。


①事前に存在Checkした処理
　while(true)
{
string text = sr.ReadLine(); if (text == null) break;
csv分解();

int cnt = sql実行(Select count(*) from TABLE where ユニーク条件)
if(cnt==0) sql実行( insert into TABLE (xxx,yyy) values (@xxx,@yyy))
else sql実行(update TABLE set xxx=@xxx , yyy=@yyy where ユニーク条件)
}
②例外を利用した処理
　while(true)
{
string text = sr.ReadLine(); if (text == null) break;
csv分解();
try
{
sql実行(update TABLE set xxx=@xxx , yyy=@yyy where ユニーク条件)
}
catch()
{
sql実行(insert into TABLE (xxx,yyy) values (@xxx,@yyy) )
}
}

結果は
① 36秒
②4406秒
でした。100倍以上の開きがありました。例外が高コストな処理なのがよく判ります。

CSVデータは、[Provider=Microsoft.Jet.OLEDB.4.0;Data Source=xxx] で読み込めば ADO.NETとして処理できます。
そこで　[Provider=Microsoft.Jet.OLEDB.4.0;Data Source=xxx] で接続し、
DataTable dt = (SQL実行)"select distinct left( right(str([F1] + 1000000),5),2) , F4 from KEN_ALL.CSV ";
foreach(DataRow dr in dt.Rows)
{
(SQL実行) ( insert into 都道府県表 (code ,名称) values (@code,@名称))
}
で実行しました。③
結果は
③3秒
でした。殆どがDistinct文の処理時間のようです。必要なデータを抽出時に絞ることが重要ですね。(Linqに通じる思想かな)

(*) CSV fileは DataTableに読み込めば、処理が単純になってスッキリ扱えるのでお気に入りなんですが、あまり知られてないのですよねぇ。

都道府県表を作るような処理の場合、重複チェックをDBに依存するのでなく自前で判定すればどうかも、試行しました。④

private List 自前で重複チェック_List = new List();
　while(true)
{
string text = sr.ReadLine(); if (text == null) break;
csv分解();

if (!自前で重複チェック_List.Contains(名))
{
自前で重複チェック_List.Add(名);
sql文実行( insert into TABLE( xxx,yyy) values(@xxx,@yyy))
}

結果は
④1秒 (実値0.92秒)
でした。
まとめると(都道府県表をつくるという視点で)
① 36秒
②4406秒
③ 3秒
④ 1秒
最大格差は 4400倍!!。自分もビックリ。「事務データRDBで処理するのがベスト」との声もありますが、このケースのように、事前に対象データの絞り込みは言語で行うほうが良いケースもあります。
実装手段は複数あることが多いので、コスト比較して決定する必要があります。
商売の購入時に合見積もりを取るのと似てますね。

携帯サイトアプリの画面遷移

携帯サイトはJavascriptもAJAXもCookieも使えません。
画面遷移に使えるコントロールは<&a href=''/> か の二種類程度しかありません。
{更新][削除}[戻る]など複数の分岐をボタンで行うとき、複数のsubmitボタンを配置することになります。
submitキーの反応は、pagePostBackとして自画面で受けます。そのとき、画面情報は Page.Request[] で取得できます。
幸せなことに、submitボタンが複数個あっても、押されたボタンのみが送られてきます。
(*)仕様的にそうするしかなったのでしょうが、画面情報を取得するという面では、Submitコントロールは別扱いなんでしょうね。
押されたsubmitキーの判別は、Page.Request[]を順次スキャンして、コントロール.Nameを調べるのが正攻法でしょう。
　画面仕様によっては、データの量に応じてn個のsubmitキーを配置することもあります。
その際は、レコードIDをコントロール名に含めるなど、小技をつかって小細工することになります。
うーん。エレガントでないですね。なんかスマートな方法がないものでしょうか。

トイレットペーパー持ち出し禁止?

最近、雑居ビルのトイレで、このような張り紙を見かけます。こないだは、
「 トイレットペーパーは持ち出さないでください。あなたの行為は誰かが見ています。後々後悔しないためにも。」
のような、訓示めいた張り紙もありました。
見かける頻度が高くなっているのは、持ち帰る人が増えたわけか。節約の為だとしたら、セコすぎますね。
以前は(電車の)駅トイレは紙は有料でしたが、最近は標準で設置しています。結構な費用が必要だと聞きます。
こちらのほうが、持ち帰る被害が、多そうですが、どうなんでしょうね。
　持ち出す人は、ほかに使用目的があるのでしょうか。
トイレにゴミ袋を放置して、ゴミ処理する人もいるとか。
気が滅入る時代なんだなぁ。

３穴パンチ

(今は改善されているかもしれませんが)
IBM関係の書類は3つの穴が空いている書類が多かったです。
日本以外の会社では、3穴バインダーが多いからだと聞きました。でも、此処は日本です。
(参考) http://www2.ocn.ne.jp/~hasamaya/jimuyouhin/panch/4panch.htm
一般の文具屋さんには、3穴バインダーは置いてません。パイプ式も殆どが二穴です。
西洋で主流とされる3穴式が日本で普及しなかった理由は判りません。日本での主流は二穴です。
その文化背景を考えると、外資系企業でも、配布資料は二穴式にして欲しいです。
3穴パンチも需要が少ないため、結構高価なものになってます。

紙のサイズも、欧米ではA3/A4/A5が主流だそうです。B3/B4/B5は日本ローカル仕様のようです。
明治期は舶来崇拝だと言われますが、日本規格を貫いて独自色を出した部分もあるようですね。
それは、良いことだと思います。文化といえますね。「郷にいれば郷に従う」でしょう。外資系企業が母国文化を持ち込んで、不毛な摩擦が生じると、双方にとってマイナスですね。
文房具一つで、不満を感じるので、感情は難しいものです。

坂の上の雲

大河ドラマが11月で最終回になったので、変だなぁと思っていたら、足かけ三年に渡るドラマが始まるとか。
1年を通して観続けるのは、辛いです。ビデオにとっておいても、観ないままお蔵入りすることも多々あります。
筋書きの展開が早いときは、間が飛ぶとストーリーがワケワカになったりします。
三ヶ月単位のドラマが主流になっている昨今で、3年スケールのドラマで勝負するとは、さすがNHKだなぁ。と思ったしだい。
　司馬遼太郎史観の是非は、ともかく、ドラマとして楽しめそうでした。でも2部、3部が1年後というのは。
そのころは、1部の内容は忘却しているだろうな。スパンが長すぎる希ガス。

営業日カレンダー

窓口業務システムには営業日カレンダーを設定することがあります。
定休日が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ヶ月延期になった高校もありました。
　早く沈静化することを望みます。

SQL Serverの高精度時刻

SQL Server2008 から日時の型にDatetime2(n) が加わりました。高精度版です。
併せて、getDate()の高精度版はSYSDATETIME()になります。
100ナノ秒単位の値が格納されます。DBの更新処理の所用時間より小さい単位なので、期待して試行しました。
ところが、従来通り、mSec単位しか設定できない。資料を手繰っていくと、精度はOSに依存すると書いてあります。
Vist,Win7のクライアント系はどうも、低精度のようです。Winodows 2008 Server だと、しっかり100ナノ秒単位まで格納されてました。
stopwatchは高精度で動作するので、不可能ではないのでしょうが、こんな所にも、差別化を図っているのですね。

RDBのデータ型

所用があって、.net上で走るRDBのデータ型をピックアップしました。
SQL Server 2008, DB2.9.5,MDB(Oledb4.0),Oracle10g,MySQL5.1,PostgreSQL8.4,SQLite3,FireBird2.1
のData型の比較表を作成しました。
他に、ADABAS, BerkeleyDBが .net上で走行可能なようですが、試行版のADABASが見つかりませんでした。
BerkeleyDBはミドルウェアーが使用するモジュールのリンクが上手く構築できず、放棄しました。orz。

最近のインストーラは親切なので、殆どのRDBが悩むことなく動作させることができます。
各RDBの思想が感じられて面白かったです。DB2とSQLServerはローカルにぶら下がっているRDBを探してくれるので助かります。
Oracleは接続子等を理解しないと駄目なので、プロ志向が高い。他は、理解しなくても動作してくれます。どちらがいいかは意見が分かれそうですが、私は、動作させてから理解するほうが良いと思います。
デフォルトのUser名とPassword名は、判りにくいDBもあり、単純な箇所で躓きます。

PostgreSQLには 、Point,Box,Circle等の型があり、他と差別化が顕著でした。
こうやってリストにすると、シノニムって多そうですね。
SQL Serverの{TimeStamp}はDataTable単位の永久連番で排他用なんですが、他のRDBは日付項目のようです。
これは、誤解を生みやすいと思っていますが、RowVersion型のシノニムで廃止予定だとか。
SQL Server2008にはVarDecimal型があります。(見落としてました。)

先
抜粋

CSVとTSV

CSV:Comma separated value


TSV:tab separated value

です。したがって、「タブ区切りのCSV File」というのは用語として矛盾しています。

しかし、現場では普通に交わされています。

ExcelやAccessのインポート･エキスポートの資料でも、 CSV出力の項目でカンマかタブの指定があるので、CSVの配下にタブとコンマがあると認識されているのでしょうね。

このテーマでググってみると、結構ヒットします。

http://kzworks.at.webry.info/200808/article_24.html

http://www.google.com/search?q=%E3%82%BF%E3%83%96%E5%8C%BA%E5%88%87%E3%82%8A%E3%81%AECSV+&rls=com.microsoft:ja:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7ADRA_ja

逆に、「TSV-fileで作成してね」と言っても通じないのが現実なんでしょうね。

IEのMailto:

クライアントのMailerを呼び出して、メール送信を連動させるのに便利な句です。

クライアントの好みでメーラーは様々です。FirefoxなどのBrowserは任意のメーラーとMailToを関係付けることが可能です。ところが、IEは Outlook系のメーラしか関係付けできないようなのです。

(*)私が知らないだけだったらごめんなさい。

outlook系は何かと評価が分かれるので使ってないのですが、IEを使っていて、Mailtoに関連する項目をクリックすると、Outlook系の初期設定を要求する画面が起動します。

　なんか融通が利かない仕様の感じがして、IE離れをして

他のブラウザーも頑張っていますが、大半はIEのようなので、それだけメーラーはOutLook系が多いということなのでしょうか。

携帯サイトアプリのリンク

携帯サイトアプリで画面遷移は、<a href="xxx">で行います。


HyperLinkや　LinkButtonは使えません。(Full BrowserはOK?)

「戻る」や「次へ」の画面遷移をボタンでなくリンクでしたい仕様もあります。

サーバープログラム(.net語)がクリックされたことを認知できません。

HyperLinkやLinkButtonのように、イベント駆動にできません。これは、辛かったりします。



複数の画面から呼び出される共通的な画面は多々あります。



例: 3画面からなるアプリがあるとします。

商品紹介の画面(A)は、注文画面(B)から呼ばれるし、カタログ画面(C)からも呼ばれます。

・(B)から呼ばれた(A)の戻るリンクは(B)に戻る

・(C)から呼ばれた(A)の戻るリンクは(C)に戻る

これらの動作は、イベント処理で分岐させると楽なのですが、a href=xxx　での画面遷移になるので、サーバー側処理はできません。

href="xxx" の部分がハードコーディングになるので、戻り先が固定されることになる。これは嬉しくない。

(B)を呼び元ごとに複数枚作成するのは間が抜けています。

(B)を吐き出す前に、href=xxx の部分を動的に書き換えて、吐き出すようすれば、対処できます。



Webアプリと同様だと認識していたら、間違いでした。いろんな所で躓いて、工数が読めなくなりました。

パスワードの厳格さ

パスワードの設定の基準が OSやアプリケーションによってバラバラです。


アプリは制作者が異なるので、設定基準が異なるのは不可避なのですが、 MSのOSでも異なっているような。



Client系のOS( XP,Vista,Win7)だと IDとPasswordの関係は問われないようです。

　ID="ABCDE" で PassWord が "ABCDE1" であっても OKです。

Windows2008 だと、PassWordに IDも文言が入っていると蹴られます。上記の例だと "ABCDE" がともに存在する。

その上、大文字小文字と数字が必須になっいます。　セキュリティ強化の面ではよいのですが、クライアントとサーバーでPassword基準が異なると、既に運用されているクライアントPCをWindows2008の下に紐付けようとすると、Windows認証がうまくないです。都度 ID/Paaswordの問い合わせ画面が開く事になったりします。ActiveDirectryを導入しても解決できる問題ではなさそうです。

Windows2008のユーザー設定の時にPassword設定し直して、端末に反映し直せば良いのですが、

同じ NT系のOSなのに基準が違うのは、なんかスッキリしません。

　「三ヶ月に一度パスワードを変えろとか、異なる接続先毎に違うパスワードにせよ」という職場もあるので、それに比べれば緩いかもしませんが、一人でいくつもパスワードを覚えられません。せめて、 IDとPasswordに同じ綴りがあってもOKとしてほしいものです。 <-- この感覚の甘さが、蟻の一穴になるのかも知れませんが。

新幹線のゴミ集め周回

いつの頃か、新幹線車内で、ワゴンサービスの後に、ゴミ回収員がゴミ袋を抱えて回るようになりました。


至れり尽くせりなんですが、爺衆から見れば過保護に映ります。「自分が出したゴミは自分がゴミ箱に捨てる」のがマナーだと思うのです。

自分で出すのを能動的行動とするならば、座っていて、ゴミ袋が回ってくるのは受動的行動(?)なのかな。

　と考えていたら、昔は、紙くず屋さんが回って来てたなぁ。ということは、受動的行動とマナーは別次元のものなのね。

マナーの定義に絶対的基準は無く、時代によって左右されるということで、世代論争に過ぎない訳ね。

　至れり尽くせりの生活は、人を怠慢にするのは事実ですが、サービス業がそうするのは当然の気もします。

社会が至れり尽くせりになり、受動的人間が増えているように映るのも爺衆だからか。

うーん。結論が出せない。　優柔不断な私。

携帯向けアプリは、通常のWebアプリで

「携帯向けアプリはMobile.Controlで作りましょう」的なガイドを目にします。それを鵜呑みにして、VS2008環境下でMobile.Controlを使えるようにトライして挫折しました。
VS2008には　モバイルプロジェクトのテンプレートがありません。
モバイルフォームを使うために、モバイル用テンプレートを登録してあげる必要があります。
参考: http://techbank.jp/Community/blogs/mymio/archive/2009/09/07/3434.aspx
それでも、ToolBoxのモバイルコントロールは有効にならない。
IDEのデザインモードが使えないのは致命的な感じ。

普通のWebアプリで作成しても、不具合がないので、拘る必要があるのか疑問に感じ、BBSに聞いてみました。
「特に必要ない」との回答を得て一安心なのですが、モバイルコントロールの位置づけがハッキリしませんね。
うーん。モバイルControlの出番ってどのケースなのだろう。

携帯端末のシミレーターは、DoCoMo/ Softbankは生きているのですが、AU のは配信停止中のようです。
P1エミレータという有料エミレータもありますが、個別の実機に比べると若干動作が異なるようです。
携帯向けアプリは外観調整(レンダリングの結果)で時間を食うものだと実感した次第。最終段階に多くの時間を要するので、非携帯アプリと比べて、開発時間の配分は難しいですね。
フルブラウザー搭載機が増えてますし、メモリーも多くなっているので、アプリの対象とする機種の線引きが難しいです。
5年前の機種(2004年以前）は未対応としても良い気が少しします。
絵文字入力ソフト「i絵文字」が Windows7 で動作してくれないのは、私ローカル現象なのだろうか。

本宅の具合が芳しくないので、こちらにミラーサイドを設置します。
本宅
こちらも宜しくお願いいたします。

(*)Google Bloggerの頁には「本人に連絡する」等の本人宛のメール欄設定はできないのでしょうかね。
他のblogにもついていない頁があるので、本宅の機能なのかなぁ。

祈願{サーバー回復} !!