DataControllerでDynamic Dataみたいな

ASP.NET MVC Tip #4 - Create a Custom Data Controller Base Class - Stephen Walther on ASP.NET MVC これもありだな～、と思います。

Google App Engineでの開発っぽい。 DataControllerだけが大事なところなのにコード量がべらぼうに少なくて、なんか嬉しい。 Form 値はRequest.Form.Keysをforeachで取り出したのとエンティティのプロパティが同じなら(上手く言えないけどリフレクションで)書き換える感じで。エンティティそのままでViewData用のクラスなわけじゃないから、 System.Web.Mvc.BindingHelperExtensions.UpdateFromを使えないのかな(NewとUpdateで同じコード書いてるのか切ない部分)？

でもね、GetDynamicGetがカッコよすぎる。 IdentityColumnNameも主キーがintの項目を1つにするルールを貫けば(Railsとかそうだし)超絶便利な予感。 派生してるのがHomeControllerだからリソース名がHomeに思えるけど、そこはデフォルトのままいじってないってことなんだろうから気にしない。実際にはこのサンプルならMoviesControllerとかにするのがナウなヤングのRails風？

RESTfulじゃないけど「設定より規約」なところがいいっす！ 最近のお気に入りはDBのテーブル全てにEntryDateとModifyDateをDateTime型で作っておいて、DataContextクラスのSubmitChangesをオーバーライドして勝手に値を入れるようにすること。

    public override void SubmitChanges(ConflictMode failureMode)
    {
      ChangeSet changes = this.GetChangeSet();
      DateTime now = DateTime.Now;
      Action setNow = (entity, name) => {
        var etype = entity.GetType();
        var prop = etype.GetProperty(name);
        if (prop != null)
          prop.SetValue(entity, now, null);
      };

      // insert
      foreach (var entity in changes.Inserts)
      {
        setNow(entity, "EntryDate");
        setNow(entity, "ModifyDate");
      }

      // update
      foreach (var entity in changes.Updates)
      {
        setNow(entity, "ModifyDate");
      }

      base.SubmitChanges(failureMode);
    }

GetChangeSet()で追加・更新・削除それぞれの対象レコードを取得できるから、それを取り出して自動更新。エンティティの型は宣言しないでvarで。varと規約ベースの開発は最高っす！ ただ悩みもありまして．．．。

入力値の検証(Validation)をどこでやるのがいいのかってことなんですけどね、LINQ to SQLのEntityのpartial classでやると、確実にチェックではじけていいんだけど、タイミング的にはもう少し早い段階でやりたかったりする。ViewDataクラスにバリデーション機能をつけるのがいいのかな．．．。アプリケーションの制約と、データベースの制約とレイヤーが違うからそれぞれに必要なんだろうけど(例えばAと Bっていうカラムがあって、更新するときにどっちも空は嫌だけど、どっちも空でもDBでは問題なしとか)。 タイムリーにオノさんところで紹介されてたサンプル(SingingEels : ASP.NET MVC in the Real World)を見てみたけど、普通にコントローラでForm値を検証してるじゃんよ．．．。 こんな感じなのかな～(とりあえずTempDataに入れちゃうとロードバランサとかで無茶ぶりできなくなる)。

追記なんですけど。 ASP.NET MVC Tip #5 – Create Shared Views - Stephen Walther on ASP.NET MVC これまた面白いのが．．．。Tip #4の続きで今度はまさにDynamic Data。 コントローラ用のViewフォルダに、コントローラでView()するASPXがない場合の初期動作として、Sharedフォルダ使う動きをうまく生かして、すべてに共通のViewでページ生成。なので、インターフェイスを動的に作る必要があるからASPXのコードビハインドにコード書いてる。 全然気になんない！Scaffold！

フリーマーケット

何気に海外のドラマを見てる時にフリーマーケットのシーンがあって、テロップに「Flea Market」って書いてて初めてフリマの意味を知りました。

さて、DataContractJsonSerializer使ってますか？ かつて何でもありだったJavaScriptSerializerの次に出てきた標準クラスなんだけど、これを使おうとするときは基本型指定ですよね。

