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.

Yay visual studio yay

Don't you just love opening your IDE and ask it to compile only to have it say back to you it cannot because there is an undefined class.

You look at the class and notice that it is already defined so you recompile a few times to no avail, it still doesn't compile

Out of desperation you restart your IDE and then as if by magic, your IDE realises it actually knows what the hell it is doing?

yeah love it.

Visual Studio, the IDE with Alzheimers

Tuples and Record

When I sit down to learn a language and I learn it has tuples I immediately smile. They are an nice feature to any language and F# has a nice implementation of them.

Like every other data structure they are quite easy to implement

let aTuple = (1, 2);;

Another nice feature is that tuples also work with the F# pattern matching, an example is as follows.

let greeting (name, language) =    

 match (name, language) with     

| ("Steve", _) -> "Howdy, Steve"    

| (name, "English") -> "Hello, " + name     

| (name, _) when language.StartsWith("Span") -> "Hola, " + name     

| (_, "French") -> "Bonjour!"     

| _ -> "DOES NOT COMPUTE"

So the '_' operator, which is the match everything also works in tuples. So again super fun happy time.

So then we move onto Records. In my head the main difference between a tuple is and a record is persistence.  A tuple to me feels like a throw away value where as a record, since the fields are name has aa degree of persistence. 

Compare to most other F#, Records have a slightly different syntax. 

First you need to define you record. 

type website = 

 { title: string;

    url: string};;

then you define it like normal

let google = {url = "http://www.google.com"; title = "google"};;

As you can see, the order of the attributes do not matter. 

Now if you want to reference a Record you simply use the field name

Google.url;;

So easy.

Now here is the only hard bit to wrap your head around. F# is immutable, variables do not vary, hence why i call them values. Immutablity is a hard concept if you are new to it. At the heart of it the value will not change, instead you create a new one. 

So you delcare a Record, for example lets say a coordinate, 

type coordinate = 

 {X: float;

 Y : float};;

let start = { X = 1.0; Y = 1.0};;

So that delcares the starting point. But coordinates by there very nature change, if I cannot mutate the variable what do I do? well F#'s answer to this is to clone the value. 

let SetX item newX = 

 { item with X = newX};;

let finish = SetX start 15.0;;

That is F# Tuples and Records in a nutshell. 

F#: A Tail of recursion

Get it? Tail recursion? It is a joke you see, you are not laughing, well, I am not being paid to make you laugh.

Anyway, in all seriousness if you are like me, you look around at various things, reading snippets about various languages and the concept of tail recursion keeps on coming up and it is rare that anyone really describes what on earth it is.

Recursion is a part of functional programming, you go through uni and more often than not the lectures will claim it is what makes a language functional, (they are wrong, but my anger towards the educaction of my profession is another story).

So what happens in normal recursion is that when your program calls a function it pushes the instruction pointer (the address in the program code that identifies the next operation to execute). Once the function returns the stack is cleared and the instruction pointer is restored and the program continues along its merry way. Simple stuff right, all coming back to you from your computer theory classes?

Anyway recursion can throw a spanner into the works, a stack generally has a fixed block of memory it is allowed to use, generally around 1mb, so if your recursive function is given a large amount of data to work through, you will most probably enter the realms of the stack overflow.

So this is where tail recursion comes into play, the idea behind tail recursion is that nothing will execute after the recursive call, since there is nothing left to execute after the recursive call there is no need to store the instruction pointer on the stack, so indeed the stack stays nice and safe and you will not see that dreaded stack overflow.

BUT I hear you say, that is all well and good for simple recursive functions, but what happens when I need to do some operations of the result?

To answer this, lets us do an example.

let rec fib = function

| 0 -> 0

| 1 -> 1

| n -> fib(n - 1) + fib(n - 2)

This is not a tail recursive function and infact if you wanted to know the fibonanci number of somethign stupidly large you will get a stack overflow.

What we know about fibonnaci numbers is x = (x -1) + (x -2) and when we are working out x we already know x -1 and x -2 so we can pass them around as parameters

let fib n =

let rec loop acc1 acc2 = function

| 0 -> acc1

| n -> loop acc2 (acc1 + acc2) (n -1)

loop 0 1 n

F# Guards are my hero

Previously I mentioned pattern matching which is a nice feature of F#. It is suggested that it is the most powerful feature of F# and I am starting to see why especially in conjunction with Guards.

Continuing my comparrison of F# and Erlang pattern matching erlang also offers guards, but it only has only a few built in guards where as F# you can do whatever you like.

For example

let randomTest = function

| x when (x > 0 && x <> "return value"

|0 -> 0

|x when (x <> "return value"

Granted my example is retarded and simplistic and pointless but hopefully you can see the awesomeness of being able to give whatever you want in the guard clause.

Also the cause doesn't need to be built in functions it could be something like

|x when (x > 0 && (someFunction x) == true) -> "return value"

The downside.

Erlang only offers a small set of built in guards because that way they can guarentee they will terminate but in F# since the programmer can define his own guard clauses, who knows, if they make a mistake the function may never terminate.

So F# gives a decent amount of control over patterns but no promise of relability

Fibonacci Sequence, I totally know you

Edit -> sorry about the formatting, it exploded and I am far to lazy to fix it.

So I have looked at the first tutorial of F# and created my first program which I will get onto in a minute.

My first impressions is that F# is the bastard son of many programming ideas, for example each of these are valid forms of iteration within F#

let processItems (items : Item []) = 

  for i in 0 .. items.Length do

    let item = items.[i] in

      proc item

And

let rec processItems = function
  | []       -> ()
  | hd :: tl ->
      proc hd;
      processItems tl // recursively enumerate list

And

for item in collection do 
  process item

So to say it is a functional langauge isn't entirely correct. It is a mixed paradigm
taking ideas from OO, imperative and functional, which in itself is really 
interesting. 

Onto my sample program, like most tutorials the first thing they get you to do is a 
fibonacci sequence generator.

Here she is

start code

#light open System  let rec fib = function
    | 0 -> 0
    | 1 -> 1
    | n -> fib (n-1) + fib (n-2) 
let main() = 
    Console.WriteLine("fib 1 = {0}", (fib 1))
    Console.WriteLine("fib 2 = {0}", (fib 2))
    Console.WriteLine("fib 3 = {0}", (fib 3)) 
    Console.WriteLine("fib 4 = {0}", (fib 4))
    Console.WriteLine("fib 5 = {0}", (fib 5)) 
main()

end code


The #Light line is a nice one, when playing in the REPL everything was of this sort 
of format

let x = 5;;

But #light allows the programmer to omit redundant tokens such as the ';;' and it 
makes whitespace important. So so tabs throw warnings, but if you have set up your 
vim correctly, it will have no issue.

Secondly pattern matching. You do not need to use if, else, switch etc statements 
which is cool. From my understanding of erlang, F# seems to offer a nice stepping in 
point to a very unique language. But that being said I do not know enough about either
language to support that claim very well.