Archive for January, 2009
jQuery datepicker IE6 positioning bug
We’ve been using the jQuery datepicker on my current project and came across some strange behaviour with regards to the positioning of the calendar in IE6.
The calendar was always positioning itself right at the top of the screen instead of just below the textbox it was hooked up to but in Firefox it was working fine.
After a bit of exploration in the jQuery code (ui.datepicker.js) we worked out that the ‘document.documentElement.clientHeight’ call in the ‘_checkOffset’ function was always returning a value of 0 meaning that the position of the calendar was always right at the top of the screen.
_checkOffset: function(inst, offset, isFixed) {
var pos = inst.input ? this._findPos(inst.input[0]) : null;
var browserWidth = window.innerWidth || document.documentElement.clientWidth;
var browserHeight = window.innerHeight || document.documentElement.clientHeight;
...It turned that we were missing the doctype at the top of the HTML page which make the page standards compliant and as a result document.documentElement.clientHeight returns the proper height.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
Not having this set puts IE into Quirks Mode meaning that document.documentElement.clientHeight always returns 0.
We found a post on the Webmaster World Forum which helps explain why this change makes a difference.
F#: Forward Operator
Continuing on my F# journey I came across a post by Ben Hall describing the approach he takes when learning a new programming language.
One of the approaches he describes is that of writing unit tests to help keep your learning on track. I’ve only been using the F# interactive console so far so I thought I’d give it a try.
After reading about the somewhat convoluted approach required to use NUnit or MBUnit to write F# unit tests I came across XUnit.NET via Matthew Podwysocki’s blog post about FsTest – a testing DSL he’s written to use on top of XUnit.NET.
One of the cool F# features I came across while reading Matthew’s post is the Forward Operator (|>).
This is particularly useful for writing test assertions which read like English. For example:
[<Fact>] let list_should_contain_3() = [1..5] |> should contain 3
Typically we would have the function followed by the data we want to apply it against but using this operator allows us to do it the other way around.
From my understanding the forward operator (also known as the push operator) pushes the value from the left hand side of the function to the first parameter of the function.
To use a simpler example of adding 5 to a number.
Normally we would do this:
> (fun x -> x+5) 5;; val it : int = 10
Using the forward operator we can do this instead:
> 5 |> (fun x -> x+5) val it : int = 10
If we look at the definition of “|>” this makes a bit more sense:
> (|>);;
val it : ('a -> ('a -> 'b) -> 'b) = <fun:clo@84>It takes in 2 arguments “‘a” and “(‘a -> ‘b)” and returns “‘b”.
The first argument in this case is the value ’5′ and the second is a function which takes in an “‘a” and returns a “‘b”, in this case the (x -> x +5) function.
Armed with that knowledge the DSL example hopefully now makes more sense. To recall with the full code:
#light open Xunit let should f actual = f actual let contain (expected: int) (actual: int list) = Assert.Contains(expected, actual) [<Fact>] let list_should_contain_3() = [1..5] |> should contain 3
This is the same as writing the following:
[<Fact>] let list_should_contain_3() = should contain 3 [1..5]
Working from the ‘should’ outwards…
> should;;
val it : (('a -> 'b) -> 'a -> 'b) = <fun:clo@0_1>It expects to take in a function (‘a -> ‘b), a value (‘a) and will return a value (‘b).
In this case that function is ‘contain’:
> contain;; val it : (int -> int list -> unit) = <fun:clo@0_2>
It expects to take in two values (an int and a list of ints) and doesn’t return any value (unit is the equivalent of void in C#.)
Evaluating both together:
> should contain;; val it : (int -> int list -> unit) = <fun:clo@88_1>
Here we have a partial application of the ‘should’ function i.e. we have only passed in one of the arguments (the ‘contain’ function). We have now created another function which requires an int and a list of ints and returns nothing.
If we now take the whole statement together:
[1..5] |> should contain 1;;
It seems like the [1..5] should be applied as the first argument to the ‘contain’ function but in actual fact the precedence rules dictate that the right hand side of the “|>” gets evaluated first meaning that the 1 is passed as the first argument to ‘contain’.
The [1..5] is passed in as the second argument to the ‘contain’ function completing all the inputs needed by the expression and therefore executing the Assert.Contains(…) assertion.
Matthew Cochran has an article which helps explain the operator with some diagrams and Matthew Podwysocki talks about it more in his post about language oriented programming.
I’m new to F# so if I’ve got anything wrong about the way this works please let me know.
Agile: When is a story done?
I’ve worked on a few different agile projects and one of the things that hasn’t been completely consistent is when we consider a story to be ‘done’.
There seem to a few different approaches, each of which has its benefits and drawbacks.
Why do we care?
We care about ‘done’ for tracking the points we have achieved in an iteration and for knowing when we have added the value the story provides. For this post I’m interested in ‘done’ in terms of when we count the story towards our points total.
Business proxy signoff
With this approach we count a story as done when it has been signed of by a business proxy, typically a client business analyst or maybe a combination of a BA/QA.
The benefit of this approach is that we have normally have better access to a BA meaning that we don’t end up having stories piled up waiting to be signed off as being done.
I have seen 2 mini approaches, both of which require a story walk through with the BA/QA:
- Acceptance tests pass => Done
- Acceptance tests pass + exploratory testing satisfactory => Done
With the first approach any bugs beyond the acceptance criteria will be tracked as bugs whereas with the latter the story will be moved back and just considered incomplete.
The disadvantage of either of these approaches is that we are counting something as done before it’s actually been signed off by the business, which means that we might have a false sense of the value we’re delivering. If the business proxies are communicating regularly with the business though I don’t think it’s necessarily a problem.
Business signoff
With this approach we only count a story as done when it has been signed off by our business stakeholder.
The benefit is that when a story is classified as done we have actually delivered something that is acceptable to the business.
On the other hand, when using this approach it’s fairly important to have access to the business stakeholder on a regular basis if the velocity of the team is to be measured accurately. When we don’t have this access we can end up with a backlog of stories waiting for sign off, all the while lengthening the time from when it was last worked on to when it is eventually considered complete.
In production
This is an approach which I haven’t seen used on a project but which I read across in a post written by David Laribee.
I can see how this makes sense as we haven’t actually delivered any value to our customer until the software is actually being used.
I think the difficulty of using this approach would be if we aren’t releasing code into production regularly – we wouldn’t get feedback on how we’re progressing and therefore would have more difficulty noticing when things in our process aren’t working as well as we’d hope.
In Summary
I think the further down the process we consider a story as done the more accurately our points total represents the value added to the customer.
Although we can get quicker ‘points feedback’ by classifying done earlier in our process, the accuracy of what that points total actually means is perhaps lowered.
I’m not sure which approach is the best one because each has its benefits and drawbacks. It will be interesting to see whether there are any further variations on what is considered ‘done’ on future projects I work on.
I am aware that I may be asking completely the wrong question and what we should be asking is ‘Does it matter when it’s done other than for reasons of tracking velocity?’
F# Option Types
I’ve been spending a bit of time working through the Real World Functional Programming book to learn a bit about F# and one of the cool features I came across today (while reading Chris Smith’s post on F# lists) is the Option type.
I first came across this idea a few months ago when discussing null handling strategies with a colleague who pointed out that you could get around this problem in Scala by using the Option class.
From what I can tell this works pretty much the same way and solves the problem that we have when we want to perform an operation but don’t know whether or not a value will be returned.
If a value is returned then we don’t have a problem, but if not then we want a clean way of handling this.
One example of this is when trying to retrieve a value from a collection. When we try to get a value which doesn’t exist this would typically throw an exception.
To give an F# example, trying to find the value 7 in a list from 1-5:
1 | List.find (fun x -> x = 7) [1..5];; |
This throws the following exception:
1 2 3 | System.Collections.Generic.KeyNotFoundException: The item was not found in the collection at Microsoft.FSharp.Core.Operators.not_found[T]() at <StartupCode$FSI_0277>.$FSI_0277._main() |
Luckily there is another way of trying to find this value:
1 | List.tryfind (fun x -> x = 7) [1..5];; |
val it : int option = None
Note that the type is now ‘int option’ with a value of ‘None’. If we search for a value that does exist:
1 | List.tryfind (fun x -> x = 3) [1..5];; |
val it : int option = Some 3
We get a return value of ‘Some 3′.
The beauty of this approach comes when pattern matching against these values. To give a contrived example:
1 2 3 4 5 | let find value list =
let option = List.tryfind(fun item -> item = value) list
match option with
| None -> printfn "Value %d not found" value
| Some(valueFound) -> printfn "Found value: %d" valueFound;; |
> find 1 [1..5];; Found value: 1 val it : unit = ()
> find 6 [1..5];; Value 6 not found val it : unit = ()
I really like this idea and it seems cleaner than approaches I have used in C# and Java to achieve a similar outcome. I’m sure I’ll come across more usages for it as my knowledge of F# increases.
Incidentally, Luis Diego Fallas has written a cool post showing how to use option types in C#. The syntax obviously isn’t quite as clean as it is in F# but it still reads reasonably nicely.
2008: My Technical Review
Others in the blogosphere seem to be doing 2008 round ups around about now so I thought I’d jump in on the action.
Project Overview
- I worked on 5 projects this year writing code in C# 2.0/3.0, Java and Ruby.
- 2 of the projects were writing client side code, 2 web applications and 1 writing services.
- The domains I worked in were investment banking, insurance and an industrial automation system
What did I learn in 2008?
Probably the year in which I’ve learn the most so far and I’ve blogged a lot of it previously so these are just some of the main points that come to mind.
- I hadn’t worked on a legacy code base until this year but got the opportunity to work out how to put tests around code written in a non TDD way. I still have more to learn around this area and Michael Feathers ‘Working Effectively with Legacy Code‘ is probably the best place to learn it.
- I thought I had a reasonable grasp on coding in an Object Oriented way but I worked on a project in the second half of the year where I realised how much more could be done by sticking to the principles. We tried out object calisthenics in some coding dojos and I learnt a bit about the idea of managing the flow of an application through using lots of small fine grained objects rather than putting a lot of state into a smaller number of them.
- I’d heard of REST but hadn’t worked with this approach on any projects. I did on two projects this year and I think what it advocates ties in very nicely with my current preference for minimising state and keeping it simple.
- I worked on projects which all approach agile in a slightly different way. My favourite approach was on a project at the start of the year which was termed lightweight agile by one of my colleagues. Looking back on it now I suppose it was almost lean in a way – we had some process but not too much, information about stories was only shared just before it was needed and we spent really high percentage of the time coding. It just worked!
- I started writing this blog with some regularity and realised that putting your thoughts into words makes them much clearer in your own mind. I think sharing your learning is not only a good way of tracking what you have learnt but for providing a starting point for others trying to learn the same things so I intend to keep doing this.
- Twitter is a really good learning medium – I wrote previously of how I was using Twitter as a learning tool and since then it’s proved itself again with some interesting conversations about the Context/Spec framework Scott Bellware wrote and which Glenn Block is learning about, and some interesting ideas around Software Craftsmanship by Corey Haines and Cory Foy. I’ve not met any of these guys but Twitter has given me the opportunity to learn from them which I think is really great.
What do I want to learn in 2009?
There are bound to be areas of learning that come up which I hadn’t considered and I’ll gain knowledge in those areas, but these are some of the areas that I already know I need to improve in.
- Reading code bases – This is one thing I’ve ended up doing much more in 2008 than 2007, in particular reading the code of open source projects. Going to the source is one of the best way of learning different approaches to problem solving and I’m keen to learn techniques for doing this more effectively. I intend to blog my thoughts on different code bases as I did for Oxite as I find doing this allows me to gain more from the process.
- In my reading of open source code I’ve realised that code written for frameworks is much different than that written for applications. I’m keen to spend some time coding like this, just need to find an open source project that intrigues me enough now!
- Functional programming – I have played around briefly with Erlang and F# this year and in the latter part of the year I’ve had the opportunity to work with some of the functional features in C# but I haven’t practice for any length of time yet. I’m keen to see how doing so will influence the way that I write code in imperative languages. I imagine that if I work in the Java world at some stage in 2009 Clojure will be another language to look at.
- How to utilise coding dojos effectively – a more general area of learning than the others but I want to try and work out if/how we can make these sessions about deliberate practice to make them more effective for improving skills.
- How to apply lean on projects – I’ve been doing quite a bit of reading about the The Toyota Way and Lean lately and I’m keen to see how we can apply this principles on software projects. I think this will be in the form of applying agile principles more effectively but it will be interesting to find out.
