トレイなしの食材販売

少し古い記事でず。http://www.ryutsuu.biz/commodity/b091716.html
西友が、肉などの小売の単位を、トレイパックでの包装をやめて、真空パックに切り替えたそうです。
後追い報道(ラジオ放送)によると、売上が倍増したらしい。　

・ゴミとなるトレイがない
・消費期限が伸びた
・価格が安くなった

良いことずくめの印象を受けるのですが、なんか腑に落ちない。

小規模小売店での販売は、石油系のトレイは使わなかった。新聞紙に包んだり、ラップで包んで販売していた。


大型スーパーが登場して、小分けしたパッケージを店頭に並べる必要から、トレイ梱包の商品が登場した。
上記の記事を逆読みすると、トレイ梱包する工程のために、消費期限が５日縮まり、価格が４０%高くついていることになる。
「以前のスーパーは安く販売する」という姿勢があったのだが、逆に割高の商品を売っていてたことにならないのか。

トレイ梱包することで、家庭に不必要なゴミを持ち帰らせて、家庭ごみ量産の一翼を握っていたことにならないか。
「レジ袋の節約」はよいことに聞こえますが、それの数倍のトレイを使用しているので、エコの定義じたいが納得できない。


真空パックで、消費期限が確保できるのは喜ばしいてすが、「トレイの使用量を年間約13 トン削減した」と言われてても、「いままで、それだけのゴミを家庭に押し付けていたの?」という印象しか残らない。


一時、百貨店の過剰包装が問題になったが、承知の上で購入している面もあります。
日常のスーパーでの買い物から生じる梱包材のゴミのほうは、否応なしに押し付けられるし、ゴミの分別に手間がかかります。


此の頃はスーパーの出口で、トレイ専用のゴミ箱を設置しています。精算後の顧客は、そこで、商品を解体して、持ち帰る姿を見かけます。

商品陳列だけの目的のトレイはなくしたらスッキリします。でも、少量ずつラップするのが難しい商品だと、量り売りすることになります。
量り売りにすると、店員の手間がかかって経費増になるのかな。でもトレイ梱包コストと比べると、差は小さいと思うのだが。

ブランド名は会社と共に

三洋と松下は創業者が、義理の兄弟です。
三洋は松下から独立して設立されました。言わば兄弟会社です。
それが０９年末に松下の子会社になりました。これも時代ですね。
その時のニュースでは、「SANYO」ブランドは残すとアナウンスされていた記憶があります。
それが一転して「SANYO」ブランドを無くすというニュースが流れました。


NECが ATマシンを出すとき、「(NEC)PC98は継続して製造します。」


ソニーがVHS製品を出すときは、「βマックスの製造は続けます。供給が止まることはありません」と言ってました。


　企業の言うことは「リップサービス」が多いなぁ。思うのです。
でも、会社が存続しているから、まだ救いです。

コニカミノルタ、サンスイ、ナカミチ......その業界で不動の地位を築いたのに、消えてしまったブランドも多々あります。
該当商品の愛好家にとって残念です。


Compaqは HPと一体になりましたが、ブランド名は残っているといいますね。


ORACLがMySQLを手中にしたとき「MySQLは残す」といってますが、数年後はどうなってるやら


サンマイクロシステムズがORACL傘下なってから、どうもJAVA周辺に元気さ感じられない。


MSに吸収されてからVisioの元気がない


　「ブランド名」は一企業のものだけでなく、ユーザーと共有してこそ価値がでると思ってます。
　会社の仕事はは利益追求だけでなく、社会還元も仕事だとおもうのですが.........「ブランド名」維持がこれに該当するかどうか判りませんが。

万能試験紙

「子供が夏休みの自由研究に使う」と言うので、万能試験紙を買ってくるように指示されました。
それが何者なのか、調べなかった私の落ち度はあるのですが。.....
「東急ハンズに売ってそう」という憶測だけで、出向いたのですが、店員に「万能試験紙ってなんですか」と逆質問に逢いました。
どうやらPH測定らしい。扱ってないとのこと。薬局に置いているのでは、ということで、薬局を数件回るが、どこも、「万能試験紙って何?}状態。
出かける前に調べときゃよかった。


