スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
拍手コメントを見る

ハイテクウェア



ちょっと遅くなったけど、モーフィーへの誕生日プレゼントです。

このウェアは体温を一定に保つ効果があるそうで、この時期でも快適になるんだとか。

ま、胸の星だけで選んだ様なもので、ハイテクはオマケかな。
スポンサーサイト
拍手コメントを見る

ごめんなさい。二度と食べ(れ)ません。

辛くって辛ぇ~(からくってつれぇ~)

昨晩は仕事で遅くなってしまったので、家で料理は無理かな?と思い、飯田橋のバーガーキングで夕飯を買って帰りました。
飯田橋から自宅までおよそ1時間。間違いなく冷めますが、それでも良いからワッパーが食べたいと相方が。



さて、相方には希望通り「ワッパー」を買いまして、僕には「クレイジー・ワッパー」なるやつが目に付いたので購入です。
帰りの地下鉄とバスの中は、なんだか辛(から)そうな匂いが漂ってました。みなさんごめんなさい。

さて、帰宅後、そのクレイジー・ワッパーを食してみたんですが、予想外の尋常じゃない辛さ。
辛いものは平気な方だと自負していたのですが、顔面から汗噴き出しまくり。
悲鳴をあげながらもなんとか完食しましたが、しばらく口の中がしびれてしいました。

このときは、「もう、(チャレンジは)いいかなぁ」というレベルだったんです。

今朝。といっても早朝5:00頃。腹痛で目がさめました。
いや~、辛(つら)いのなんのって。こんどは下が火事ですよ。

犬の散歩やら、朝食やら、朝の行事を済ませて家を出るまで、4~5回はトイレのお世話になりました。

このときは、「ごめんなさい。二度と食べれません」という心境の変化が。

通勤中も途中下車を覚悟しながらでしたが、なんとか落ち着いた様で、ストレートに出社できました。

辛いもの自慢の方は、是非! 拍手コメントを見る

テーマ : 日記
ジャンル : 日記

スーパー普通

モバイルバンキングのサービスでケータイから履歴をみたんです。

利息がついてるじゃあーりませんか!!!
・・・っていったって、0金利が続いている昨今、全然大した金額じゃないんですけど。

で、気になったのが、摘要の文言。

「利息 スーパーフツウ」

普通預金口座だから「フツウ」はわかるけど、それに「スーパー」なんてつけられると、あたかも、

「あんた、ちょー一般人だよねぇ」

と言われている気がしてしまいますです。
いや、当たっているだけに、なんか、、、ね。
今更言っちゃう?みたいな。 拍手コメントを見る

テーマ : 日記
ジャンル : 日記

命はつよし


7月頭に撮ったジャコウアゲハのメスです。
オスは黒いけど、メスは羽の中央付近が薄い黄色なが特徴です。

幼虫は毒性のあるウマノスズクサが主食なので、卵もそこに産むことが多いみたい。

写真のメスもウマノスズクサ辺りをヒラヒラしてました。

が、その翌日あたりに雑草の伐採がありまして、この辺りの草花は一網打尽の木っ端微塵。せっかく産みつけた卵は…。

あれから一月半。

またぞろ雑草が生え始めたのですが、ツル性植物のウマノスズクサもじわりじわりフェンスに絡みつき始めました。

で、今朝の散歩では、またジャコウアゲハの幼虫がモシャモシャと葉っぱを食べているのを発見し、命って強いなぁと思った次第です。
拍手コメントを見る

今年も無事に迎える事が出来た

今日は我が家の長男坊だった愛猫シャールの命日です。
あれから5年かぁ。時の流れは早いなぁ。

今日は花火を買って帰って、家族で月見をしながら楽しもうっと。 拍手コメントを見る

テーマ : 日記
ジャンル : 日記

月の雫



なかなか美味い。「コクの時間」

今日はモーフィーの5歳の誕生日でした。

昨日は自由が丘でお祝いしたんですがケーキにかぶりついてました。今朝の散歩では多量のウンチが(笑)
拍手コメントを見る

陸のマナティ


まるでマナティ。