で、ASP.NET MVC Preview3になってからJSONをレスポンスに返すためControllerに新たにJsonResult Json(...)が定義されてますよね。 で、これってobjectを引数に渡すんだけど、型指定しないってことじゃないですか。もしやと思って、ソース見てみたんです。 そしたら．．．。

#pragma warning disable 0618   
 JavaScriptSerializer serializer = new JavaScriptSerializer();    
 response.Write(serializer.Serialize(Data));    
#pragma warning restore 0618    

こんなコードになってた。強引っすね。 いいのかな～。自分も使いたいんだけど、使っていいのかな～。 だってね、LINQ to SQLのデータモデルクラスをそのままJSONで扱いたいけど、DataContractじゃないし、DataMemberついてもないからそのままだと使えなくて、でもそのためだけに別クラス作るのも馬鹿らしいじゃないっすか。みんなどうしてるんだろう。

そしたらさ、ガスリー君(本物なのかな？)が言うんですよ。 First thoughts on ASP.NET MVC Preview 3 | Aaron Lerch 「The JavaScriptSerializer class is actually undeprecated in .NET 3.5 SP1. 」 って（．．．どういう意味？）。 使っていいのか！？いいのかガスリー君！？

MVCContribでRESTful

CodeProject: RESTful routing in ASP.NET MVC. Free source code and programming help こんなに簡単に．．．。

SimplyRestfulRouteHandlerを使えばいいよ！ってことですね。 そもそもMVCContribってなんですか？ってなもんです。

なので、ちょっとソースをダウンロードして確認(現時点でのダウンロードが55っていうのが人気の無さを物語ってる気がしなくもなくもないけど気にしない！)。 かゆい所に手が届く系のライブラリって感じ？

RESTfulを単純にHTTP Methodだけで考えれば、リソースに対してGET/PUT/DELETE/POSTでアクションを決定するようにすればいいよね。ってことはリソース=Actionじゃなくて、リソース=Controller。 でも、WebでHTMLをViewにする場合、入力ページ(新規と編集)もGETだからリソースのGETとかぶる。あと、コレクションのGETも。 そうなると少し面倒な感じがしなくもないけど、RoutingでうまいことなんとかなるのがASP.NET MVCのいいところ。 URIの設計をしてて思ったのは、URIのリソースをそのままコントローラと一致させないで、以下に内包したコントローラとして頭を切り替えるかが結構キモなんですね。

会社と社員を内包関係で表現すると /Companies/{companyId}/Employees/{employeeId}

だけど、それぞれがコントローラになるんですよ～。 てことは、個別にしてもいいじゃない？

/Companies/{companyId} /Employees/{employeeId}

でも、これだと所属を表現できないからヤダってこともあるでしょう(会社と社員じゃないサンプルの方がよかったね．．．)。 デフォルトアクションがそれぞれIndexだとしたら、CompaniesController.Indexと EmployeesController.Indexがそれぞれのコレクションリソースで、個別のリソースを取得するためにもうひとつModelアクションを定義。で、RoutingでうまくModelアクションにルーティングしてあげればうまいこと出来るよね。

GET /Companies → 会社一覧取得 GET /Companies/New→ 会社新規フォーム POST /Companies → 会社新規登録 GET /Companies/123 → IDが123の会社取得 GET /Companies/123/Edit → IDが123の会社編集フォーム PUT /Companies/123 → IDが123の会社更新 DELETE /Companies/123 → IDが123の会社削除

こうしたいって時のコントローラでのアクション。 ※前回書いたRESTfulAttributeがある前提。

[RESTful(Post="Create")]
public ActionResult Index(int? id) {...}

[RESTful(Put="Update",Delete="Destroy")]
public ActionResult Model(int? id)
{
 if (id.HasValue)
  return Show(id);
 else
  return New();
}

public ActionResult Update(int id) {...}
public ActionResult Destroy(int id) {...}
public ActionResult Show(int id) {...}
public ActionResult New() {...}

これをうまくRoutingでさばきます。

routes.MapRoute(
 "Companies-Model",
 "Companies/{id}/{action}",
 new { controller="Companies", action="Model" },
 new { id = @"[\d]+" }
);

routes.MapRoute(
 "Companies",
 "Companies/{action}",
 new { controller="Companies", action="Index" },
 new { action=@"[a-zA-Z]*" }
);

