2009年9月26日土曜日

アイスホッケーのルール改定

最近アイスは試合に出てないので知らなかった(レフェリークリニックにも出てないし)んだけど、ルール改定があると語りべさんとこで知りました。戦国時代到来!<1> | 加藤じろう直営!「語りべ」通信

レフェリー2人制とアイシング後のチェンジ禁止。NHLでは既に実施されてるルールだし、これはとてもいいルール改定だと思うな~。アイスホッケーの最大の問題点は「レフェリーに見られなければ反則も反則にならない」部分。どんな競技でもそうだけど。ホッケーって使ってる道具が凶器にもなる危険なものだから悪意をもってそんなことするとすぐケガするし、感情的になって報復行為に行ったりする人をかなり見かける。

上手なプレーヤーもそんな人がいたりして、スポーツマンシップはどこへやら。チェックに行くのとは意味が違う部分の話ね。そこに来てレフェリー2人制は希望を感じる。それを県連レベルでもちゃんとやれればの話だけど。県連レベルで実施することの最大の懸念は「判定基準の同等な2人のレフェリーを常に立たせることが出来るのか」につきる。とりあえず、県連ローカルルールでやるような社会人リーグではどこも適用しなさそうな雰囲気。そんなに沢山(ラインズマンいれて4人必要になる)レフェリー用意できないっていうのは致し方ないのかもね。

アイシングでのチェンジ禁止はクリアしかしないようなディフェンスのいるチームではかなり致命的。でも、ホッケーを楽しむ(試合の勝ち負けだけが楽しみだとあれだけど)にはいいルール。で、こちらについてはルールブックの条文にきちんと記載があって「412条の2 ラインズマンがアイシングコールをするためにハンドアップをした後...」ってなってる。ラインズマンのハンドアップが遅かったり、フロントがアイシングを取ったけど、バックがハンドアップしてないとかになると大荒れの予感。とりあえず今シーズンはAプールのみの適用で様子見みたいだね、神奈川は。

話変わって今日は先週に続けてアメージングで試合。3戦目にしてやっと勝てた。オオニョさんがいなくてマジ助かった。スガマタさんに続いて今期から参戦してくれた新ゴーリーのアオキさんの活躍がすばらしかったデス。なんか最近のS40蒲公英はゴーリーに恵まれてきてる気がする。しかも帰りに寄ったスタバで初めて黒エプロンのバリスタを見た。ちょっと感動した。

2009年9月23日水曜日

SHURE

Amazon.co.jp: Ultimate Ears MetroFi 220 MF220: 家電・カメラ

これをさ~、気に入って使ってたんだけどさ~。

断線。半年で。泣ける。

代わりになる物を探しに電器屋巡りしたけど、置いてないんだね。みんなiPhoneで音楽聞くのと通話とするときどうしてるんですかね。Bluetoothとか充電面倒じゃないっすか?面倒でくじけたんだけど...。

結局、今回もAmazonのお世話になることにしようと思うんだけど、少し学習してイヤホンとマイク部は別々に出来るようにまずは↓これ。

Amazon.co.jp: SHURE iPhoneでの高品位なハンズフリー通話を可能にするマイク付き接続コード MPA-3C: 家電・カメラ

んで、なるべく素の音がいいから、イヤホンは↓これ。

Amazon.co.jp: SHURE 高遮音性イヤホン・ブラック SE102-K-J: 家電・カメラ

写真 

連休が空ける前に届いてくれて嬉しす。明日からの通勤が楽しみだぜ~。遮音って怖い気もするけど、気配を感じ取れるように修行します。

2009年9月21日月曜日

Routeでデフォルト省略させたくない

GenerateLink does not return the control name and the view name only for the INDEX view - Stack Overflow

これってデフォルト値と同じパラメータを省略(後方に有効値パラメータ無しの場合)させずに、URLを取得出来るようになればいい、っていう問題だったり?

  routes.MapRoute(
    "Default",                                              // Route name
    "{controller}/{action}/{id}",                           // URL with parameters
    new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
  );

↑こういう登録をしてる場合に、

  var url1 = Url.RouteUrl("default");
  var url2 = Url.RouteUrl("default", new { controller="Home" });
  var url3 = Url.RouteUrl("default", new { controller = "Home", action="Index" });

