Be careful where you get your information

The internet is rife with misinformation.

As a developer you tend to depend heavily on searching for examples of how to solve a particular problem such as code snippets, and patterns and practices. There is very little ground breaking work and it is almost certain that someone has been there, done that, and blogged the solution to your problem already.

Problems arise when you choose the wrong source to trust. For example, today I was trying to figure out how to get ASP.NET not to render a name attribute for the form element as we are starting to target XHTML 1.1 compliance for BeforeYouBuy. A quick google came up with this.

Certainly the answer that is proposed is “a solution”, but it’s certainly not “the solution”. A slight modification to my search turned up this how to on the msdn site.

It’s really down to knowing where to look.

Superstring theory 101

I thought I’d post this presentation Brian Greene did at TED in 2005 given that it seems a few people are interested in the book I’m currently reading:


The presentation is a fantastic primer on Superstring theory and, should it wet your appetite, the book will certainly appeal.

We’re typists first… really?

I read Coding Horror on a semi regular basis, and generally Jeff has a pretty engaging writing style and his posts are fairly interesting. I was really surprised when I read this one though.

Jeff ascertains that “We are typists first, and programmers second”.

Well, I vehemently disagree. While typing ability is obviously important in the job and a necessary skill, saying that we are typists first places very little value on the technical skills required of programmers to do their job well (not to mention the years at university most of us have spent earning our Computer Science degrees, Masters and in some cases PhD’s!).

Personally I don’t even like the label “Programmer”. I feel it undervalues the skills I have. Software Engineer is far more accurate description of the job most of us do. Writing a non-trivial application these days requires an understanding of many challenging concepts.

Todays Software Engineers need to consider concurrency issues, network theory, efficient persistence mechanisms, efficient search algorithms (the volume of data we are dealing with is growing exponentially), but to name a few.

Let’s not sell ourselves short by calling ourselves programmers.

Returning to Jeffs’ typists first allegation though, one comment on his post summed it up nicely for me:

I’ve always really liked your blog Jeff, but this is a BS post


The Big Bang Theory, the best thing on TV right now?

If you haven’t yet seen The Big Bang Theory you should make an effort to rectify the situation immediately. It really is an excellent show based around intelligent witty humor rather than cheap laughs and tremendously funny.

The story focuses around two ubergeeks, Leonard and Sheldon and how their life changes when they meet Penny their new “normal” (and very pretty) neighbor. I love the fact that the show celebrates the geeky, ultra intelligent side of their characters and although most of the laughs come from their lack of ability to deal with normal every day social situations, the writers do it in such a way that is funny without making Leonard and Sheldon the butt of every joke.

The Big Bang Theory manages to mix in enough scientific content and references to keep us geeks happy while still being incredibly watchable and entertaining for those with less of a penchant for things science.

Check out a few snippets from the first show of season one:

If you haven’t seen season one it’s already out on DVD, grab your copy now, you won’t be disappointed!

var country_code = geoip_country_code();if (country_code != “GB”){ document.write(“”);}else{document.write(“”);}

MooTools ASP.NET Webservice Ajax calls.

I had some trouble trying to find an example of how to call an ASP.NET webservice from MooTools. I eventually pieced the bits together from a couple of forum posts and thought I’d post an example here in case anyone else was having the same problems.

If I have an ASP.NET webservice that has a GetById method that takes a single int parameter and returns an object I can call it with the following code:

