退職しました

7月31日をもって10年勤めた会社を退職しました。8月1日から新しい会社で働きます。

社員数2,000人超の中堅SIerを辞めて社員400人くらいの会社へ転職するので、いろんな方に「もったいない」と言われましたが、自分の中ではこの会社に継続して勤めることがもったいないと感じたので転職することにしました。

前の会社(部署)はゆるくてぬるくてMAXパワーの半分程度を出すと仕事が片付いてしまいます。10年戦士となるとサラリーマンとしての技術的なスキルはピークに達するので、他の人ではできなくても自分ではできることが多くなって評価があがります。あとは管理職になって腹八分目で仕事をしていけばある程度は昇進できるような未来が見えました。サラリーマンですからエンジニアの理想よりも、よりリスクを抑えて利益が大きくなる方法を考えていけばいいんです。新しい技術は趣味程度にさらっと追いかけていけばいいんです、客から言われなければ無理に導入する必要はないんです、必要になれば部下に「やれ!」って言えばいいんです。自分の仕事じゃないし、そのほうがリスクを抑えられる。そうやってあと30~35年サラリーマンをだらだら続けていけば、一応1部上場の企業なのでそれなりに給料がもらえる最後の世代だと思っています。自分たちは海外との競争から逃げ切れる最後の世代だと感じています。

その一方で、社外のエンジニアの方と知り合う、Twitterやブログで一方的に知る機会がこの2年くらいで一気に増えました。外には化け物のような(自分よりもはるかにすごいという意味で)人たちがゴロゴロいることを知りました。また、新しい技術(最近では、Windows Azureの新機能リリースやASP.NET MVC4が中心)に触れる機会が一気に増えました。ブログも自分なりに真面目に書くようになりましたし、勉強会などで発表させていただく機会が何度かありました。おぼろげにVBを書くことしかできませんでしたが、業務経験なしでもVBがすらすら書けるようになりましたし、C#も書けるようになりました。30を過ぎてから新しい技術に追随していくことがしんどくなるのではなく、昔よりも楽に新しい技術を追いかけることができるようになりました。

また、ゴミみたいな人たちを使って自分が最大できることの半分の成果をあげればいい仕事はつまらないということを再認識しました。そうなると人間欲が出てくるもので、こういう化け物みたいな人たちと新しい技術を使って一緒に仕事をしてみたい、と思うわけです。しかも、客から言われたことを濁目で淡々とこなすSIではない仕事を。ドラゴンボール的にいうとナメック星時代のクリリンレベルの自分が、ギニューさんやフリーザ様と一緒に仕事をしてみたいと考えてみたってことです。今の会社に対する不満は百万個や二百万個はあります、ただ、それは些細な話しで退職のきっかけになったわけではありません、些細なネガティブな理由で退職してもいいことはないでしょうから。それよりも、今の会社ではなくほかのSIではない会社を見てみたいということと、サラリーマン11年目の自分の評価を他の会社から聞いてみたいという思いで転職活動を始めました。

今年のGW前に転職エージェントに登録しました、たまたまGWがあったので履歴書・業務経歴書を書くまとまった時間があったのは非常にラッキーでした。GW明けに転職エージェントに合い、こちらの希望を伝えました。

  • PM・コンサルではなく、エンジニア職
  • SIerではない会社
  • C#, ASP.NET
  • Windows Azureとかあったらうれしいな

すると、この条件に合う求人はほとんどないんですよね。「SIerじゃない」という条件の時点で、求人条件はほぼLAMP系になります。思わずTwitterでつぶやきました

「ASP.NET / C# / Windows Azureの求人なんて存在しないze!」

「みんな!転職するならLAMPのスキルを身につけよう!!」

そしたらMSの中の人にDMでフォローされました(笑) 仕方がないので条件に完全に合致しない会社も応募しましたが、案の定、求めるスキルと職務経歴が合わない会社は書類選考で落ちました。面接は選考というよりもほぼ勧誘でした。これまでの業務経歴を簡単に説明することと、向こうからのいくつかの質問に答えるだけで勧誘が始まりますw これからこういうサービス/ビジネスをやっていくから、こういう仕事をして欲しいとか、「フレームワークのソース見る?」とか、採用面接に来ただけの人間(機密保持契約結んでない)にこんなことまで言っていいの?とこっちがドン引きになるくらいでした。自分くらいの年齢の人ってどの会社でも不足してるんですね、世代的には団塊Jrよりも下の世代なのでそんなに多くはないですけど、今の20代に比べれば少なくはないと思うんですが。みんなどこにいるんでしょうね。どの会社も20代後半~30代半ばくらいで指示しなくて黙っていても仕事ができる人って足りないし、欲しいんですね。ちなみに、履歴書・業務経歴書にはざっくりとこんな内容を書きました。

  • 経験年数10年(リーマソ11年目)
  • プロジェクトリーダーを担当することが当たり前ですが何か?
  • ASP.NET, C#できますけど?(たぶん...たぶんできると思う...)
  • 新しい技術好きです、個人的にはASP.NET MVCアツいです

