Balancing Architecture and Functionality

There are loads of jobs that we need to do on our code base. One of those is probably to introduce a caching layer, the question is when do you schedule the work to design and implement a caching strategy when using an agile, user story based process. We don't want to do premature optimisation but at the same time shoe horning a caching layer in at the 11th hour to fix a performance issue sounds like a total nightmare.

For now I think we'll wait and include it in our permissions stories, I think it can fairly safely cache all the users permissions on login and clear the cache when the session expires. It won't need to worry about invalidating cache entries, if permissions change then the user will have to log out and log back in again and at least that'll give us a base to build object caching and perhaps output caching on top of.

This interesting caching article got me started on thinking about this article,  hopefully it'll still be up when I come to need it. http://openmymind.net/Caching-Your-Worst-Best-Friend/

This one is interesting too. http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui

Don't Block the UI Thread with Task.WaitAll use TaskFactory.ContinueWhenAll

The WPF MVVM application I've been working on recently had a view model which loaded data from a couple of different sources. Like all good developers I didn't want to block the UI thread and have an unresponsive app so I did this.

 Task[] tasks = new[]  
 {  
   _resourcesService.LoadSomething(result => { /* Handle callback for this method*/ }),  
   _otherService.GetSomethingElse(result => { /* Handle callback for this method*/ })  
 };  
 Task.Factory.ContinueWhenAll(tasks, t =>  
 {  
   // Check for faulted tasks.  
   // Do tasks that can only be handled when everything is loaded  
 });  

Beware Ping.Send and the BSOD

The application I'm working on is a partially connected client-server application, it uses a mesh network and/or 3G to synchronise databases.

To test if the client and server could communicate the Ping.Send method seemed like a good place to start (although it's not ideal, an actual WCF service has to be available too). However, if you interrupt Ping.Send mid flight... BSOD. This is only really a problem in development, if the ping is returning in a reasonable amount of time then the chances of interrupting it are slim, but if the server is unavailable, and the ping time-out is too high, and I'm stopping and restarting the application frequently this leads to 4 or 5 blue screens a day.

Disclaimer, it's something at the OS/driver level that actually causes the BSOD, I've not diagnosed exactly what and I probably wont bother, it might be something specific to my network card or could be something in Windows itself but there are plenty of other people seeing the same thing, for example...

http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/1f847268-e38d-4ac3-a1ea-f41069604fd0/

http://connect.microsoft.com/VisualStudio/feedback/details/721557/bluescreen-process-has-locked-pages-netframework-ping-send

http://connect.microsoft.com/VisualStudio/feedback/details/691615/stopping-debugging-session-while-waiting-for-pingreply-causes-bsod

This final link suggests and excellent workaround...

The bug seems to appear only on .NET Framework 4.0. I do not know if the bug is in .NET 3.5 as well. I have checked, that the .NET Framework 2.0 does not show this bug. Therefore, to avoid this bug, switch back to that framework version.

...or maybe not.