お尻に角があるのが特徴のスズメガの幼虫らしいです。

散歩途中で見かけました。
拍手コメントを見る

羽化!




昨晩、サナギに変化がありました。
しゃーく博士に頂いた情報のとおり、なんとなく色が濃くなっていたんです。
サナギになってから10日かな?

翌朝には羽化するかもと期待していたら、サナギから抜け出すところは見逃しましたが、羽を乾かすところは間に合いました。

ボディは2.5センチあるかないかの小さいキアゲハ。
無事に羽化してくれて嬉しいです。
拍手コメントを見る

.NET DataTable の集計速度を計測してみた

.NET の DataTable では Group By 的な事をやろうとしても、そういったメソッドは用意されていません。
実現方法としていくつか思いついたのですが、本格実装に入る前に、どの方法が一番パフォーマンスに優れているのか計測してみました。
※ちなみに汎用的な方法ではないので期待せぬよう。

例として次のようなテーブルを集計対象とします。
+--------+--------+-------+--------+
| Shop | Item | Price | Number |
+--------+--------+-------+--------+
| Odakyu | Apple | 200 | 500 |
| Odakyu | Melon | 600 | 100 |
| Odakyu | Orange | 150 | 300 |
| Seibu | Apple | 180 | 400 |
| Seibu | Orange | 160 | 600 |
| Tokyu | Melon | 700 | 50 |
| Tokyu | Orange | 170 | 200 |
+--------+--------+-------+--------+

Shop には仕入先の名称が入り、Itemには品物、Price には品物の単価、Number には仕入数。
というテーブル構造です。

これらの商品を仕入れた店では Apple の仕入件数は何件?などを「集計」したいとします。
上記の表から Apple が入っている行(レコード)を対象として、その行数(レコード数)が分かれば、Apple の仕入件数が何件あるのかが導き出せます。
+--------+--------+-------+--------+
| Shop | Item | Price | Number |
+--------+--------+-------+--------+
| Odakyu | Apple | 200 | 500 |
| Seibu | Apple | 180 | 400 |
+--------+--------+-------+--------+

結果としてはこの様に2行あるので、仕入件数は2件ということになります。

SQL の場合は、これらの集計は簡単で、次のように記述することで結果を得る事ができます。
SELECT COUNT(*) FROM MyTable WHERE Item='Apple'

各Itemで集計したい場合は、次のように記述します。
SELECT Item, COUNT(Item) FROM MyTable GROUP BY Item

結果は次のようになります。
+--------+-------+
| Item | Count |
+--------+-------+
| Apple | 2 |
| Melon | 2 |
| Orange | 3 |
+--------+-------+

この様な結果を得られるよう、DataTable 上のレコードに対して処理を行う場合はそれなりの手順を踏む必要があります。

以下に、思いついた3つの例をあげますが、得られる結果は全て同じです。
コーディング上、一番スッキリするのは次の書き方だと思います。

■ DefaultView.ToTable() を利用する方法
001://
002:// Example1
003:// DefaultView.ToTable() を利用する方法
004://
005:private DataTable example1()
006:{
007: DataTable dtChild = dtSrc.DefaultView.ToTable("dtChild", false, "Item");
008: DataTable dtParent = dtSrc.DefaultView.ToTable("dtParent", true, "Item");
009: dtParent.Columns.Add(new DataColumn("Count", typeof(int)));
010:
011: DataSet ds = new DataSet();
012: ds.Tables.Add(dtParent);
013: ds.Tables.Add(dtChild);
014:
015: DataRelation rel = new DataRelation("rel",
016: dtParent.Columns["Item"],
017: dtChild.Columns["Item"],
018: false);
019:
020: ds.Relations.Add(rel);
021:
022: dtParent.Columns["Count"].Expression = "Count(Child.Item)";
023:
024: return dtParent.DefaultView.ToTable();
025:}

