Alexander Beletsky's Development Blog

I've been using Git about a year now, immediately after creation my github account. I got really nice impression of using this tool, but still - on my primary job at e-conomic we are using SVN as primary VCS tool.

You are probably aware about all good thing with Git. If you still don't you might check out these great answers on Stackoverflow. In short - Git adds benefits, but it adds complexity as well.

After a bit evaluation I found that those benefits are worth to stop using SVN and switch to Git. But, if you ask your colleagues "Are you ready to go with Git?" you would probably hear "No!". It is clear why, people are getting used to current tools.. infrastructure are build around them. And switching from one VCS to another seemed as destruction of building fundament for many developers.

Fortunately, Git has a killer feature that other DVCS does not have! And this feature will help you to smoothly start with Git even if your company is still using SVN as standard. Yes, I'm talking about git-svn.

Believe me, it is amazing! I always have a little distrust for such kind of integration tool, but so far it works as charm. So, I'll give you a small instructions that will make you possible to get to your office tomorrow and start use Git as your own VCS.

Setup you environment

• Download and install msysgit
• Setup local user information, example

      git config --global user.name “alexander.beletsky”
      git config --global user.email “alexander.beletsky@gmail.com”
  

• If you are on Windows and doing only-Windows development, it is recommended to turn off autocrlf

      git config core.autocrlf false
  

Checking out code from SVN repository

• Run git clone command (it might take some time, depending on repository and history size)

      git svn clone https://mysvnserver/repo 
  

As clone finished, you will see that new folder repo created with the content of your SVN repository. Now, this folder is actually Git repository + you local sources copy. Try to run git log inside the repository and you will see that all your history are there!

Let's do some work

Now, suppose you start to work on some bugfix. By default, git repository contains one branch called master. Good style is do not do direct commits into master at all, just keep it as synchronization point between SVN repository and your local repository. So, to do actual job you to create branch.

    git checkout -b bugfix-id-1453

This command will create new branch called bugfix-id-1453 and immediately switch to it. If you haven't noticed how that happened - please welcome to git's high performance world.

You changed some file and ready to commit. In git it's a 2 steps operation. First, you need to put content to stage.. second, you store the content in new commit object.

    git add .
    git commit -m "issue has been fixed"

Commit changes back to SVN

You've fixed a bug and now fixed is placed in bugfix-id-1453. But you should give it back to rest of the world.

Checkout your master branch:

    git checkout master

Get the latest changes from SVN:

    git svn rebase

Now SVN server and local master branch are identical. We have to merge our fix into master:

    git merge bugfix-id-1453

Now master contains previous SVN state + new fix. We have to synchronize local repository and SVN server:

    git svn dcommit

Conclusions

Git-svn is perfect tool to start using git without radical changes in organization. It gives everybody change to try it out, how much it really fits your needs. I'm having a big pleasure now of working with Git. I'm not saying it's ideal smooth process, sure I met some difficulties. But for me those difficulties are nothing comparing the benefits I'm getting with it.

I'm really inspired with cloud ideas since I first time met it. No doubt, that clouds are future of computing. I like the metaphor comparing cloud and electric power plant: "Last century if you plan your business depend on electricity, you have to afford huge and expensive electric generator - you have to host it, support it and do all maintenance stuff by yourself. You pay for everything by yourself, just to be able to plug one device. Then power plant come and electric wires covered a country, you no longer need your own electric generator, you can buy the electricity from power plant station. You pay only for that you used and it is much cheeper, since a lot of people using it together with you". Clouds are modern power plants - to be online you no longer need to buy servers, establish a data center, maintenance all infrastructure. You could by the resources from cloud services provider.

Clouds are about to change the business. It is much more easy to start-up new product in web, since you have to care only about product, not infrastructure. I knew some companies in past with quite good ideas, but those ideas buried under infrastructure complexity and expensiveness. And the clouds are about to solve that problem, microISV should be happy about.

I was thinking about all my current and future products are going to in cloud for sure. First and obvious point to look was Microsoft Azure. But after some elaboration I disappointed a bit:

1. Azure is overcomplicated. I'm not saying I'm not able to understand that.. But all those Roles, Processes, Blobs - it is just too much details. But what I basically waht is to place my existing working product into elastic space, that's it.
2. It is still expensive. This Azure price calculator, my simplest configuration would be ~50 USD/month. This is more than I currently pay for VPS.

So, I saw not enough reasons to switch immediately.

Yesterday, I've been contacted by Host1Plus company. They started out beta cloud in the new datacenter which is located in Frankfurt Main, Germany. And they are looking for beta testers of new service. The proposition looks really fine to me, since I could try the power of clouds and in the same time help a company with a feedback I could provide.