http://www.kagakukan.sendai-c.ed.jp/yakuhin/yak/134.htm


上等なリトマス試験紙ではありませんか。なんでも試験できるような大仰な名前。商品名なんだろうか。
中学生が実験に使用するほど有名なものなんですね。私の時代にはなかったような。
　でも、常備している店がないのは、どういうこと?
市中の店に置いてなくて、仕方なく通販で買ったのですか、カードを用いないで、現金決済で1000円程度の買い物をすると、高くつくではありませんか。

(*)IT屋が言うのは御法度ですが、私はネットでのカード決済を信じていない。通販は現金引換え等にしている。
送料や手数料で 980円の買い物が2000円近くかかってしまう。

これって健全な状態なんだろうか。
そういうば、ビーカーやフラスコなど実験道具や材料を売っている店って、見かけなくなりましたね。どこで調達しているのだろう。

Linq2Entities と Linq2SQL

ADO.AdapterやADO.Updateが使う、自動生成されるSQLの冗長さもあって、OR Mapppigが嫌で、DataSet型を毛嫌いしていました。
しこしこSQL文を書いていました。それの延長線で、Linq2SQLも使いませんでした。
で、VS2010をいじっていく過程で、Linq2EntityとLinq2SQLを触ってみました。
「使えるじゃん」という印象です。Linq2SQL.Log で吐き出すSQLをみる限り、冗長性は改善されています。
joinなどが、言語側で記述できるのがよいですね。
でも、安易に書くと冗長なSQLを吐き出すので、結果のSQLの検証は必須なので、「SQLを知らなくても使える」とミスリードするのは疑問です。
逆に、より深い知識を要求されそうです。実行計画を見る場面も増えそうです。

Linq2Entitiesの棲み分けが見えません。簡単な動作テストしかしてませんが、Linq2SQLと Linq2Entityで差が見えない。
逆に、不便な点が目につきます。
・MsSQLに限定される。
・Linq2Entityを別プロジェクトで構築したとき、メイン側のapp.configに登録しないと、接続できない。
・同じプロジェクトで同じDBに対して、 Linq2SQLとLinq2Entity を同居させたとき、名称が重複してコンパイルできない現象がある。
等々。

当分は、Linq2SQLで十分かな。

都道府県コード

全国地方公共団体コードの大区分で
01:北海道 02:青森県～47:沖縄県まで規定されていますが、DB設計時に、このコードの名称に疑問を覚える。
県コードとか、地域コートとか称するならば、理解できるが、行政区分上、同格である地域単位の名称を「都/道/府/県」と4つアサインしいてるのが、不思議。
　明治初期、重要な地域を東京府、京都府、大阪府と「府」にしたのは、他の「県」とは別格扱いにしたかったからです。「道」の北海道は、幾つかの県を設置したものの開発が進まず、
一つにしたかったが、並みの県より大きいので「道」にした経緯があるようです。
でも、戦後は、都道府県は同格になりました。同格なので、すべて「県」にしても差障りはないとおもいます。名残で「都道府県」があるのでしょう。
でも、「都道府県コード」でなく、「行政コート」とか、「知事域コード」とかのスッキリした名称にして欲しい。
「都道府県コード」では、要素名が項目名を表していて、モッチャりしている感じがします。
{Ref]とか「Area」とか「州」とかのコード名称にして欲しい所です。
DB項目名が「都道府県コード」だと、 rec["都道府県コード"]="東京" となりますが、
DB項目名も「県コード」とするとrec["県コード"]="東京" となり、違和感が残ります。
同様に、、「市町村コード」も、スッキリした代名詞が欲しい。
　項目名として「都道府県コード」ほ「モッチャり」と感じるのは私だけかなぁ。

Framework4の控えめな型

新機能の影に隠れた感のありますが、新しい型に「BigInteger」があります。
有効桁数無限大(?)の整数型です。(例外はOverflowでなく OutofMemoryだそうです)
　使い道が思いつかないのですが、必要があるから実装されたと思います。
　高桁数のπの算出は手順が確立していますが、BitIntegerで計算すると
速度的にどうなるのでしようか。