これは、DeafultView.ToTable() の引数に distinct が指定できる事を利用しています。
順不同ですが、やっていることは大体次のようなことです。
007行では、dtSrc の "Item" 列だけを採用し、全レコードを dtChild に代入しています。
008行では、dtSrc の "Item" 列だけを採用し、かつ重複しないレコードが dtParent に代入されます。
dtParent と dtChild を DataSet に加え、親子関係を設定します。
dtParent に集計用の列"Count"を追加し、そこに dtChild の集計値を代入するように計算式を指定します。

以上の処理手順により dtParent には各項目とその集計数が入ります。

------

次の方法は、元テーブルのレコードを逐一参照して、集計結果を別テーブルに代入するという方法です。

■ DataTable.Select() を利用する方法
001://
002:// Example2
003:// DataTable.Select() を利用する方法
004://
005:private DataTable example2()
006:{
007: DataTable dtRet = new DataTable();
008: dtRet.Columns.Add(new DataColumn("Item", typeof(string)));
009: dtRet.Columns.Add(new DataColumn("Count", typeof(int)));
010:
011: dtRet.PrimaryKey = new DataColumn [] { dtRet.Columns["Item"] };
012:
013: foreach(DataRow drSrc in dtSrc.Rows)
014: {
015: DataRow drRet;
016: string exp = string.Format("Item='{0}'", drSrc["Item"]);
017: DataRow[] drs = dtRet.Select(exp);
018:
019: if (0 == drs.Length)
020: {
021: drRet = dtRet.NewRow();
022: drRet["Item"] = drSrc["Item"];
023: drRet["Count"] = 1;
024:
025: dtRet.Rows.Add(drRet);
026: }
027: else
028: {
029: drRet = drs[0];
030: drRet["Count"] = (int)drRet["Count"] + 1;
031: }
032: }
033:
034: return dtRet;
035:}

集計結果は、dtRet テーブルに入ります。dtRet 上の Item 列の値は重複を許可していません。そのため、019行の Select() メソッドの呼び出しでは、結果が0行か1行しか返ってきません。
dtSrc テーブルの全ての行を対象として、指定列の値に一致するものがなければ新しい行を dtRet に追加(023行~)し、一致するものあれば、既存の"Count" 値を増加させています(029行~)。

------

残る最後の方法は、Example2 とほぼ同じですが、既存レコードの検索に DataTable.Rows.Find() を利用した方法です。
集計結果のテーブル dtRet には、重複するItemが許可されていないという事ならば、Select() メソッドで複数行返ってくる可能性を考慮せずに、単一行を処理した方がスマートなのでは?と考えたのと、Select() と Rows.Find() にどれだけ差がでるのか興味がわいたので、実装してみました。

■ DataTable.Rows.Find() を利用する方法
001://
002:// Example3
003:// DataTable.Rows.Find() を利用する方法
004://
005:private DataTable example3()
006:{
007: DataTable dtRet = new DataTable();
008: dtRet.Columns.Add(new DataColumn("Item", typeof(string)));
009: dtRet.Columns.Add(new DataColumn("Count", typeof(int)));
010:
011: dtRet.PrimaryKey = new DataColumn [] { dtRet.Columns["Item"] };
012:
013: foreach(DataRow drSrc in dtSrc.Rows)
014: {
015: object [] objs = new object[] { drSrc["Item"] };
016: DataRow drRet = dtRet.Rows.Find(objs);
017:
018: if (null == drRet)
019: {
020: drRet = dtRet.NewRow();
021: drRet["Item"] = drSrc["Item"];
022: drRet["Count"] = 1;
023:
024: dtRet.Rows.Add(drRet);
025: }
026: else
027: {
028: drRet["Count"] = (int)drRet["Count"] + 1;
029: }
030: }
031:
032: return dtRet;
033:}


以上の3例を使ってのパフォーマンスの計測結果です。
           +--------------------------------+
| 対象件数 |
+-------+-------+-------+--------+
| 100 | 1000 | 10000 | 100000 |
+----------+-------+-------+-------+--------+
| Example1 | 0.062 | 0.109 | 1.546 | 35.907 |
| Example2 | 0.015 | 0.031 | 0.406 | 5.203 |
| Example3 | 0.000 | 0.015 | 0.140 | 1.703 |
+----------+-------+-------+-------+--------+
※処理に掛った時間(秒)です。
※参考:Windows XP, Intel Core2 2GHz