I'm going to join. If it is interesting for you, join with me. Here is some links that could be helpful:

• http://www.host1plus.com/press/beta-cloud-vps-will-be-launched-by-host1plus/ press release about it
• http://www.host1plus.com/beta-invitations/ mailing list for all the beta testers who wants to join the campaign
• http://www.host1plus.com/forum/ the community forum where all beta testers can join to start the discussions

Last time we explored a way of HTTP request from the IIS up to MvcHanlder. Then UrlRouting module match URL we registered in Application_Start(), it gets corresponding IRouteHandler class and calls for GetHttpHandler method. In ASP.NET MVC URL IRouteHandler interface is implemented by MvcRouteHandler class which return MvcHanlder instance. The actual MVC story begins exactly in MvcHanlder internals.

Generic overview

We know that HttpHandlers are special objects that handles requests and produce a response. MvcHanlder produce nothing by itself. Instead, it uses ControllerBuilder object for creating Controller and call controller Execute method. It is Execute method responsibility to find corresponding action, call action and wrap action return result it HTTP response.

As you can see, it implements 3 interfaces: IHttpHandler, IHttpAsyncHandler and IRequiresSessionState. The handler could operate in 2 modes: sync and async, depending on caller. ASP.NET frameworks ProcessRequestInternal method try to utilize asynchronous mode of work first.

The constructor of MvcHanlder receives RequestContext class, that is part of System.Web.Routing and contains information about HttpContext.

Synchronous and Asynchronous modes

Of course, the details of operation in synchronous and asynchronous modes are differ from each other, but main algorithm of work is exactly the same.. Let's first see how it operates in sync mode.

Process the request

Due to IHttpHandler interface, MvcHanlder expected to support one property and one method:

IsReusable is always false, meaning that for each request the runtime would create new instance of handler. ProcessRequest receives HttpContext and basically delegates call to internal ProcessRequest method.

Notice to the first line.. HttpContext is being wrapped with HttpContextWrapper and casted to HttpContexBase. Rest of code never (mostly) using HttpContext directly, but through HttpContexBase. The HttpContexBase have been introduced to improve testability of ASP.NET applications, since HttpContext is unable to be mocked.

ControllerBuilder, ControllerFactory, Controller

Let's see inside the ProcessRequest method to see how exactly the controller is being constructed and called.

The call is wrapped with a little security handler, that would do perform the check for Trust settings, before calling internal action. Inside the action IController and IControllerFactory are being declared and initialized in ProcessRequestInit method.

First, it puts MVC version information into HTTP response header, removes optional parameters from routes (one we mark with UrlParameter.Optional) and gets the name of controller from RequestContext. Remember, in global.asax we define URL pattern like "{controller}/{action}/{index}", so in case of such URL products/search/122 the GetRequiredString will return "products".

ControllerBuilder is a singleton and factory method that creates IControllerFactory instance.

ControllerFactory is responsible for creation of controller by given name.

The ProcessRequestInit gets the factory from ControllerBuilder, ask factory to create controller by the name from URL and returns results back to ProcessRequest.

Here we also could see good example of comments that lies.. "// Instantiate the controller and call Execute" - maybe sometime ago that was true, but not its false since Execute is not called here.

Execution

As soon as controller factory and controller are successfully created, ProcessRequest calls for controller Execute method. Now, it is controller responsibility to produce the output and we will see how it does that in next "Inside MVC" posts. Execution is wrapped inside try / finally block and finalize code will release the controller by calling ReleaseContoller method of factory.

Meanwhile in Asynchronous...

In async world the things are bit more complex. There are no one single method, but 2 instead. BeginProcessRequest and EndProcessRequest.

The request initialization and creation of factory and controller is exactly the same. The difference in execution, for async controller 2 delegates are being created,

In fact, that than the request execution begins, beginDelegate is called that would call BeginExecute of the controller. At the end of request endDelegate called that would call EndExecute of controller.

What about tests?

That was a great surprise to me that MvcHandler is well unit tested. All aspects of its work are covered with corresponding tests.. I've heard a lot of developers complains like, "oh, it is so low-level code.. could not test it". But MVC team, proof it is wrong. HttpContexBase could be easy mocked, so no excuse of not writing unit tests for modules/handlers. As I said in into, test code is really clean, following AAA principle's, so I got a lot of pleasure of looking inside.

BTW, they are using Moq framework for mocking, that I personally like as well :).

Previous: Inside ASP.NET MVC: Route to MvcHandler Next: Inside ASP.NET MVC: ControllerBuilder class

