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.