Example1 が極端に遅い事がわかります。10万件のレコードに対しての集計結果におよそ36秒掛っています。
データ量が多くなってくると顕著ですが、この3例では、Example3 が最も優れている結果となりました。
ちなみに、100万行ほど処理させた結果は次の通りです。
Example1 : 421.258 (7m01s)
Example2 : 52.001 (0m52s)
Example3 : 16.766 (0m17s)


Example1 コードのどこに問題があるのか細部の計測を行ってみたところ、ボトルネックとなっていたのは、008行の DefaultView.ToTable(, true, ) の重複しないレコードを抽出する部分でした。
Example1 ではこの部分がキモであるにも関わらず、上記のようなパフォーマンスの悪さからすると、残念ながら使う場所を限定せざるを得ないレベルのようです。

また、Example2 と比較すると2~3倍程度高速なのが Example3 です。
単一行しかないと分かっているならば、Select を使うよりも Rows.Find() を利用するのが良い様です。

なお、これは、VisualStudio2005 で実験しています。
拍手コメントを見る

テーマ : プログラミング
ジャンル : コンピュータ

Once Bitten, Twice Shy

Great White の "Once Bitten, Twice Shy" という曲。
このPVにすんごいカワイコちゃんが出演していたのを思い出しました。

今みると、チラチラとちょっとしか映らないんですけどね。
英語版 Wikipedia で "Great White" のページみたら、ちゃんと説明&リンクがありました。
その正体は、"Bobbie Brown" というモデルさんだったらしいです。
御歳40歳。"Once Bitten, Twice Shy (youtube)" が 1989 の曲だから、今から21年も前。。。

最近疲れやすい理由が客観的に分かってしまい、ちょっとブルー。

そんなことより、"Once Bitten, Twice Shy" はことわざだった事を知りました。

直訳すると「一度咬まれると、二度目は臆病になる。」ですが、要するに「一度失敗すると二度目から慎重になる。」ということらしいです。

日本語のことわざに例えると「羹(あつもの)に懲りて、膾(なます)を吹く。」だとか。
・・・・知らないし、そんなの・・・・

意訳すると「熱いものを食べて口の中を火傷すると、次からは冷たいものでもフーフーと息を吹きかけてしまう。」という事らしいです。

ここまで説明されると、「あー、あるある!、わかるわかる!」ってなりました。

で、それを有効活用した例がこちら
やるなぁ、って感じ。

さらに、WHAM! の "Last Christmas" にもこのフレーズが出てくるらしいです。 拍手コメントを見る

梅乗せシステム


昼飯の弁当のオニギリです。

具材をオニギリの中に忍ばせるという高等技術は、僕にとってスペースシャトルのマニピュレーターを操作するくらいの訓練を要するに違いない!

、なんて考えたりしています。

という訳で、日々のオニギリには写真の様に梅干しの実を半分にしたものを乗っけているわけです。時間もかからないし。

しかし、今回選んだ混ぜ合わせ素材は「三島のゆかり(梅入り)」

しっとり梅+カリカリ梅ってかんじでした。


こういうのを愚行と言うんでしょうね~。
拍手コメントを見る

光輪


うっすらと見えました。
キアゲハのサナギは変化なし。
拍手コメントを見る

イナズマン!



に、なる前のサナギマン。

月曜日にバルコニーの軒下にキアゲハの幼虫がよじ登って体を固定したかと思ったら翌日にはサナギになってました。

明日か明後日には成虫になるかな?

早起きしなきゃ!
拍手コメントを見る

怪談:天からの贈り物

空気の澄んだキャンプ場に昼前に到着した。
あいにく空は曇ってはいるが、都会の猛暑から逃れられたという思いで気分は開放的になっていた。

