Loosing the Language war

Everyday our log files increase, immense amount of data pours in, from server statistics, to the number of students in the application. The question of how to present this data is rapidly coming to a head.

To begin with we used Erlang, for no other reason than it was our server side language and the need to keep the language count under control is always a pressing issue on the dev team. Erlang is a heroic language it is the reason we have had 100 percent uptime on the product but it was not designed to be used as a parsing language, Why you ask?

Erlang is tail recursive passing a full copy of the parameter each time it is called, which in itself is fine and tail recursion is elegant in its own way, the problem arises with Erlang's representation of strings. Each character uses 8 bytes of memory. That's right -- 8 bytes, not 8 bits! Erlang stores each character as a 32-bit integer, with a 32-bit pointer for the next item in the list (remember, strings are lists of characters.). The reason for this is that Erlang can handle any Unicode character thrown at it, while noble in theory it was not valuable in practise.

So, with erlang out of the game there was a call out for a new language to take its place. Before my job at Monash I worked at a place called Editure and it was amongst other things a perl house, so instinctively I ran with perl, I knew it was basically unix calls with some nice wrapper around, it had a nice library support with CPAN. Sure its OO is tacked on with gaffa tape but I did not need OO for what I was doing, so perl seemed like the perfect choice.

But it still lost.

Perl did the computation at light speed, with the ability to spit the data out in HTML it made for easy automated reports but this was not enough, why? perl is loosely typed and as a result you generally have the slack to code fast and loose, which if fine when you need to hack together a report in an hour, but in six weeks time when you need to revisit your code and you have forgotten the method signature on your hand built datetime to gregorian seconds you will need to find the method instead of having the compiler yell at you for being a moron.

Perl is not a large scale maintainable language, I am sure perl 6 will change that, while it also washes my car for me but until that time perl gets too sprawling too quickly. I can understand entirely even only writing a fractional amount of perl code why Editure picked up its bags and moved into the JVM.

Also? timelocal, built in perl function has a epoch of 1900 where as other builtins have it as 1970, what the hell perl!

So, the race has seemingly been won by Scala, a functional language on the JVM written by Martin Odersky, this is where my knowledge of the language ends, but if it truly has won, I am sure I will be learning it soon.

Unit Testing: Are they valuable?

In my opinion no.

The first company I worked in, Unit tests were the holy grail, something they always wanted to do, but our codebase was so old, so complex and so intertwined it would have taken months of dev effort to write these tests and management didn't see the benefit. I left that company with the opinion that Unit tests were great, it would solve all problems and I would be a super effective programmer.

Enter my current job, I came in too a near completed version of our product and we had some serious server issue, tricky logic was just confusing us and in the end it was decided that unit tests would save us, bring us out of the maze and into the light, it was then I learnt the truth, unit tests are clunky and ugly.

Our problem was that we made the tests after we wrote the server code. So you write the test framework, run it, it goes red, you change it and run it and it goes green, but does it go green because it actually is correct or because the test suffers from the same logic issues that causes you to write the test in the first place.

So in theory you write the tests before you start the code base. So you write the test then you write the function, test the function rinse and repeat. Now some people would argue that this is the correct way to do it, but for every line of production code you have you have a line of testing, and the testing isn't guarenteed to help. Everytime you refactor you need to rewrite the tests, which could lead to the problem that we had that your test is no longer accurate.

Some people would say that writing the tests allows them to nail down the perfect design and stops the need to refactor. To that I say, anyone who says they are such a good developer that they never need to refactor their code is a liar. Code evolves with time and refactoring is the way to keep the codebase lean and clear with this evolution.

Now I am not saying that all tests are wrong, I am just saying that the fine granularity of Unit tests are wrong, Intergration/Acceptance tests are an entirely different beast and exceptionally value in a development suite.

For more information about this please read this following blog as it is the one that got me thinking about unit tests

http://blogs.msdn.com/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx

Functional Spec, how I hate you.

I have very little to say on the matter besides it is crazy that some people love doing that sort of paperwork.

If I am out, drinking or whatever, in person I can tell you what my application does no worries. I can go in depth about why we did what we did, what pedagogy we are peddling, the whole nine yard. Sit me infront of my machine and ask me to write it up, I fail hard. Oh so hard.

In the end I went for the child book analogy and made SO many picture. Oh so many.

The due date for the application I am working on has jumped forward by like 3 months and each day that goes by I am less and less certain that we can make it. In structure we are as rock solid as ever, our back end replaced from a standard server to that of an ejabbered XMPP one, adopting the metaphor of the old school mIRC chat room. So with an properly configerd erlang back end, our server never crashes, which is good.

The concern comes that we will not have the time to test the edge cases that users always manage to get themselves in the first minute they pick up the machine. Our testing team are doing an amazing job, coming at the application from various angles with a sledge hammer but even they cannot work so many miracles before they can't find anymore.

