What:
With the raise of the web 2.0 meme, more and more web applications claim to support REST architectures. We'll explore together what is REST and what is not, and how we can write a testable web application that supports the REST concepts on the asp.net platform, with a code-intensive overview of current toolkits (asp.net MVC and others).

Where:
MRM Worldwide London
76 - 80 Southwark Street , Bankside Studios, London SE1 0PN

When:
Tomorrow Wednesday the 21st of May, 18:30

Why:
This, I have no idea of :)

That is, if I get Visual Studio 2008 SP1 installing properly on my demo laptop, which is no small feat in itself, or face a frantic rewrite of some of the presentation tomorrow.

Today is a day off, as I've accumulated 36 hours of work between Monday and Tuesday and needed some rest. The last project I've been working on has been one of the most interesting I've had in a long time, not only because I took more responsibilities than usual, being both a lead dev and as a scrum master, but because of the amount of technology we've fetched in one app. To give a quick run-down:

• Fluid database design with an object-based linq2sql database (no dbml file and no sql files in the whole project)
• Sql Compact Edition
• ado.net synchronization services to sync to a central database, and hopefully the sync framework for multi-party syncrhonization
• WPF all the way, with a ViewModel way of developing
• Castle stack, for Windsor and a bit of DynamicProxy2 love
• 3G support for an always on experience

I've learnt quite a few things in the process, so here's a few reflections for my own benefits.

• When you don't know what you're building, you're going to have a hard time knowing when it's done
• Working under pressure can be fun, but it's exhausting and it does highlight a failure in the planning part. We're getting better but we're nowhere near there yet
• It's fun to see people with a background go around in WPF. It always starts quite code-centric and evolves into more XAML as time goes by
• I still don't see people using Blend for anything meaningful. There's a wide range of reasons why, from crashes to not liking esoteric Xaml to the recording model. It doesn't go down well with either populations right now, at least as far as WPF is concerned.
• The only reasonable way to monitor the correct use of patterns and abstractions is to do it continuously. Not paying attention to the code base and coming back with changes weeks later is not a good idea, and a complete failure on my part. I need to get better at agreeing, explaining and enforcing design decisions.
• No one can work on several projects within a company and stay focused. This doesn't work at all. From now on, I will flat out refuse to work on  something else in the same day. If you want my time for two projects, my minimum time unit will be a day. Interruption decreases my productivity so much it's unreasonable, and the project (and my nerves) suffer.
• Frameworks that hide all of their internal implementation suck big time. Understanding object tracking in linq2sql is not easy or enjoyable, and bite you. Badly.
• Frameworks that show all of their internal implementations suck big time. Castle Windsor (at least RC3) throws exceptions in all the wrong places, and make dealing with registration more painful than it needs to be (when it works at all).
• Designers and UE people *need* to be involved throughout the process, and work on the same stuff as the rest of the team. The way people think they can go off and work on the UE or the design on their own schedule, with only validation from tech (when they don't send the work done the day before a release) is driving me absolutely insane. This doesn't work for them (we can tell them how much more flexibility they can have in their own design), it doesn't work for us (they provide diagrams of stuff we've already delivered, or stuff that is completely limiting the capacities of the platform). It's the typical waterfall model, and fall and fail it usually does.
• Someone needs to wake up and realize that the technology is not there to support the design, and the design is not there to put a nice face on technology. They're two sides of the same silver coin, they need to work together to deliver. That's what Apple does and it works great.
• I'm always amazed at how little is still invested in most of my clients companies around supporting other development teams. With a core team of a couple of peoples working to support other teams and evangelize the company's infrastructure, any company would save *so much time* on all other projects, from enforcing good standards, deployment procedures, automation etc. Think a few weeks per project.

Overall, a very good project, a great team and a freedom that I don't have very often with clients. I think it'll be difficult to move to my next project, the comparison will suffer!

Got a message from Catriona, and the original location for our alt.net beers event was fully booked, so it's now around the corner from the previous location. See the original post for the details.