Facebook killer? http://wave.google.com/

I wish this page on ClientScriptManager.RegisterClientScriptResource() instead of saying towards the end "The following code example demonstrates how to programmatically apply the WebResourceAttribute metadata attribute" instead said something like "In order for ClientScriptManager.RegisterClientScript() to work you *must* apply the WebResourceAttribute attribute to your assembly." 'cos that's what delayed me an hour in finishing custom control yesterday afternoon. Doh! I'll add some feedback.

What's more annoying is that as caught me out before ... so I should have remembered the attribute was necessary. Hopefully by blogging this it'll stick in my memory for next time. Hopefully.

This article of storing generic collections into ViewState was a life saver today because that's exactly what I was trying to do. A quick google of the error message I was getting ("The state information is invalid for this page and might be corrupted.") found that blog post and the solution to my problem. Nice.

I was talking a while back about symmetrical code but it is not just individual code blocks that benefit from symmetry it is also the whole structure of the code. For example, if you've got lots of screens each then it's a good idea that the code follows the same structure across them all so if you were to compare them side by side they'd look symmetrical e.g. the validation code is in a method with the same name in each screen and initialisation / validation / etc. are done in the same order in each screen*.

Of course another way of looking at it is they all follow the same pattern, which is why "Patterns" is a big thing in coding nowadays. Going further out you could say that the screens always do X, any custom controls do Y and the business layer always does Z etc. leaving everything nice and ordered and neat and it was talking with a mate the other week when I first heard this expressed as the phrase "separation of concerns".

I heard the phase again on the MIX09 videos on ASP.NET MVC so I think this must be a new phrase of the moment** and I can see why 'cos it put succinctly*** the need to know what should go where when coding to make sure maintenance and debugging happen as easily as possible.

In other news lunchtime footie has been cancelled again today, gutted.

UPDATE (04-06-2009): I heard the phrase "separation of concerns" again today.

Used my free time today to catch up on MIX09 in particular the new ASP.NET MVC framework and how it compares with Web Forms. Looks good and has nice separation* ... not that Web Forms has bad separation, it was only if you started building custom controls and putting business logic into them (which I've seen done) that you then got confused as to where you should write the next bit of code or hunt for the bug* ... though in some ways it seems to be going back to the days of classic ASP since there aren't any click events and the likes.

I like the admission that although MVC gives you more control than Web Forms but as a consequence it therefore needs more work to develop sites. Hence Web Forms are not going away. Only thing is I can see a prototype needed to be developed the quick way then needing more control when developing drop1 :-)

I was interested to see that jQuery was included as part of the install because last I looked Microsoft were putting a decent effort into their own JavaScript API but I see now that, with being on .NET 2.0 these last 18 months** that "Microsoft will be shipping jQuery with Visual Studio going forward". And "also plan to contribute tests, bug fixes, and patches back to the jQuery open source project". Cool.

After watching last night The Big Bang Theory the other night last night I looked up Loop Quantum Gravity which got me reading about Renormalization because I did that back in the days I did my PhD though I'd forgotten many of the details.

I the article about Renormalization I read the line "integration around the poles" which immediately flashed into my head a diagram I remember from my A-level maths. So today, between doing chores, I've been reading up all the A-level maths stuff. I started with contour integration* where all sorts of phrases started to ring a bell "Cauchy integral theorem", "residues", "branch cuts" and "integrating around the pole". Then I read up on differential equations with "separation of variables" and "particular solutions"

There was even more stuff** that rang a bell as soon as I read it so I've been quite impressed today by my brain's storage capacity.

Have got some free time at the moment so this week have been teaching myself Windows Presentation Foundation (WPF) yesterday / today by re-writing my pet project to re-size / re-"aspect ratio"* photos for emailing / putting on photo frame / printing.

It's been a good little project to learn stuff** - wrote it initially in .NET 1.0 a few years back, added BackgroundWorker and application settings when .NET 2.0 came out and last xmas I did some major refactoring 'cos it was starting and hence needed to be more base class / interface driven***.

Anyhow I've made a first stab at writing it as a WPF application and so far here were a few things that didn't sit right: I get markup + code and separating out styles being a (mostly) ASP.NET programmer but in the MSDN demos I've seen hacks to reference the markup defined object from the code files and I've seen styles stuck in data templates neither of which feel right. I'm hoping that the these are just shortcuts done for the purposes of writing demos and that if I play with a little more something will click so that it all makes sense and I'll blog more about this when it does. Certainly I've already simplified some of the bits in the demo (with the help of other's blogs) so that they seem more reasonable to my mind.