The internet Lies and other news

Over the last few months I have been slaving away implementing the design for our project. Taken on a lot of responsibility for the client side code. This has been a lot of fun and I have learnt a lot unfortunately I have not learnt how to capture damn ApplicationCommands.

You know the interne? The guy with the tubes, anyway, he told me, on the down low that I could totally treat it like a normal command. -> INCORRECT

after I told him he was a dirty liar, he then told me I could add a new command binding, again incorrect.

I have a theory as to why, I think they ApplicationCommands do no happen to behave like normal RoutedCommand. A routedCommand checks agaisnt itself to see if it has a handler and then fires it at the object with focus and THEN bubbles up the chain.

But I am thinking that the ApplicationCommand does not fire against itself to begin with, instead it goes straight to the object with the Focus, and the object has a built in handler for the command. So before I can even register the command it has fired and executed.

Also, just to make my boss happy

Did you know that mobile safari can only execute Javascript for 5 seconds. It makes sense as javascript only has one ui thread and you could risk not getting control back to your phone.

End of the Third Reich

So when I started this blog I was all happy and excited with Darkstar, saying it was the greatest thing since sliced bread, it was the be all and end all of Servers and I still think I am right, but it isn't there yet.

Working with it for a month or so now, certain things have come to light, the most deadly of which is its death spirals, a bad transaction comes in and then BOOM, it slows down, the transaction might be too big so it keeps stepping backing off to try again later, but it will never get smaller so it will never execute, it will just sit there being all destructive and mopey.

Darkstar is also too much of a black box, too much magic happens behind the scenes and as a result when it does death spiral you cannot do anything but sigh, blow out your database and restart it, which really isn't acceptable for any application.

I am really hoping that when Darkstar actually finishes that these problems get resolved as after all it is still in its beta phase because as a technology it seems pretty damn cool, but for our needs it is no longer viable.

Dragging and Dropping on a WPF InkCanvas

So I am working on the Image handling code for our app at the moment, specifically the drag and drop portion of it and boy howdy am I already annoyed at it. Firstly, if you work in VS the good ol IDE with alzheimers the thing about it is that people tell you to run in Administrator, which is all well and good up until you want to drag a file/image/x from your desktop into you app, it doesn't like it, it will not allow it and it will not tell you why. That is 30 minutes of my life I am never getting back.

So you don't run as administrator, you put a debug hook in you skeleton of a event handler and BAM, it works, it gets picked up and you are happy you thing that you will be able to get the dropped in object out of the parameters as easy as pie. Mistake number 2

All file data likes in the DragEventArgs, you have to dig through e.Data to find all your stuff out, going through more or less a massive conditional logic block asking things like

if(e.Data.getDataPresent("FileName") except it might not be a FileName, it might be something else, the ones I know of are FileName and Text, but there are probably more and you need to handle that data different as well.

So, I started hacking away and then decided screw this noise, the basic functionality of this has been done a million times, sure we will have to modify it for our resource server some point down the track, but until that day comes, I will let someone else do the work

http://blogs.vertigosoftware.com/alanl/archive/category/1040.aspx

His example code for this is very good, it is neat, clean and much better than I would have done

Refactoring

I have taken a forced break from F# due to actual work arising. Will I go back? I hope so, but the chances of it being used to replace our C# front end are doubtful.

Anyway I wanted to take the time to talk about my thoughts on refactoring. Every junior developer will hear the talk about it. Generally it will come from a senior developer and I know mine used a whole mess of buzz words, Dirty Code, Smelly Code etc, and the goal of it was to make clean code. They are 100 percent right, if you haven't had this talk, find a senior developer you respect and bring it up.

So I had my talk in my first job and it did inspire me, I wanted to write awesome code, clean, sleak fast, BUT that feeling quickly went away as I had no idea how, sure I could pick some things up here and there, remove duplication and make sure my naming convention was A) consistent with everything around me and B) expressive enough that my intentions were clear.

So time moved on and I came to my new job, refactoring as it always does was brought up again but this time the talk was replaced with this book. http://martinfowler.com/books.html#refactoring

Through the programming world a lot of people say that book x or book y is a must have and a must read. I cannot comment about most of those books, but I honestly think that Martin Fowlers book is.

This refactoring book is not a lot of preaching about the awesomness that is refactoring, although it does explain the use of it, It is mostly examples, here is situation x, it is bad because of y, here is how we clean it up.

The book also provides naming conventions for standard refactorings and trys to explain when they are useful but more importantly when they are not.

The first 3/4's of the book are relevant to all developers, the last 1/4 I stopped reading, not because it was not good, but I had no scope on it, there were discussions on design patterns that I never implemented so I could not understand why things were broken and if I couldn't understand that, there was no point me reading about the refactoring.

The book examples are written in Java, a language I do not know (I know right, weird) but I didn't find that it hurt my understanding of what was being said.