XMP InvariantCulture or CurrentCulture

Well it wasn’t to be all smooth sailing in my XMP adventure. It turns out dates will always be a problem in life. The BitmapMetadata class has a property DateTaken that is a string! When I copied the date from the backup file to the current file it was swapping the days and months around?

Whats wrong with this i thought?
destMetadata.DateTaken = sourceMetadata.DateTaken;

Download trusty Reflector to the travel laptop and voila!
It turns out the property getter uses DateTime.FromFiletime to get the string. It appears this uses the Current Culture to format the date. The setter parses the passed in value using Convert.ToDateTime(value, CultureInfo.InvariantCulture);

I maybe missing something and I am sure it is by design, but surely they could have used a consistent culture to save me from this? Especially on my honeymoon!
DateTime fromDate = Convert.ToDateTime(sourceMetaData.DateTaken, CultureInfo.CurrentCulture);
destMetadata.DateTaken = fromDate.ToString(CultureInfo.InvariantCulture.DateTimeFormat);


Recruitment Sucks

The biggest bain of my job by far is recruiting new hires. The market for C# developers in Sydney is very tight at the moment and what seems to be available is not very impressive. So I thought I would compile a list of my many frustrating encounters; both with Candidates and Recruiters.
We are hiring again.. so I’m sure i’ll add more in the future.

Lucene.Net

Mike, one of the co-founders of Atlassian has posted some interesting slides on Lucene, a Java OSS reverse indexing project. The slides give some insight into how Jira and Confluence make use of Lucene’s capabilities.

About two years ago, I was driving to the Snowy Mountains with Atlassian’s other founder Scott, who was waxing lyrically about the virtues of Lucene and how it could help solve Campaign Masters then current performance problem.

Two years on, Atlassian is five years old and Lucene.Net has long since been the solution to one of our biggest teething issues. Again we are looking to Lucene to do for us what our database can not, on a clustered scale. Mike’s slides cover their scaling issues and what their options and problems were for clustering. Fortunately, our situation seems much less complex and we will be testing the speed of Lucene using indexes on network storage.

Lucene.Net, AFAIK, is up to 1.9 and doesn’t currently support the Update/Delete features of it’s 2.1 Java sister.

UpdatePanel and Rendered (Inline) Javascript

It seems that the UpdatePanel essentially replaces the InnerHTML of  a DIV with the delta returned from the server. If you try this yourself you will notice that any javascript elements in the html are not fired.

All javascript registered on the server-side (if you are using .NET) with the ScriptManager is put into a separate section of the returned delta. The atlas runtime obviously then loads these scripts into the document manually.

What if the returned HTML has Javascript tags already rendered in it? Nothing.
Such was our predicament and we had no control over the HTML that would be returned to the UpdatePanel (ReportViewer Control). Could we manually load the javascript ourselves when the UpdatePanel returns the payload? As it turns, we could.

You can create script elements on the fly and they get evaluated as you do. Atlas has the ScriptLoader object that will do it for you if your JavaScript is an external reference. Tweaking this idea we got a solution that found all the new Script elements and added them to the document.

The code is below; the scriptLoader was taken from this post.
The main thing to know is that a script element has a text property that can be modified.
The atlas scriptloader sets the src property whilst the innerHTML and innerText properties are readonly.

NUnit and Dynamic Object Creation

I have had a couple of tests failing for some time that I could not fix. I came back to them today and have still not got very far. The code that fails during testing, only fails during testing and I can only guess it has something todo with the way NUnit loads the assemblies.

My problems:

ConstructorInfo constructor = systemJobType.GetConstructor(typeArray); – returns null during testing
Activator.CreateInstance(systemJobType, getConstructorArguments(node)) – returns null during testing(IEventHandler)Activator.CreateInstance(handlerType);- doesn’t return null but the cast fails during testing

The commonality in these lines is that they all use interfaces. The first two lines are trying to do the same thing in different ways, create an object that takes an interface as an argument. The use of interfaces is obvious in the second line. The interfaces are different but they are all in different assemblies to where the code is running, although they are referenced.

So im still stumped….

Is it just me?

… or is XML a really stupid choice for Build Scripts?
Im sick of writing NANT scripts in XML.

I guess it’s just me as there is almost nothing around that doesn’t use XML, at least in the .NET world.