私達は知らず知らずのうちに使いにくいものをそれが当たり前のように押し付けられえていることに気が付いていません。ということは、お客様にも使いにくいものを押し付けているかも知れません。
もっと素直な、もっと自由な発想が必要です。
技術屋の石頭ではもう生き残れません。

震災から一年が経ちましたね。
被災地ではまだまだ大変な日々が続いていると思います。
震災に関する番組もたくさん有り、私も決して今後も忘れてはいけないと思いました。　
いろんな番組の中で、日本のエネルギー問題について取り上げられていました。
火力や原子力を使わないで、日本に合った地熱発電と言う内容でした。
私達も電力監視を販売してるから、興味深く観てました。　
例としてアイスランドでは地熱発電を使って、電力を補っているんですが、初期投資をした後の費用は安く、また発電後の蒸気もお湯に変えて各家庭に供給しているとてもエコな発電設備でした。 また発電装置の殆んどが日本製なんですって。驚きました。
日本には技術もあり火山国でありながら普及されないのはもったいないですね。
日本のエネルギーも変わる希望が持てると言う事が分かりました。

とあるページに下記のような記事を見つけました。

———————————

エンジニアの仕事は、新しい「もの」を作り出していくことです。文字どおりの「もの」もあれば、目に見えにくい「サービス」や「システム」もありますが、さまざまな技術的成果を集め、集めたもののそれぞれを信用し、自分が作りたいものの「部品」として扱って組み立てる過程は同じです。楽観的だからこそ、この過程に積極果敢に取り組み、目指す「もの」を完成させることができるのではないでしょうか。いいかげんに集めたり、それぞれの成果を信用しなかったりすると、最終的な「もの」はできません。

　だから、もし常に「できない自信＝悲観」をもつ技術者がいたら、その人が無理してなにか作っても、ろくなものにならないのではないかと私は思います。それはもう「技術者」とはいわないのでは、という思いさえ頭をかすめます。

————————————

私の周りの他の会社さんも、暇な所と、忙しいところの格差が広がっているように思います。上記が必ずしも合っているとは、言えませんが技術大国日本が崩壊している大きな要因ではないかと思います。そんな時代だからこそ、より勉強しなければと切に思いました。

VS2008が出る前の話。拡張メソッドを使用することで、列挙型にメソッドを追加できるという点に興味を持ち、早く使って見たいと思ってました。しかし、ネット上ではあまり使わない方が良い的な書き込みが多く、使うべきかどうなのか悩んでました。

しかし、実際にVS2008やVS2010を使い出すと、使わずにはいられない、使わないともったいないことが良くわかりました。VS2008以降は拡張メソッド(とラムダ式)によって、ほんとに開発が楽になりました。

自分の場合、案件毎のプロジェクト内で拡張メソッドを作ることはほとんど無く、社内用の共通ライブラリ内で大量に作ってます。最近共通ライブラリに追加している機能は拡張メソッドばかり。拡張メソッドライブラリになっていってます。

使いどころは大体以下の３つ。

１．列挙型のメソッド

今までだと例えば列挙型の名称を取得したいと思った場合、名称を取得するstaticメソッドを作成して対応していました。

string name = DockStyleFuncton.Name(DockStyle.Fill);

拡張メソッドを使うと以下になります。

string name = DockStyle.Fill.Name();

スッキリしました。インテリセンスでメソッドが出てくるので書くのも楽です。

２．処理のパイプライン化

例えばdouble値に対して丸め→絶対値→文字列変換を順番にしたい場合、

string strValue = Math.Abs(Math.Round(doubleValue)).ToString();

拡張メソッドを使うと以下になります。

string strValue = doubleValue.Round().Abs().ToString();

したいことの順番とコーディングの順番が同じなので直感的です。
これも１と同じく、インテリセンスでメソッドが出てくるので書くのも楽です。

３．genericクラスが特定の型の場合だけ利用できるメソッド

例えば以下の拡張メソッドを作ります。