Of course one big win is the ability to turn it into an XBAP but I think I need to walk before I try to run :-)

I've been doing integrating / code review / bug fixing work for drop 2 this past week and a bit; making sure the UI code the outsourcers wrote ties in with the rest of the system.

<aside>
I've never used thought of myself as a "dot the i's, cross the t's" kind of person but when I was doing the drop 1 bug fixes a month or so ago I got real satisfaction from ticking off the bugs one by one. It wasn't as though there were lots of bugs, it was there were a few that each had a few steps to solve in order to fix the bug. It was this step-by-step approach that I found satisfying, it was like you were layout out a table cloth and as you sweep your hand forward the ripples get pushed forward until the fall off the end of the table and you're left with a perfectly smooth table cloth. Perfectly mown lawn kind of satisfaction.
</aside>

Where was I ... ah yes, the re-occurring thought I had as part of the code reviewer / integration work was the importance of symmetry. For example

   if (....)
   {
      a.b = true;
      x.y = false;
   }
   else
   {
      a.b = false;
      m.n = false;
   }

   else
   {
      a.b = false;
      m.n = false;
      // No need to set x.y here because ...
   }

   needToBlah = (....);

   a.b = needToBlah;
   m.n = needToBlah;
   c.d = !needToBlah;
   p.q = !needToBlah;

   // Only ever need to set x.y to false because ...
   if (needToBlah)
   {
      x.y = false;
   }

One of the things that can help with integration are "continuous integration" tools; by using CCNet we ensure that when a developer checks in some code it gets checked out, built, the unit tests run and then deployment packages run (which create the database tables and stored procs). This makes sure your changes are tested against everyone else changes and encourages developers to "Get Latest Version"* before checking in lest your check in clash with something and "break the build"

The big question is what to do next. The obvious thing is to automatically build the next project in the chain; the argument being if you changed the model and rebuilt, then you need to rebuild the business and UI layers to pick up any issues that the model change might have cause. A downside is that you probably know that the business layer is going to break and are about to fix it so why bother with a build you know is going to fail. You could wait until you've updated all layers before checking in** but on the other hand you may want your model changes in there so than others can start using them now.

More importantly, in a large team, you could also find yourself checking in code into the UI project just as it's building following a business layer build so then they end up waiting twice as long to see if their build goes green. That's an argument of streamlining the builds to as quick as possible, of course, but if you're running lots of unit tests and test deployments you might need to juggle. There is always the idea and there is always pragmatic.

Ultimately the answer is communication, a colleague will come round and warn us when he's "getting the planets aligned", by which he means he's about to turn off the automatic builds so he can build each bit in turn manually and make sure we've got a last known good deployment.

Well we demoed the bug fixes to drop 1 and the first half of drop 2 to the client end of last week. Getting to that point has meant the last two months have all been long days, so this weeks feels like a bit of a lull in comparison. Hence I thought it time to put down my thoughts and reflections. I was last writing about NUnit so let's start there...

NUnits are good, when you're working in a 15 developer strong team you need to keep an eye on any "treading on toes"; will a change in one corner of the model affect a different corner; will a change to the model affect the business layer in a corner you're not expecting; likewise with the UI. Unit testing is very helpful here - run all the tests to make sure not only your bit goes green but the rest all stays green - but it is not a panacea.

Where unit testing can trip you up is on integration. This is not surprising really because unit testing it about testing the units, and that where "continuous integration" tools can help; more on them in another post. However, seeing all that unit test green can give you a false sense of "it working". Especially if you're in management :-) And yet just because all the little bits work doesn't mean it'll all work when you put it together*. I can attest to that having spent most of a week getting the front end to talk all the way through to the back end ... and back again. Serialisation issues, checksum issues**, impedance mis-match issues***, model mapping issues**** all came into play.

Of course that time was time well spent: getting one operation / action working all the way through, taking out the "TODOs:" and other bits of workaround code unless they were for some other action, is important stuff. Once you've proved it really really works end-to-end you can be much more confident that the other actions, with their green unit tests, will work end-to-end too.

So as a "word to the wise" remember to put time aside for integration on the project plan; try to see the unit test green as the first step to "it's working". A phrase from my days learning maths at school springs to mind: "necessary but not sufficient".

