Too strong? Maybe, but the ASP.NET Web Forms programming model has run its course. It was hugely impressive when it originally appeared - I remember it being announced as ASP+ in 2000, and how phenomenal it seemed. You can build a web page visually, using a rich set of controls, and have ASP.NET abstract away much of the problem of managing state. It also lets you write code in any .NET language, which is just-in-time compiled at runtime for fast performance.

ASP.NET works the same as ever today; but the web has moved on. The Web Forms model makes programming the web more like programming Windows, which was cool at the time but not any longer.

Fortunately for Microsoft, it has an alternative, called ASP.NET MVC. The first full release was announced at the Mix09 conference last week, and you can download it now. I took the opportunity to ask some of the delegates what they thought of it.

The reactions I got fell into two broad categories. The first group found it difficult to puzzle out what it really was, even those who had attended sessions on the subject. The second group loved it, and never ever wanted to go near Web Forms again. In fact, such was the frustration with Web Forms among some developers, that they had developed their own alternative frameworks but were now moving to the official one.

So what's wrong with Web Forms? Complaints I heard include that it is not testable; that it is not really compatible with AJAX; that it is inflexible; that ViewState, hidden form data which preserves state across page refreshes, is a nuisance; and that it is hard to write REST-style applications or those which properly support the Back button.

Enter ASP.NET MVC, which answers all of these complaints. MVC stands for Model View Controller, though having played with it a little I find the name somewhat misleading, as well as being a mouthful (contrast the delightfully-named MonoRail, which is an interesting alternative). Why misleading? Well, it doesn't have much of a Model, as this post observes. It does have views and controllers; but I think one of the reasons developers find it hard to grok is that starting with a discussion about MVC architecture is not the best way to teach it.

I think the place to start is with URLs and routing. It also helps to know that ASP.NET MVC follows the principle of convention over configuration (though not to the same extent as Ruby on Rails). In a nutshell, ASP.NET MVC breaks the link between the URL in the browser and aspx files on the web server; instead, it processes the URL and returns what you want it to return.

A "View" in ASP.NET MVC is an .aspx page, but in the form of a lightweight template, not a Web Forms with a complex page lifecycle.

I've been playing with ASP.NET MVC recently, and it is a delight. Yes, there is more manual coding than with Web Forms, but it is worth it for the additional control you gain. Even the performance seems better, a consequence of the lightweight approach. As it happens, I'm also a believer in test-driven development. I guess I'm in the second group that I spoke to at Mix09.

Microsoft is not killing off Web Forms; rather, it is very insistent that they remain under full development. I get the impression that the company expects ASP.NET MVC to be a minority choice.

Nevertheless, if you work with ASP.NET do not hesitate to check out the new framework. Personally I think ASP.NET MVC might just rescue its web platform from a slow but inevitable decline.

As you can tell, I have portfolios on my mind these days :-) But there's a reason for that. A portfolio is a collection of work that you can assess over time. One way to prepare for an interview is to build your accomplishment portfolio.

It's easy to describe how to build this portfolio: In reverse chronological order (most recent job first), list each accomplishment and the meaning behind that accomplishment. A key piece of recognizing an accomplishment is to ask yourself "so what?" If you can answer that question in a way that has meaning for a hiring manager, you've got a great accomplishment.

Here's an example. If one of my accomplishments is to coach a project manager, I can say "Coach PM, with result that he saw more risks and took more proactive actions. Project came in on time, allowing company to recognize revenue in Q2." It's even better if I can put a specific dollar amount on that accomplishment, so I answer the implicit "so what" question.

So, that sounds pretty easy, right? Well, the difficult part is deciding which accomplishments you want to discuss from each job you've had. For example, if you've been working for 20 years, do you include the accomplishments from 15 years ago? Probably not, unless one of them led to a pattern of similar accomplishments in which your responsibility has grown over time. For the past 10 years? Probably.

The key is to use accomplishments which highlight your ever-increasing areas of responsibility, challenge, and knowledge. Make sure you think about accomplishments which point to work you want to take on more of, not work you don't want to do anymore.

If you've been working for a while and you haven't written down your accomplishments, start with your current or most recent job first, and write those down. Then, start moving backwards in your career. If you can, use the accomplishments as bullet points on your resume. If you think you really have some career-spanning accomplishments, consider a resume cover page (not a cover letter) that highlights your accomplishments over your career.

Whatever you do, remember to update your resume and accomplishments at least once a quarter, if not once a month. Doing this periodically helps you see where your career is going, and if you're headed on the right track for you. If you have a quarter where you haven't accomplished anything, consider whether this job is helping or hurting you, or if you could reorganize or remake part of your job.