ここに(http://msdn.microsoft.com/ja-jp/library/system.numerics.biginteger.aspx)
使用例がありますが、
ソースのなかに、
BigInteger number = BigInteger.Pow(Int64.MaxValue, 2);
BigInteger number = Int64.MaxValue ^ 5;
の二種類の形式がありました。
この行で XORを使う意図が見えません。VBでのべき乗が "^"なので、補正し忘れているように思います。

それはともかく、サンプルを作って測定しました。( Athron 64*2 4600+)
▼Code

BigInteger number1 = Int64.MaxValue;
BigInteger number2 = (BigInteger)Int64.MaxValue * (BigInteger)Int64.MaxValue;
BigInteger number3 = BigInteger.Pow(Int64.MaxValue, 2);

Console.WriteLine("number1[" + number1.ToString() + "]");
Console.WriteLine("number2[" + number2.ToString() + "]");
Console.WriteLine("number3[" + number3.ToString() + "]");
▲
▽結果
number1[9223372036854775807]
number2[85070591730234615847396907784232501249]
number3[85070591730234615847396907784232501249]
△

1000000回 Loopさせて、速度差Check
{
BigInteger number = Int64.MaxValue; '★
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i <= 回数; i++){number++;}
sw.Stop();
Console.WriteLine("bigInteger 所要[" + sw.ElapsedMilliseconds.ToString() + "][" + number.ToString() + "]");
}

対象の型を　 BigInteger, BigInteger? , Long , Long? , Decimal , Decimal ? に変えて実行


bigInteger 所要[251msec][9223372036855775808]
bigInteger? 所要[278msec][9223372036855775808]
long 所要[ 4msec][-9223372036853775808]
long? 所要[ 41msec][-9223372036853775808]
decimal 所要[ 45msec][9223372036855775808]
decimal? 所要[ 84msec][9223372036855775808]

さすがに、ネイティブな Long型が速いのは、予想通りでしたが、
decimal型の5倍程度のコストなのは、予想外に早かった。
逆に、各型のNull許容型の遅さも意外でした。

BigInt型はstring型と同様に、変更不能型で変更の都度、新しいインスタンスを作成されます。
そこで、文字型で同じ回数のLoop測定してみました。

{
string a = "";
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i <= 回数; i++)
{
a = i.ToString();
}
sw.Stop();
Console.WriteLine("string 所要[" + sw.ElapsedMilliseconds.ToString() + "][" + a.ToString() + "]");
}

結果
string 所要[267][1000000]

ILの掃出しコードをみてませんが、数値結果から類推すると、 Biginteger,BigInteger?, string
共に、同じような値なので、文字列として演算しているような感じがします。

不注意発言

豪雨などで安全維持のため鉄道が遅れるのは結構なことです。スイスの列車はスピード超過らしいので時間厳守よりも安全重視して欲しいです。
でも、人身事故(飛び込みや駅校内での接触)の場合は、不満やストレスが溜まります。
朝、始業に間に合わなくなったとか、帰りの終バスに間に合わなくなったとかだと嫌になります。「死んでまで他人に迷惑掛けるな」と思うほどです。

数分程度の遅れは多々あることなので、あまり問題視されません。
　最近は、気象がおかしく連日の猛暑日の為か、「急病人がでましたので遅れました。」・「乗客の介護の為遅れました。」とかで遅れることが多くなったようです。
不調ならは通勤途中で倒れる前に、休みましょう。休める体制でないって? 急に倒れるほうが迷惑を掛けると思います。
健康上の問題なので自己の健康状態には気を付けましょう。

閑話休題。
家族が(学生)JRに乗車していたとき、急病人がでたらしく、乗っていた電車が10～20分遅れることになったらしい。
車掌は「急病人がでましたので遅れました。」とでもアナウンスすべきでしょう。ところが、車掌は
「急病人のせいて遅れます。」とアナウンスしたらしい。これはダメでしょう。
心無い一般乗客が、そのように思うのは勝手ですが、車掌等のサービス提供者側の人は、狭い範囲とはいえ、公共の場での発言なので影響があります。
そのとき居合わせた友人たちの間で。「あ! 言っちゃった。本音が出たんだよね。」などと話題になったようです。
本人が気づいたのか、お咎めがあったのかは判りませんが、その後の、車内アナウンスの量が、極端に減ったらしい。