うざい投稿に「うざい」と投稿する心理

技術系の掲示板(まぁ、@ITなんだけど)を見ているとたまに、うざい投稿や規約違反の投稿がある。

掲示板自体は、スレッドに対して回答しなければ、スレッドの海に沈んでいく仕様となっている。

なので、そのまま放置するか、サポート用のスレッドに規約違反の投稿があった旨を報告するくらいだ。

ちょっと考えれば、うざい投稿に「うざい」と投稿してスレッドを上げることで、他の閲覧者に該当のスレッドを晒すことで「うざい」気持ちが伝播していくと分かると思うのだが、その手の投稿も結構多い。

まぁ、つまり

うざい投稿に「うざい」と投稿する。その投稿自体もまたうざい。

のである。

そこで、なんで、いちいちそんな投稿をするのか適当に想像してみた。

1.直情的で、他の閲覧者のことまで考えが及ばない。良くいえば素直。

2.「うざい」スレッドがここにありますよ。とあえて他の閲覧者に広告することで、同じ気持ちを共有したい。と思っている。

3.投稿者に「そういう投稿はうざいですよ。」と親切心から投稿している。閲覧者のことまでは考えが及んでいない。

4.「うざい」投稿をした投稿者を断罪したい。自分は正義感に溢れていると思っている。

Share

マイクロソフトのハードウェアサポート後日談

とりあえず、家に帰って検証してから、故障窓口に電話しないと・・・。

定時内しかつながらないから、家に帰ってまた、いろいろとメモを取って職場で電話しないといけないのですね。

オンライン受付してほしいよ。

NAL-6295の舌先三寸 – やっと見つけたと思った電話番号ではだめだった

検証してから、故障窓口に電話して交換してもらえる事になったのだが、保証書をFAXしないといけない。

自宅にFAXはないので、まだ送っていないのだが、困ったな。

コンビニかな。

とりあえず、交換してもらえることになってよかった。

Share

ラムダ式と匿名型:VBとC#で出来ることの違い

C#は、式だけではなく、メソッドのように{}で囲った中にステートメントを書ける。

VBは、式だけしか書けない。

この違いは結構大きい。

匿名型に関していえば、

C#は、宣言時に初期化した内容を書き換えることができない。(ReadOnly)

VBは、宣言時に初期化した内容を書き換えることができる。書き換えたくない場合はkeyキーワードでReadOnlyにできる。

この違いも結構大きい。

いいとこ取りしたいなぁ。

Share
カテゴリー: .NET

やっと見つけたと思った電話番号ではだめだった

先日購入した、マイクロソフト製のキーボードを修理に出したくて、一所懸命マイクロソフトのサイトで修理に出すためのコンタクト先をさがした。

それにも、かなり時間がかかって、NとMの押下時のセンサが鈍いだけだからあきらめようかというところでやっと見つけた。

なんで、このご時世、電話だけでしか受け付けてないのか。

しかも、平日定時内。

NAL-6295の舌先三寸

プロダクトレジストレーションセンターに書いてある問い合わせ先の中に、ハードウェアの故障とあったので、電話してみたら、「その手の依頼は取り扱っていない」といわれてしまった。そして、教えてもらった電話番号はフリーダイヤルじゃない。どうも、一度サポートに電話して故障が確定したら修理ではなく交換という手続きになっているらしい。

教えてもらった電話番号を後で調べてみたら、サイト上はオフィスの無償サポートの電話番号なんだよね。

わかりづらいなぁ・・・。

Share

やっと見つけたと思った製品別サポートもだめだった

キーボード

マイクロソフト インターネット キーボード

マイクロソフト オプティカル デスクトップ ウィズ フィンガープリント リーダー

マイクロソフト オプティカル デスクトップ エリート フォー ブルートゥース

マイクロソフト ヘルプとサポート

電話が混んでいて、自動アナウンスでサポートのページでも問い合わせられると言っていたので、探してみた。

どうも、ここから製品別サポートのページに飛べという話みたいなんだけど、まだ、この製品へのリンクが存在しない・・・。

発売されてから、もう1ヶ月経とうとしているんだけどなぁ・・・。

追記:

電話がつながって、いろいろと聞いてみたら、ハードウェア製品は電話でのみの受付らしいという事がわかった。

また、故障かどうかの切り分けができるまでは、フリーダイヤルじゃない方に電話してからじゃないと、故障の受付をしてくれないという事もわかった。

そのわりにプロダクトレジストレーションセンターには故障の窓口への電話番号しか書いていないんだよね・・・。

なんと不親切な・・・。