↑これは全部"/"と出力されるけど、これが"/Home/Index"になって欲しい、と。違うなら意味なくなっちゃうからそういう質問だと仮定。

やっぱりRouteクラスを派生させてGetVirtualPathのoverrideでしょ!

  public class FullRoute : Route
  {
    public FullRoute(string url, IRouteHandler routeHandler): 
base(url, routeHandler) { } public FullRoute(string url, RouteValueDictionary defaults,
IRouteHandler routeHandler):
base(url, defaults, routeHandler) { } public FullRoute(string url, RouteValueDictionary defaults,
  RouteValueDictionary constraints, IRouteHandler routeHandler):
base(url, defaults, constraints, routeHandler) { } public FullRoute(string url, RouteValueDictionary defaults,
RouteValueDictionary constraints, RouteValueDictionary dataTokens,
IRouteHandler routeHandler):
base(url, defaults, constraints, dataTokens, routeHandler) { } public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values) { var dict = new RouteValueDictionary(Defaults); values.ToList().ForEach(kv=>dict[kv.Key] = kv.Value); var url = Url; dict.ToList().ForEach(kv => url = url.Replace(string.Format("{{{0}}}", kv.Key), (string)kv.Value)); url = Regex.Replace(url, @"{([\w].+)?}", ""); url = Regex.Replace(url, @"(\/){2,}", ""); var path = base.GetVirtualPath(requestContext, values); path.VirtualPath = url; return path; } }

※途中のパラメータが空白の時は考慮してないのであしからず。なんかthrowすべきだよね~。

これを使うようにRouteTableに追加。

  routes.Add("FullDefault",
    new FullRoute(
      "{controller}/{action}/{id}/{foo}/{bar}",

      new RouteValueDictionary(new { controller = "Home", action = "Index", id = "", foo = "", bar = "" }),
      new RouteValueDictionary(),
      new MvcRouteHandler()
  ));

※idより後ろのパラメータは特に意味なしデス。

そうすると

  var full1 = Url.RouteUrl("fulldefault");
  var full2 = Url.RouteUrl("fulldefault", new { controller = "Home" });
  var full3 = Url.RouteUrl("fulldefault", new { controller = "Home", action = "Index" });

これが全部"/Home/Index"を返すようになります。

こういう事でいいんですかね?って英語でどうやって答えればいいのか分からない...。

2009年9月20日日曜日

戸塚ホッケー事情

MHLのシーズンも始まって、この土曜で既に2試合消化したけど、どっちも負けたから特に書く事もない...。切ない。とりあえず、あれだ。初戦はゴーリーいなかったからいいとして、2戦目はひどい。あれじゃ、100戦しても100回負ける。もう少し賢く守りましょう。新規加入のゴーリー、スガマタさんはとてもすばらしいゴールテンディングを見せてくれてたよね?後はディフェンスの問題だけなんだから。

で、試合の話はいいとして、今日戸塚でみんなでおしゃべりしてる時に、戸塚に誰がいるのか誰か来るのかを簡単にみんなで共有できるようにするのに、ミチアキさんが「Twitterどう?」って話になったよね。その場にいた数人には説明したけど、なかなか言葉だけだと分かりにくいと思うので、みんなでガンガン使ってみよう!

http://twitter.jp

ネット関連に疎い人も多いと思うけど、スズキ君にはサヨちゃんが上手いこと説明して登録するようにしといてね!S40組にはオレが説明するとして、クラッシャーズ組にはヤマケン選手よろしく!後は、ちょっとづつ広めていきましょう。クローバー組はタカオ?

Twitterって何?って言う人も多いと思うけど、検索すればヤマのように説明出てくるから何とかなるよ。ケータイからのアクセスは...ケータイ持ってないからよく分かんないよ!モバツイッターとか?

そのままTwitterにつぶやいても、メッセージが流れてよく分かんなくなると困るので、戸塚スケートファクトリー用のハッシュタグとして Totuka Skate Factory Hockey の頭文字を取って#tsfhとしてみる感じでどうっすか。つぶやきの最後に#tsfhって書いてつぶやくだけ。そしたらTwitter / Search - #tsfhここにアクセスすればいい、戸塚の状況がすべて見られるようになるっていう寸法。