Your portfolio is an indication of the kind of person you are and the kind of worker you tend to be. Use that information to help you manage your career.

As an IT professional, the skills you use for your job are your most valuable asset - most gainful employment within the sector relies on some specialist knowledge. Whether from experience or education, the things you have learned define the job you can do.

It is safe to say that any investment in your skills is worthwhile, then - expanding your knowledge of things IT related will help greatly in developing your career - cementing and diversifying your current role (with greater chances for advancement) and improving your prospects for later roles as well.



The dangers of over-specialisation

The detriments of a narrow skill set are all too obvious, then - technology is a fast moving sector to work in, so if you don't keep your skills up to date you could get stuck in a legacy support dead end, or worse - find yourself replaced with a new wave of fresh faced developers toting the latest buzzwords and paradigms.

That's not to say that a certain degree of focus can't be a bad thing - if you're amongst the few real experts in a niche area, you can certainly make a very tidy profit - but all the same it is wise to be sensitive to the evolving landscape of IT. If you're in a receding area of expertise, over-specialising can be dangerous.

Certain subcultures in tech can breed this kind of lack of adaptability - those in the almost self-contained Java and .NET worlds are more vulnerable than most. Being involved in a close community is largely a good thing, at least as far as support is concerned - but it's not hard to become isolated from other areas and miss out on some of the more up-and-coming languages, platforms and techniques.

Being a 'jack-of-all-trades' isn't much better

Keeping an open mind to new technologies can pay dividends - but it's wise to be at least slightly cautious. Overzealous chasing of the bleeding edge can lead to a lack of depth to your knowledge - which will adversely affect your skill set as a whole.

Challenge yourself. Expend at least some time broadening your knowledge into adjacent sectors. But never forget the core skills that define your role today - use them as a base, not something disposable to discard at the first sign of change in an industry.

While the life of a technology worker can be fast paced, the changes that come about are evolutionary - and with the right mindset, and with a little effort expended to keep your awareness fresh, you can do well.

I'm at Microsoft's Mix09 conference in Las Vegas, where the big news (aside from small matters like the final release of Internet Explorer 8) is the beta release of Silverlight 3.0, Microsoft's browser plug-in that competes with Flash as a platform for rich internet applications.

Silverlight 3.0 is stuffed with new features, one of which is the ability to run outside the browser. Right-click an applet, choose Install onto this computer, and suddenly you have a desktop application complete with a shortcut in the Start menu, or on the Mac desktop. This has triggered a debate over how SLOOB (that's Silverlight Out Of Browser) compares to Adobe's existing AIR (Adobe Integrated Runtime), which supports Flash applications running on the desktop.

Understandably, Adobe folk like Ryan Stewart are emphasising the differences:

"I think AIR and the Silverlight OOB (Out of Browser) are two very different technologies for two very different scenarios...AIR is about letting you take your web application skills to build desktop applications and Silverlight OOB is more about letting you take your Silverlight applications to the desktop. The different models will be different for everyone, but right now AIR gives you a lot more flexibility and more API hooks into the operating system."

The big issue is how much these desktop/web hybrids interact with the local machine. Microsoft makes a point of how SLOOBs run in the same sandbox as they would in the browser, which means the user can install without a security prompt, but also that the application has very access to the user's desktop. The only access to the file system is to a protected area called isolated storage, or via a file dialog that the user controls. Microsoft says there might (or might not) be a way of displaying notifications but that is about it.

AIR applications by contrast run with the same permissions as the user. Installation involves the user consenting to a dialog which usually threatens unrestricted access to the system. Your AIR app can read and write any files that the user can read or write. There is also a notification API, and support for drag-and-drop.

That said, AIR applications are also restricted by design. They cannot be extended with native code, or execute other applications. Adobe has always presented AIR as a way of delivering web applications on the desktop, rather than as an alternative to C++ or .NET for traditional desktop applications. So is it really so different from SLOOB?

Well, some of the AIR features do give it an edge. One is the ability to fire notifications (annoying though this can be). It's something that Microsoft definitely intends to add to SLOOBs, though I get a different answer every time I ask about it; it might not come until Silverlight 4.0. Another difference is that AIR can host HTML as well as Flash content, which is an advantage for applications that depend on both. AIR also includes an embedded relational database engine, SQLite, whereas SLOOB developers will have to roll their own or use XML, though I doubt this is really a big deal. One other thing: Silverlight knows nothing about printing, which is unfortunate when running outside the browser.

Nice features; but I still feel that AIR and SLOOB are close competitors. Both take a cross-platform, rich internet application runtime and make it available from a desktop shortcut and with offline support. That makes a huge difference to users, even if the technical differences between running in or outside the browser are not so great. SLOOBs are going to be attractive to .NET developers because they include the .NET runtime and can be developed in the familiar Visual Studio IDE.

Personally I'd like to see an option to run AIR applications sandboxed, as full file access is more than most of them need. I'd also like an option to run SLOOBs with greater local system access when needed. Why not have the best of both worlds?

In the meantime, I'm expecting both to succeed. For applications that will work as a SLOOB, it makes a great user-friendly, cross-platform alternative to Windows Forms; and we've already seen effective user of AIR for cloud-centric utilities like Twitter clients. Both platforms are also highly effective for visualizing data. Who knows, this approach could become the norm for a wide range of business applications.

If you are like most people I know, you have too much to do. Maybe you're only on one project at work (I hope so!), but you have house stuff to do, garden stuff to do, kid stuff to do, dog or cat stuff, book stuff, parent stuff--you name it, you have a todo list a mile long. And, some of you have many more than one project to do at work. Is there a way to get through that all those todos?

Maybe. First, you need to know what you need to do now, and what you can do later. Here's my approach to managing my todos over time:

1. Make a big list of everything. Empty my brain onto the paper. Don't worry about organizing it, just write it down. (Yes, this is from David Allen's Getting Things Done.)