There is still "devil in the detail" though: because you are the first route through, you don't know what obstacles you'll come across and how long it will take to overcome them hence estimating integration time really is just an estimate. It's why we found estimating drop1 a lot more difficult than estimating drop2. It why I'd recommend in the early stages keeping that part of the plan as flexible as possible; in the early integration stages I worked best when I didn't have a to estimate how long it would take rather I just had to get it done.

I work near one of the tourist raps in London so there are always a good few tourist groups about as I walk to work or go for a walk at lunchtime. This morning I got walking alongside such a group when the lead bod at the front turns round and says in a foreign accent I couldn't quite place, "And this type of rain is called? ... Drizzle".

Excellent, come to London to improve your English by learning all our words for rain and see that although British do get stereotyped for always talking about the weather there is a reason for that - once you're here for any length of time you'll soon realise we do have a lot of rain and it does fall in lots of different ways.

I'm getting really into unit testing in the current project. Before xmas I was working on adding to the model of an existing application; I was given one particular corner to work on. And alongside coding the model I had to add to our NUnit tests, this wasn't quite test driven development (write the tests, write the model) but it was close (write the first iteration of the model, use NUnit as a test harness)

Writing the tests was especially fun because this corner of the model had a fair bit of business logic in it, hence I had to try to out-think myself and test all possible corners of the business logic. It's quite fun trying to out-think oneself. It's also most satisfying working on test when you see everything go green*. In fact I think that's a point worth noting for any project manager: programmers like to see their code "pass", it satisfies our need for achievement, unit testing is therefore easy to get developers to take up so it's an easy way of getting those developers to do more testing :-)

That was all at the end of last year. I'm writing about it now because last Friday I had to extend the business logic in that corner of the model. Importantly the modification only affected a portion of the model - specifically to extend the date range considered when searching certain types of data - which meant I had to be careful that my update didn't affect the ranges of the searches.

And that is exactly where unit testing and test driven development is perfect: I added four more tests that checked the new range of the new code to check different scenarios and then pressed the button. That all of the previous test stayed green told me that my new code hadn't broken anything, that my new tests went red told me I needed to fill in the code - the fails were NotImplemented exceptions. Hence I could keep my mind on just one task, to get the new code working**. Cool.

I see that Asus are designing PCs like the good old days.

Wow, haven't blogged for ages, down to time mostly - when I was teaching I'd get periods of 30 mins when delegates were working on exercises and had no questions which gave me plenty of time to discuss and explain things I'd been asked whilst teaching. Now I'm developing I get 7 mins whilst the build is running and the questions I come across are about the project I'm developing for not the technology in general.

But don't want to freeze the blog entirely and I do occasionally get asked or just bump into interesting technology stuff so I guess I'll just have to keep it short to fit in 7min build times ... or just write the blog entry in several goes.

Recently I upgraded my digital camera and gave my old one to my mum, I bought the old one back in 2001 I think. In the box I also found the old wrapper for the memory card I bought with it; it was a 64MB CompactFlash which was close to the maximum capacity you could get at the time I seem to recall*.

With that in mind read this: http://www.dpreview.com/news/0809/08092306pretec_64gb_100gb_cf.asp ... so that's a 1000** times more in only seven years. Which is 10 lots of doubling, in 10 lots of 18 months, which is on the faster side of Moore's law

Oh and the 64MB CF card cost me £70 ... duty free.

Following on from a previous post we have (reported here)
> So what is happening to LINQ to SQL, which was last year’s ORM layer from
> Microsoft. "LINQ to SQL is still being developed, but Entity Framework is
> the big bet," said Program Manager Elisa Flasko at the developer’s panel.

Another year another database framework.

It's quite to track login status using a cookie: each secure page looks for a specific cookie coming with the requrest, if user doesn't have the logged-in cookie send them to the login page where the user enters their username & password, the login page checks these and if they are ok sends the user back to the page they wanted to go to along with the "logged-in" cookie. This is generally a GoodThing as it means the user only has to type in their username & password once* - which lessens the chances someone sees what you're typing - and the browser only has to submit them once - which lessens the chances someone can catch them flying across the internet.

The thing often overlooked is that the "logged-in" cookie is sent with every browser request so any hacker watching the network traffic has plenty of opportunity to catch that cookie. Once they've got the "logged-in" cookie they can send a request to the same web site with that cookie attached and hence they'll be identified as being logged on. As you. This is known as a replay attack.

The only way to stop against a replay attack is to use https for all the secure pages on you site. Now often you will sees sites using https for the logon page but this only secures your username and password; if the rest of the pages use http then the "logged-in" cookie is still sent unencrypted to those pages and is hence catchable.

