Saturday, 11 August 2012

Thai Fish Curry

Thai Fish Curry with Noodles

serves 4

2 tbsp vegetable oil

1 large onion, chopped

2-3 garlic cloves, chopped

handful of white mushrooms

350g white/yellow fish fillet (cod or haddock), cut into cubes

350g salmon fillet, cut into cubes

2 tbsp Thai red curry paste

400g / 1 can coconut milk

handful of fresh coriander, chopped

1 tsp brown sugar

1 tsp fish sauce

2-3 spring onions, chopped

2oz beansprouts

3-4 basil leaves (pref Thai basil), finely chopped


  1. Heat the oil in a wok and gently sauté the onion, garlic and mushrooms until softened but not browned.
  2. Add the fish, curry paste and coconut milk and bring gently to the boil. Simmer for 2-3 minutes before adding half the coriander, the sugar and the fish sauce. Keep warm.
  3. Meanwhile, soak the noodles for 3-4 minutes or until tender, and drain well through a colander. Put the colander and noodles over a pan of simmering water. Add the spring onions, beansprouts and most of the basil and steam on top of the noodles for 1-2 minutes or until just wilted.
  4. Pile the noodles into a serving bowl and to pwith the fish curry. Sprinkle the remaining coriander and basil over the top and serve immediately.

Taken from "Wok & Stir-Fry" published by Parragon Books Ltd and with a few alterations by me.

Sunday, 10 June 2012

Stone Code Sober (also, don't use ConcurrentBag in Mono)

Ugh. Saturday night, sans alcohol, post-Prometheus. Sobriety on a weekend evening can only mean one thing... staying up till fucking 4am and writing code.

As it happens, I did have something to try and achieve. Namely, getting some prototype Spring.Net-based code working in Mono, running under XSP, running on an Ubuntu box.

The code itself is based on some of the same ideas as a current piece of work - a custom http handler and framework that is built for speed and simplicity. At the heart of it is a message bus with attached listeners waiting for commands and an application context to be delivered. The listeners act on the context and it ends up holding the output state ready for the response to be marshalled. It is quite straightforward and /very/ fast, utilising singleton objects from Spring.Net.

Now, I have an Ubuntu box (shard, a little ultra-small-form-factor Dell, bless it) and I've already been through the pain in the arse of getting Spring.Net working under Mono. Well, just Spring.Core really, but that's the only bit I'm interested in so fuck it, whatever. I'm using Mono 2.8 which gives me .Net 4 functionality. If you're interested in getting Mono/XSP working on Ubuntu or Fedora Linux then I highly recommend this page which has a comprehensive install script. I did have to do a little bit of make check; make install afterwards to bring my MonoDevelop stuff up to date, but aside from that it went smoothly (although it took about 45 minutes on shard!).

So, I have .Net 4 capability, a working Spring.Net/Common.Logging build, and that script gave me XSP version 4. I've never used XSP before but there are quite a few good pages on it, even if they do appear to be from 2006. Hell, I can't even remember if we had Google back in 2006. There followed a couple of bumps of a) remembering that I had to set up the custom http handler part of it in the web.config, and b) my .Net solution in MonoDevelop won't make an ASP.Net web application project that uses anything above version 3.5 for reasons best known to itself, which stops you referencing the projects directly from the web host. However, XSP and Mono are more than happy with it, so I made an empty library project that referenced the projects and now have a pre-XSP step that copies the latest DLLs into the web host application.

Alright. Now I have a working application. Almost. This happened:

This kept me going for over an hour, having to break bits of code by design in order to get a sensible answer out of Mono since I couldn't attach a debugger to it.

The problem occurred whenever the Store behaviour was called. Now it turns out that this behaviour happens to be the only one which refuses to do anything if the user isn't authenticated. Like so:

When the behaviour returns false, that signals that the command that is being delivered on the message bus has not been fully satisfied. So therefore it will move on to the next listener it has. Here is the delivery code:

Now what I couldn't fathom, is why this somehow breaks in Mono but runs fine under Windows. The bug is essentially implying that there is a listener in the collection which is null. I was feeling paranoid about this and so I made sure that there was a null check on the Add routine in the message bus.