こうやって、実際に故障してから、故障した製品の交換にたどりつくまでに人数を絞って、コストを削減しているのかと、穿ったみかたもしたくなる。

とりあえず、家に帰って検証してから、故障窓口に電話しないと・・・。

定時内しかつながらないから、家に帰ってまた、いろいろとメモを取って職場で電話しないといけないのですね。

オンライン受付してほしいよ。

Share

なぜ、修理の依頼を電話でしか受け付けていないのだ。

先日購入した、マイクロソフト製のキーボードを修理に出したくて、一所懸命マイクロソフトのサイトで修理に出すためのコンタクト先をさがした。

それにも、かなり時間がかかって、NとMの押下時のセンサが鈍いだけだからあきらめようかというところでやっと見つけた。

なんで、このご時世、電話だけでしか受け付けてないのか。

しかも、平日定時内。

せめて、メールでも受け付けてくれてよいと思うし、欲を言えばというか、Windows LiveIDを登録してユーザ登録させるくらいなんだから、ユーザ登録のページ経由で修理の受付をしてくれても良いのではないかと思う。

なんのためのユーザ登録だよ。まったく。

EPSONなんかは、ユーザ登録経由で修理の受付もしてくれたし、一切電話を利用しないで全て片付いた。

もうちょっと、売った後のことも考えてほしいし、今後ハードウェアを売って行くつもりがあるのなら考える必要があるだろう。

修理に出すつもりのキーボードとマウスのセットは、会社と自宅用に2セット購入するくらい良いものなのに・・・。

Share

第20回codeseek勉強会

第20回codeseek勉強会を開催します。

今回は、TechEdの開発者で一番話題になったLINQを取り上げます。

LINQは、データアクセスをこれまでとは違った視点で表現しようとする

革新的テクノロジーですが、必然的に、いままでのコーディング技術、

管理技術が通用しなくなるものでもあります。

今回の勉強会では、このLINQがアプリケーションプログラミングに

おいて、コーディングに及ぼす影響を中心に意見交換をする場に

したいと思っています。

第20回codeseek勉強会

「LINQとアプリケーションプログラムコード」

(共催:tk-engineering、こみゅぷらす、eパウダ~)

2007年9月29日(土)

10:00~12:00

場所:マイクロソフト新宿オフィス

募集締め切り:9月25日(火)23時59分99

codeseek 勉強会のお知らせ

第20回codeseek勉強会が開催されます。

内容に興味のある方は申し込みしてみてはいかがでしょうか。

申し込みはこちらから。

Share

CommandBuilderのConflictOptionについて

ConflictOptionをCompareRowVersionに指定しているとき、

テーブルにtimestamp(rowversion)列が存在するときは、主キー+timestamp列で、

テーブルにtimestamp(rowversion)列が存在しないときは、主キーのみ(overwriteChanges相当)で

where句が生成される。

timestamp列が存在しないときは、

CompareAllSearchableValues(全ての項目を比較する。)相当になったほうが安全なのになとふと思った。

まぁ、全テーブルにtimestamp列があれば、何も困る事は無いんだけれども。

Share
カテゴリー: .NET

読みやすいコードのためにLINQを利用する。

最初に断っておきたいこと

C#3.0の話です。
LINQやラムダ式自体の説明はしていません。
簡単なサンプルにするため仕様がシンプルで効果を感じられないかもしれませんが、
もしもっと複雑な仕様だったら等、想像してみてください。

まず最初に、下記のサンプルを見てください。

簡単な仕様として、

受け取った在庫リストの集計対象のものだけ集計したい。
集計対象とは、数量が10より大きくて、数量を1000で割った時の余りが0のものの事である。

を実現します。

class サンプル1
{
private class 在庫計
{
public int 数量計 { get; set; }
public int 金額計 { get; set; }
}
public void サンプルメソッド(在庫[] 在庫リスト)
{
在庫計 在庫計情報 = new 在庫計();
foreach (在庫 在庫情報 in 在庫リスト)
{
if (在庫情報.数量 > 10)
{
if ((在庫情報.数量 % 1000 == 0))
{
在庫計情報.数量計 += 在庫情報.数量;
在庫計情報.金額計 += 在庫情報.金額;
}
}
}
}
}

この例の場合、たしかに仕様を実現していますが、if文が実現している仕様についてコード上から読み取ることができません。

そこで、ラムダ式を利用し、集計対象の時にtrueを返す匿名メソッドを作成して実装してみます。

