あけましておめでとうございます。

去年を振り返ると、仕事がきっちきちで常に慌ただしくはありましたが、
良くも悪くも大きな変化が無い安定した年でした。

今年は少し腰を据えて開発を行い、新しい技術にチャレンジしていきたいです。

C#用の面白そうなオープンソースライブラリが載っていたのでメモ。
InfoQの記事

このライブラリを使うとC#に関数型言語の言語拡張が行われるそうです。
自分はF#やScalaなどの関数型言語にあまり詳しくないので、どういうメリットが生まれるのか良く分かっていないのですが、このライブラリをきっかけに覚えたいと考えています。

次バージョンの開発ソフトVisual Studio 2015に付属するBlend（XAMLのUIデザインツール）の見た目がVSそっくりになるそうです。機能もインテリセンスやコードスニペットが追加され、VSと似た雰囲気になります。多分ベース部分の実装が共通化されたのだと思います。

しかし、まだVSと統合はされておらず残念です。コーディングとUIデザインを完全にシームレスに行えるのは、さらに次のバージョンになるのでしょうか。

現在契約している楽天のデータSIMカード(月額900円)の高速通信容量の変更があり、今まで1G/月までだったのが2G/月までになりました。ありがたい。

このSIMカードを４ヶ月くらい使っていますが、1G/月を越えたことは
無かったので、当分はこのSIMカードで充分みたいです。

以前にC#などの.netアプリケーションからEXCELファイルの読み書きを行う方法として、Open XML SDKというマイクロソフトが公開しているライブラリについて記載しました。http://www.infortec.co.jp/blog/archives/Item_453

今回、ある案件でEXCELファイルを保存する処理が必要になったためOpen XML SDKを使用してみました。が、とても分かりにくい！使いにくい！

どうもEXCELのファイル形式であるOpen XMLに対する低レベルな実装しか無いようで、なんとも泥臭い。自分でラッパーを作れば使い物になるかも知れないが、そんな時間は無い。

しかたがないので、いつものようにEXCELをCOM参照して開発しようかと思ったが、ネットで調べると、EPPlusというライブラリを発見。

試して見ると、とても使いやすい。雰囲気的には今までのEXCELのCOMオブジェクトを正しく進化させ.netで扱いやすくした感じ。 すばらしい。

[2014.10.22 追記]
残念ながらEPPlusの使用は断念しました。
理由は、EXCEL COMオブジェクトの全機能をカバー出来ておらず、実現出来ない 機能があるからです。
出来なかったのはグラフのデータ系列の色・太さ・マーカ等の変更、グラフの目盛線の表示有無の変更など。
単に自分が探しきれなかったからかも知れませんが、 EXCELであれば、「マクロの記録」を使用すれば必要な機能にたどり着けるので、探す手間も全然違います。
結局は、マイクロソフトが.netで扱いやすいEXCEL制御クラスを用意してくれれば解決する話。なんとかならないのかな～。

2つのスレッドで１つのコレクションを操作することが良くあります。

たとえば、１つのスレッドで測定値をコレクションに追加し続ける。
もう１つのスレッドでコレクションから測定値を取り出し、画面表示したり、ファイル保存したり。

C#のList<T>などのコレクションクラスはスレッドセーフではないので、
複数スレッドで操作する場合、操作する前にLockを行います。
しかし、Lockをするのはいちいち面倒ですし、間違ってLockせずに使用する不安もあります。

.Net3.0からはSynchronizedCollectionクラスなどスレッドセーフなコレクションが追加されています。
このコレクションを使用すると、AddやRemoveなどの単独操作はスレッドセーフになります。
しかし、ForEachなどの複合操作はスレッドセーフになりません。ですので不安が残ります。

結局、SynchronizedCollectionを内包し、スレッドセーフな操作しか行えないクラスを作成するのが一番良いかと考えています。
実装可能な操作はかなり限定されます。
AddかEnqueue、Clear、DequeueAll(全ての要素を取得してクリアする)、ToList、Count
こんなところでしょうか。
キューの操作しかできないので、クラス名はThreadSafeQueueにします。
スレッド間での複数要素の受け渡し用と割り切れば、役に立つのではないかと思います。

なお、List<T>のようにインデックスによる取得操作は実装できません。
指定したインデックスの要素が別のスレッドでRemoveされている可能性があります。
Dequeueも実装できません。
Dequeueした時には要素が１つも無い可能性があります。
TryGetやTryDequeueにして取得できたがどうかも戻せば良いかも知れません。

今月も社内の画像処理フレームワークに色々と機能追加を行いました。
１．別の画像処理シーケンスのサブルーチン呼び出し
２．ビット深度変換
３．円形マスク画像作成
４．濃淡補正に新しい演算方法を追加
５．16bit画像対応
６．値演算関係の機能追加

画像処理を必要とする案件が増えていますので、
社内用に画像処理フレームワークを作成したのは正解でした。
開発速度、品質、コストの全てにメリットがあります。

社内ネットワークが1Gbpsになりました。
実測した所、今までは約90Mbps。新しくなって約400Mbps。

たぶんジャンボ・フレームにするともっと速くなると思いますが、ネットワーク上に100Mbpsの機器も繋がっているので当分はこのままです。

モバイルwifiを購入しました。

前から欲しかったのですが２万円近く、高すぎるので買っていませんでしたが、AWR-100TKが6000円台で購入できることをネットで知り、すぐに購入しました。

これに合わせて楽天のLTEsimカードを購入。
月900円で １GBまでの通信が行えます。

これで、外出先でも安くインターネットが使用できるようになりました。
（電話会社に毎月毎月高い金を払うのはイヤ）

設定はとても簡単ですぐに繋がります。

１ヶ月使った結果、800MBくらいの使用料でしたので、今後仕事での使用量が増えることも考え、どこかのタイミングで3GB(1677円)に変更しようと思ってます。

今日は.net用の自社ライブラリのお話。

メソッドのデリゲートにログ出力やリトライなどの機能を追加するメソッドを色々と作って使っていました。
以下は使用例。

//ログ出力を追加
Skin.Log(“test”, () => {
Hoge();
});

//リトライを追加
Skin.Retry(5, () => {
Hoge();
});

//メッセージBOX表示を追加
Skin.Msg(“msg”, () => {
Hoge();
});

上記のように１つだけ追加する場合は問題無いが、複数の追加を行う場合以下のようになり非常に分かりにくくなってしまいます。

//メッセージBOXを表示し、リトライを行い、ログ出力をしてから、Hoge()を実行
Skin.Msg(“msg”, () => Skin.Retry(5, () => Skin.Log(“test”, () => {
Hoge();
})));

汚い。特に最後の行の括弧が沢山並ぶのがきもい。
なんとか綺麗に書く方法がないか検討した結果、以下のようにメソッドチェインできるようにしてみました。

//メッセージBOXを表示し、リトライを行い、ログ出力をしてから、Hoge()を実行
new Action(() => {
Hoge();
}).Log(“test”).Retry(5).Msg(“msg”).Invoke();

すっきりしました。けど、追加する順番が逆になり、シーケンスがちょっと分かりにくい。
もう少し良い方法は無いか、今も考えています。