一部経歴を詐称していますが...(だってC#の業務経歴ないんだもん(´・ω・`))できないことを「できる!」と言っているのではなく、できることを「できます!」といっているので(自分の中では)問題ないと思っています(`・ω・´)キリッ。いくつかの会社はとんでもないスピード感で採用を進めてきます、面接が終わって帰宅途中の電車の中で結果通知のメールが来ます。実際には転職エージェントを通じてメールが来るので、面接後すぐにエージェントへ結果を通知していることになります、あらかじめ結果を用意しておいたんじゃないかと思うようなスピード感です。しかも「明日、来れますか?最終面接になります」と。その上、最終面接も帰りの電車の中で結果通知メールが来ることがありました、内定通知書付でw もう、絶対面接前に用意していたとしか考えられませんw 現職(もう退職したので、正確には前職)の会社だったら何度も会議して決めるんでしょうねぇ(遠い目)、どの口が「ビジネスのスピード感を高める」とか言ってるんでしょう...おっと、すみません、愚痴になってしまいました。

転職活動を始めてみたら、2週間くらいで最初の内定がもらえて3週間で応募した会社の全ての面接が完了しました。2001年の新卒採用試験ではかろうじて1社からのみ内定をもらえたのですが、11年後には3週間で3社から内定が出ました。で、そのうち採用のスピード感が最も早い会社に決めました。ASP.NET+C#でのアプリ開発エンジニアという職種になります。

明日から

「わたしの戦闘力は530000です」

という人たちと仕事ができると思うと、本当、ドキがムネムネします。自分ドMなので、フリーザー様のように「このクズ野郎!」とか「この虫ケラが!」と言われるとうれしくなってしまいます。

そんなにたくさんの会社の中を知っているわけではありませんが、SIerって能力のある人にはしんどい環境だと思います。自分が転職することを決めたせいか、濁目・社畜自慢をしている人を見ると「会社辞めればいいのに」と思ってしまいます。会社のグチであったり、「オレはXXXXがやりたいんだ!」と主張する労力よりも採用面接を受ける労力のほうがよっぽど小さいですよ。経験や能力が本当にある人であれば、転職先を選べる環境にあると思います。

7月後半は毎日前の会社の送別会でした、毎日二日酔いで昼間も酔っ払った状態だったかもしれません。10年でいろんな部署をたらい廻しにされたため社内の知り合いが(辞める直前の部以外では)多く、直接会ってごあいさつできない方も何人かいらっしゃいました。送別会では絶対転職先の話題になります、転職先や職種について説明が面倒臭いので、転職先について

「Gで始まる(.NET界隈では)有名(だと思う、ソーシャルアプリを作っている)企業」

と説明して勘違いさせたり。

「次の会社でもSE?」とか訳の分からないことを聞く人もいるので

「次の会社ではピージーです。(`・ω・´)キリッ」

と適当に答えたこともありました。ごめんなさい。

// 自部署の送別会よりも常駐している顧客先での送別会のほうがたくさんの方が参加するのは、よくある話ですよね。

このブログについてですが、平日昼間に満たされない思いをぶつけて書いていました。今後、平日昼間にエンジニアとしての自分が満たされることがあればこのブログは更新されないかもしれません。

ASP.NET MVCのクラスの作り方を考えてみた(3)

何回シリーズになるか分かりませんが、「プログラミング ASP.NET MVC」を読んでASP.NET MVCのクラス構成について考えた記事を書いています。これまで2回書いており、内容は以下の通りです。

第3回目はpatterns&practicesのProject Silkで利用されているUnityを利用したDIについて書きます。Unityは制御の反転(IoC:Inversion of Control)を実現するためのフレームワークです。IoCとはDIの1つ上、抽象化された概念だと思ってください。IoCを実現するための実装の1つがDIになります。(用語や概念を厳密に説明できるほど理解が進んでいないです)詳しいことを知りたい方は、以下のページを良く読んでください。

制御の反転

Unity におけるポリシーの挿入

Project SilkやUnityについてはすでにブログで書いている方がいらっしゃるので、最大限参考にさせていていただきました。

ASP.NET MVC 3 と Unity の組み合わせを試し中 (shibayanさん)

Project SilkにならってUnityを使ってみる (miso_soup3さん)

今回は(2)で作成したソースをUnityに対応させたいと思います。まずはNugetでインストールします。

PM> Install-Package Unity
依存関係 ‘CommonServiceLocator (≥ 1.0)’ の解決を試みています。
‘CommonServiceLocator 1.0’ が正常にインストールされました。
Unity を Microsoft patterns & practices からダウンロードします。このライセンス条項は http://www.opensource.org/licenses/ms-pl で参照できます。固有のライセンス条項がある追加の依存関係がパッケージに含まれていないかどうかを確認してください。パッケージおよび依存関係を使用することで、該当するライセンス条項に同意したものとみなされます。ライセンス条項に同意しない場合は、関係のあるコンポーネントをデバイスから削除してください。
‘Unity 2.1.505.0’ が正常にインストールされました。
‘CommonServiceLocator 1.0’ が MvcHogeApp に正常に追加されました。
‘Unity 2.1.505.0’ が MvcHogeApp に正常に追加されました。

Web.configにインターフェースと実装クラスのマッピング設定を記述します。

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <configSections>

    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>

  </configSections>

  <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">

    <namespace name="MvcHogeApp" />

    <namespace name="MvcHogeApp.WorkerService" />

    <namespace name="MvcHogeApp.Models" />

    <assembly name="MvcHogeApp" />

    <container>

      <register type="IHogeWorkerService" mapTo="HogeWorkerService" />

      <register type="IHogeDao" mapTo="HogeDao" />

    </container>

  </unity>

</configuration>

 

Project SilkではWeb.configではなく専用の設定ファイル(Unity.config)にマッピング情報を記載していました。また<register>タグで指定するマッピング情報では名前空間を省略せずに書いてありました。

次にリゾルバの設定です、なぜかIDependencyResolverインターフェースを実装した、欲しいインスタンスを取得するリゾルバが提供されていないので、自分でコードを書く必要があります。今回はProjet Silkで実装されている「UnityDependencyResolver.cs」をそのまま利用しました。このとき知ったのは、Unity関連のクラスはMicrosoft.Practices.Unity名前空間にあるんですね。Unityがルートじゃないんですね。

そしてリゾルバの設定です、Global.asax.csのApplication_Startに設定を行います。

protected void Application_Start()

{

    IUnityContainer container = new UnityContainer();

    container.LoadConfiguration();

 

    IDependencyResolver resolver = new UnityDependencyResolver(container);

    DependencyResolver.SetResolver(resolver);

}

 

こうすることで、引数なしのコンストラクタが不要になります。Web.configに記載したマッピングの設定にしたがってUnityがインスタンスを取得してくれるためです。コードはこうなります。(わかりやすくするために、以前のコードも残してあります)多少コードがすっきりしたことがわかると思います。

public class HogeWorkerService : IHogeWorkerService

{

    private IHogeDao Dao;

 

    // 通常のコンストラクタ

    //public HogeWorkerService()

    //{

    //    Dao = new HogeDao();

    //}

 

    // DI(コンストラクタインジェクション)コンストラクタ

    public HogeWorkerService(IHogeDao dao)

    {

        Dao = dao;

    }

 

    // コントローラーから呼び出されるメソッド

    public HogeViewModels MakeHoge()

    {

        // 省略

    }

 

今まで通り、引数付きのコンストラクタは単体テスト用に必要です。

Unityを使った感想ですが、それほどDIフレームワークを利用するメリットが思いつかないです。コードがややすっきりするのは確かですが、デフォルトコンストラクタがなくなるだけなので、それほど劇的に変わりません。逆に、設定ファイルに型・インターフェース名を文字列として記載するのでタイプミスでエラーが発生してハマるリスクのほうが大きい気が...(昔S2Containerのdiconファイルの記述でハマった悪夢が蘇りました)

ただ、Release/Debug用に設定ファイルを分けることで、取得するインスタンスを切り替えることができますし、単体テストプロジェクトにも設定ファイルを作成して、リゾルバを設定することで引数付きコンストラクタもなくすことができると思います。(Project Silkではそこまでやっていませんでしたが)使うのであれば、プロダクションコード、テストプロジェクトまで徹底的に使わないと、使い方を覚えるコストをペイできないんじゃないかなぁ、と思いました。手放しで「素晴らしい!」とは言えませんでした。う~ん。

Unityの単純な使い方ではなくて、シナリオがあってUnityを使うとこんなに素晴らしくなるという説明を誰かブログに書いてくれないですかねぇ。自分は書けませんでした。

今回はUnityをテーマに書きました。作成したソースはSkyDriveにアップしてあります。「MvcHogeApp_v3」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

 

ASP.NET MVCのクラスの作り方を考えてみた(2)

前回のエントリーでざっくりしたクラス構成を作成しました、今回はそれに対する単体テストコードを作成します。

前回作ったASP.MVCのコードは以下の構成になっていました。

  • Controllerが呼び出すコーディネーター的な役割のWorkerServiceクラスを作成
  • DI(コンストラクタインジェクション)でインターフェースと実装を分離

今回単体テストを実装するにあたっての前提は以下のとおりです

  • 単体テストフレームワークはMSTestを使用します(Visual Studio 2012 Express for Webに同梱)
  • Mock用フレームワークはMoqを使用します

本当、ホビープログラマーがVisual Studioから単体テストを実行できる時代が来るとは思いませんでした。Visual Studio 2012 Expressには単体テスト機能が含まれています、Visual Web Developer 2010+Nunitで開発するなら、Visual Studio 2012 Express for Webを使いましょう。

まずはNugetを使ってソリューション作成時にあわせて作成したテストプロジェクトにパッケージをインストールします。

PM> Install-Package Moq
‘Moq 4.0.10827’ は既にインストールされています。
‘Moq 4.0.10827’ が MvcHogeApp.Tests に正常に追加されました。

まずはControllerのテスト(HogeControllerTest.cs)を作成します

[TestClass]

public class HogeConrtollerTest

{

    // Moqを使ったテスト

    [TestMethod]

    public void TestMethod1()

    {

        // mockの作成

        var Mock = new Mock<IHogeWorkerService>();

        Mock.Setup(m => m.MakeHoge()).Returns(new HogeViewModels

        {

            HogeId = 1,

            HogeName = "HogeHoge"

        });

 

        // アクションメソッドの呼び出し

        var Target = new HogeController(Mock.Object);

        var Result = Target.Index() as ViewResult;

        var ViewModel = Result.ViewData.Model as HogeViewModels;

 

        // assert

        Assert.AreEqual(1, ViewModel.HogeId);

        Assert.AreEqual("HogeHoge", ViewModel.HogeName);

    }

}

ServiceWorkerクラスは各種ビジネスロジッククラス、データアクセスクラスなどを呼び出します。そのため、単純にServiceWorkerクラスのメソッドを呼び出してしまうと、それら各種ビジネスロジッククラス、データアクセスクラスの都合に引っ張られてしまいます。簡単な例としては単体テストを実行する環境にデータベースが作成されていて、テーブルが作成されていて、テストの条件に必要なデータが全部揃っている必要があります。また、呼び出し先のクラスメソッドが実装されていて、そのクラスにはバグがない状態でなければServiceWorkerクラスのテストができません。ServiceWorkerクラスのバグなのか、呼び出し先のクラスのバグなのか切り分けが必要になってしまいます。

そのため、呼び出し先クラスのmockを作成して、テストされるクラスにとって都合のいい(テスト条件に合った)固定の戻り値を返すように設定します。この場合はHogeWorkerService.MakeHogeメソッドの戻り値HogeViewModelsが固定値になるようにします。そしてこのモックをテスト対象クラスのコンストラクタの引数に指定します。これが、前回DIを採用した理由です。

ネット上にあふれている単体テストの記事を見ていると、単体テストができそうな気がするかもしれません。ただ、クラスの呼び出しは階層化されており単体テストをしたいクラス・メソッドから呼び出しているメソッドの戻り値を考慮しなければならず、これが現実の単体テストを難しくしている、ハードルを高くしている原因だと思います。なので(自分の身の回りでは)、単体テストは行われていません、UIを操作して手動でテストしたほうがはるかに簡単と考えられています。しかし、MockとDIを採用することで現実的な難しさまでハードルを下げることができると思います。

そして、WorkerSeriveの単体テストコードはこのようになります。

[TestClass]

public class HogeWorkerServiceTest

{

    [TestMethod]

    public void TestMethod1()

    {

        // mockの作成

        var Mock = new Mock<IHogeDao>();

        Mock.Setup(m => m.GetHogeList()).Returns(

            new List<HogeModels>

            { new HogeModels { Id=1, HogeName="HogeHoge"}}

        );

 

        // メソッドの呼び出し

        var Target = new HogeWorkerService(Mock.Object);

        var Result = Target.MakeHoge();

 

        // assert

        Assert.AreEqual(1, Result.HogeId);

        Assert.AreEqual("HogeHoge", Result.HogeName);

    }

}

現実のクラスはMock作成時の戻り値設定はこんなに簡単には行かないでしょうが。それでも「単体テスト」といいつつ、階層的に呼び出しを行ってテストをすることに比べれははるかに簡単になると思います。

今回は単体テストをテーマに書きました。作成したソースはSkyDriveにアップしてあります。「MvcHogeApp_v2」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

次はUnityを使ったDependectyResolverについて書きたいですね。

// なんで単体テストクラスのテンプレートに

// using System.Collections.Generic;

// using System.Linq;

// が含まれていないんだろう?軽くはまりましたわ。単体テストクラスのテンプレートはかなりすっきりしたのに、ちょっと残念

ASP.NET MVCのクラスの作り方を考えてみた(1)

以前のエントリーで紹介した「プログラミングASP.NET MVC」を読んだこと、.NETラボ勉強会でMVVMの話を聞いたこともあって、ASP.NET MVCでどのようにクラスを作っていくのかを考えてみました。プロジェクトテンプレートにはControllerクラスしかありませんし、スキャフォールドで作成したコードはControllerが直接データアクセスクラスを呼び出しいているし。ネットには超単純なシナリオにしか(現実的にありえないような)対応出来ないコードだし。

ネットで公開されているようなコードはわかりやすく・単純化するために仕方がないと思います。確かに新機能の説明や「ASP.NET MCとは」という内容に200~300行書かれても読む気がなくなってしまいますから。しかし、patterns&practicesで公開されている「Project Silk」や「Project Liike」のコード、現実のアプリケーション開発のコードはそれらネット上のサンプルからの乖離(飛躍)が非常に大きく、サンプルと現実の溝を少しだけ埋めてみようかなと思った次第です。

一発で「こうだ」というコードが公開できるとは考えていないので、ブログを書きつつ、考えつつ、軌道修正していくので複数回のブログになると思います。あと、前もって断っておきますが書籍「プログラミング ASP.NET MVC」の内容の自分なりの理解内容を発言することになると思います。とくにオリジナリティはないと思います。

今回はControllerクラスの設計について考えてみました。具体的には、この3つのテーマです。

  • Controllerクラスには何を記述すべきか
  • クラス同士の依存性をいかにして弱くするか
  • MVCの「C」と「M」の境目はどこになるのか

Controllerクラスには何を記述すべきか

Controllerの責務はクライアントからHTTPリクエストを受け取って、HTTPレスポンスを返す(Viewを返す)ことです。それ以上でもそれ以下でもありません。建物の出入口に当たる部分になり、クライアントの都合に引っ張られる部分になります。そして、セッション管理などのWeb/HTTPに依存する処理は担当するものの、いわゆるビジネスロジックと呼ばれる部分はコントローラーには記述しません。その役目はModelの部分が担います。Modelはなるべくクライアントアーキテクチャーに依存しないように作成したほうが、汎用性/再利用性が増すため、Webというアーキテクチャーに依存する部分はControllerに記述すべきだと考えます。ViewはModelのことを知らないですし、ModelはViewのことを知らないわけですから、クライアントアーキテクチャーに依存する部分はControllerが担当するのは自然なことだと思います。

そしてControllerに対して1つのWorkerServiceと呼ばれるクラスを作成します。ControllerとWorkerServiceは1対1で紐付き、Controllerで受け取ったHTTPリクエストに対する処理を行います。Controllerから必ず1つのWorkerServiceを呼び出します。複数のControllerから共通のWorkerServiceを呼び出しても構いません。そして、WorkerServiceはコーディネーターとしての役割を担います、WorkerService自体にはいわゆるビジネスロジックは記載せずに、複数のビジネスロジッククラスを呼び出して処理を行います。そして処理結果をViewModelとしてControllerに返します。Controllerは自分が知っている1人のWorkerServiceに処理を委ねます、WorkerServiceは自分が知っている複数のビジネスロジッククラスを呼び出して、処理結果をViewModelとしてControllerに返します。ConrotollerはHTTPリクエストの受付、WorkerServiceはビジネスロジックの実行を受け付けます。

図にするとこうなります。

image

クラス同士の依存性をいかにして弱くするか

クラス同士の依存性を弱くすると何が嬉しいのか、何なんでしょうねぇ...一番のメリットはテストがしやすくなることです。コードを変更せずに依存するクラスを変更することができれば、Mockを使ったテストがやりやすくなります。それ以外のメリットは...すみませんよくわかりません。個人的な実装と実行の分離の現実界は、DI(Dependency Injection)の利用かなとおもいます。実装クラスにに対してインターフェースを用意し、コンストラクタで依存性を注入するやり方です(コンストラクタインジェクション)。

このやり方の最も現実的なところは、依存性の型情報をC#のコードとして記述できることです。DIコンテナとしてSearsarプロジェクトのS2Containerを利用したことがありますが、設定ファイルに文字列として型情報のマッピングを記載しています。個人的にはtypoまみれになるので設定ファイルの利用が嫌いです、マッピングを文字列ではなく型情報をとしてコードで記述できれば、インテリセンスが効きますしtypoをかなり防ぐことができます。設定ファイルにマッピング情報を記述してtypoでハマると悲惨ですよ...ハイ。なのでS2Cotainer.NETのQuillの考え方はすごく好きです。ASP.NET MVC+C#の考え方なら、設定ファイルでゴリゴリ書くよりもコードで書くほうが合うと思うんですよね。

あと、プロダクションコードではDI目的のインターフェースと実装クラスは1対1になるので同じファイルに書いてしまったほうがコードの見通しが良くなると思います。

Unityも確か設定ファイルにマッピン情報を記載したはずです。Project Silkのコードをしっかり読んでないとか、Unityについてほとんど調べてないです、すみません...

MVCの「C」と「M」の境目はどこになるのか

ControllerとServiceWorkerの話が出現すると、「C」と「M」の境目はどこなのか、ServiceWorkerは「C」なのか「M」なのかという話題になるかもしれません。個人的には

「(´・ω・`)知らんがな」

です。「C」と「M」って論理的な考え方なので、物理的なクラスがどちらに属するかを真剣に議論してもねぇ。論理的な考えに基づいてきちんとクラスの責務が決められていればいいと思うんですよ。敢えてどちらかと言えば「C」かと思います、ServiceWorker自体はビジネスロジッククラスの呼び出しを行なってViewModelを作っているだけなので、「C」なのかな、と。

そして出来上がったコードはこのようになりました

Controller

public class HogeController : Controller

{

    private IHogeWorkerService WorkerService;

 

    // 通常のコンストラクタ

    public HogeController()

    {

        WorkerService = new HogeWorkerService();

    }

 

    // DI(コンストラクタインジェクション)

    public HogeController(IHogeWorkerService workerService)

    {

        WorkerService = workerService;

    }

 

    // アクションメソッド

    public ActionResult Index()

    {

        // コントローラーはHTTPリクエストを受け取って

        // HTTPレスポンス(View)を返すのみ

        // Webに依存する部分(セッション管理など)のみを担当する

        // アクションフィルタでできることはアクションフィルタで済ませる

       

        // アプリケーションとしての処理はすべてWorkerServiceに委ねる

        // ViewModelの作成もWorkerServiceに任せる

        // 1つのアクションメソッドで1つのWorkerServiceの呼び出しを行う

 

        // コントローラーはこのようなすっきりとしたものになるはず

        var ViewModel = WorkerService.MakeHoge();

        return View(ViewModel);

    }

}

WorkerService

// DIのためのインターフェース、実装クラスと11なので同じファイルにしてしまってもいいと思う

public interface IHogeWorkerService

{

HogeViewModels MakeHoge();

}

 

// WorkerServiceクラス、コントローラーから処理を任される

// このクラスから各種ビジネスロジッククラスを呼び出して

// アプリケーションの仕様を実現する

public class HogeWorkerService : IHogeWorkerService

{

    private IHogeDao Dao;

 

    // 通常のコンストラクタ

    public HogeWorkerService()

    {

        Dao = new HogeDao();

    }

 

    // DI(コンストラクタインジェクション)コンストラクタ

    public HogeWorkerService(IHogeDao dao)

    {

        Dao = dao;

    }

 

    // コントローラーから呼び出されるメソッド

    public HogeViewModels MakeHoge()

    {

        // この例ではデータベースアクセスを行う処理だけを呼び出しているが

        // 現実はもっとたくさんのメソッド呼び出しを行うはず

        var Hoge = Dao.GetHogeList().First();

 

        // ViewModelの作成はこのクラスで担当する

        return new HogeViewModels

        {

        HogeId = Hoge.Id,

        HogeName = Hoge.HogeName

        };

    }

 }

Model(データアクセスクラスのみ)

// DIのためのインターフェース、実装クラスと11なので同じファイルにしてしまってもいいと思う

public interface IHogeDao

{

    IEnumerable<HogeModels> GetHogeList();

}

 

// データアクセスクラス 「XXXRepository」という名前にするのは違和感がある

// Models」ディレクトリでいいんだろうか...

public class HogeDao : IHogeDao

{

    public IEnumerable<HogeModels> GetHogeList()

    {

        using (var db = new MvcHogeAppContext())

        {

            return db.HogeModels.ToList();

        }

    }

}

作成したソース(ソリューション一式)はSkyDriveにアップしてあります、「MvcHogeApp」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

「プログラミングASP.NET MVC」読みました

4月のWindows Developer Daysで買った「プログラミングASP.NET MVC」をやっと読み終えました。自分自身に対して「今さらかよ」と突っ込みたくなりますが…素晴らしい本でした。

IMG_20120425_002027

本書の対象はASP.NET MVCの開発経験がある、または、サンプルソースを読んだことがあり、このフレームワークを利用してどのようにプログラムを記述するかを理解している人、さらに、包括的に、深くASP.NET MVCについて理解したい人だと思います。

「ASP.NET MVCとは」や「そもそもWebFormとは何が違うの?」についてはほぼ触れられていないため、初心者ではなく中級者がより理解を深めるために読む内容になっています。自分も個人的に簡単なアプリを作成したことがあり、(ちょっとサバを読むと)自称中級者なので、この本の対象としてはぴったりだったかもしれません。

本書の中で一貫して書かれていることは、ASP.NET MVCの柔軟性です。素の機能をだけを使用しても、これまでのASP.NET以上にアプリケーションが作りやすくなっていますが、それに加えてASP.NET MVCはほぼすべての要素が使いやすくカスタマイズすることができます。ビューエンジン、ルーティング、モデルバインダー、HTMLヘルパー、属性といったありとあらゆる要素に対して、カスタムモジュールを追加・標準モジュールを置き換えることができます。「第1部 ASP.NET MVCの基礎」では、標準機能の説明を行ったあとにあるシナリオにもとづいてカスタム機能をどのように実装するかについて触れています。

個人的に読んでいて興味を持ったのは、第2部(7章、8章)のコントローラーの設計の部分についてです。MVCの「C」部分にはどんな処理を書くべきか、その延長上にMVCの「M」とは何か、について記載があります。自分のようなレベルの低いエンジニアの書くプログラムは(しかもサンデープログラマーなので書く前にちゃんと設計しない)コントローラーに処理(ロジック)を記載してしまいます、で、Mの部分はデータアクセスのみ。ネット上に大量にあふれているサンプルコードもこのように書かれているケースが多いですが、サンプルのような超シンプルなシナリオだから破綻しないだけで、通常のシナリオではコードが破綻します。自分の経験上、比較的簡易なシナリオでもコントローラーに処理が満載になってしまって我に返ることがあります。コントローラーはHTTPリクエストの受付と、レスポンスの返却を行います、モデルバインダ経由で受け取ったViewModelをどう扱うかは、Modelに任せます。それがWebアプリケーションのMVCのパターンです。(たぶん)あまり長く書くとボロが出るので、この辺に興味がある方はこの本の7章、8章を読むといいと思います。キーワードとしては「ぜい肉のないコントローラー」「iPODDパターン」「ServiceLocatorモデル」でしょうか。

この本は現実にはありえないような超シンプルなシナリオではなく、より現実に即したシナリオにも適用できるべく記述されているため、読んだ内容が次々に頭に入ってくるというわけではありません。もともと中級者以上向けの内容に加えて、現実にありあり得るパターンに対応しようとすると、自分のCPU(脳みそ)では知恵熱が出てしまいます。わかったような…わからないような…中途半端な気分になります。

そして、ふとこんなつぶやきをしてしまいました。

image

image

すると意外に反応があって、この本の内容、もしくは中級者以上向けのフォローの場って需要があるんだなと感じました。読書会は定期的に複数回開催されるもののようなので難しいですが、自分も中級者以上向けの勉強会というかイベントには参加してみたいです。

ということでこんな内容を聞いてみたいと妄想してみました。他の方のブログやプレゼンテーションを引用させていただいています、問題がある場合はTwitter(@david9142)または、ブログのコメントで連絡ください。

タイトルは

「ぼく/わたしのかんがえたさいきょうのえーえすぴーどっとねっとえむぶいしー」

初心者は完全に置き去り、中級者に対してLevel5の方たちが「オラオラ!! オレのテールに食らいついてこい!!!」と煽る場にしたいですね。そんなドMなLevel2,3なエンジニアが集まる場にしたいです。個人的に聞いてみたい話は以下のブログ・プレゼンテーションの内容です、しかも、上級者向けにカスタマイズされたものを。

MVCの「M」と「C」とは

年末だからこそ ASP.NET MVC のモデルの作り方について考えてみる (@shibayanさん)

ぜい肉のないコントローラ をめざそう! (@miso_soup3さん)

Patterns&Practice

Project Liike: モダン モバイル Web アプリ開発ガイダンス&サンプルコード公開です! (@chack411さん)

モダン ブラウザのためのクライアント サイド Web 開発ガイダンス ~ Project Silk リリース (@chack411さん)

単体テスト

基礎から見直す ASP.NET MVC の単体テスト自動化方法 (@normalian さん)

オープンソース

ASP.NET Open Sourcing Discussion with Scott Hanselman (@shanselman)

 

自分の知り得る情報は限られたものなので、ASP.NET MVC界はもっともっと有名な方がいらっしゃるのかもしれません。自分の言いたかったことは、この本をきっかけに

「わたしの戦闘力は530000です」

という人達(MS社員も含む)の全力のプレゼンテーションを聞いてみたいなぁ、という個人的な好奇心が生まれました。こういう場を設けるためには何をやったらいいんでしょうか?「自分はこんな内容を聞いてみたい」という意見が色々とあると思います。Twitterは苦手なので、ブログで会話しませんか?「ぼく/わたしのかんがえたさいきょうのえーえすぴーどっとねっとえむぶいしー」というタイトルで、このブログエントリー・プレゼンテーションの全力のを聞いてみたい、という内容をブログで書きましょう。で、書いたら #aspnetjp のハッシュタグをつけて、ブログ書きましたとつぶやいてみるのはどうでしょうか。きっと誰かが…こういう場を設けてくれるはず…何とかしてこういう場を設けたいです、はい、本気です。

Go Azure 2日目に参加しました

Go Azure2日目に参加しました。1日目についてはこちらを。

2日目はJapan Windows Azure User Group (JAZ)が中心となったコミュニティのセッションやハンズオンセミナーが行われました。自分は金曜日のマイクロソフトのセッションよりも、土曜日のセッションを楽しみにして来ました。初日よりも参加人数が少なかったですね、平日にマイクロソフトの社員の話を聞くことを目的とした人が多かったんでしょうか。スーツで参加した人が多かった(ほとんど)でしたし。

キーノートは初日の振り返り。Blobストレージにhtml+jsのような静的なファイルを置いて究極のスケールサイトが作れるという話が印象に残りました。確かにBlobストレージはHTTPでアクセスできるので可能ですよね。

午後からはずっと「クラウド開発トラック」部屋に閉じ篭ってました。

TFS on Azure で始めるイマドキのソフトウェア開発

TFSの歴史とAzure上のTeam Foundationのお話です。TFSの適用範囲の拡大、クラウド上にTFSがあることのメリットの説明。そして開発プロセス、ソフトウェア開発の目的の重要性のお話でした。

この5年で開発を支援するツールはプロセスとともに大幅に進化しました、ただ人間はそんなに進化してません(自分の見える範囲では)。

  • 計画は作ってみるものの、やってみなければそれができるかどうかわかりません。
  • やってみたらできませんでした、計画をどう変更していいかわかりません。
  • 計画を変更してみたものの、それができるかどうかはやってみなければわかりません。
  • 計画を立ててみたものの、絶対にこんな計画ではうまくいきません。
  • 計画通りにはいっていないけど、やるしかない!

とか

  • この技術やったことないので、できません
  • やり始めてみたものの、どうやったらうまく行くのかわかりません
  • なんかよくわからないけど、サンプルをコピったら動きました
  • なんかよくわからないけど、変えてみたら動かなくなった
  • 何にも変えてないんですけど(本当は何か変更してる)、なぜか動かなくなった

とかとか。そんなことを考えたらネガティブな気分になってしまいました。ツールもプロセスも進化してるんですけど、人間が進化してないのでその進化に対応ができないんですよね。プロジェクトに10人いたら、1人はプロセスの適用方法であったり、ツールの運用であったり開発技術に追随できているでしょうが、残りの9人はどう計画を立てたらいいのか、どう開発をしたらいいのかわからない有象無象の人の印象です。(自分の周りは)

ツール・プロセスの進化を啓蒙することは非常に重要ですし、進化させることは非常に重要なんですが、現場は「計画通りでなくても、プロセスに則っていなくても動く・納品可能なソフトウェアをとにかくつくること」「実際はプロセスに則っていなくても、プロセスに則っていることを証明するためのエビデンスを作成する」ことに力を注いでいます。何とももどかしいです。TFSとかScrumとかは都市伝説じゃないか(現実にはツールを使ってScrumを適用している現場なんて存在しないんじゃないか)と思ったりしてしまいます。

すいません、ネガティブになりすぎたのでここらで終わらせます。ツールやプロセスの進化に追随できる人間になりたいです、はい。

One ASP.NET – ASP.NET Web Stack

一人のファンとして「キャー! シバヤンサーン!!」という気分でした。こういう方にはオーディエンズを置き去りにするようなセッションをやってほしいですよね。

「オラ!オレのテールに食らいついてこい!!」

ってやつを。「ASP.NET WebFormとは」とか「ASP.NET MVC とは」とか「SignalRとは」をお話させるのはもったいないです。そんなことは全部知っている前提で、技術的にもっともっともっともっと尖った話が聞きたいです。ブログを読んでいるとそういったことを知っている方なので。そういった場を作りたいですね。

懇親会でお会いすることができました、やっぱり「あ、あのクラウディアを嫁っていってる人」と思われてました…間違ってはいませんが。

AWS のクラウド デザイン パターンを Windows Azure に持ってきてみた

Windows Azureを使用したクラウドデザインパターンの適用方法のお話。1イベントのプレゼンテーションとしてSlideShareに公開するだけじゃなくて、JAZのコンテンツとしてサイトに公開してもいいんじゃないでしょうか。もっと検索エンジンから探しやすく、アクセスしやすい形にして残して欲しいなぁと思いました。大変な作業だと思いますが、それだけの価値があると思います。

クラウド上のデザインの話は断片的にブログなどで紹介されてる方もいらっしゃいますが、これだけ体系的にまとめられている資料はもっともっと多くの人の目に触れられるようになってほしいです。

ネットワーキングパーティー

転職活動とか、他のコミュニティでお会いした方と少々ですが声を書けることができました。2~3回「クラウディアの方ですよね?」と声をかけられましたが、「あ…はい…」とつれない返事をして3次元の名前を名乗らずにごめんなさい。あと、ムッシュさんと同世代だったことが新しい発見でした。

最後に、きちんとミッションをコンプリートしました。

Experience of Windows Azure is priceless(1)

DVC00012

Experience of Windows Azure is priceless(2)

DVC00013

このイベントの準備・当日の運営に関わった方、本当にお疲れ様でした&ありがとうございました。自分はブログ書くことと写真撮って(・∀・)ニヤニヤすることしか出来ませんが、本当に勉強になりましたし、楽しかったです。