Monday, March 14, 2011

I'll say it up front, I'm tired of using Web Forms :) I'm a professional web architect (it sounds huge, no it's not. I just do that for a living) and I personally think that it's a counter intuitive framework to deal with. I can't do MVC often since nobody around me is using it (I'm not mad at that fact by the way). But it's a shift I'd like we do, and why we should do it is the main goal of this article.

Introduction

Hi,

From my experience, I've witnessed some changes in web development since year 2K. This article will essentially focus on the history of the Web Forms framework and its key aspects while comparing them with MVC. So instead of promoting MVC, I'll show you why Web Forms is bad for your health. After that, you'll go wherever you want! I will also put some code sometimes to show you the differences between the two but don't expect a feature by feature comparison, there's plenty of web sites on the topic.

Web Forms

The Beginning

Let's talk about the beginning of Web Forms and the .NET era. The ASP.NET Web Forms framework was released in January 2002. I built my first web page 7-8 years before that in notepad. I was also building web sites professionally for 2 years at that time.

To my knowledge, it was the first serious object oriented framework (again, to my knowledge). So it was quite interesting and also a big thing. The community desperately needed a true widespread object-oriented framework. The Microsoft IDE was also great since they had enormous experience in that field (with MS VC++ or VB). It was well received by the developers and well adopted. I was thrilled myself and I used it for 3 or 4 years and I'm still using it today (see introduction).

The Problem

Maybe the problem with Web Forms was actually from the experience the Microsoft Web Forms team had previously with other programming frameworks. I did a Microsoft VC++ certification a while back and this is the thing that got me thinking about the flaws of Web Forms. The certification was about creating Windows desktop applications. It was about creating forms with buttons and putting labels in the form and such, rings a bell?

That's right, all in all, the biggest error Microsoft did was to try to encapsulate web sites programming into desktop applications programming. Again that's my personal point of view but... a colleague of mine told me the exact same thing about Web Forms not too long ago while I was writing this. Funny coincidence! What's even more funny, is that the guy didn't knew until recently how to send a regular mail envelope, with a real stamp! So, huh humm, basically anyone can agree on that point! (I'm messing with you colleague ;))

Smoke and Mirrors

So we've been doing web sites for 9+ years now with something that tries to make it like it's desktop application development. But how they did it? How it works? Let's see some basic Web Forms "features" that makes it possible:

View State

The biggest difference between desktop applications and web applications is the notion of state. In desktop applications the application is in memory on the client's computer. You can set variables and retrieve them at will. You can click a button and everything else on the form stays like it was before because it is in memory. Well, you get the general idea.

In web development, there's practically no state. You navigate to a page, the previous one is gone. This is because the HTTP protocol is all about (almost) anonymous requests and responses. To overcome this problem (reliably tracking a client), servers implement what is generally called a session: a cookie that travels back and forth between the client and the server so that the server can uniquely identify a returning client. The server can then keep some data associated to each of its clients on its side (according to the application's needs and only for a certain amount of time). Well, the View State isn't like that at all. Even if the session could bring state to the table.

So why all the explaining? Sure the session can bring a sense of state between the client and the server. But the View State implemented another mechanism to keep the state between the client and the server. An example of a state-keeping web page would be like: if I click on a button to submit a page, I want the text boxes in that page to retain their values after the click (just like in a Windows application). After all, their values should be gone since it's a brand new request and a brand new response. It would have worked with the session (details skipped) but maybe the things we wanted to keep track in it would be too big. The server would have to store all sorts of data in the session and it would have taken servers down (remember, session is stored on the server). So they said to themselves: "okay we want to mimic a desktop application, we want a notion of state across page submissions. We can't store that state on the server, what can we do?". They decided to move that state on the client (in the resulting web page sent to the client). That's right, all the things the page want to keep track of is sent to the server, then the server sends it back along the response to the client. The View State is born. The View State acts as the "local memory" of the web application (as the local memory in the desktop applications) and is hosted in the web page client side, hidden from the presentation. In other words, the state is implemented as a ping pong game, the ball being the View State.

Normally, with some existing frameworks back in the days you would have to mimic the mechanic yourself according to your needs. It was pretty cool to see it working out of the box at first I have to admin.

Controls

The next thing Microsoft did to, again, makes you believe you're doing desktop application development was to create "server side" controls. Just like in desktop application development, in Web Forms you have labels, text boxes, panels, buttons, etc. They work hand in hand with the View State to initialize and render themselves and such. You place them in in the web page just like controls in a form. In the code behind you can manipulate the behavior, style, content, events, etc... of the controls. This is a two edged swords but I'll talk about it later.

Page Life Cycle

When you say buttons, you say events. In desktop applications you have events: when the forms loads, when a button is clicked, when it is destroyed, etc. The page life cycle takes care of everything regarding events in Web Forms and acts as the same thing in a web application.

So there you have it (basically), the smoke and mirrors of Web Forms. There's plenty of other things in Web Forms that makes it what it is, but I'm focusing on its building blocks here and already it's more than enough to understand how bad it is.

How Web Forms Swims Against the Wave

Well what's bad about trying to make things easier? Making things easy for developers!? Sure it's easy! I can tell you myself it's viable. For simple examples you find on the Internet that's fine! It's stops there. Why? Because having those things around (View State, Controls, Page Life Cycle, etc), it comes at a price. A price I'm not willing to pay and I'm not even talking about performance here but learning curve and productivity. Also because the roots of Web Form are based on complicated things not meant for the problems they are trying to solve. Sure the examples in your books are working perfectly, simply because they're showing you mimics of some desktop applications. Not professional modern web applications. Let's go through the previous list to see how they just don't work in a professional grade web application.

View State

First, the View State can be huge. It is transferred between the client and the server on every form submission (every so-called event) so your application consumes more traffic. It is not compressible by http compression since it is composed of random-like characters. It can become corrupt between the client and the server (Validation of viewstate MAC failed remember?). Since the View State constantly travels between the client and the server it must be secured. We don't want a client nor a man in the middle to forge a View State. So there's more and more considerations and things involved. More and more complexity. You also have to keep that in mind with Web Farms or when you're doing load balancing without affinity: what if a page request is made on a server and its submission lands on another? The submission won't be allowed because the View State security involved between the client and the server wasn't initiated by the second server. Sure it's configurable, but you said it, you have to configure it!

Another thing. To make View State possible, your page must also have one and only one form tag that wraps the whole body of your document. Because any "post-back" (button click, pager click, drop-down changed) can trigger a form post to the server (and the controls can be anywhere in the page and we want to keep the state of each and everyone of them), a form must wrap them all. What if I want to have a separate form? What if I'm doing a mobile version of my web site that doesn't use JavaScript. You're stuck on using Web Forms compatible components and following the mold.

Controls

As I said, there's plenty of controls in Web Forms. The problem is that there's never a 1-to-1 association between a Web Forms control and an HTML element. You understand why: they're meant to be controls for a desktop application. Let's look at an example:

There's some confusion here right? Let's take a look also as the asp:Label control. The asp:Label tag will translates into a span HTML element when rendered on the page. But if you set its AssociatedControlId attribute, it becomes a label HTML element!

Now let suppose I'm at the beginning of my career, I've studied hard to do some HTML and CSS, and then I open my first project at my brand new job and I see that. I would probably think that either my course was a complete rip off or, that the industry moves so fast that walking wasn't fast enough to get to the job that morning. Seriously, you immediately ask yourself those questions: How can I put inline styles, how does the server control translates to the client control? What's the CssClass property, aren't we using the class property? Should I put the runat attribute on everything? I'm confused! Well, me too.

In the end, the problem is that they never thought you would have to look at the resulting page source AND they never thought that someone else besides you (a developer) would have to take a look at the HTML source code (.aspx). But guess what, you're not alone to play in this project and your co-workers are certainly not always Web Forms developers (not even .NET developers). Nevertheless, we all have a thing in common: we know HTML.

Architecture

Before we wrap up about Web Forms and start talking about MVC, there's one last thing I want to point out, it's how Web Forms behaves on architecture. A good architect will finds its way in any framework, let me clarify that. But I feel that Web Forms encourages by nature a bad architecture. I think that it starts with the user controls: You can manipulate them client-side AND server side. It creates an open bridge between 2 of the 3-tiers of your application (presentation and business). You can change the CSS of a control from within the code behind. You can register a script from the code behind. When you do that kind of stuff it's like taking a sheet of paper and folding the first tier onto the second. If by any chance the 3rd tier is tightly coupled with the 2nd, everything folds into a big paper ball ready for the trash can... I meant the recycle bin of course (yeah I'm green).