Ok, so. All good, yeah?

No. Still fucked. In desperation, I added some code to show the listeners collection every time a message was being delivered. The result?

There were 2K of listeners in each of my two message buses listener collections. WTF?

The listener collection is pretty straightforward:

So just a ConcurrentBag of my interface type. That's absolutely fine and to my knowledge I had no reason to believe that it would spawn extra capacity.

I ran that particular test with an unmodified listeners collection on my Windows build and received the following result:

Which is correct behaviour. WTF?!? It turns out that there appears to be different behaviour for the System.Collections.Concurrent.ConcurrentBag in Microsoft.Net 4.0 and in Mono 2.8, where the Microsoft version enumerates correctly based on number of added items, and the Mono version seems to enumerate over an extended capacity.

Given that there is little practical difference in contention handling between locking on a System.Collections.Generic.List and using a ConcurrentBag, I started to use a List as it doesn't have the same retarded behaviour.

Yay! Working application... And now when running the upload tester...

Which gives me one of these...


At which point it was time for sleepz.

Friday, 8 June 2012

Sunday, 3 June 2012

How to Stop .Net 4 Client Profile being The Default in Visual Studio and Cocking Everything Up

The .Net 4 Client Profile project target in Visual Studio happens to be, about every couple of weeks or so, the bane of my fucking life. I will make a project, forgetting that it is the default for some of the templates and proceed to spend ten minutes wondering why the hell I can't find any references. This annoys the hell out of me and I have not found a way to back out of it being installed as a default for many types of project (listed on this msdn page)

At the behest of a work mate, I'm going to write this short guide on how to change the default for these projects.

In this example, I am going to change the default project target for the Console Application project type.

1. Find the right folder

I don't know where you have Visual Studio installed, but mine is at "C:\Program Files (x86)\Microsoft Visual Studio 10.0"

Further, you need to find where it keeps the project templates.

Should be in: {visual studio directory}\Common7\IDE\ProjectTemplates\CSharp\Windows\1033 (where 1033 is your language region)

2. Open up the archive

Actually, best bet is just to extract it somewhere

3. Edit the file "consoleapplication.csproj"

Here we go. In the top PropertyGroup section. Here's the bastard to remove:

  $if$ ($targetframeworkversion$ >= 4.0)

Scrub that motherfucker like it ain't no thang.

4. Save, replace in archive, etc, etc


5. Wondering why this didn't work?

Because of reasons that I cannot fathom, there is a cache of the project templates.

6. Copy the files into the cache

They will need to go into a folder called "", which will be found at: {visual studio directory}\Common7\IDE\ProjectTemplatesCache\CSharp\Windows\1033


There... Hopefully that feels better. Thanks for wasting my time, Microsoft.

Thursday, 24 May 2012

Projects, Mono, old habits...

I checked out Mono on Ubuntu yesterday and I'm massively impressed so far. It picked up an old .net application that I wrote to publish RSS articles for the Dirty Fire Project website and it worked flawlessly. I think it will be perfect for the side project that I'm working on with an old friend. More on that some other time...

And on suggestion from a new acquaintance, I spent a while getting back in touch with my bass... I hate being rusty and just playing again is so good. More!

Work is interesting. The new tracking cookie legislation in the UK is hitting us hard but it looks like we have a working management solution now. Testing tomorrow, so fingers crossed. I believe we aren't under pressure to release anything until next week so we can test it all tomorrow as required, get it signed off without a rush and then prep the second deployment head in relative calm. Let's hope it works! And, you know, doesn't destroy our billing system, campaign traffic partners, database... o.O

And it's too hot to sleep.

EDIT: Blogger for Android is literally the worst fucking user experience ever. I've been trying to get the Dirty Fire Project website link right now for 30 minutes. Even when I went to the website desktop version from my phone to fix it, the cursor doesn't work properly. The Android app can't even get the right time and date for posts so they appear completely out of order. What a barrel of shite.

Tuesday, 28 February 2012

Spring woes

This blog: ... just saved me a tonne of pain. Although admittedly this was after suffering about 2 hours of pain at the hands of Spring.Net completely failing to work all of a sudden.