こうやって、2つのRoutingでひとつのコントローラに対する、ルーティングを登録すればIDのありなしをちゃんと１つのコントローラで処理できるから、なんて素敵にRESTful！ってなりませんかね。 ※正規表現はよしなに。

ROAなURIを考えた場合{controller}/{action}/{id}だとアクションがリソースになるけど、{controller}/{id}/{action}でコントローラをリソースにしちゃいましょうっていう。

/Companies/123/Employees/456   

とかのルーティング↓。

routes.MapRoute(
 "Employees-Model",
 "Companies/{companyId}/Employees/{id}/{action}",
 new { controller="Employees", action="Model" },
 new { companyId=@"[\d]+", id = @"[\d]+" }
); 

※コレクション部のルーティングも同じように。

イロイロ内包するならたくさん書くか、"/Employees"を"/{controller}"にしてあげる。 統一インターフェースでのアクセスは規約でアクションを決め打ちすることで最強になるでしょう。 全然MVCContribの話じゃないっすね．．．。

で、これを簡単にするのにMVCContrib。 Simply Restful Routing ここにあるように、アクション名を規約に通りにつければ、HTTP MethodとURIを見て、うまいことルーティングしてくれます。PUT/DELETEはブラウザから送れないので、そこはHidden で"_method"にメソッド名を入れてオーバーロードPOST。Railsっぽく。 どっちを使うかは気分次第で！

進化の過程をウキウキウォッチング

いや～、ずいぶん変わってしまいました。 Preview2からPreview3への移行をしてみようと作業してて思ったのが、簡単にできるようになったかもってところです。 もちのろんでASP.NET MVC Preview3ですよ！ 分かりやすくRESTfulフィルター作ります。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;

namespace MvcApplication4.p3
{
 public class RESTfulAttribute : ActionFilterAttribute
 {
   public string Post { get; set; }
   public string Put { get; set; }
   public string Delete { get; set; }

   public RESTfulAttribute() : this("", "", "") { }
   public RESTfulAttribute(string post, string put, string delete)
   {
     Post = post;
     Put = put;
     Delete = delete;
   }

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
     string httpMethod = filterContext.HttpContext.Request.HttpMethod.ToLower();
  
httpMethod = (filterContext.HttpContext.Request.Form["_method"] ??
filterContext.HttpContext.Request.HttpMethod).ToLower();

     var actions = new Dictionary() {
       {"post",Post!="" ? Post : filterContext.ActionMethod.Name + "Post" },
       {"put",Put!="" ? Put : filterContext.ActionMethod.Name + "Put"},
       {"delete",Delete!="" ? Delete : filterContext.ActionMethod.Name + "Delete"}
     };

     if (actions.ContainsKey(httpMethod) && actions[httpMethod] != "")
     {
       filterContext.Cancel = true;
     
       var controller = filterContext.Controller as Controller;
       var actionInvoker = new ControllerActionInvoker(controller.ControllerContext);
       actionInvoker.InvokeAction(actions[httpMethod], new Dictionary());
     
       return;
     }

     base.OnActionExecuting(filterContext);
   }
 }
} 

はぁ、もうこの時点で違うんだね。 InvokeActionがControllerじゃなくて、ControllerActionInvokerクラスに移動になりました。 素直に呼び出せるからこれの方がいいね。 2個目のパラメータの意味が不明。MVCのソース見てもExecuteで↑みたいにnewしてる。 RESTful属性をつけたアクションの実行時にPOST/PUT/DELETE毎にアクションを振り分ける処理です。 属性のパラメータで名前を指定しなかった場合は、自動で呼び出しアクション名+HTTP MethodをInvoke対象のアクション名にしてます。

ホントはGETのときにNew(新規フォーム)/Edit(編集フォーム)/Show(表示だけ)を振り分けるのもID見たりしてフィルターでやった方がよりカッコよしかも。あと、どの表現(XHTML、JSON、XMLとか)を返すかとかも拡張子みたいな形で分けるとなお素敵さアップ。 続いてHomeControllerにアクションを追加。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;

namespace MvcApplication4.p3.Controllers
{
 public class HomeController : Controller
 {
   public ActionResult Index()
   {
     ViewData["Title"] = "Home Page";
     ViewData["Message"] = "Welcome to ASP.NET MVC!";

     return View();
   }