Verdict

Web Forms is a framework designed for an elite group of highly qualified professional web developers. You heard me. As I said earlier, you rarely do the simple examples you find in books right? So now you do something serious but you will always encounter a problem. Always, if you're not a well trained and highly qualified Web Forms developer as I said. Not problems related to HTML/JavaScript, the HTTP protocol, but the framework itself: how do I do that? how can I bypass that? why does I have this result? Why I have this meaningless error message? In what page event I should put this? How can I track this JavaScript error generated by the library? Why? How? Please kill me? I'm sure you have your load of examples.

Like I said, not every web developers, webmasters, HTML integrators knows Web Forms (and for some they shouldn't have to), but we all have a thing in common: we know HTML. Let's take this hypothetical scenario for a fairly beginner web developer that decides to use Web Forms: First you have to read your 800 pages brick. This is not enough you have to read articles each time you encounter a problem. One requirement of the application needs a custom control because it doesn't exist in .NET and is fairly wicked. You have to hack a little your control and have to learn JavaScript because it does some animations client side. You have problems with the generated client IDs. You also realize that the HTML generated from a component in the control enters in conflict with the CSS provided by the HTML integrators (they did it first on a plain HMTL page). Now that everything looks good some values doesn't show up on Postbacks. You read articles on custom controls. Your Postback finally works but your manipulations server side doesn't seems to be taken in account unless you refresh a second time the page. You read your book again regarding Page Events.

At the bloody end, you realize that you've spent most of you time fighting against the freaking framework and not on focusing on your goals. Let's take it from the start again, pens in hand. Web Forms tells you: "hey, we're so cool you won't have to do HTML nor JavaScript". You take that for granted and start learning for 90 days, you do the project above, you finally learn JavaScript for 30 days because the framework won't do everything by itself. You also read on the HTTP protocol (clients/servers requests/response, headers, etc) and debug in the Firefox console. Another 30 days. In the end you ended up learning every areas of web development. So why don't we do our things like grown ups from the start? Why don't we pick a slimmer framework, suited for the web, easier to learn, and at the same time we learn the nuts and bolts of all the remaining areas of web development? I guarantee you, if you do that you can't loose. Plus, if you call in the next 30 minutes.. (joke). Seriously if you do that, whenever you change frameworks, you still know the basics that "never" changes: HTML, JavaScript, HTTP Requests/Responses, AJAX, jQuery, etc... Isn't that pathetic, those are the things Web Forms don't want you to know.

The .NET Model View Controller (MVC)

Background

(disclaimer for the next 3 paragraphs: I know that MVC has been around sooner on Ruby on Rails than .NET. Just put all the MVCs in a bag and pretend that I'm talking about all of them at once)

I once heard something really hurtful (at that time) from some smelly game developers: "Web developers are not real programmers". Sure, I've come across many lazy web developers because I feel web development is more accessible for the mass (I'm sorry). Sure with some time game developers can do web sites on their own and I know that the other way around is not necessarily true. But in 2K, I must admit that it was nonsense (at least for me)... no methodologies, no structure, no real code reuse, no architecture. Anybody could do a website. The only goal was to deliver as fast as you can and be paid as low as they can. After all, web is easy. Our profession has since matured because we sat down to think of it (excluding myself in the "we").

I think technologies and concepts had a role in the transformation of the web site creation process. Since the web is a matter of requests and responses, I think that nobody saw the necessity of having a big set of object-oriented objects to be instantiated and connected together to deal with the business rules knowing that 10 milliseconds later it would be destroyed at the end of the request. It was hard to follow the "regular" design principles without doing some kind of over-design when applied to the web. So with time some concepts appeared that were more and more suited for the web.

So... where am I going with all this? I think MVC is one of the concrete symbols resulting of that needed change. To me it's not just another comparable features by features framework. It goes beyond that. It has history behind it and it acts as a proven point when I say that it was nonsense back in the days. The form to join my sect is at the end of this article. Just kidding, but seriously, the web has more and more of its share of design principles.

MVC's Foundations

The .NET MVC framework's name comes from the name of a design pattern. It is already more reassuring than Web Forms isn't it? MVC stands for Model View Controller. Essentially, the goal is to isolate each letter so that development, testing and maintenance can be done independently from one to another (Model–view–controller From Wikipedia, the free encyclopedia). MVC is more than that (since above is a description of the design pattern itself).

So how is MVC so great? Instead of swimming against the wave like Web Forms, MVC just goooo with the flowwwww. Remember that I've said that the HTTP protocol was all about anonymous (almost) requests and responses? Well MVC is all about requests and responses too. Each request that can be made to the server correspond to a method of a class. If the method has parameters, it means that the request (either POST or GET) must provide those parameters (if the parameters are mandatory, of course). And passing those parameters in the HTTP protocol jargon simply means submitting forms or using the query string. And they lived happily ever after. -END

I'm kidding but it's almost that simple! But how do I know which URL correspond to which method of a particular class you may ask? Well, lets put names on what I've been talking about. The methods are declared in classes: those classes are the Controllers. And those methods I've been talking about are called Actions. So each Controller have Actions. There's a built-in URL rewrite mechanism that makes a mapping between the URL and the Actions in the Controllers. The actions are free to return json, HTML, etc. So you see its suited for today's needs.

I don't want to go in details because this is not the main purpose of this article. But just remember that you have a bunch of methods in some classes and each methods usually correspond to a unique URL. Requesting an URL will call the appropriate method which will return you some content. You have no page life cycle, you don't have a View State, you don't have server side controls, you have simplicity. Let's see how it compares to the flaws of Web Forms.

MVC versus View State

There is no View State in MVC. If you use straight HTML, nothing will automagically retain its value if you submit a form back to the current page (the text in the text boxes will be gone). To have the values retained you can use "helpers" in the aspx pages:

Wow no HTML clutter. But wait a minute you may say... aren't the aspx pages are hard to read for non-developers? Just like you told us with Web Forms? Yes I agree that's a new syntax. But it's a syntax only used for forms generally. Besides, the attributes given near "[...] new { style = [...]" are a 1 to 1 match with the HTML attributes. So the CSS guys can still use the real attribute names for their HTML elements. Also, if your receive your CSS in advance, prior to coding a form let's say, you know that the HTML generated from the helper won't be coming from outer space. The CSS guys won't have to comply to the framework anymore (but it's now the other way around, like it's supposed to be).

MVC Versus Controls

There are no controls per se in MVC. There are user controls. But again not built-in. You have to do the job yourself or have a look at the jQuery library. It means that you have full control (no pun intended) over your HTML. Look at a portion of a MVC aspx page:

Woah it's 1999 again in your head... there's a server tag in the script's src. Yes for you it's a step back and it makes you think about your classic ASP programming. But remember the view isn't tightly coupled with the controller. There's no way to initialize or set-up your view other than that. The only thing the controller gives you for your view is a bag of informations. That's a good thing. Plus, you have complete control over the HTML generated, over the JavaScript, over the CSS, etc. Go create an MVC site and tell your friend to do "view source" on your site's homepage. Some will believe that it's a static website in plain HTML. It's that clean.

But, isn't it a tedious task, editing the aspx page this way? Ok I'll answer one last of your questions: No. Remember all the books you bought to learn Web Forms to finally have to learn JavaScript anyway to get lost in their endless libraries? Well buy an HTML book, a JavaScript book, a jQuery and CSS book from the start and do MVC. You'll end up being much more productive because remember, you never do easy examples as in books. And the knowledge you gain, you put it on something useful. Not a dying framework. That's still good for your career if by any chance you stop doing MVC. Plus, there's plenty of jQuery goodies out there. Trust me don't be worried.

MVC Versus Page Life Cycle

Since the request hits a method server side, there's no page life cycle in MVC. So no surprises on what gets called first or what gets initialized first. (wow short section)

Last Words on MVC

I didn't go in details as you can see and there are probably more questions rising in your head than before reading this article. But that's the point. I'm here to shake you up a little. MVC is a slim, to the point framework that puts the emphasis on a good architecture. Sure it's up to the developers but at least when you create a brand new project, the folders are well organized to give you some kind of directions. Not only the aspx code is cleaner for everybody, not only the resulting source code is cleaner but also the urls are cleaner. Being RESTful, they're great for indexation and bookmarking.

Now you go learn MVC to see what I'm talking about!! To give you an idea of how easy and fun it is, I have read around 60 pages of the book to get started in only an afternoon to do professional sites with MVC (when it was in beta stage). You can do it too! There is a new version of the book available and this is all you need to do amazing .NET MVC sites in no time.

Conclusion

Today, it's not everybody anymore that can do websites at the level we (web developers) do it. It's a complex game, you can't hide and pretend it's something else anymore. If you have to spend more time dealing with a framework than actually doing your application, you have problem. A problem we often have with Web Forms.

Maybe web development is still rather new and we're just beginning to see real object oriented concepts applied to it to solve problems for what they are. But still, it becomes more and more mature. In the end, we're maybe not calculating tangent in our day to day lives but personally, doing simple things well is harder than doing complicated things well. It's up to us to make web development better, as simple as it sounds.

Next Steps

As I said earlier, I've read 60 pages of a previous version of this book () to get started using MVC! It is that easy. I can't recommend you enough that book and I can't say it better than amazon itself: "The book's authors, Steve Sanderson and Adam Freeman, have both watched the growth of ASP.NET MVC since its first release, with Steve taking a particularly prominent role. You can be sure you are in safe hands."

29
comments:

You have pointed out why WebForms makes the easy stuff easy and the hard stuff darn near impossible. But MVC is not the answer; though nothing is impossible with MVC, everything is tedious and difficult.

What you need is a component framework that is better thought-out than MVC; one in which a half-way decent developer can understand the underlying nuts, bolts and gears to do that which is novel and unforeseen by the framework designer. What you need is Apache Wicket.

I’m still not convinced. I want to be but I’m not… I've been developing Web sites since the late 90's. MVC sound tedious for 'clean html'. How often does your client 'right click, view source'? In all the years I've been doing this I have never had a client view the source or care about it. What paying clients look for is results(value==cost*time). If I can do the exact same app with WebForms app in a few weeks or MVC app in a few months which one would be easier to sell? "But look Mr. Client it has really cool HTML" unless you're selling your stuff to someone who really wants an MVC app then, yeah, but otherwise I don't see the value of the extra work load. As for the SEO clean URL thing, I don't get it. I can do all these things and more with an URLRewrite module and a map in IIS 7.5. View state: you should turn it off and leave it off. jQuery, CSS, and the like can be just as powerful with WebForms. I do it all the time without any problem. The key is being judicious with what controls you use and when. Separation of concerns: I'm not seeing a lot of advantage here either. What I’m finding is most developers forget there is a database server, web server and most likely a decent client PC with broadband and the load of the app can be spread out. I think they call this n-tier :pIf I’m remiss here or if you can help me better understand this please let me know.

Thanks for your comment, really. I'll try to explain my point of view regarding each points you mentioned. I agree, my article is rather "black or white" but I give you credits on some things you brought.

Regarding your experience

I agree that if you're that experienced, Web Forms can be quite powerful with the controls and such. But I think the learning curve is too steep for newcomers. I learned MVC in a ~70 pages preview book. It sits right beside my ~800 pages ASP .NET 3.5 book :)

Regarding the cleanness of the source

First, where I work we can deliver ~50 sites per year. It's a fast paced environment. There is a department for each specialties: developers, HTML/CSS integrators, etc... I can also tell you that there's some movement in the staff (and I'm not just talking about interns). What the CSS integrators learn is HTML, not Web Forms tags. So putting money on training or debug sessions are quite useless. Back to Web Forms: Now how can they know how a control renders itself? By looking at the resulting source. Even in MVC the developers have to look at the source, the pages are more and more dynamic than ever. Not inspecting the DOM or looking at the source is like a mechanic not opening the hood to find your car's problem. In MVC, HTML/CSS integrators are in a more natural environment for them I believe. I agree there's also some server gibberish in their page, but it's more expressive. If you do everything all by yourself, well I agree MVC can be daunting.

Regarding SEO

Just like if you want XHTML compliance, rewriting, no viewstate, etc. You have to install a module or do the thing yourself. I prefer to start clean with minimum dependencies.

Regarding jQuery, CSS

Well I pretty covered CSS ;) But I'll tell you again my main argument: you don't know how the control translates to in HTML and sometimes it is not XHMTL compliant. Regarding jQuery, you're right, my only complain is that finding DOM nodes by ID is a painnnn! I'll give you credits though on Microsoft official controls, they are mature and uniform. With MVC and jQuery, you often rely on Mr. something's plugin.

Separation of concerns

Again newcomers will invariably put some JavaScript and CSS from the code-behind. By doing that you glued the UI and the business and that's bad. With a framework that permits that in the first place is wrong. With your experience, I agree that it must be well coded. In MVC, the controller is passing a bag of data to the view and that's the only communication that occurs. The view takes what's in the bag and display it. You can have the same controller feeding 2 different views with the same data: mobile and desktop for example. Since there's no page life cycle, the controller is pretty isolated also, since it resolves as a single function. Your database, well, is in your data center :)