Even when you turn on https for all the secure pages of your site you're still not 100% secure against replay attacks. The thing to remember is that cookies are sent to the web server with every applicable request - to set applicability there are options you can set on the cookie - domain (web site), path (area of web site), expires (date and time), secure (only over https). If you don't set the secure flag then, when you navigate away from one of the secure pages, back to a page over plain (unsecure) http, the "logged-in" cookie is still sent and hence you are open to a replay attack again.

And this is exactly what this hacking toolkit takes advantage of: http://www.theregister.co.uk/2008/09/11/cookiemonstor_rampage/

So if you're writing web apps and you need to avoid reply attacks being inflicted on your users, the please set the secure flag of your "logged-in" cookie. E.g. if you're using ASP.NET set the requireSSL attribute in the <forms> element of your web.config file: http://msdn.microsoft.com/en-us/library/1d3t3c61(VS.71).aspx

This news report on the Ryanair plane that suffered a loss of pressure reminded me why I stopped regularly reading news papers. It starts with alarm then sets aside about a third of the report on how the some of the oxygen masks were faulty, this completes the first column in the printed version of the report.

Anyone reading the first column and stopping there could get quite scared of flying and perhaps scared of flying with RyanAir in particular*. And should you be in a loss of cabin pressure incident you too will be wondering if you're oxygen mask will work and fill with oxygen.

If you keep reading beyond the first column however, you'll get to the bits of how many passengers were injured, what happened to the rest of the passengers and what might have caused the incident. If you keep reading beyond that you'll get to two rather important quotes:

"Passengers sometimes misunderstand and expect there's going to be a surge of oxygen, when in actual fact there's simply a steady stream. ... The oxygen masks were working."

and even more usefully

"These masks never inflate, but they are still working perfectly"

The first quote is from the boss of RyanAir and it would be reasonable to think "of course he would say that, he doesn't want to admit any liability". The second quote is from the safety editor at Flight International Magazine who should know what he's talking about. It also tallies with the information I've read on the flight safety cards.

Why tuck these quotes away at the end of the article? Why not put them straight after the quotes suggesting there was a problem with the masks? Especially since those earlier quotes give a false impression of how the oxygen masks are meant to work - "Mine wasn't filling up with oxygen and neither was my son's." - and could worry people in future if they are in a similar cabin pressurisation failure.

Why make most of the story about the fear and terror rather than what to do if you find yourself in the same situation - one of the things I've always wondered is how hard to pull the oxygen mask towards yourself, the instructions tell you that pulling on the mask will start the flow of oxygen but is that a light pull or a stronger one? I've always feared I'd keep pulling until I pulled the thing out of the ceiling!

It was the film Bowling for Columbine when I first came across the idea that the media portray the fear aspect of news stories and it was after that that I found myself reading and watching the news much less often. When I do read the news, and see stories like the one above**, it only serves to put me off more.

When Boris Johnson was elected I predicted that it would be great, a breath of fresh air, for about six months, then there would be some diplomatic meeting with some ambassadors or business leaders and he would put his foot in it and it there would be a "bit of an incident".

Well almost

I was sent a link today and I now have a new favourite web site ever showcasing errors made when over "photoshopping" images: http://photoshopdisasters.blogspot.com/

OK I'm not sure I ever had favourite web site ever, mostly 'cos that's not the sort of phrase I use, but this web site has put a big smile on my face today and at this time of night that's the nearest phrase that springs to mind

So what appeals so about this site? Part of it is it the range of different type of mistakes - the naff ones, the glaring "how did they not spot that"ones, the "did they really think they could get away with that" ones*, the floating hands where you know someone has been on a tight time scale and just missed something small at the last min. There is certainly a pinch of "well my attempts with the clone brush don't look so bad after all".

But the ones that amazed me most were the ones that highlight just how much the "fashion" media fakes the body beautiful. Probably the best example is (Warning: lingerie photo ahead) this where the shadow shows the model's true figure**; but actors, singers and comedians are not immune either.

Every few months or so there are articles in the press about if modern fashion is affecting girls growing up today and giving them low self esteem. Well me thinks those articles should point people to this site to say aim for an average weight / BMI, stay fit and healthy and let photoshop do the rest***.

UPDATE:
Errr... shouldn't the back out go over the baby's eyes

I remember this film poster it was in the tube right next to where I stand most mornings, and I remember thinking was that really the best they could do.