twitter

戸塚に行く前・着いてから・誰かを誘う時、いろいろつぶやいてみたら便利なんじゃないかね~。

追記

大事なことを書き忘れてた。Twitterでたけはらをフォローするときのアカウント名はtakeparaデス。

2009年9月15日火曜日

こういうのはいいのかどうか

ASP.NET MVC Transaction Attribute (using NHibernate) - Scott's Blog

NHibernateじゃなくても、以下のようなTransactionAttributeで。

using System;
using System.Transactions;
using System.Web.Mvc;

namespace MainSite.Controllers
{
  [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false)]
  public class TransactionAttribute : ActionFilterAttribute
  {
    private TransactionScope _transactionScope;

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
      _transactionScope = new TransactionScope();

      base.OnActionExecuting(filterContext);
    }

    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
      base.OnActionExecuted(filterContext);

      if (filterContext.Exception == null)
        _transactionScope.Complete();

      _transactionScope.Dispose();
    }
  }
}

適当なDataContextを用意してこれまた適当なAction(適当すぎてすいません)で。

    public ActionResult Index()
    {
      ViewData["Message"] = "Welcome to ASP.NET MVC!";

      return View();
    }

    [HttpPost,ActionName("Index")]
    [Transaction]
    public ActionResult IndexPost(string name)
    {
      var db = new DataClasses1DataContext();
      db.Table1s.InsertOnSubmit(new Table1 {name = name});
      db.SubmitChanges();

      //throw new HttpException(500,"Error!");
      return RedirectToAction("Index");
    }

Unit of Workって言うんですかね~。Exception起こせばロールバックするんだけど...。トランザクションってこのレイヤで意識するものなのかな~。う~ん。好みや規模に合わせて好きなやり方でどうぞ、ってことで。

2009年9月12日土曜日

runAllManagedModulesForAllRequests

VS2008での開発中のWebサーバーはWebDev.WebServerで、これってsystem.webServerセクションを処理しないで、IIS6と同じ動きになるじゃないっすか。

ドはまった。いきなり全然動かない状況が発生してテンヤワンヤ。そもそもIIS6にデプロイするものを作ってて、でもちょっとテストしたくなってIIS7にデプロイしたらイエロースクリーン。サッパリ原因が分からず泣きそうになった。出てきたエラーは↓これ。

セッション状態は、構成ファイルまたは Page ディレクティブで enableSessionState が true に設定されているときのみ使用できます。System.Web.SessionStateModule またはカスタムセッション状態モジュールがアプリケーション構成の <configuration>\<system.web>\<httpModules> セクションに含まれていることも確認してください。
説明: 現在の Web 要求を実行中に、ハンドルされていない例外が発生しました。エラーに関する詳細および例外の発生場所については、スタック トレースを参照してください。

例外の詳細: System.Web.HttpException: セッション状態は、構成ファイルまたは Page ディレクティブで enableSessionState が true に設定されているときのみ使用できます。System.Web.SessionStateModule またはカスタムセッション状態モジュールがアプリケーション構成の <configuration>\<system.web>\<httpModules> セクションに含まれていることも確認してください。

全然、解決出来そうなtipsが見つからなくて、将来の自分のためにここにコピペしとく。なんでセッションがいきなり動作しないんじゃ!と、お悩みなら、とにかくrunAllManagedModulesForAllRequests属性を確認。IIS7って統合パイプラインだったりするのが魅力なんだけど、こんなことに時間をつぶされるとは...。

    <system.webServer>
      <validation validateIntegratedModeConfiguration="false"/>
      <modules runAllManagedModulesForAllRequests="true">
        <remove name="ScriptModule" />
        <remove name="UrlRoutingModule" />

SessionStateModuleがマネージモジュールなおかげでこの属性を外すと、EnableSessionStateを設定しろと全然違うメッセージになって泣ける。

今後主流になるIIS7.5(Windows 7だけど)の場合は、英語っぽいメッセージになったけど、これまた検索で見つかるようにコピペしとこう。

The SessionStateTempDataProvider requires SessionState to be enabled.
説明: 現在の Web 要求を実行中に、ハンドルされていない例外が発生しました。エラーに関する詳細および例外の発生場所については、スタック トレースを参照してください。