Here is quick description of application application I made on Hackatone this weekend.

Candidate.net is just working name for the project that I'm going to change as soon as I got better idea :). It supposed to be a kind of service that provides integration with your github repositories and provides a Continues Deployment cycle for that repositories. Namely, every code change that being pushed to github is immediately build, tested and deployed, so the time between code push and production is very short excludes any manual work.

I've spent ~16 hours for building up this application, sure I haven't managed to make it as a service.. but - during the process I've changed my vision for project, so first I would like to create good continues build engine (like Team City or Jenkins) and base my future service on top of it (yeah, I already got some further plans :).

Technologies behind:

• ASP.NET MVC3
• jQuery + some small pluggins
• UppercuT build framework

A picture says 1000 words, so here my little screencast of Candidate.net in action. It demonstrates the ability of setting up new application and hooking github push requests to build new application instance.

Source code is hosted on github https://github.com/alexanderbeletsky/candidate. Don't forget it is really early prototype, the code is in big mess now.. I'm going to improve it much soon, so please keep watching repository.

I had a lot of fun of building this and have a better vision of how the application should look like. Hope to share it soon. I would be happy to hear some feedback on this.. and of cause you are free to fork repo and make your improvement (especially in UI/UX :).

This weekend I've been visiting very interesting event - Hackatone that took place in Ciklum office. Hackatone is whole night hacking session there every team or person could came up with any idea, implement it and present to crowd. Many times I heard about similar events either in podcasts or blogs that I read.. but never tried that myself. Thank's for DOU enthusiasts I got opportunity to try that. Here is my report of that event. There would be some mix of English and Russian language, hope that would not make you confuse :)

The event began with common meeting there people were sharing ideas of applications they are going to build. During my pretty long journey with in Continues Production I already got my idea - I wanted to build Deployment-as-Service product that easily integrated with github and utilizes power of UppercuT for building .NET web applications. There was very few .NET developers there, already having their own ideas to build.. so I went alone.

If you have been to Ciklum office, you probably know what SkyPoint is.. It is 20-th floor in office that resides on one Kiev's hills, so you might imagine this exceptional view from there. I grabbed a chair started to work.

Due to experience I got with .NET deployments and Jenkins I had pretty much well understanding what the workflow should be. I've created ASP.NET MVC3 in my Visual Studio and stared to develop. The scope of work I planned to do was pretty much big and I a little nervous about my ability to finish everything. I tried to work as fast as I can.. Full hour, that 10 minutes break and full hour again. Maybe because of that creative atmosphere around or straight orientation on final result but I think I really got a Flow..

So, after ~3 hour of work I've created my github repository for new project - Candidate.net:

Keeping that rhythm I continued to work mostly till 3.00 AM.. About 60% of work were done. I felt a little tired and decided to stop for today and had a good sleep to continue tomorrow. My plans were ruined as soon as I stepped to 19th there people gathered together.. So, in 5 minutes I got several shots of cognac and was sitting on a floor with guitar in my hands :). I had a real fun and relax there. Haven't noticed at all how 2 hours are gone and sun started to rise.. We had a really nice moment of meeting new day on staying on office balcony.

I have to continue the implementation, so I went back to SkyPoint and run my Visual Studio again. Of cause I could not get such rhythm as I got yesterday, the process were much slower. I had to refuse of several more ideas I wanted to build, ignore the rules of Clean Code, SOLID and DRY. Did some ugly tricks, just to make application work. I had issues with testing and deployment since WiFi connection were quite slow. But, long story short - I implemented very basic workflow and realized that would be it for presentation.

I found a sofa and finally got a change to have a sleep. Don't know why but I managed to sleep only for one hour, just woke up and could not sleep again. So, I had a shower (yes, there are showers in Ciklum office), coffee.. and very nice breakfast. I had some time before presentation began, so I re-tested my application several times more and was happy about results.

At 15.00 PM presentations began! I showed Candidate.net ability to initialize new application, build and deploy it in minutes.. How you can deliver with just a push a code to github, the rest of job done by Candidate. I don't think I really impress people there, because of .NET crowd were to small.. but I tried to do best. After the presentation I've been contacted by several guys who interested with such concept.

Most of the presented projects were either old-school games implemented with new technologies or mobile applications. One guys did a nice linux kernel exploration and share his ideas.

After there was a manual voting for each project to decide on 3 best, I didn't win :). Winners got their congratulations and presents for sponsors. I quit really quickly since I was a little late for my friend wedding that was that day :)

That was really nice experience for me. I appreciate Ciklum, DOU and everyone involved, who make that possible. Thank you guys :)

