Muto Masayuki

Swift2: Control Flow

2015-10-28T00:00:00+00:00

iBooksのSwift本を読む続き。

辞書からデータが取得できたかできないかはnilが帰ってきたかどうかで判断できるので、 if let value = dict[key] { ... と書ける。
for-in はまあ、はい。
for もはい。

whileループの説明で突然 Snakes and Ladders というゲームが出てきた。

他の言語のdo-whileに相当するものがrepeat-while。repeat-whileはwhileより Snakes and Ladders には向いてる。
switch-caseはexhaustiveでなければならない。(全パターン網羅してるか、default:が必要)
フォールスルーはしない(ので、各ケース中にbreakは必要ない。やりたければfallthroughキーワードを使う)
caseの条件ではletをつかって値の束縛(value binding)ができる。whereをつかうと値に対する条件も書ける。
ネストしたループを抜けるためにループラベルをつけられる。label: while ... とかくと、break label でそのラベルのwhileを脱出できる。(またSnakes and Laddersが登場)

Swift2: String

2015-10-27T00:00:00+00:00

SwiftのCharacterはUnicode extended grapheme clustersを保持するデータ構造なので、例えば「が」の場合一文字で「が」単体なのか「か」と「゛」の組みなのかは問わずひとつのCharacterとして扱う。(OS Xの闇を感じる)
Characterの性質から、Stringのcharactersプロパティは文字数を計算するために文字列を全部舐める必要があるので、長い文字列で文字数を計算するときは注意が必要。
文字列の比較はcanonically equivalent。「が」が単体か組みかをとわず「が」なら同じ扱い。
文字列からUnicodeの表現を得るには、utf8、utf16、unicodeScalarsプロパティを使う。それぞれUInt8、UInt16、UnicodeScalarのコレクションが得られる。

classとstructure

2015-10-26T00:00:00+00:00

iBooksで The Swift Programming Language (Swift2.1) を読んでるメモ。

P.37 structはclassとほぼ同じだけど、structは常に値渡し。
P.41 protocolはC#でいうところのinterface。mutatingをつけないと変更可能にならない(素晴らしい、でもそもそもstructやenumが変更可能なんだ、、、それはそれで便利そうではあるけど。self = ...って他にない味わいだな)
P.43 extentionはC#でいうところの拡張メソッド。ただし、protocolを当てる(実装する？)のにも使える。extension自体に名前が不要なのが良い。protocolを既存の型に後付けできるのは素晴らしい。
バックスラッシュを入力するのにいちいち option + ¥ を打つのがだるい。¥をデフォルトでバックスラッシュに割り当てられないのかしら。
extension Hoge: ExampleProtocol { まで入力したらExampleProtocolのスタブを作って欲しいんだけどそういう機能はどうやって呼び出せばいいのだろう。
optionalのnilはObj-Cのnil(ポインタ)と見た目が同じだけど別物。(そりゃそうだ)

僕はもうC#をC系の言語で一番現代的なプログラミング言語の機能をうまく取り入れた言語だというのをやめようと思う。Swiftの方がよくできてる。

メッソッドの宣言のところでthrowsをつけると例外を投げられるようになるっていうの、一般化して「これをつけるとこれができる」っていうのをプログラマが実装できるようにならないものかなと思った。そのうちそういうことができることが普通になるんじゃないだろうか？Haskellではモナドという形でそれができるようになているけど。

クラス定義はモジュールで囲む

2013-12-24T00:00:00+00:00

モジュール内のクラスを定義をするときに、class MyMod::MyClass; endとするか、module MyMod; class MyClass; end; endとするか、どっちがいいのかなぁと思っていろんなgemのコードを読むと、圧倒的に後者であることが多い。

一見前者の方が簡潔に書けて良さそうな気がするが、定数を探すスコープが変わるという実用上の問題があるため、みんな後者を使う。具体的に言うと、内部のクラスで親モジュールの別のクラスを参照しようとする際、クラス名だけで参照可能にしたいなら、モジュールで囲む必要がある。

Sequel::Modelを使うときはautoloadする

2013-12-20T00:00:00+00:00

最近Sequelを使いはじめて、ハマったことについて。

Sequel::Modelを使うと、ARパターンを実現できるので、やってみたいなーと思って、こういうコードを書く。

ヤッターモデルの定義ができたよー。さて、アプリケーションクラスからこれを使おうっと。

さてさて実行……

!!突然の死!!

ググるとこんなのが出てくる。

By design, Sequel requires the database connection be set up before model class definition, since it parses the database schema on model class creation. So you should set up your initialization code to connect to the database first.

Sinatra::Modelが設計上の選択としてコネクションを必要とするというのは理由の説明ではあるが、requireしたいんだけど、という質問の答えにはなっていない。問題なのは、requireされたコードがその場で実行されるということなので、解決策としては、requireを遅延させてやることである。かといって、例えばsinatraのconfigureブロックの中でrequireを行うなんてバカなことはやりたくない。

結論としてはautoloadを使う。これで、ファイル管理上の問題を解決できる。

ASP.NET MVC で bless

2012-12-19T00:00:00+00:00

この記事は One ASP.NET Advent Calendar 2012 の19日目の記事です。

IEにはいろいろなバグがあってWebサイトを作る際には割増料金が欲しいところなわけですが、その中でもあまり知られていない(？)制限の一つとして、CSSファイルあたりのセレクタの数の制限があります。

これを解決するために Bless という node.js で実装された CSS を分割するツールがあります。これをASP.NET MVC4で使用します。

方針

ASP.NET MVC4 には静的コンテンツを出力前に加工する Bundle という仕組みがあり、 CSS と JS については minify と結合を行う際にはこれを使うようになっています。また独自の Transformer を定義することにより sass を css に変換するといったことも可能になっています。(この仕組みを利用したライブラリとして Bundle Transformer があります。良くできてる感じがしますが使いませんでした。)

Bundleで実装できればフレームワークとの相性が良く、一度加工したら内部的にキャッシュしてくれたり、ブラウザにキャッシュを破棄させるためのダミーのパラメータをURLに付与するなどの定型処理を任せることができてとても楽です。ただし、加工の処理を.netで実装できる必要があります。今回行いたい bless は node.js で実装されており、.netのnode処理系というものは存在しないため、Bundleは採用しませんでした。

静的コンテンツを加工するもう一つの方法は、ビルド時に実行するということです。この場合、開発環境で動くexeさえあればなんとかなります。

実装

手順を追って紹介していきます。

Bundlerのインストール

ASP.NET MVC4 で node を使うのはそれはそれで非常に面倒なのですが、Bundlerを使えば簡単です。nodeが同梱されていて動く状態になっていますので、まずこれをインストールします。Bundlerにはいろいろな機能があって便利そうですが今回は使用しません。

README.txt がプロジェクト直下に配置されるので、これを削除しておきます。(Webアプリをデプロイした後に見えてしまう)

Blessのインストール

npm install bless -g すると node_modules ディレクトリ配下にblessディレクトリが作成されますので、これを先ほどBundlerをインストールしたプロジェクト内のbundler/node_modulesにコピーします。

コピーしたらプロジェクトに含めておきます。

bless の呼び出しバッチの作成

bless を呼び出すバッチ(GenerateCss.bat)をプロジェクト直下に作成します。このとき、ファイルの文字コードはSJIS、改行コードはCRLFになるようにしてください。 pushd、popdしているのは、node関係や場合によってはrubyでsassを変換する際に、パスに空白があるとだめだったりcygwinとの相互運用がうまくいかなかったりすることがあるので、その対策です。

 1 @echo off
 2 
 3 set ProjectDir=%~1
 4 pushd "%ProjectDir%"
 5 
 6 rem 必要に応じてbundlerを実行してcssの変換やminifyを行う
 7 
 8 rem bundler.cmd はパス内に空白がある場合の考慮が足りないので直接node.exeを実行する。
 9 rem bundler\node.exe bundler\bundler.js {BUNDLE_DIRECTORY}
10 
11 bundler\node.exe bundler\node_modules\bless\bin\blessc {ORIGINAL_CSS_FILE_NAME} {BLESSED_CSS_FILE_NAME}
12 
13 popd

これだけのスクリプトでどれだけの落とし穴があるというのでしょうか。Windowsは早く滅びればいいと思います。そして21世紀にもなってbatが生き長らえているというのはとても悲しいことです。

ビルドイベントの追加

ビルド時にbless(とbundler)を実行するように、ビルドイベントの追加を行います。ダブルクオートとcallを忘れないようにしましょう。

1 call "$(ProjectDir)GenerateCss.bat" "$(ProjectDir)"

クリーン用バッチの作成

注意点は生成用バッチと同じです。

1 @echo off
2 
3 set ProjectDir=%~1
4 pushd "%ProjectDir%"
5 
6 del {BLESSED_CSS_FILES}
7 
8 popd

クリーンイベントの登録

プロジェクトを一旦アンロードし、プロジェクトの編集を行います。Projectエレメントの直下に次のxml断片を記述します。

1 <Target Name="AfterClean">
2   <Exec Command="call &quot;$(ProjectDir)CleanCss.bat&quot; &quot;$(ProjectDir)&quot;" />
3 </Target>

ところでヴィヅアルスタヂオという人はこう……なんでクリーンのフックについてはUIがないんでしょうか……？？なんとなくわかる気もしますがわかりたくない……

祝福ファイルのプロジェクトへの追加

ここでプロジェクトのビルド・クリーンを試してみてください。長いCSSがビルド時にblessされてIEでも問題ないように分割されたり、それらがクリーン時に消えてくれることがわかるはずです。

できていたらblesscにより生成されたIE対応CSSを忘れずにプロジェクトファイルに含めておきましょう。

ここで問題なのは bless によって生成されるファイルがいくつになるかわからないということです。そうそう数が増減することはないので普段は困りませんが、CSSのセレクタが増えて分割ごのファイル数が増えたときには忘れずにプロジェクトファイルに追加するようにしてください。

Bundleに登録する

祝福されたファイルをScriptBundleに食わせて出力します。こうすることで、キャッシュ飛ばし用のパラメータ(正式な名前があれば教えてください)が自動的に付与されます。blesscの出力は hoge.css hoge-blessed1.css hoge-blessed2.css … というようになっていて、hoge.cssが他を @import する形になります。このとき、hoge.cssの中にはキャッシュ飛ばし用のパラメータがつきますが、親ファイル自身はアプリケーション側でこれを付与してあげる必要があります。そのためにScriptBundleを利用します。

BundleConfig.cs に次のように記述します。

1 bundles.Add(new StyleBundle("~/assets/css/hoge").Include("~/assets/css/hoge.css"));
2 
3 // これがないとキャッシュ飛ばしパラメータがつかない
4 BundleTable.EnableOptimizations = true;

その上で、 Layout.cshtml にて

@Scripts.Render(“~/assets/css/hoge”)

のように参照します。これで完成です。

その先

ASP.NET MVCのBundle側に寄せるのか、NuGetのBundlerに寄せるのか、どっちかにしたらいいんだと思いますが……どっちも面倒そうですねえ……。方向性としてはMVC標準の方が中間ファイルがないしバッチファイルも書かなくていいし管理しやすいと思います。誰かそういうNuGetパッケージを作ってください。

C# で Dynamic Scope

2012-12-18T00:00:00+00:00

この記事は C# Advent Calendar 2012 の18日目の記事です。

C# はとても良い言語ですが、しばしば他の言語のあれ(プログラマブルにメソッドを追加する機能、コンパイル時にコード走らせる機能、構造的部分型、パターンマッチ、Immutableで辞書のキーになれる型を簡単に作れる仕組み、返り値の型でのメソッドのディスパッチ、本物のマクロ、等々)が欲しいなぁと思うことはよくあると思います。今日はそういうものの中でも言語の枠組みの中でなんとかできそうなダイナミックスコープについて、実現する方法を考えてみます。

DynamicScope

ごく稀に「この処理の実行中だけ、この変数の値を一時的に別の値に変更したい」ということがあります。たとえば、HttpContext.Current.Userを参照するMVC4というライブラリがいて、Aさんでログイン中なんだけどBさんのつもりで処理をして欲しいときなんかが、まさにそうです。コードで書くとこんな感じです。

1 var originalUser = HttpContext.Current.User;
2 HttpContext.Current.User = tempUser;
3 
4 // tempUser さんがログインしてるつもりでとても重要な処理を実施する。
5 SomeImportantProcess();
6 
7 HttpContext.Current.User = originalUser;

この一見動きそうなコードですが重要な問題があります。それはSomeImportantProcess()の中で例外が投げられた場合、HttpContext.Current.UserはtempUserのままになってしまうという点です。これを修正してみます。

 1 var originalUser = HttpContext.Current.User;
 2 HttpContext.Current.User = tempUser;
 3 
 4 try
 5 {
 6   // tempUser さんがログインしてるつもりでとても重要な処理を実施する。
 7   SomeImportantProcess();
 8 }
 9 finally
10 {
11   HttpContext.Current.User = originalUser;
12 }

怠惰なプログラマの皆様におかれましてはもうやってらんない状況です。originalUserという変数が新たに出現するのもダサいですし、finallyを明示的に呼び出すなんて、よく訓練されたC#プログラマには我慢できません。

この手の「変数を一時的に別の値に置き換える」というのは広義のダイナミックスコープと言えます。であれば、ダイナミックスコープであると直接表現したいところです。理想的にはこんな感じです。

1 dynamicScope (HttpContext.Current.User = tempUser)
2 {
3   // tempUser さんがログインしてるつもりでとても重要な処理を実施する。
4   SomeImportantProcess();
5 }

残念ながらC#にはマクロが無いので、変わりにusing構文で妥協しましょう。丁度C#の世界にはTransactionScopeというものもありますし、そんな感じにできないものでしょうか。

1 using (DynamicScope(HttpContext.Current.User = tempUser))
2 {
3   // tempUser さんがログインしてるつもりでとても重要な処理を実施する。
4   SomeImportantProcess();
5 }

こんな感じですが、もうちょっとだけC#での実装に合わせて妥協します。

1 using (DynamicScope.Create(() => HttpContext.Current.User, tempUser))
2 {
3   // tempUser さんがログインしてるつもりでとても重要な処理を実施する。
4   SomeImportantProcess();
5 }

第一引数で変数を指定し、第二引数で一時的に上書きたい値を指定します。ギリギリ許せますね。

実装してみます。

 1 public static class DynamicScope
 2 {
 3     public static IDisposable Create<U>(Expression<Func<U>> expression, U value)
 4     {
 5         return new DynamicScope<U>(expression, value);
 6     }
 7 }
 8 
 9 /// <summary>
10 /// ダイナミックスコープをDisposableとして実現するクラス
11 /// </summary>
12 class DynamicScopeImpl<TValue> : IDisposable
13 {
14     Action ResetAction;
15 
16     public DynamicScopeImpl(Expression<Func<TValue>> expression, TValue value)
17     {
18         var rhs = Expression.Parameter(typeof(TValue), "value");
19         var body = expression.Body;
20         var assign = Expression.Assign(body, rhs);
21         var actionExp = Expression.Lambda<Action<TValue>>(assign, rhs);
22 
23         var action = actionExp.Compile();
24         var original = expression.Compile()();
25 
26         action(value);
27 
28         ResetAction = () => action(original);
29     }
30 
31     public void Dispose()
32     {
33         if (ResetAction != null)
34         {
35             ResetAction();
36             ResetAction = null;
37         }
38     }
39 }

第一引数はrefでも良さそうに見えますが、refはクロージャで持ち回すことができなかったので、Expressionになっています。もしかしたらILをどうこうしたりExpressionを頑張ればrefでもいけるかもしれません。識者の登場が待たれます。

荒削りではありますがこれである程度安心してグローバル変数を上書きできるようになりました! エラー処理は読者への宿題とします!

マルチスレッド対応は……スレッドコンテキストスイッチをフックできればなんとかなりそうですが、そんなことできるのかしら？識者の方教えてください。

テストも書いてみます。

 1 [TestMethod]
 2 public void DynamicScopeTest_Object()
 3 {
 4     var x = Utility.CreateDefault<DefaultTestClass>();
 5 
 6     Assert.AreEqual("hoge", x.Name);
 7 
 8     using (Utility.DynamicScope(() => x.Name, "name"))
 9     {
10         Assert.AreEqual("name", x.Name);
11     }
12 
13     Assert.AreEqual("hoge", x.Name);
14 }
15 
16 static int GlobalVariable = 5;
17 
18 [TestMethod]
19 public void DynamicScopeTest_Global()
20 {
21     Assert.AreEqual(5, GlobalVariable);
22 
23     using (Utility.DynamicScope(() => GlobalVariable, 6))
24     {
25         Assert.AreEqual(6, GlobalVariable);
26     }
27 
28     Assert.AreEqual(5, GlobalVariable);
29 }
30 
31 [TestMethod]
32 public void DynamicScopeTest_Local()
33 {
34     var now = DateTime.Now;
35     var localVar = now;
36 
37     using (Utility.DynamicScope(() => localVar, now.AddMinutes(1)))
38     {
39         Assert.AreEqual(now.AddMinutes(1), localVar);
40     }
41 
42     Assert.AreEqual(now, localVar);
43 }
44 
45 [TestMethod]
46 public void DynamicScopeTest_MultipleDispose()
47 {
48     var now = DateTime.Now;
49     var localVar = now;
50 
51     using (var scope = Utility.DynamicScope(() => localVar, now.AddMinutes(1)))
52     {
53         Assert.AreEqual(now.AddMinutes(1), localVar);
54         scope.Dispose();
55         Assert.AreEqual(now, localVar);
56         localVar = now.AddSeconds(5);
57     }
58 
59     Assert.AreEqual(now.AddSeconds(5), localVar);
60 }

このテストを書いてみてわかることは、Expressionは無名関数と同様に環境を保持しているように見えるということです。どうなっているんでしょうか？謎です。

ASP.NET MVC4 使ってみた

2012-12-08T00:00:00+00:00

前回のASP.NET MVC4始めましたの記事から1年ぐらいの間、ずっと ASP.NET MVC4使ってたわけですが、その感想を書いてみます。

before_filter がなくて辛い。

Railsでいうところの before_filter がないのが辛いです。URL中、あるいは POSTされた内容のIDからオブジェクトを取得して、なければ404を返す、というような定型処理を各アクションにいちいち書くことになってしまうので、汎用の before_filter が欲しいなと思いました。同様にafter_filter、 around_filterも欲しいはず。

ただこれC#で書くとするとぱっと思いつく感じでは

 1 [Before("FindUser")]
 2 /* こんなところに書かないといけないし、メソッド名を文字列で指定しなければならない */
 3 /* 複数指定したい場合はどうする？ */
 4 public class HogeController : Controller
 5 {
 6     protected User User { get; set; }
 7 
 8     void FindUser(ActionExecutedContext filterContext /* めんどくさい型 */)
 9     {
10         if (/* パラメータとれるの？ */)
11         {
12             User = ...;
13         }
14         else
15         {
16             /* 404 返す */
17             /* めんどくさい */
18         }
19     }
20 
21     [Before("...")]
22     /* クラスのBeforeに指定したものとここで指定したものとで実行順序が不定 */
23     public ActionResult Show(string id)
24     {
25         return View(User);
26     }
27 }

ということになってしまって、あまりスマートでないし問題がいろいろありそう。いい方法がないか考え中です。

attr_accessible がなくて辛い。

MVC4はModel Binderという仕組みがあって、アクションメソッドの引数に適当な型を指定しておくと、アクションが呼ばれた際のパラメータをうまいことオブジェクトに詰め替えてくれます。

非常に簡単に書くと次のようなコードになります。

 1 /* フレームワークがパラメータをUserクラス詰め替えてくれてくれる */
 2 [HttpPost]
 3 public ActionResult Update(User user)
 4 {
 5     if (!ModelState.IsValid)
 6     {
 7         return View(user);
 8     }
 9 
10     Update(user);
11 
12     return RedirectToAction("Show");
13 }

でもこれだと

IDが不正な場合
ここで更新してほしくないプロパティがパラメータとして渡された場合

に意図しない状況になります。

そこで実際には次のようなコードを書くハメになり、非常にだるいです。

 1 [HttpPost]
 2 public ActionResult Update(string userId, UserUpdateParameter userParam)
 3 {
 4     /* UserUpdateParameter はほぼ User と同じパラメータを持っている! */
 5     /* パラメータや制約が変化した場合の追従がだるい */
 6 
 7     var user = Db.Users.Find(userId); // userIdからユーザを取得
 8     if (user == null)
 9     {
10         return HttpNotFound(); // できなければ 404
11     }
12 
13     if (!ModelState.IsValid) // 文字列長や必須項目等のバリデーション
14     {
15         // 不正なら入力画面に戻る
16         return View(userParam);
17     }
18 
19     user.Name = userParam.Name;
20     user.Age = userParam.Age;
21     /* 以下必要なパラメータ分くりかえし!! */
22     /* だるい!!! */
23     /* パラメータ増減したらどうするの？ */
24 
25     Update(user);
26 
27     return RedirectToAction("Show");
28 }

アクション毎にUserUpdateParameterとか作るのは面倒すぎます。 Userクラスとほぼ同じプロパティを持っていて、制約も同じにする必要があるクラスを定義しろと言われても、どこかで絶対にミスします。ここでRailsの attr_accesibleの考え方を参考に、パラメータとして受け取っていいプロパティについてのみ、[Accessible]をつけることにすると良いのではないかと思います。

 1 public class User
 2 {
 3    [Key]
 4    public string UserId { get; set; }
 5 
 6    [StringLength(200)]
 7    [Accessible]
 8    /* パラメータとしてアクションメソッド受け取ることができる */
 9    public string Name { get; set; }
10 
11    [Accessible]
12    public int Age { get; set; }
13 
14    /* パラメータとしてアクションメソッドで受け取らない */
15    public bool IsAdministrator { get; set; }
16 
17    /* パラメータとしてアクションメソッドで受け取らない */
18    public string EncryptedPassword { get; set; }
19 }

その上で、オブジェクト間のプロパティのコピーを行うヘルパークラス Parameter を定義します。

1 var user1 = new User();
2 var user2 = new User { Name = "hoge", Age = 5 };
3 
4 // Accessible なプロパティについて、内容をコピーする
5 Parameter.UpdateAttributes(from: user2, to: user1);
6 
7 user1.Name // "hoge"

こういうものがあれば、先のUpdateアクションは次のように簡潔に書くことができます。 (前節のBeforeと組み合わせています)

 1 [HttpPost]
 2 [Before("FindUser")]
 3 public ActionResult Update(User param)
 4 {
 5     if (!ModelState.IsValid) // 文字列長や必須項目等のバリデーション
 6     {
 7         // 不正なら入力画面に戻る
 8         return View(param);
 9     }
10 
11     /* 必要なパラメータ分くりかえして書かなくても良い */
12     /* FindUserによってUserは取得済み */
13     Parameter.UpdateAttributes(from: param, to: User)
14 
15     Update(User);
16 
17     return RedirectToAction("Show");
18 }

これで本質的なところだけがアクションメソッド内に書かれている状態になり、割とハッピーです。

RouteValueDictionaryで一つのキーに複数の値を入れられない。

えーと……HTTP的にKey=1&Key=2&Key=3と書けるのに、RouteValueDictionaryに複数の値が入れられないのって、どうみても片手落ちです。これはさすがに今までのように部品を追加する方法では解決できなくて、フレームワーク側に手をいれないことにはどうしようもないので、どうにかしてほしいです。

rake routes 相当のものがない。

これはURLルーティングの仕組みが違うから難しいのだろうと思いますが、欲しいですね。

ValidateAntiForgeryがアレ

もうめんどくさくなってきました。

Cが厚くなる。

これはMVC4に限った話ではないのですが、Mを厚くするのをどうすればいいのかわからないので、Cにたくさんコードを書いてしまうことになってしまうのは、やっぱりよくないんだろうなと思いました。最初のうちはいいんだけど、複数のコントローラで似たような処理が発生したときに、切り分けをどうするかで毎回悩むことになってしまいました。

総論

Rails使いましょう。

ASP.NET MVC4 はじめました

2012-01-14T00:00:00+00:00

ASP.NET Web Formsをしばらく使ってるんだけど、テストし辛いとか、Web API を作るのが手間だったり、HTMLと遠かったりするのがイマイチなので、 ASP.NET MVCを勉強してみようと思う。

せっかくなので最新の(まだ正式リリース前だけど)MVC4を使うことにする。題材としては日々食べたごはんをメモするサイトを作ってみる。

まずこのへんに目を通した。

今わかってる知りたいこととしてはこんなところ

Code First でDBのmigrationってどうやるの？
画面に出る複雑な共通部品(Gridとか)をどうやって共通化するの？
IDをDBでの自動採番にしない場合どうなる？(関連をちゃんと設定できる？)
ProfileProvider、MembershipProvider、RoleProvilderって何するもの？どう使うの？
DI使えって言ってる人がいるけどそれは何故か？どういうメリットがあるのか？
リポジトリパターン使えって言ってる人がいるけどDbContextで良いのでは？IQueryable使いたくならない？

今の成果はモデルを書いてコントローラを自動生成で作っただけ

github

マクロ内でメタ情報を使う

2011-12-19T00:00:00+00:00

マクロ内でメタ情報を使う際には、マクロ定義時に消えてしまうリーダマクロ(^:dynamic など)ではなく、マクロ展開後にも残る明示的な形( with-meta を使う形)で書く必要があるという話。

ローカル関数を簡単に定義する

2011-12-19T00:00:00+00:00

Clojure でローカル関数が簡単に定義できないのがイケてない話

アクティブパターンでエラー処理をする

2011-12-07T00:00:00+00:00

この記事は F# Advent Calendar 2011 の参加記事です。

JavaやC#のような言語でプログラムを書いていると、処理本体は短いのに、なんでこんなに長くなっちゃうんだろう……ということがよくあります。関数の頭でnullチェックをして、Exceptionをキャッチするためにtry…finallyで囲んで、等とやっていると本体がどこにあるのかわからなくなるということは日常茶飯事です。こういったコードはどこが重要な場所なのかがわかりにくく、メンテナンス性が低いものです。

現代的なライブラリや言語ではできるだけ本質的なところだけを書けるようにいろいろな仕組みが導入されています。今日はそういった仕組みの一つとして F# のアクティブパターンを紹介します。

社内勉強会のプログラミング添削会(?)で書いたじゃんけんプログラムを例にとって説明します。

まずアクティブパターンを使わないで書いた場合のプログラムがこれです。 Rock,Paper,Scissorsのうちどれかを二つ選んで引数として渡すと、左か右のどちらがじゃんけんに勝っているかを判定して表示するものです。

type JankenHand =
    | Rock
    | Paper
    | Scissors

type State =
    | Draw
    | Right
    | Left

let Janken l r =
    match l, r with
    | Rock, Rock      -> Draw
    | Rock, Paper     -> Right
    | Rock, Scissors  -> Left
    | Paper, Rock     -> Left
    | Paper, Paper    -> Draw
    | Paper, Scissors -> Right
    | Scissors, Rock  -> Right
    | Scissors, Paper -> Left
    | Scissors, Scissors -> Draw

let parse s =
    match (s:string).ToLower() with
    | x when x.StartsWith("r") -> Rock
    | x when x.StartsWith("p") -> Paper
    | x when x.StartsWith("s") -> Scissors
    | _ -> failwith "argument is not in (r,p,s)"

let main = function
    | [|_; l; r |] ->
        match Janken (parse l) (parse r) with
        | Draw -> "draw"
        | Left -> "Left wins"
        | Right -> "Right wins"
        |> printfn "%s"
        0
    | _ ->
        printfn "fsi Janken.fsx {R,P,S} {R,P,S}"
        1

main fsi.CommandLineArgs

アクティブパターンを使った版がこれです。

type JankenHand =
    | Rock
    | Paper
    | Scissors

type State =
    | Draw
    | Right
    | Left

let Janken l r =
    match l, r with
    | Rock, Rock      -> Draw
    | Rock, Paper     -> Right
    | Rock, Scissors  -> Left
    | Paper, Rock     -> Left
    | Paper, Paper    -> Draw
    | Paper, Scissors -> Right
    | Scissors, Rock  -> Right
    | Scissors, Paper -> Left
    | Scissors, Scissors -> Draw

let (|JankenHand|_|) j =
    match (j:string).ToLower() with
    | x when x.StartsWith("r") -> Some Rock
    | x when x.StartsWith("p") -> Some Paper
    | x when x.StartsWith("s") -> Some Scissors
    | _ -> None

let main = function
    | [|_; JankenHand l; JankenHand r|] ->
        match Janken l r with
        | Draw -> "draw"
        | Left -> "Left wins"
        | Right -> "Right wins"
        |> printfn "%s"
        0
    | _ ->
        printfn "fsi Janken.fsx {R,P,S} {R,P,S}"
        1

main fsi.CommandLineArgs

元々 parse という関数だったのが (

JankenHand

) という関数に変わり、main関数の中のパターンマッチがそれに伴って変化しています。

最初の実装では main 関数の中で引数のパースに失敗したとき、例外が飛んでプログラムがスタックトレースを吐いて終了するようになってしました。パースに失敗したとき例外が飛ぶようになっていると、スタックトレースを吐いて死なないようにするためには、parse部分を try…catch で囲む必要があります。しかも、引数のパースが失敗したときにプログラムの正しい使い方を表示するのであれば、catch 説の中に使い方の表示をするコードを書かねばならず、すぐ外側に既に存在している使い方表示とコードが重複してしまいます。

アクティブパターンをつかって処理する場合、パースが正常に完了したときにのみパターンにマッチするため、それ以上特別な例外処理を追加することなく、通常の条件分岐(match式、function式)の中で自然に例外的状況を取り扱うことができるようになっています。変更後のコードではおかしな入力があった場合にはスタックトレースを吐いて死ぬのではなく、使い方を表示して終了します。

このようにアクティブパターンを使って例外処理を書くことは、単に見た目に簡潔になるだけでなく、網羅的でもあります。あらゆるパターンを網羅していない場合にはコンパイルエラーになるため、XXの場合のケアを忘れていたためプログラムが落ちた、ということが起こり得ないのです。

パターンマッチとアクティブパターンはかっこいいif文以上の価値があるので積極的に使っていきたいですね。