I'd just re-factored some caching code out of an application-specific project and into a general support library. The caching system is set up in Spring.Net and uses generics syntax to define a cache (which is HashSet based) of an application entity object. This was fine before I re-factored because both the cache and the entity object were in the same assembly. However, after the re-factoring, Spring was completely unable to initialise the caches and saying that it couldn't find the type.

The blog explains that if you are using the generics syntax to define an object which consists of objects that are from a different assembly, then it is not sufficient to use the long-hand qualification syntax. You need instead to create a typeAlias entry for each of those objects from outside of the generic's assembly.

So I was expecting the following to work:

<object id="ThisDoesntWork"
type="Asura.Storage.Caching.Cache&lt;PPT.Entities.Contact, PPT.Entities>, Asura.Storage">

But instead I had to add this to the config sections:

<section name="typeAliases" type="Spring.Context.Support.TypeAliasesSectionHandler, Spring.Core"/>

And then this to the spring section:

<alias name="Contact" type="PPT.Entities.Contact, PPT.Entities" />

And then the object itself looks like this:

<object id="ThisDoesWork" type="Asura.Storage.Caching.Cache&lt;Contact>, Asura.Storage">

Anyway, see for the full article.

Saturday, 25 February 2012

GiveCamp project continuing...

So I'm having a cheap Friday night by staying in and doing some more coding on the project that was started at #GiveCampUK back in October. We've pretty much decided on the database schema now which has meant that I can spend time setting up the entities and support libraries for the application.

Originally, this was going to be an application written using Microsoft Lightswitch, a simple query screen development platform sitting on top of Entity Framework 4. However this was canned due to limitations in Lightswitch preventing us writing queries that would perform well. It's a nice idea and environment (once you've got your head around it), but it's profoundly limiting with respect to what it allows you to do with the queries it generates. So, as I said this was canned after it became clear that it wasn't going to play nicely.

Therefore, I find myself writing a .Net WinForms application. But I've hit a problem which may see this just go back to being a website.

I've put a lot of effort into the model and store patterns used, into the caching that will be available to the application, into the Spring.Net implementation which keeps the whole thing easy to configure, into the stored procedures performing basic data access to the entity tables; but it's no good:

The problem is that this will be used by more than one person, at the same time.

Therefore, if something changes in the database, every connected application must be kept up to date.

This causes me a massive, massive problem for consistency. But I don't know if I am worrying about this unduly? After all, the people using this aren't going to be doing break-neck speed data entry, they aren't going to be removing large swathes of the database, they're probably going to be doing one thing each, and they're probably going to be in the same room. So, how much do I worry about it?

What I have currently is a watchdog system. A scheduled background task in the application calls 'home' to the database to determine if there has been a change since the last time it checked / a change occurred. This notifies the master cache that it should reload its data again. The application needs to make sure that this behaviour does not interfere with what the user is doing too much, and I don't know at this point whether it will do that.

I'm going to try and press in with this as a simple WinForms application, but it is very tempting to just make it an ASP.Net website which means that all the locking can be performed locally and safely.

Maybe I should've gone to the pub after all...

Tuesday, 17 January 2012


Checklists. Tea. Tense. Putting a Spring.Net - based job processor live today which will run tings seen and unseen.


Deployed :)

Monday, 16 January 2012

Problem on site...

Problems today on the site as the Logging database filled... That was fun. The whole site started hitting 5.5 second delays as every logging write would cause the database to automatically grow. Interestingly, it happened exactly a month ago as well (massively blaming DBAs).

Just making a note of it here so I can look it up next time :)

Thursday, 12 January 2012

Deadlines schmedlines

Ok, so we missed a deployment window today. It was for a Spring-based job processor that will support the website by handling fire and forget jobs. Luckily the only fallout will be the twiddling of thumbs tomorrow and a few people inconvenienced. It was close, but the prospect of releasing such a thing without it being fully tested and proven on staging was too much for both our team lead and myself to bear. However, through the course of the afternoon we put the system through a whole bunch of failure scenarios which should mean that Monday's deployment will go better in the light of the knowledge gained and the configs puzzled over.