例外の詳細: System.InvalidOperationException: The SessionStateTempDataProvider requires SessionState to be enabled.

そもそも、この属性をいついじってしまったのかさえ覚えてない...。普通にプロジェクト作成したときには指定されてるから自分で消したのは間違いないんだけど、IIS7にデプロイするまで問題が発覚しないから、要注意。

全然関係無いけどBubbleShareにアップしてるアルバムをダウンロードしようとしても0バイトのZIPファイルになってて全然ダウンロード出来ない。早くダウンロードしないとそろそろ閉鎖しちゃう。あわあわ。

2009年9月6日日曜日

HandleErrorの使い方リベンジ

前回の投稿の時には全然気にしてなかった問題を最近突っ込まれたので、改めて試して見ました。

そもそもASP.NET MVCで例外発生時のハンドリングをどうするのか、というのは前回の投稿に書いてるので読んでもらえれば分かると思います。と、言うと読んでもらえない気もするので簡単に説明すると、web.configでsystem.web/customErrorsをOnにしておき、ControllerやActionにHandleError属性を指定する。そうするとException毎に出力する内容を自分で制御出来るのさ!、というものです。

ここでポイントになるのはsystem.web/customErrorsでエラーハンドリングをする部分です。と、いうのも発生したエラーを捕捉し、表示したい内容を切り替える際に、この方法だとエラーページから302 Redirectで表示ページに遷移します。でも、人ではない何か(クローラやらAjaxなんかでのRESTクライアント)に正しくエラーを伝えるにはHTTP StatusCodeに正しい値をセットしたレスポンスを返さないとダメじゃないですか。ダメだとしましょう。

前回の実装では、302 Redirectの後に返されるレスポンスで正しいHTTP StatusCodeを返してる。けど、ちょっと待てと。そもそもRedirectいらないだろと。おっしゃる通りです。まったくその通りで、リクエストに対してRedirectなんかせず、スパッとステータスを返すのが正しい実装ですよね。

どうすればそういう実装が簡単にできましょうか、が今回の主題です。で、この主題を実装して正しく動くのはIIS7以降に限定なのでそうじゃない環境の人は「ふ~ん、そっすか」くらいにしか得るものがないかも。ガンバです!

まずsystem.web/customErrorsだけだとリダイレクトされてしまうので、これを何とかしたい。IHttpModuleとかで実装するのも手としてはありかもしれないですが、そんなことしなくてもweb.configにsystem.webServer/httpErrorsというのがありまして。このセクションにエラー発生時の挙動を書きます。それだけだとcutomErrorsと何が違うんだと思われても致し方なし。決定的に違うものがありまして、それがresponseMode="ExecuteURL"という属性。これを指定するとただのHTMLレスポンスでもなく、リダイレクトでもなく、指定したURLの実行結果を返してくれるんです。まばゆいくらい素敵です。

httpErrors Element [IIS 7 Settings Schema]

詳しくはリファレンスをチェケラッなんだけど、残念なことに日本語になって無くてですね...。ここは一つ「早く日本語にしてください!」とこのエントリを読んだ人はチャックに言いましょう!IISというかインフラは担当が違うと弱音を吐くようなら「担当に伝えてください!」とチャックに言いましょう!だって担当知らないし。

MSDNのドキュメントの苦情もすべてチャックに!そんなチャックはTHE TRUTH IS OUT THEREこちら(ゴメンねチャック)。

話を進める前に前回の状況のスクリーンショットを確認しておきます。

error1 error2

左が立ち上げた時の状態。右がBad Requestのリンクをクリックした状態。クリックすると拡大するのでステータスを確認してみてください。302 Redirectの後に400 Bad Requestになってますね。ちなみに開発環境のwebDev.webServerはwebServerセクションを見てくれないので、ローカルのIISにデプロイして確認する必要があります。今回はWindows 7上のIIS7.5にデプロイしてます。