   public ActionResult About()
   {
     ViewData["Title"] = "About Page";

     return View();
   }

   [RESTful]
   public ActionResult Resource(int? id)
   {
     return Content(string.Format("GET!({0}) - {1}", Request.Form["value"], id), "text/html");
   }

   public ActionResult ResourcePost()
   {
     return Content(string.Format("POST!({0})", Request.Form["value"]), "text/html");
   }
 
   public ActionResult ResourcePut(int id)
   {
     return Content(string.Format("PUT!({0}) - {1}", Request.Form["value"], id), "text/html");
   }
 
   public ActionResult ResourceDelete(int id)
   {
     return Content(string.Format("DELETE!({0}) - {1}", Request.Form["value"], id), "text/html");
   }

   public ActionResult Item()
   {
     ViewContext vc = new ViewContext(ControllerContext, "dummy", "", null, null);
     var page = new ViewPage();
     page.Html = new HtmlHelper(vc, page);
     page.Url = new UrlHelper(vc);

     string partial_html = page.Html.RenderUserControl("~/Views/UserControls/Item.ascx");
     return Content(partial_html, "text/html");
   }
 }
} 

Resourceって言う名前のアクションを定義して、RESTful属性をくっつけました。 前 (Preview2)まで、単純にテキストを出力するのがなかったから、RenderTextなんてのをControllerにくっつけてたんだけど、新たにContentって言うメソッドで出力できるようになりましたね！ちなみに今回は使ってないけどJsonもあるよ！

最後のItemアクションはユーザーコントロール(ascx)の実行結果を出力するため(パーシャルっす)のサンプル。これは前とほぼ変わってないけど、全体的に引数の数が増えてる感じ？

最後にページ部分。Home/Index.aspxを書き換えてます。

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true" CodeBehind="Index.aspx.cs" Inherits="MvcApplication4.p3.Views.Home.Index" %>

<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent" runat="server">
<h2><%= Html.Encode(ViewData["Message"]) %></h2>

<p>
<a href="<%= Url.Action("Resource") %>/1" class="restful">GET</a>
<a href="<%= Url.Action("Resource") %>" class="restful">POST</a>
<a href="<%= Url.Action("Resource") %>/1" class="restful">PUT</a>
<a href="<%= Url.Action("Resource") %>/1" class="restful">DELETE</a>
</p>

<p>
 <a href="javascript://" class="partial">どろんじょ</a>
 <div id="partial"></div>
</p>

<script type="text/javascript">
Event.observe(window, 'load', function(){
 var baseAction = '<%= Url.Action("Resource") %>';
 $$('a.restful').each(function(anchor){
   anchor.observe('click',function(e){
     var method = anchor.innerHTML;
     var index = anchor.href.indexOf(baseAction);
     var url = index >= 0 ? anchor.href.substring(index) : baseAction;

     new Ajax.Request(url,{
       method: method,
       parameters:'value=restful',
       onComplete:function(ajax){
         alert(ajax.responseText);
       }
     });
     Event.stop(e);
   });
 });

 $$('a.partial').first().observe('click',function(e){
   new Ajax.Request('<%= Url.Action("Item") %>',{
     onSuccess:function(ajax){
       partial.innerHTML = ajax.responseText;
     }
   });
 });

});
</script>
</asp:Content>

UserControls/Item.ascxの中身は何でもいいんだけど、とりあえず↓。

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="Item.ascx.cs" Inherits="MvcApplication4.p3.Views.UserControls.Item" %>
<div>
 <ul>
   <li>マジで恋する5秒前</li>
   <li>ムゴ、ン色っぽい</li>
 </ul>
</div>

処理を簡単にするために、Site.Masterでprototype.jsを読み込むようにしてます。 実行すると、最初が↓。

PUTリンクをクリックすると↓。

んで、どろんじょリンクをクリックすると↓。

これで今日からRESTful！

Preview3!!!

やっと出た～！！

ASP.NET MVC Preview 3 Release - ScottGu's Blog ASP.NET - Release: ASP.NET MVC Preview 3 Source Download details: ASP.NET MVC Preview 3

Northwind使ったサンプルプロジェクトも出てるけど。 Updated Northwind Demo For ASP.NET MVC Preview 3 このままじゃなんかエラーで動かない！