ここはキャンプ場といっても公営でも私営でもなく、施設らしきものは何もない。水回りもないからあらかじめ飲料水などは買い込んでおく必要がある。
命綱となるコンビニも、ここから4~5キロ離れた場所にあった。
川の水なんて飲めたもんじゃない。というのも、トイレすら存在しないので、基本「自然に返そう」が暗黙の了解となっている地域だったからだ。
当然、不便極まりないのだが、無になれそうな気がする場所であることには違いない。そういう点が気に入ってこの場所を選んだのだった。

仲間は既にテントを組み立て始めている。さて、俺も、、と思ったらケータイ電話が鳴り始めた。
山間に響き渡る場違いの着うた「サザエさん」は、表示をみるまでもなく、お袋からの電話だった。

テントを組み立てている連中は、こんなとこまで電波が届くんだな、とからかっている。

「もしもし・・・」
「良かった。あんた、無事?」
「無事だけど、何?」
「今しがた、あんた宛ての妙なハガキが届いてね。『今日の昼12時から。悔い改めよ』って書いてあるから。何だか気味悪くなっちゃって。」
「なんだ、それ?誰から?」

案の定、差出人は不明。ハガキは至ってシンプルな文字で書かれているらしい。
腕時計をみると、ちょうど12時を回ったところだった。

「無事ならいいんだけど、無茶しないでよ。」

味の無くなったガムを吐き捨てて、もう電話すんじゃねーよ!と啖呵を切ろうと思った矢先、「え?え?なに?なに?・・・」というお袋のパニくった声が聞こえた。
「ちょ、ちょ、ちょ、掛け直すわ」と言って、ガチャンと電話を一方的に切られてしまった。

まったく、なんなんだよ!
取りだした煙草を口にくわえて、最後の1本だった事に気が付いた。ビール飲む前に買い出しに行かなきゃな、と考えていたら、また「サザエさん」が鳴り始めた。

「ケースケ!」
「こんどは何?」
「げ、玄関先になんだかグニャっとしたものがたくさん落ちているの・・・」
「は?なに?それ?」
「なんだろ、これ、、、」

「は?」
わけのわからない事をいってやがる!と吸っていた煙草を捨てて、怒鳴ってやろうかと思ったら、

「あつっ!あちっ、アチチ!!、、、ギャー!!!」
「ど、どうした!?」
「た、た、た、煙草が、煙草が降ってくるぅぅ~」

ギョッとなって捨てた煙草に視線を移した。捨てたはずの場所には煙草はなかった。もしや!?
「オカン、最初のグニョグニョしたのって、ガムじゃないか?」

「へ?ガム?そうかもしれないけど、もう煙がすごくて・・・近づけないわよ!」
咳き込みながらも、かろうじて言葉をしぼりだしている。

そういえば、

数日前の夜、路上でガムを吐き捨てた時に黒ずくめの老婆に何か言われた。災いがどうのこうのと言っていた。
相手にはしなかったのだが、こちらを見る目に寒気を感じたのは思い出した。

まさかなとは思いつつ、ためしにツバを吐いてみた。

「ひ、ひぇぇぇぇ!!!」電話口でお袋が悲鳴を上げている。
「なんか、今度はなんか水っぽいのが降ってきた!!!」

状況が飲み込めた。どうやら俺が何かを捨てると何倍にもなって家の玄関先に現れる様だ。
自分の考えをかいつまんで説明し、そんな子に育てた覚えはないよ!と泣き叫ぶお袋に「次が大事なトコだから、腰をぬかすんじゃねぇぞ」と言い放った。

俺は、老婆の冷たい視線を思い出しながら、「つめが甘いぜ!婆さんよ!」とニヤケながらポケットに突っこんでいた千円札を取り出し、ポイッと捨てた。

「なんかヒラヒラ降ってきたけど、、、ぎゃぁぁぁ」
「驚いたか!!」
「ばかっ!燃え始めた!家が、家が・・火が移った!!」

舞い降りた千円札は煙草に引火したらしく勢いよく燃えあがり、その炎は実家に燃え移ったらしい。
電話が切れたので、急いで掛け直したが繋がらない。

電話での会話が切れたとたん、静寂が広がった。
周りをみわたすと、仲間は食料の買い出しに行ったらしく、車が見当たらなかった。
ツイている。この秘密を知られないでいる方が都合が良かった。