I hope I gave you some good arguments :) Read some Domain Driven Design by Eric Evans. We seem to have a similar background. When implemented with MVC/IoC/Linq it's very sharp. Maybe I'll blog about that too. Definitely a turning point in my young career.

Don't hesitate if you have any other questions. I don't mean to have answers, but I have opinions :)

I would be interested if it were possible to work remotely, and come in for meetings every couple of weeks or so. I only recently moved to Ottawa from Vancouver. Hopefully I won't have to move again for a while :)

I followed you on Twitter. Perhaps it would be better to continue this through DM?

'Because having those things around (View State, Controls, Page Life Cycle, etc), it comes at a price. A price I'm not willing to pay and I'm not even talking about performance here but learning curve and productivity'

Why? Arent you supposed to be in the business for a long time, meaning 'Experienced individual'. I dont get you there! Sorry

I'm in the industry for a certain amount of time yes. But the Web Forms framework, in my opinion, is to much deep/fat and is unnatural to web development. So having all the experience in the world won't help.

And it's actually worst if you have some experience "at large". You know that you can actually achieve the same result (or better) with fewer lines of code and experience and knowing of the framework. Period. Having the experience will help in making you project fit with the framework but knowing perfectly its limitations won't make the limitations go away.

I'm currently developing on Google App Engine in java with Spring MVC. I did plenty of Coldfusion a while back, some php and some classic ASP. I did .NET MVC of course and Web Forms for several years now.