public static IEnumerable〈TValue〉 Values〈TKey, TValue〉(this IEnumerable〈KeyValuePair〈TKey, TValue〉〉 items) {
    if (items == null) yield break;
    foreach (var item in items) {
        yield return item.Value;
    }
}

すると、KeyValuePairをコレクションするListや配列の場合、Valuesメソッドが使えるようになります。
同じようにKeysメソッドやContainsKeyメソッドなども作っておくと便利。

みんなが好き勝手に拡張メソッドを追加していったらえらいことになりそうではありますが、
ライブラリ化して管理すればリスクは低そう。それよりも使うことのメリットのほうが断然大きいです。

とあるマンションのリビングの壁に照明スイッチと給湯コントローラ、そして、ビデオインターフォンが配置されていました。
一見するとそれらは床からの高さがバラバラの配置です。
私は普段から制御盤にブレーカーやリレーを配置したりタッチパネルにスイッチやランプを配置しているので部品の上端や下端、または、中心を揃えることが習慣になっています。
「あーあ、不細工なことしてるなぁ」と思いました。
しかし、実際にそれらをいじっていると「あっ！そうか」と声を上げてしまいました。
ビデオインターフォンは人の目の高さに、給湯コントローラは小さい子供の届かない高さに、照明スイッチは小さい子供が背伸びをすれば届く高さに配置されているではありませんか。
【誰が】【何のために】【どのように】【それを使うのか】
大事な事を忘れておりました。

今、部品造りで半田なども使ってます。
もちろん最初の研修中の時は上手くいかなかったり、時間がかかったりで大変でした。
先輩などの教えで、イメージしながらするのをモットーに頑張ってます。
気分は職人さんです♪
使ってもらえる方の事を考えて、もっと綺麗に、もっと丁寧に心を込めて作ってます。
でも、何度も同じ事を繰り返す度に早く出来るようになりましたよ。
私も、もの造りに参加してます。

設計とは。

使って頂く人の立場にたって、安全に、使いやすく使って頂けるように、何も無い所から考える事で、設計したものを入れる（納入して頂く）事ににより、業務に支障が出る事は持っての他。
コードを書く事も、図面を引く事も、作業であって設計ではありません。

だから、上むいて考えている時は、サボっているのではありませんm(__)m

ソフトウェアの品質を確保するには、真っ先に「テスト」
というのが思い浮かぶのですが、「QFD：品質機能展開」
という、設計段階から品質を確保するという考え方もあるようです。
確かに、設計の段階でお客様が満足するシステムを考えられていれば、
仕様変更も最小限になり、品質の高いものができると思いました。

最近のC#での開発は、BackgroundWorkerやタスク並列ライブラリなどによって並列処理・非同期処理がどんどん簡単になっています。

次バージョンで追加されるasync/awaitによってさらに簡単になるでしょう。
しかし、マルチスレッドの作成は簡単になっているが、マルチスレッドセーフな実装にするのは依然難しく泥臭い。

C#に関数型言語のパラダイムがもっと注入されるか、コンパイラやプロファイラなどでの検出が強化されないと、危険なプログラムだらけになりそうで怖い。

マイカーのタイヤにスリップサインが出てきました。
ただでさえ年末年始の出費がかさんでいる時期に４本替えか・・・。
できるだけ安く買えるお店をネットで探していると聞きなれないタイヤメーカーをヒットしました。
台湾の”NANKANG”です。現在とまったく同じ性能(205/55R16-91V)のタイヤがなんと４本で18,920円でした！背に腹は替えられぬで早速注文。オートバックスでの交換費用が11,200円。総額30,120円で済みました。しかし、これは手放しで喜べる話でしょうか？円高の恩恵で安いアジア製品を更に安く仕入れることで日本国内の製品はますます売れなくなるのでは？しかも、品質に遜色がなければ脅威となります。現在、1台湾ドルはたったの2.55円です。企業努力もクソもありません。