しばらくすると、また「サザエさん」が鳴った。

「家、燃えちゃったよ。」

落ち込むお袋に対して、俺は余裕しゃくしゃくだった。ただ、ポケットにはもう金は残っていなかった。

「俺がなんとかするから心配すんなよ。」と心配する声色とは反して笑顔が広がったのだが、突如、俺は体の異変に気が付いた。

「やべぇ、オカン。そこからすぐに離れてくれ。」
「どうしたの、これ以上何がヤバいっていうのよ。」
「俺・・・腹下したみたいだ。」


拍手コメントを見る

行き詰まり

ここ数日、仕事に進展がない。
とあるメーカーのSDKを利用して、情報を取得してるのだけれども、実装に行き詰ってしまいました。

日本のサポート(代行業者)に質問して、その方々が理解して、アメリカのメーカーに質問していただいているらしいのですが、ここしばらくはブレイクダウンを重ねるメールのやりとりが続いて、なかなか本論に到達できていない様子。

メーカーサイドがやっているフォーラムにも類似の質問を投げたのだけれども、こちらはなしのつぶて。
別の質問には素早い対応だったので、よほど下らない(初歩的な)質問の扱いなのかもしれないし、核心に迫ってしまったのかもしれない。

しかし、現在の挙動が仕様だったりなんかすると、かなり痛い。
別の手段が思いつかない。

というわけで、数日もんもんとしています。 拍手コメントを見る

カーナビ様の帰還

注意:はじめに、、長いですよ。

しめ鯖号(Impreza GDBC)からキス天号(Subaru R2) に移設したパイオニア製のカーナビ(AVIC-ZH77MD)が引っ越し2年目で無反応となったという事は以前に報告した通り。
しばらく放っておいたのだけど、無味乾燥の液晶画面をみていると虚しくなるし、音楽機能の代わりに鼻歌を奏でると「いったいぜんたい何の曲だよ!」という相方からのドツキ攻撃から逃れるためにも、修理に出そうと決めました。

パイオニアのホームページを訪れると、サービスセンターへの持ち込みは実機だけ。取り外しなどの作業は行わないとのこと。
取り外し云々を頼むとなると、ディーラーに持って行くとか、オートバックスとか、イエローハットに持って行くことになって、余計な工賃が発生してしまう。
車の電装品はまったく詳しくないけど、カーナビくらい自分で外さんとな!(ケチなだけ)ってことで作業開始。

必要なもの。

10mmのレンチ(バッテリー端子を外すため)。
マイナスドライバーと長めのプラスドライバー。
ラジオペンチ。
メモ紙、ペン。

作業中の危機への影響や感電等を防ぐためにバッテリーのマイナス端子を外す必要があります。。
バッテリーを外すと、トリップメーターがリセットされので、リセットされて困るものは予めメモしておきましょう。僕の場合は、燃費計算にしかつかっていないけど走行距離を一応メモ。

AVIC-ZH77MD は2DIN埋め込み型。R2の化粧版をマイナスドライバーで丁寧に外し、、っていっても、どこに爪があるのかわからないので、適当にやってみた。
開けて分かった事だけど、化粧版の爪はど真ん中の下にあって、そこにそっとドライバを差し込んであげれば「ペコッ」と外れるはず。

化粧版を開けると車体とカーナビを固定してるステーがでてくるので、プラスドライバで4か所のスクリューを外してあげる。
なお奥の2つは、結構遠くにあるので、長いドライバが必要になります。

固定個所が外れると、本体をズルズルっと楳図かずお氏のへび女のようにゆっくりと引っ張り出すことができます。ただし、長くないケーブルもあるので、無理に引っ張らない事。

表に出てきた背面にはなにやらゴチャゴチャと配線ケーブルが。
自由度を高めるためにも短めのケーブルから外していくのが効率がよさそうです。
ナビ裏


でもまずは、背面左下にある電源ケーブルから外します。
ケータイ電話との接続ケーブルは、左右にロック解除のボタンがついているので、押しながら引っこ抜きます。
GPSアンテナケーブルはロック機構が付いているですが、端子が小さくて僕の指では解除不可。指とラジオペンチを駆使して引っこ抜きます。