function doAjaxWebServiceRequest (id) {
var completeDelegate = Function.createDelegate(this, this.callback);
var failureDelegate = Function.createDelegate(this, this.error);
var request = new Request.JSON({url: ‘http://hostname/MyWebService.asmx/GetById’,
onComplete: completeDelegate,
onFailure: failureDelegate,
urlEncoded: false,
headers: {“Content-type”: “application/json”}
request.send(JSON.encode({‘id’: id}));

The returned object will be in JSON format. The lines where I create my callback delegates using the Function.createDelegate method allow me to set the scope of ‘this’ in my call backs to be the object I making the request from.

Hope that helps someone out!

Mootools differences in IE and Firefox

We’re using the MooTools scripting framework on our site and today I discovered a strange difference between Firefox and IE. I was creating an element and injecting it into the DOM and then trying to change its CSS class and styles.

addClass and setStyle
MooTools provides methods on it’s Element class that allow you to manipulate the CSS styling of an element. You can do things like:

// Add a css class to the element with the id foo

// Set the width of the foo element
$(‘foo’).setStyle(‘width’, ‘100px’);

Unfortunately when viewing an ASP.NET page in IE that includes a script that uses these functions you get a script error saying that the “Object doesn’t support this property or method”

At first I thought the solution was to go back to basics:

// Add a css class to the element with the id foo
$(‘foo’).className = ‘fooStyle’;

// Set the width of the foo element
$(‘foo’).style.width = ‘100px’;

However I then realised that I was trying to call the MooTools Element methods on a vanilla element object rather than a MooTools one. The second line below solved the problems in IE and meant I could go back to the first way of applying the styling.

var myelement = document.createElement(“a”);
myelement = $(myelement);

IE vs Firefox
In retrospect it seems strange that this worked in Firefox, I guess Firefox must be able to do some sort of implicit conversion to a MooTools element in order to resolve the method call.

MooTools seems really great, it’s lightweight and easy to use. The learning curve seems much lower than some of the other more complicated offering available.

The only reservation I have at this point is that from what I’ve read on the forums it doesn’t play nicely with any other scripting framework due to it’s lack of namespaces and the maintainers seem quite hostile to anyone who suggests that would be a good thing.

NMock and out parameters

While trying to create a unit test the other day I came across the situation where my mock object needed to return a value via an Out parameter. A quick google turned up this post over at dev:ices.

I thought that had answered all my questions but when I tried it I kept getting a very unhelpful error:

—— Test started: Assembly: Tests.dll ——

TestCase ‘Tests.BatchOrderMessageHandlerTests.TestNMock’
failed: NMock2.Internal.ExpectationException : unexpected invocation of foo.DoFoo(, , out)
1 time: foo.DoFoo(equal to , equal to , equal to ), will set c=, return [called 0 times]
at NMock2.Mockery.FailUnexpectedInvocation(Invocation invocation)
at NMock2.Mockery.Dispatch(Invocation invocation)
at NMock2.Mockery.MockObject.Invoke(Invocation invocation)
at NMock2.Monitoring.Invoker.Invoke(Invocation invocation)
at NMock2.Monitoring.ProxiedObjectIdentity.Invoke(Invocation invocation)
at NMock2.Monitoring.ProxyInvokableAdapter.Invoke(IMessage msg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Tests.BatchOrderMessageHandlerTests.IFoo.DoFoo(Int32 a, Int32 b, Int32& c)
C:svnGLGParnters.TradeIdeasPositionManagersrcTestsBatchOrderMessageHandlerTests.cs(136,0): at Tests.BatchOrderMessageHandlerTests.TestNMock()

0 passed, 1 failed, 0 skipped, took 0.77 seconds.

A bit confused I quickly whipped up a trivial test as my unit test was a bit complicated and returned an enum as the Out parameter. My hypothesis was that NMocks couldn’t return an enum as an Out parameter.

public interface IFoo
int DoFoo(int a, int b, out int c);

public void TestNMock()
IFoo foo = _mockery.NewMock();

.With(1, 1, Is.Out)
.Will(new SetNamedParameterAction(“c”, 2), Return.Value(1));

int result = 0;
int a = foo.DoFoo(1, 1, out result);

Assert.AreEqual(2, result);

This also failed so I checked what version of NMocks I was using. My NMock2.dll assembly had a revision number of 1.0.2313.18049. I downloaded the latest binaries from the NMock website. Checking the version number of the latest build shows it to be

Rerunning the unit tests against this version of the NMock library everything now works!

So, if you’re having trouble with out parameters in your NMock mocks, upgrade your build version.

NHibernate 2.0 and the join table syntax

I’ve noticed my post on Mapping a view with NHibernate is always quite popular. Resorting to mapping from a view has worked fine in the past as long as you only required read access, but if you wanted to build a complex object relational mapping that you could update you were in trouble…

Until Now

With NHibernate 2.0 recently being released we now have access to the join table syntax in our mapping documents. This means we can now build more sophisticated domain objects that map on to more than one table. NHibernate takes care of the multi-table inserts and updates behind the scenes making your life easier.

This has to be one of the most underrated features of NHibernate 2.0 as it finally allows you to break away from the one to one mapping between domain objects and your relational model which has ultimately caused compromises in the past.

I urge you to check out this and the other fantastic new features available in the latest NHibernate release.