Learning functional Javascript through Koans

July 19, 2010 by mrdavidlaing · Leave a Comment
Filed under: HOWTO, Javascript, Software Craftmanship

Given how Javascript interpreters are improving in leaps and bounds; and that it seems to be the only language that will be supported by all web devices; its time to for me to revive my Javascript skilz. Fortunately the tooling has improved greatly; Eclipse 3.6 for Web Developers and JsTestDriver bring a refactoring and a unit test runner to Javascript development.

Interestingly, Javascript seems to have more functional than object orientated characteristics; so it seems reasonable to learn it wearing my functional hat.

I’ve been enjoying learning Ruby syntax via RubyKoans – little tests that teach you syntax and convention as you make them pass

I though I’d create a similar set of Functional Javascript Koans to help refresh my Javascript skills.

Its a bit rough; so please fork and contibute back improvements.
http://github.com/mrdavidlaing/functional-koans

Tags: koans; javascript; functional

Fitnesse Smell – Executable Requirements that look like Scripts

June 16, 2010 by mrdavidlaing · Leave a Comment
Filed under: Code smells, Testing

Gojko (who wrote the Fitnesse book) has this interesting discussion on what makes a good acceptance test in Fitnesse.

http://gojko.net/2010/06/16/anatomy-of-a-good-acceptance-test/

His point seems to be that Fitnesse is a good tool for documenting specifications, and continuously automating their validation. When your Fitnesse tests become like “scripts” (which is how developers are trained to see the world), then Fitnesse is a pretty crummy test execution environment (just use a unit test runner!)

Interesting that alternate tools – http://www.concordion.org, http://wiki.github.com/aslakhellesoy/cucumber/, http://www.specflow.org/ have arisen that effectively try to limit the power of the “test description language” to prevent the acceptance tests becoming script like.

Interesting food for thought – I know that many of my Fitnesse tests exhibit this codesmell

Tags: acceptance tests, codesmell, fitnesse

Why Pair Programming Doesn’t Reduce Productivity

June 6, 2010 by mrdavidlaing · Leave a Comment
Filed under: Agile, HOWTO, Pair Programming

The other day I was asked why pair programming doesn’t reduce productivity; and its taken me a few days to come up with a this succinct answer –

because we’re building a system to release software changes rapidly over a long period of time, not type more lines of code to reach some predefined goal post

The purpose of a software team is to deliver a working software solution that solves customer’s problems over a long period of time.

This would be easy if:

Customers knew what they wanted
Developers knew how to deliver the features
The world remained the same on the day the software is released as it was at the time it was designed.

The trouble is that none of these are true. We have to guess at the right solution, get some real world experience with it, and then optimise when we know more about the problem domain (aka, after we have delivered the feature for the first time).

The way to do this better is to reduce the length of the feedback cycle (think 5 days, not 6 months), and grow a system that can rapidly and repeatedly deliver changes to the software over the life (years) of that software.

Pair programming contributes directly to growing this system by:

Facilitating communication about the architecture & design of the system, and ensuring everyone actually understands it
Reducing brittleness & bottlenecks caused by one person “owning” a core module
Improving consistency and adherence to common standards
Catching bugs at the cheapest time to fix them

Unintuatively, it also tends to ensure that developers actually spend longer working on the software by:

Reducing “wander time”. You are less likely to get sidetracked into email, facebook or some interesting blog article when pairing.
Reducing “stuck time”. Two perspectives on a problem have twice as many solutions to try out

These articles go into more depth:

To conclude, pair programming would be a unproductive if developers had the perfect solution is their head, and programming was just the task of typing that into the computer to release a single perfect version of the software.

But in the real world we we’re in the business of creating a system that can rapidly deliver changes to the software as it narrows in on, and adapts to the best solution to the problem at hand. And to do this, pair programming excels.

Tags:

CI for Flex 4; running FlexUnit4 unit tests and FlexMonkey4 acceptance tests with Maven and FlexMojos

June 4, 2010 by mrdavidlaing · 2 Comments
Filed under: Continuous Deployment, Flex, HOWTO

The FlexMojos project is a great way to bring your Flex application under a grown up continuous build system like Maven.

Getting FlexMojos 3.6.1 working with Flex 4, running Flash Builder 4’s version of unit tests and FlexMonkey4’s version of acceptance/UI tests is pretty tricky.

Hopefully this sample project – http://github.com/mrdavidlaing/flexmojos-sample along with this screencast will save someone else the pain I went through to get all these playing together.

Howto add new component to FlexITP from David Laing on Vimeo.

Patches welcome – just clone the git repo make your change, and request a pull.

Tags:

DTOs: To Flatten Or Not To Flatten?

April 20, 2010 by mrdavidlaing · 2 Comments
Filed under: Architecture, Software Craftmanship

that is the question…

I’m busy working on a JSON based API with client libraries in Flex, C# and Javascript (and eventually iPhone, JavaFX etc).

One of the things the API deals with is the concept of a Market. Markets have a number of properties that “belong” to them, simplistically things like MarketId and Name.

[-]^?View Code CSHARP

public class Market
{
    public int MarketId {get; set;}
    public string Name {get; set;}
}

However, I can see that in using a list of markets, its going to be useful to know related data about the market for things like sorting. For example, when showing a list of markets I’d like to know the volume traded in the last day so I can colour them differently. Or the price change in the last hour etc.

DTO wise, there seem to be several options.