I agree that it's hard to take it for granted that Web Forms isn't suited for today's web development.

What ppl are developing today are MVC frameworks (In php, java, ruby... name it... it rains MVC frameworks). Not Web Form frameworks! And there's a reason for that. Going with the flow of web development and its true nature. Stateless, request/response paradigm, decoupled, data exchange in various formats, separation of concerns, etc..

So having all the experience in the world won't help code workarounds and cope with the inflexibility of the .NET Web Forms framework!

I can start a post, which I can make the promise to myself that every time I encounter a bug/shortcoming/odd thing about Web Forms, I will document it. But I won't, I'm looking forward. I can tell you that I just wasted a whole day with the .NET validators used with update panels.

My view is: learn the basics so that you are free to choose any lightweight framework and watch your productivity raise to a whole new level.

It is also fulfilling to be able to hop from a technology to another and see how they do things a little differently.

I'm in the process of writing a book about achieving that. But I have several projects going on. I'll see. I'll probably make it available through this blog while writing it, chapters by chapters.

I strongly believe that WebForms is a great framework for applications and MVC is a great framework for websites. I'll agree with most points here, WebForms is complicated and requires deep understanding in order to use it successfully.

This is a poorly written article. I read through maybe a third of it before I gave up frustrated by all your typos and crappy wording. It sounds like the effort of a grade school kid trying to make a point. I see this all the time with my 3rd grader. You know, where the point you are trying to make really isn't supported by enough or any evidence to then say "see it is bad". You ought to re-work the whole thing and then it might make a little more impact to those you are trying to reach. And have someone on the tech side check it over. Or maybe this is just a bad morning for me or something. : )

I'll say it up front, I'm tired of noobs like you trying to prove MVC to be a better framework than Webforms ;-)If you have never build for the web and your background is Winforms or something similar. Then yes, go for MVC because it will push you in the right direction of web development.

But when you know what you are doing, then there is nothing that MVC will do for you that you can't do with Webforms. Just disable ViewState and never ever use default MS controls. And for websites I would recommend to use the URL routing mechanism.

Search My Blog

Who Am I

Mike Gleason jr Couturier

Hi there, my name's Mike. I'm an architect and a technology enthusiast. My field of expertise revolves around .NET and JavaScript notably Google Maps where I became in 2010 the 23rd Maps API Certified developer. I decided late 2009 to share a bit of my knowledge and experience in this blog so I hope you like it, don't hesitate to leave a comment. I also founded a website to find and organize live poker games that keeps me busy.