と、コメントに書いてる人もいて、同じくアセンブリをいったん削除(System.Web.Abstractions,Mvc,Routhing)してから、Program Filesに入ったDLLを参照で追加すると動いた。 ソースも即行ダウンロードしたけど、どこがどれだけ変わったのやら。 とりあえず、Preview3 Readme.docを見たけど、もっとこう細かいところの一覧とかも欲しかったりする。わがままですね。

でも、HtmlヘルパーのDropDownList(ListBoxも)がMultiSelectListを渡すようになって、ちょっと良くなったのはいいけどRadioButtonListは相変わらずstring[]を返すんだね。結果に対するAggregateによる生成はどうなんでしょうね。いいんですかね。

あと、せっかくだから(最近ドはまり気味の)RESTfulなサンプルにしてほしかったりするな～。 URIは名詞で！統一インターフェースで！ あと、個人的にかなりショッキングなのがViewDataのModelプロパティ．．．。同じ名前でプロパティを定義するようにしてたからっていうね。悲しいね。

ソース見てて思ったけど、あれだね、カスタムViewDataと、標準ViewDataの両方がViewにわたるんだね。標準ViewDataのModelプロパティにカスタムViewDataが入ってる(カスタムとか標準って言い方をしないよね、きっと)。この辺の変更でHtmlヘルパーのデフォルト値指定が楽になるみたい。 これは素敵かもしれない。TempDataは相変わらずSessionなのがちょっと残念。 CopyToは同じの作ってたから、最初から欲しかったので最高！ あとは、いじりつつ確認するぞ～！！ ※416からでもずいぶん違うのね．．．。

ひた隠しに

動くものを作ろうと思うと、やっぱり流行りのスタイルに乗っかりたい。そう思うのは浅はかなことでしょうか。で、ASP.NET MVCでRESTfulっぽく作るならやっぱり、HTTP MethodでActionを自動で振り分けたい。 そう思うのは、いたしかたなし。

画像を操作するResourceControllerがあったとしましょう。 画像を追加したいならResourceControllerにPhotoAddNewとかPhotoCreateなんていうActionを作りたくなるでしょう。でも待って！それじゃRESTfulじゃないよ！

複数形とか単数形は置いといて、とりあえず/Photoに対するアクセスでCRUDを処理したいよね！ 特に興味無いですか？あ、そうですか。

まぁ、聞いて下さいよ。 以前のエントリーでRESTfulFilterなんてものを書いてみましたが、ぶっちゃけあれじゃ効率悪し。 送り側にActionFilterAttributeを書く方法だと、毎回リクレクションが必要ジャン？ それなら、受け側でHTTP Method毎のAction名を指定するほうがよっぽど効率がいいってものですよ。 その辺踏まえて、以下のようなActionに。

/ResourceController [RESTfulFilter] public void Photo(int? id){...} public void PhotoPost(){...} public void PhotoPut(int id){...} public void PhotoDelete(int id){...} ※ActionResultじゃなくてvoidなのは気にしない。

で、 RESTfulFilterのExecutingでHTTP Method見て、現在のAction名の後ろに自動でInvokeActionする名前を作る(もちろん、属性のパラーメータでHTTP Method毎のAction名をセットできるようにした方が優しい)。 こんな風にしとけば、ActionFilterAttributeは1か所に指定するだけで済むので、効率よしって話です。 が、その他のActionがpublic(じゃないと、InvokeAction出来ない、よね？)なので、直接そのActionにもアクセスできちゃうのが何か気持ち悪し。出来て何が悪いってわけじゃ全然ないんだけども。なんとなく。直接のアクセスは拒否したいな、なんて思ったり思わなかったり。

そんなときはまたしてもActionFilterAttribute作成しましょう。 たとえば．．．RequireReactionAttributeとかって言う名前で。 RESTfulFilter でInvokeActionする直前に、Controllerのプロパティで例えばIsReaction = tureとかしておけば、その先でIsReactionがfalseなら実行をキャンセル(filterContext.Cancel=true)にしちゃう。そうしとけば直接アクセスしてほしくないActionに制限かけれたり(Controllerのbaseプロパティで分かる方法あるのかな)。 同じく、RequireAjaxAttributeとかって言うのも作っちゃって、XmlHtpRequest以外の要求は拒否(リクエストヘッダに何か入れとく)なんてことも、簡単(ヘッダ書き換えできちゃうから完璧なわけじゃないけど)。 prototype.jsなら勝手にヘッダーに入れてくれて楽ちんだし、DELETEやPUTのときには_methodにHTTP Method入れてPOSTにするから、そこ見て判定するようにしとくと、さらに楽ちん。