Flattening with “nulls”

[-]^?View Code CSHARP

public class Market
{
    public int MarketId {get; set;}
    public string Name {get; set;}
    public decimal? VolumeInLastDay {get; set;}
    public decimal? PriceDeltaLastHour {get; set;}
}

It seems that over time this approach will lead to very “messy” DTOs where you’re forced to do a lot of “isNull” style checking before attempting to display things.

Multiple specific MarketWithXYZ DTOS

[-]^?View Code CSHARP

public class MarketWithVolume: Market
{
    public decimal VolumeInLastDay {get; set;}
}
 
public class MarketWithPriceDelta: Market
{
    public decimal PriceDeltaLastHour {get; set;}
}
 
public class MarketWithVolumeAndPriceDelta: MarketWithVolume
{
    public decimal? PriceDeltaLastHour {get; set;}
}

An explosion of DTOs, but at least you know exactly what data you’ve got at any instance

Property Bags

[-]^?View Code CSHARP

public class Market
{
    public int MarketId {get; set;}
    public string Name {get; set;}
    public Hashtable RelatedData {get; set;}
}
 
decimal delta = Market.RelatedData["PriceDeltaLastHour "];

In a way this feels even worse than having multiple null attributes; especially for someone new to the API because you won’t know until run time which data is available.

How have you approached this problem in the past? What works, and what doesn’t? Comments much appreciated.

Update

Reduced duplication in Multiple specific option using inheritance

Tags: api, design_patterns, dtos

HOWTO Reset MySQL 5.0 root password in Ubuntu 8.04 LTS

September 19, 2009 by mrdavidlaing · Leave a Comment
Filed under: HOWTO, Ubuntu

Turns out there are lots of complicated ways, but in Ubuntu you can just reconfigure the package:

dpkg-reconfigure mysql-server-5.0

Hopefully that will save someone some hair pulling

Tags:

Utils anti-pattern & AutoMapper

June 2, 2009 by mrdavidlaing · Leave a Comment
Filed under: .NET, Architecture, Code smells

These are more for my reference purposes – hopefully you’ll find them useful:

If you’re about to name a class **Util; think harder – there is a better name that discribes what that class is for:
Chriss Missal has some advice for you

Faced with the prospect of heaps of left hand side => right hand side code in your DTO of anti-corruption layer? Consider Jimmy Bogard’s Automapper

Tags: automapper, utils-anti-pattern

The Pomodoro Technique – Scrum in the small

May 31, 2009 by mrdavidlaing · 4 Comments
Filed under: Agile, HOWTO, Software Craftmanship

Over the past month I’ve been experimenting with the pomodoro technique of time management to great success.

The technique is surprisingly simple; yet I’ve found it contains a wealth of physical and emotional benefits. To give some context; I’m using it as a programmer as part of a agile scrum team. I typically program using TDD techniques. That being said, I don’t see why it wouldn’t be applicable in most “desk” based jobs.

A pomodoro is a unit of focused, uninterrupted time; measured by an egg timer. For me, 25 minutes works well.

At the beginning of my work day, I write a collection of tasks that I think I achieve in the day onto a fresh piece of paper as my todo list. I estimate how long I think each task will take in units of a pomodoros. Next to each task I put a number of boxes; one for each pomodoro unit. I make sure not to have more pomodoro units than I achieved yesterday; and I try to make sure that I’m estimating tasks based on how long similar tasks actually took me in the past.

Then I wind up my egg timer, place it visibly on my desk and begin the first task. The ritual of winding up the timer, placing it down and hearing it tick help me to drop into the zone of full concentration – and let my team know that they shouldn’t interrupt me.

Brrrriiinng. Pomodoro up, finish the current test and stop. Cross out one of the boxes on my todo list. Get up and leave my desk; stretch, drink some water, focus on something far away to relax the eyes, go an speak to anyone who came past during my pomodoro time & was waived away.

Then back to the desk, reassess which is now the most important task to get one with, and start the next Pomodoro.

At the end of the day I transcribe the results of my todo list back to a records sheet; update our project management software (VersionOne); and leave, satisfied that I achieved what I set out to do.

I’ve found that running my day like this greatly increases my job satisfaction & efficiency.

Firstly; I’m breaking my addition to hopium, and setting myself up to fail every day. I used to live in this lala land called – I have 8 hours of productive work time each day. The empirical reality shows that I usually do 5 – 8 pomodoro units / day – so much more like 3 – 4 hours. The rest gets gobbled up by meetings, emails, conversations. So its no wonder that I used to achieved half what I thought I would each day; and left work feeling disappointed.

Secondly, having a forced reset every 25 mins really helps me to stop falling down rabbit holes. I’ll often be trying to solve a problem with a specific technique that just isn’t working, and if I’m not careful I can spend a whole afternoon bashing my head against a wall. With the forced breaks, I’ll often find that I sit back down to the problem, and have a flash of inspiration for a much simpler way to solve it, or realise that I don’t even need to solve it in the first place!

Thirdly, being reminded to get away from my desk frequently really helps physically. I’ve experienced much less “mouse shoulder” and dry eyes.

The technique is also really helpful when pairing; keeping meetings from rambling; keeping focussed on one task (rather than having to check email or twitter every 10 seconds) and getting going on a large daunting task.

If you struggle with hopium like me; I’d really encourage you to give the Pomodori technique a try for 2 weeks, and let me know how you get on in the comments to this post.

Brrriiinng