残りは、マイクケーブル、TVアンテナケーブル、AM/FM/VICS ケーブルを外します。
TVアンテナケーブルは4本もあって、端子が色分けされているわけでもなく、どれも同じに見えます。よくみるとケーブルにシリアル番号がらしきものが印刷されているので、それぞれがユニークであることを確認して、取り外しの前に端子の位置とケーブルの組合せをメモします。

カーナビの取り外しが終わったら、バッテリーのマイナス端子を元通りに装着。
エンジンがかかることを確認して、作業終了。

都筑区のパイオニアサービスセンターに持って行き、ここのところの不具合を語って、ナビが無いと不便ですね、という世間話まで。
事実、サービスセンターの地図の簡易版をプリントアウトしてしまったので、途中で迷いそうになってしまう始末。いつから地図の読めない脳になってしまったんでしょ。

それはさておき、受付でタッチパネルがずれてしまう問題や、CDの音飛びが頻繁に起こっている事なども伝えると、修理には上限金額があり\28,875以上の負担はないとのこと。
なので、不具合があればすべて修繕対象となるけれども、\28,875 を超える事はない。

とりあえず預けて帰宅したんですが、しばらくすると電話連絡があり、故障原因と見積もりを報告していただきました。対応が早い。

HDDをコントロールする基盤に問題があったため、HDDの内容を壊してしまっていた。そのためシステムが起動しなくなっていた。
HDD自体にはハードウェアトラブルはないが、内容はすべて消去されてしまう。
あと、CDのピックアップやタッチスクリーンの交換もふくめて、合わせて\28,875の上限額となるとのこと。

HDDの内容が初期化されるということは、これまで録りためた音楽が全てパーになるってことです。がぁぁぁん。
どうせ消えるならと思って、HDDももう寿命じゃないの?と突っ込んでみたけど、診断ツールではまったく問題がなかったって。頑丈なヤツめ!

ま、心機一転。こつこつと録りためればいいや。
ただ、「嵐」だらけになりそうなのは正直しんどいけど。

僕の見ている風景 【初回仕様盤】僕の見ている風景 【初回仕様盤】
(2010/08/04)


商品詳細を見る


木曜日に修理にだして、火曜日には修理完了の連絡が。やっぱり対応が早い。
木曜日も、火曜日も、所用で有給をとっていたので、なんちゅータイミングの良さ!?って感じで、夕方受け取りに行き、帰宅後装着。

プチプチのパッケージを開けると、綺麗な綺麗なタッチスクリーンが・・・・と思ったらサービスセンターの人がテストしたんでしょうね、指紋が数か所に。
ちょっとグレーな気分になりながらも、取り外しの手順とは逆回しで作業を開始。

取り付けは10分程度で終わり、異音もなく無事に起動して、GPSも正しく受信してるし、ラジオもテレビ(アナログ!)も問題なく受信してます。
CD持ってくりゃよかったなぁ、と思いつつ、それはまた次回のお楽しみって事にしました。

あー、長かった。
拍手コメントを見る

テーマ : 整備
ジャンル : 車・バイク

15年お疲れ様

これが


こうなりました。



マンションも築15年で今年は大規模修繕工事が入ります。
古いエアコンは最初からついていたもので、当時流行っていたガスエアコン!!

新たしいエアコンはパナソニック機種。

新品はよく効くし、快適だし、運転中の累計電気代の目安はでるし、でおもしろい!!

けど、次回の引き落としが怖い。

そうそう、ナビも今日修理完了とのこと。それについてはまた後日。 拍手コメントを見る

主役は…


手違いで来なかった。

けど、その損失を補うには十分なほどベルギービールと会話は美味かったです。@横浜
拍手コメントを見る
ブログ内検索
プロフィール

雷ぶ

Author:雷ぶ

最近の記事
最近のコメント
最近のトラックバック
カテゴリー
月間アーカイブ
ブロとも申請フォーム

この人とブロともになる

RSSフィード
リンク

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。