In my previous post I promised to start with exploration of MvcHanlder as entry point of ASP.NET MVC application. MvcHandler plays the major role in MVC infrastructure, but as I fugured out - the whole story does not begin there. The story is actually begins inside ASP.NET framework.

ASP.NET framework

ASP.NET framework is heart of ASP.NET MVC application. Basically, ASP.NET is a request processing engine. It takes incoming request as input and sends it through internal pipeline till the end point. The architecture allows extensibility, you could plug either into pipeline (modules) or end points (handlers). Interesting fact that ASP.NET designed to be decoupled from actual request source. So, the source of request could be any application - IIS, Cassini or any custom one.

We could imagine that each request pass through the set of filters (internal pipeline) lands up on request handler (end point), request handler creates a response object and sent it back. There are a lot of hidden details of dealing with managed/unmanaged code that you could find in this brilliant article by Rick Strahl.

For us it is important to understand two basic abstractions, HttpModules and HttpHandlers.

HttpModules and HttpHandlers

From the developers point of view the difference between those are: one implements IHttpModule interface another implements IHttpHandler interface.

Module participates in the request processing of every request in order to change or add to it in some way.

Handler is responsible for handling the request and producing the response for specific content types.

ASP.NET MVC is HttpHandler.

There a bunch of default HttpModules and HttpHandlers in your IIS configuration. Just take a look here - %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\Config\web.config.

But if you look closer you won't notice any mention of System.Web.Mvc.MvcHanlder. Hey. what's wrong? How the runtime actually knows that MvcHanler have to be called to handle our request? That was absolutely unclear to me at very beginning.

From request to handler

I opened WebRuntime.sln and found all references to MvcHandler. It is only one place there, in the MvcRouteHandler (MvcRouteHandler.cs) class. MvcRouteHandler implements IRouteHandler interface, with one single method GetHttpHandler. I put the breakpoint there and started application for debug.

As application got started I halted on breakpoint with such call stack:

Let's try to read and decrypt it.

It begins with WebDev.WebHost40.dll (Cassini Web Server) that receives request and System.Web.HttpRuntime.ProcessRequest. Here is ASP.NET framework start to work:

1. ProcessRequestInternal method called. This is the primary method of whole pipeline. First, it initialize the HttpContext object.

2. Next it get HttpApplication instance, initialize it and calls either BeginProcessRequest for IHttpAsyncHandler or ProcessReques for IHttpHandler.

3. If I go to global.asax.cs of our application it is clear that System.Web.HttpApplication implementation is inherited and System.Web.HttpApplication is a usual IHttpAsyncHandler. So, async BeginProcessRequest starts.

4. In BeginProcessRequest there is a cycle that iterates all modules and execute each of it. Reflector code looks messy, but the point is clear

5. And finally, the control goes to UrlRoutingModule that calls our factory method for MvcHandler. Aha!

UrlRouting module

UrlRouting is an HttpModule, registered in global web.config:

The goal of this module is basically matching incoming request by URL with pre-defined Route configuration and return corresponding handler for this request. In PostResolveRequestCache method it gets the RouteHandler and asks for corresponding HttpHanlder.

Wow, I didn't know that!.. UrlRouting plays a major role inside the MVC infrastructure. But there the Routes are initialized and how MvcRouteHandler is associated with request?

Back to roots - Application_Start() method

I should actually start from here, Application_Start() is entry point of application. By my journey turn to be just other way around.

Inside the RegisterRoutes we register route by giving: route name and constraints.

The MapRoute is actually extension method in RouteCollectionExtensions.cs.

Now, you can see how the route with particular URL is being register and associated with MvcRouteHandler.

Putting it all together

Now it is time to get deep breath and finally understand the route of HTTP request to MvcHttpHandler. Here we go:

• ASP.NET framework starting to process incoming request in ProcessRequest method, but interesting stuff going in ProcessRequestInternal
• ProcessRequestInternal calls GetApplicationInstance method that get application instance and calls it Application_Init()
• Application_Init() registers routes that map URL (like "home/index") with MvcRouteHandler instance
• ASP.NET framework starts to iterate modules for incoming request and found UrlRouting module
• UrlRouting module matches incoming request URL with registered collections of Routes
• For found matched Route it gets corresponding route handler (MvcRouteHandler)
• MvcHandler is being returned by GetHttpHandler of MvcRouteHandler

That's the routing that is being executed each time you put URL and hit your browser button.

What's next?

I hope next time we indeed look closer to MvcHandler :).

Previous: Inside ASP.NET MVC: Part 2: Setting up project for hacking Next: Inside ASP.NET MVC: All begins here - MvcHanlder