まだまだ工夫の余地ありだけど、HTTP Methodの自動InvokeActionだけでも、だいぶコード量削減出来てうれしい限りです。

Pagenation

なんか英語だとかっこよく見えるけど、普通にページ切り替えのこと。 LINQ使ってIQueryableなデータをページ切り替えできるようにするってばよ。

ASP.NET MVC: PagedList<T> : Rob Conery

ここのソースをそのまま流用してもよし。少しいじるもよし。自作するもよし。 結局はこういう形に落ち着くはず。 IPagedListとインターフェースを定義しておくのにも訳があり。

ASP.NET MVC - Pagination View User Control | Code-Inside Blog International

↑こういうページ切り替えコントロールを作成する時に、インターフェース渡しにしておくことで、型に依存しなくて済むから。IPagedListを受け取るようにコントロールを作っておけば、どんな型でも関係なく、ページに関する情報のみ取得できるでしょ。

上記、いずれもASP.NET MVCって書いてるけど、LINQだからMVCかどうかは関係ないと思われる。 ところで、ASP.NET MVCに限らず、AJAX的なページの部分更新を行う場合って、一般的な方法というのがあるんだろうか。 今はMVCで作ってるとはいえ、MVCに限った悩みとは思えず。 特に、リストでデータを持ってる場合とか。

<div id="container">
 <ul id="list">
   <li id="item1">Data1</li>
   <li id="item2">Data2</li>
   <li id="item3">Data3</li>
 </ul>
</div>

こんな感じのHTMLを持ってるとして、ulにliを1つ追加するような処理ってどうしましょうか、っていうね。 １．ページ全体更新。 ２．ul全体(ulタグ込み)を取得して、divのinnerHTMLを書き換え。 ３．追加対象のli(liタグ込み)を取得して、ulのinnerHTMLに書き足し。 ４．追加対象のliの中身(liタグ無し)だけを取得して、document.createElement('li')のinnerHTMLに値を入れた後、ulにappendChild。 ５．JSONか何かでデータだけを取得して、クライアントサイドですべての表示要素をcreateElement。

上からデータ量の多い順(３と４は誤差の範囲だけど)。 １はそもそも、ページ全体なんだからAjaxとか関係なし。 ５はサーバーサイドでのビュー定義がまったくもって役に立たなくなりかねないし、JavaScriptコードが多すぎて面倒。Google Gearとかだとこの方法じゃないとつらいと思われるけど、今回は対象外としたい。 ２・３・４のどれを選ぶのが妥当なんだろうか。 ２の場合、ページの初回表示の時に使用するであろうコントロール(ASP.NETだとUserControlだし、Railsならpartialか)を、 Ajaxの結果としてResponse.Write。データ1個を返すだけだったりしても、リスト全体が対象になる分、データ量は増えるけど処理は簡単。 ３と４の場合(ほとんど一緒)、リスト全体を表現するコントロールと、リストアイテムのコントロールに分けて作っておけば、ページ出力の場合と、部分出力の場合でも、それほどコード量に差が出てくるわけでもないんだけど、データ量は少なく済む。 んじゃ、常に３か４でいいのか？ってことになるんだけど、結局4だとcreatElementしなきゃいけなくて、コードがめんどっちくなる。３はというと、結構いいんだけど、サーバーサイドのコントロール階層が少し深くなって見通し悪しな気がしなくもなく。 でも結局は、２と３の組み合わせ(適材適所で！)になるんだろうとは思うけど。 今はずっとASP.NET MVCで、PostBack方式でのWebFormsを全然使ってないんだけど、サニタイズ気をつけてれば、こっちのほうが自分の思考にあってて作りやすい気がしてならない。 それもこれも結局は好みの問題なんだろね。

ハァ～。NHLプレーオフ生で観たい。デトロイト今年こそやってくれそうだし。