まずはsystem.webServer.httpErrorsを設定します。

    <httpErrors errorMode="Custom">
      <clear />
      <error statusCode="400" path="/ErrorHandle/Errors/400" responseMode="ExecuteURL" />
      <error statusCode="403" path="/ErrorHandle/Errors/403" responseMode="ExecuteURL" />
      <error statusCode="404" path="/ErrorHandle/Errors/404" responseMode="ExecuteURL" />
    </httpErrors>

適当な感じで申し訳ないっす。 で、web.server/customErrorsを変更します。

    <customErrors mode="On" defaultRedirect="Errors" />

前回の設定内容をガッツリ消して、上記のみにしてしまいましょう。これすら消すとHandleError属性が効かなくなってエラーが捕捉出来なくなるので残しておきます。

続いて、HandleErrorAttributeクラスを派生させたHttpHandleErrorAttributeクラスを作成します。この派生クラスでOnExceptionをoverrideして処理してしまいましょう!

using System.IO;
using System.Web;
using System.Web.Mvc;

namespace ErrorHandling.Controllers
{
  public class HttpHandleErrorAttribute : HandleErrorAttribute
  {
    public override void OnException(ExceptionContext filterContext)
    {
      var exception = filterContext.Exception as HttpException;
      if (exception == null)
      {
        base.OnException(filterContext);
        return;
      }

      var statusCode = exception.GetHttpCode();
      var errorViewName = string.Format("~/Views/Errors/Error{0}.aspx", statusCode);
      if (!File.Exists( filterContext.HttpContext.Server.MapPath(errorViewName)))
        errorViewName = "~/Views/Shared/Error.aspx";

      filterContext.Result = new StatusViewResult(new ViewResult { ViewName = errorViewName }) { StatusCode = statusCode };
      filterContext.ExceptionHandled = true;
    }
  }
}

普通のExceptionは無視して、HttpExceptionだけ捕捉します。後は、ControllerにHttpHanderErrorを追加するだけ。

using System;
using System.Web;
using System.Web.Mvc;

namespace ErrorHandling.Controllers
{
  [HandleError(Order = 1)]
  [HttpHandleError]
  public class HomeController : Controller
  {
    public ActionResult Index()
    {
      ViewData["Message"] = "Welcome to ASP.NET MVC!";

      return View();
    }
// 以下省略

太字のところです。 ちなみに前回のサンプルソースに付け足してます。

実行すると↓こうなります。

error3

ちゃんと1度目のレスポンスで400がが返ってますね!

error4 error5

上の2つは左がThrow Exceptionリンクをクリックしたもので、これはcustomErrorsが効いてる結果です。右がMethod not arrowedをクリックした結果で、HttpHandleErrorでViewの定義が無かった(405を用意してないです)時のものです。

エラー処理もこれでスッキリ!

2009年9月4日金曜日

あ、メタルキングじゃないことがばれた

先日のBoFの様子が早くもCodeZineで記事になってます!

「ASP.NET Web Form」か「ASP.NET MVC」か? .NETによるWebアプリ開発の今を徹底討論(1/4):CodeZine

最初のページのトップにある写真でプロジェクターの映像を見上げてるのが自分です。これだけ小さい写真だと顔も分からないから恥ずかしくないね!同じ写真内で真ん中あたりにノートパソコンのモニターがちらっと写り混んでるね~。ボスなんだよね~。このノートパソコンの画面気になるでしょ~?メモとか取ってるとか思ってるでしょ~?違うんですよ!パワポ(?)で「ここでボケて」とか「もっと詳しく」とか「なんでスーツ着てないの?」とかが用意されてて、しゃべってる途中でチョイチョイ画面をこちらに向けて楽しんでたんだよ!上手いこと写真には写ってないけど一番後ろの席で肉好きの熊さんも同じくカンペを用意してたんだよ!怖え~。BoF怖え~。罠ばっかりだ。

写真小さいとか思ったそこのあなた。2ページ目ではちょっとデカイ写真が。メタルキングじゃないことがばれた。東京生まれヒップホップ育ちのメタルキングで通してたのに普通の人なのがばれた。ちなみにカメラ目線ではありません。たまたまです。写真撮ってることなんて気がついてませんから。ド緊張してたんで。

記事ではスゴイまじめに技術の話をしてる風ですが、そこは記事を書いてくれたナオキさんの腕っす。自分へたれっす。

これからもご贔屓に~。