class サンプル2
{
private class 在庫計
{
public int 数量計 { get; set; }
public int 金額計 { get; set; }
}
public void サンプルメソッド(在庫[] 在庫リスト)
{
Func<在庫, Boolean> 集計対象 = 在庫情報 =>
{
if (在庫情報.数量 <= 10)
{
return false;
}
if (在庫情報.数量 % 1000 != 0)
{
return false;
}
return true;
};
在庫計 在庫計情報 = new 在庫計();
foreach (在庫 在庫情報 in 在庫リスト)
{
if (集計対象(在庫情報))
{
在庫計情報.数量計 += 在庫情報.数量;
在庫計情報.金額計 += 在庫情報.金額;
}
}
}

その結果、集計対象の在庫のみ集計するという部分と、集計対象である条件の詳細部分が分離されました。

ここでさらにLINQを利用して、ループの部分が実際に何をしているのかをコードに残すようにします。

public class サンプル3
{
public void サンプルメソッド(在庫[] 在庫リスト)
{
Func<在庫, bool> 集計対象 = 在庫情報 =>
{
if (在庫情報.数量 <= 10)
{
return false;
}
if (在庫情報.数量 % 1000 != 0)
{
return false;
}
return true;
};
var 在庫計情報 = new
{
数量計 = 在庫リスト
.Where(集計対象)
.Sum(x => x.数量),
金額計 = 在庫リスト
.Where(集計対象)
.Sum(x => x.金額)
};
}
}

もしくは、

public class サンプル4
{
public void サンプルメソッド(在庫[] 在庫リスト)
{
Func<在庫, bool> 抽出条件 = 在庫情報 =>
{
if (在庫情報.数量 <= 10)
{
return false;
}
if (在庫情報.数量 % 1000 != 0)
{
return false;
}
return true;
};
var 在庫計情報 = new
{
数量計 = (from 在庫情報 in 在庫リスト
where 抽出条件(在庫情報)
select 在庫情報.数量).Sum()
,
金額計 = (from 在庫情報 in 在庫リスト
where 抽出条件(在庫情報)
select 在庫情報.金額).Sum()
};
}
}

その結果、ループがなくなりましたが、在庫リストから集計対象のもののみを抽出(Where)し、集計(Sum)している事がコードに埋め込まれました。

また、在庫計情報をループで加算しないため、サンプル2までは在庫計というinner classを作成していましたが、その必要がなくなり、その場限りの匿名型で済むようになりました。

ところでサンプルコードだけを見ているとわかりませんが、集計した結果がint型の範囲を超えた時、サンプル2まで(ループで集計している)とサンプル3以降(LINQを利用している。)で実行時の挙動が違います。

サンプル2までは、例外が発生せず、マイナス値になってしまいます。

サンプル3以降は、ちゃんとOverflowExceptionが発生します。

もしサンプル2までのコードで例外が発生するようにする場合は

単純に

//抜粋
foreach (在庫 在庫情報 in 在庫リスト)
{
if (集計対象(在庫情報))
{
if (在庫計情報.金額計 + 在庫情報.金額 > int.MaxValue)
{
throw new OverflowException();
}
在庫計情報.数量計 += 在庫情報.数量;
在庫計情報.金額計 += 在庫情報.金額;
}
}

とすると、intの範囲を超えた場合

在庫計情報.金額計 + 在庫情報.金額

がマイナス値になるため

在庫計情報.金額計 + 在庫情報.金額 > int.MaxValue

の条件がtrueになることが無いため、いつまでも例外が発生しません。

そのためより値のとれる範囲の大きいlongに型変換したうえで、

//抜粋
foreach (在庫 在庫情報 in 在庫リスト)
{
if (集計対象(在庫情報))
{
if ((long)在庫計情報.金額計 + (long)在庫情報.金額 > int.MaxValue)
{
throw new OverflowException();
}
在庫計情報.数量計 += 在庫情報.数量;
在庫計情報.金額計 += 在庫情報.金額;
}
}

とするか、金額にマイナス値が無い前提であれば、

//抜粋
foreach (在庫 在庫情報 in 在庫リスト)
{
if (集計対象(在庫情報))
{
if (在庫計情報.金額計 + 在庫情報.金額 < 0)
{
throw new OverflowException();
}
在庫計情報.数量計 += 在庫情報.数量;
在庫計情報.金額計 += 在庫情報.金額;
}
}

とする必要があります。

つまり、うっかり間違った実装をしてしまうと、オーバフロー時に例外を発行させているつもりで、実は発行していないという状況になってしまいますので、そういう点でも、このくらいの集計ならLINQを利用した方が安全です。

Share