2. Now, make a grid on a piece of paper. Across the top, you have Week1, Week2, Week3, Week4. Down the side, you have "Tasks" and "Unstaffed Work."

Historically, the web development choice between the Microsoft platform and open source has been a fork in the road with many consequences. Choose Microsoft, and you generally use Visual Studio, Internet Information Server, ASP.NET, C# or Visual Basic, and SQL Server for the database manager. Choose open source, and you most likely target LAMP in one of its guises, the most common being Linux, Apache, MySQL and PHP, and work in Eclipse or almost anything other than Visual Studio.

Recently the boundaries have been blurring a little. Apache actually runs nicely on Windows, and I've used it happily to host a Subversion repository, while on the other side Microsoft has been making an effort to support PHP in IIS 7.0. But what about running ASP.NET on Linux, is that a silly idea?

I've been following the efforts of the Mono project in this area for some time, though it's been a while since I've tried it out. Mono was originally focused more on desktop than web applications, and I've used it mostly in that context. When laterooms.com tried Mono in early 2006 it quickly gave up, citing problems with Mono's Boehm garbage collector; see the developer's comments to my blog post at the time.

Still, that was three years ago. I had another look a couple of weeks ago, and I've been impressed. In particular, the ability to develop in Visual Studio and deploy to Linux is interesting. I'm working on a small project, and getting this working is remarkably simple. I used Visual Studio 2008, but set the project to target .NET Framework 2.0, as Mono lags behind Microsoft in implementing the latest .NET APIs, and using MySQL rather than SQL Server, since this is available on my Linux web server. Using MySQL with .NET is straightforward thanks to the official ADO.Net provider, which specifically supports Mono as well as Microsoft .NET.

On the web server, running Debian 5.0 Linux (Lenny), I installed the libapache2-mod-mono and mono-apache-server2 packages using Aptitude. Next, I configured Apache to use Mono on a particular web site, with a few lines of manual configuration, as explained here, and imported the MySQL database from the Windows development machine to the Linux web server.

Back in Visual Studio, I compiled the web site, uploaded it, and it worked first try. Performance is good as well.

I realise that a number of caveats apply. It's worth reading this page, the current Mono todo list, which notes some of the important areas where Mono is lacking and includes the comment:

Mono is known to be not as performant as the .NET Framework.

Note that Mono still uses the Boehm garbage collector, though an alternative is in development. Further, Mono does not implement the entire .NET Framework. Mono is a brave choice; Windows and IIS the sensible option for .NET applications.

It still seems to me significant that you can easily deploy to Linux and Apache using Mono. Not all applications are mission-critical, and not all applications need to scale as well as Laterooms.com. Mono has a number of attractions. First, it is open source, so in the event of problems you can always obtain and amend the source code. Second, running on Apache and Linux is a considerable saving in license costs. Third, you can get official developer support from Novell.

Why would you use C# and ASP.NET rather than PHP or Java? The main reason would be because you know and like the language, the platform, and/or the Visual Studio IDE. In an interesting report on the state of the computer book market, O'Reilly notes that C# is now the largest programming language for all book sales. Thanks to Mono, you can use C# but still deploy to an open source platform.

It also seems to me that Microsoft's official support for Moonlight, the Mono implementation of Silverlight, is important. Microsoft now needs Mono, in order to tick the cross-platform box and compete with Flash, giving more assurance to its long-term future.

Mono's growth over nearly a decade has been slow but steady. Perhaps now is the moment that it creeps into the mainstream.

Are you using Mono, for web or desktop development? I'd be interested in your comments.