文字列を DateTime 型に変換

DateTime 型のプロパティ Date を実装した例です。
C#7 からは、以下のようなパターンで記述することが多くなりそうです。

public DateTime Date => 
    DateTime.TryParseExact(
	"20170123", 
	"yyyyMMdd", 
	CultureInfo.CurrentCulture, 
	DateTimeStyles.None, 
	out DateTime result) ? 
	    result : 
	    DateTime.Today;

文字列で表現された日付(時刻)が正しく DateTime 型に変換できた場合は、変換した結果の result の値を返します。
そうでなければ今日の日付を返します。

参考までに、以下のような書き方もできます。

public DateTime Date { 
    get {
        DateTime result;
        if (DateTime.TryParseExact(
            "20170123", 
	    "yyyyMMdd", 
	    CultureInfo.CurrentCulture, 
	    DateTimeStyles.None, 
	    out result)
        {
            return result;
        } 
	return DateTime.Today;
    }
}

なるべく式で書いた方が良いので、私は前者の書き方ですね。

ローカル関数を使用する

C#7 からローカル関数が使えるようになりました。
今までは、ひとつのメソッドが長くなりすぎた場合に、可読性を向上させる目的で下請けメソッドを宣言していました。

int Method() {
    :
    Shitauke();
    :
}

int Shitauke() {
    :
    :
}

ローカル関数を使うと、以下のように書くことができます。

int Method() {
    int Shitauke() {
        :
        :
    }
    :
    Shitauke();
    :
}

これによって、気軽に自身のメソッドブロック内に独立性の高い処理をメソッドアウトできるので、他のメソッドに干渉されることなく関連性の高いメソッドをまとめて読めるので積極的に使っています。
ただし、メソッドブロック内のコードの可読性が落ちます。
特に、ローカル関数の宣言部分と、メソッドのメインコードの区別がつかないところが悩ましいです。
いろいろ試してみた結果、次のように落ち着きました。

  1. ローカル関数名はキャメル表記にする
  2. ローカル関数の宣言はメソッドブロックの最後にまとめる
  3. そのメソッドの主処理の末尾に return ステートメントを記述する

ローカル関数名をキャメル表記にするのは、主処理が関数を呼び出すとき、他で宣言されているものかローカル関数かを明確にできるためです。
ローカル関数の宣言を最後にまとめる理由ですが、先頭にまとめると主処理がどこから開始されるのかを探さなければならないからです。
主処理の最後に return を記述する必要は本来はないのですが、これもどこまでが主処理の最後なのかを明確にするためです。

int Method() {
    :
    shitauke();
    :
    return;

    int shitauke() { // ローカル関数名はキャメル表記にする。
        :
        :
    }
}

ただし、これが正解かというと、いろいろな意見もありそうです。
とりあえず、しばらくは上記の規則いこうかと思います。

IEnumerable の遅延実行ではまる例

先ほど軽くはまったのでメモです。

次のコードは、正しく動作しません。

IEnumerable GetItems(){
    using (var db = CreateDataContext()) {
        return db.Table;
    }
}

void Main(){
    var items = GetItems();
    foreach(var x in items) {
        Console.WriteLine(x.Title);
    }
}

理由です。
db.Table に実際にアクセスされるのは、Main メソッドの foreach で items を使用した時点ですが、この時すでに DataContext インスタンスが破棄されているためデータベースにアクセスできずにエラーが発生します。

もう少し詳しく説明すると、GetItems メソッドが return している db.Table は IQueryable型です。
これは、データベースへのアクセスに関する定義を返すだけで、実際に取得したコレクションインスタンスを格納している訳ではありません。
一方 IQueryable 型は IEnumerable 型を継承しているため、GetItems メソッドのように暗黙の型変換が実行されています。
ここに気づかないとはまる訳です。
GetItems メソッドを以下のようにすると、正しく動作するようになります。

using (var db = CreateDataContext()) {
    return db.Table.ToList(); // ←変更
}

理由は、ToList メソッドで取得したデータからコレクションインスタンスを生成したものを返すためです。
簡単な理由ですが、実際の開発コードでは、複雑にメソッドが絡み合っていたりするので、軽くはまるのでメモしておきます。

デリゲートの宣言

以下のように名前を明確に示したいデリゲートがあったとします。

public delegate int HogeHoge(int value1, int value2);

今、次のような書き方を思いつきました。

    
using HogeHoge = Func<int, int, int>;

delegate を使って正しく宣言するか、using ディレクティブを使って別名で宣言するかの違いなんですけどね。
メモしておきます。

Entity Framework コードファーストとビューの扱い

いつのバージョンからなのかわからないけれど、ADO.NET.Entity Data Model が「新しい項目の追加」ダイアログボックスのテンプレートに追加されている。
これを使うと、既存のデータベースからコードファーストに必要なモデルを一式作成してくれる。
したがって、以後は次のようにすると良いのかもしれない。

1.コードファーストでさっくりとデータベースとテーブルを作ってあげるためのプロジェクトを作成
2.作成後のデータベースにビューなどを追加
3.必要に応じてテーブルやビューを変更したりする

実際のシステムを開発する場合は、DataModel なりのフォルダを切って、ここに ADO.NET.Entity Data Model からコードファーストモデルを作る。
マイグレーションの度に、DataModel フォルダ以下を削除して、再度 ADO.NET.Entity Data Model からコードファーストモデルを作る

これがベストな解かどうかはわからないけれど、ビューも管理できるし、しばらくはこれでいこうかな

null条件演算子の使い道

調べものをしていたら、以下のサイトの記事が目に留まってしまった。

http://qiita.com/tadnakam/items/a42d320f2bb19c69a004
C# 6.0 新機能まとめ(qiita)

この以下の部分

>4 Null条件演算子
>?. という演算子が追加されたそうです。null 以外のとき、値を変換するなどに使えそうですが、使う機会は少なそうです。

とありましたけど、自分は使った経験が何度かあったので気になりました。

?.演算子は、??演算子とセットで使用すると大変便利です。

if (r == null) {
    a = 0;
    b = "";
}
else {
    a = r.A;
    b = r.B;
}

の場合に、次のように書くことができます。

a = r?.A ?? 0;
b = r?.B ?? "";

r が null の時は、null と評価されるので ?? 演算子の右辺のオペランドが有効になるのですね。

 

電力自由化における停電リスク

http://gendai.ismedia.jp/articles/-/48576

停電は多発しない筈です

電力自由化で新電力会社と契約するのは電力購入に関してだけで、家に電力を届けるための託送供給契約は今まで通り電力会社とします

したがって、この記事による停電の原因となるのは、電力の供給体制の量を超えた受電要求が起きた場合に限られる訳です

各人が新電力会社から購入した電力は、スマートメーターによって電力会社が管理し、新電力会社にデータを報告することで請求がなされています

つまり、新電力会社は、電力会社が所有する送電網に、どれだけ電気を入れたか、どれだけ電気を出したかをメーターで管理して仕入と売上としており、売上が仕入を上回った差分は電力会社から購入したことになる訳です

以上から、電力供給量の全体の不足分は電力会社が発電して調整することがわかるのですが、この仕組みって今まで通りな訳で、新電力会社が損をするかどうか(電力会社から新電力会社への電力の売価は、めちゃくちゃ高いので)だけの話です

ちなみに電力会社が、不足分の電力の責任を担うことの損害は、恐らくですが、総括原価方式によって解決するのだと思います
最新のものはわかりませんが、僕の知っている限り最新の電力改革法案に総括原価方式による価格の設定は残すとありました
この分の負担は、あくまで新電力会社への売価で設定するのみなのか、我々一般受給者にも関わってくるのかはわかりません

以上のことから、電力の自由化は必ずしも競争原理が働いて電力料金が安くなるとは言い切れないと僕は思っています

最後に、電力会社の責任と特権についてです
東電が東京電灯としてスタートする前の時代、電力会社の数は数百社ほどありました
当時は停電が多発し、感電事故や、電圧の変化による火災なども多発したため、規制や法を厳しくするとともに、これを厳守することができる現在の電力会社に絞られた歴史があり、そういった過去の教訓から、電力会社が特権を持つことは、とても自然なことだと僕は思います

WPF の DatePicker の値が格納されているプロパティ

入力系のコントロールで多用される TextBox の癖でつい下記のように書いてしまう。

<DatePicker Text="{Binding Path=Regist}"/>

最近は、生産性をあげるために、最初からまとめてコードを一気に書きあげてしまう。
そして、その後に、まとめて動作を確認する。
なので、上記の場合 Regist に値が渡らなかったり、内部的に設定した日付が反映されなかったりで軽くデバッグする羽目になってしまった。

正しくは以下です。

<DatePicker SelectedDate="{Binding Path=Regist}"/>

値を取得するプロパティ名は別名でも良いから統一して欲しいなぁ・・・

WPF でマウスカーソルを待機状態にする

MainWindow に次のコードを書いておきます。

		public void WaitCursor(bool flag) {
			if (flag) {
				Cursor = Cursors.Wait;
			}
			else {
				Cursor = null;
			}
			DoEvents();
		}


		public void DoEvents() {
			DispatcherFrame frame = new DispatcherFrame();
			Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background, new DispatcherOperationCallback(ExitFrames), frame);
			Dispatcher.PushFrame(frame);
		}

		public object ExitFrames(object frames){
			((DispatcherFrame)frames).Continue = false;
			return null;
		}

MVVM パターンなどで、VMから制御したい場合は、次のようにするとよいです。

		static public void WaitCursor(bool flag) {
			var me = App.Current.MainWindow as MainWindow;
			me.WaitCursor(flag);
		}

待機状態のマウスカーソルは、処理が重くなる場合が多く、DoEvents を自作してメッセージキューを処理させています。
メインウィンドウのメソッドを簡潔に呼び出すために、App.Current.MainWindows で取得したアプリケーションの MainWindow インスタンスから、自身のアプリケーションのメインウィンドウの型に変換しています。