:::: MENU ::::

Higher order functions – simplifying loops – part 2 of ??

This is the 2nd part of my series on everyday functional programming.

Filtering

Suppose you have a collection of items and need to grab just a subset that match a certain criteria. Programming C# in an imperative style, you could use a for or foreach loop as follows:

Functional programming recognises this common scenario as a higher order function known as a Filter [3]; where you want to create a new list for every element that evaluates to true when a predicate function is applied to it.

In C#, filter is implemented as the LINQ Where(Func)) extension method, allowing one to write the following:

Apart from the obvious reduction in number of lines; notice how much clearer the intent of the filter is, and the many opportunities for error we have eliminated.

In Javascript we use the filter function:

Mapping

In many instances you find yourself wanting to perform the same operation on every item in an existing collection. In Javascript in an imperative style we might want to do the following

In functional programming this is know as the higher order function: Map [4] and in Javascript can be applied using a single statement map()

In C#, map is implemented by the LINQ Select(Func) extension method:

[1] – http://railspikes.com/2008/7/29/functional-loops-in-ruby-each-map-inject-select-and-for
[2] – http://msdn.microsoft.com/en-us/library/system.linq.enumerable.aspx
[3] – http://en.wikipedia.org/wiki/Filter_(higher-order_function)
[4] – http://en.wikipedia.org/wiki/Map_(higher-order_function)


Everyday functional programming – part 1 of ??

This is the first of a series of blog posts where I will be exploring how functional programming techniques are useful in the daily life of a working “enterprise software” developer.

If you, like me, began programming in the 1990’s, then you will probably have started in a procedural programming style with simple task orientated scripts, and then progressed to an object oriented style for its better fit with event orientated GUI applications. As the software craftsmanship movement has grown over the past few years, you will have honed your S.O.L.I.D. OO skills; and focussed on making your code maintainable & testable/ed.

Whilst functional programming has an academic & computational background; functional elements have begun finding their way into mainstream languages. In this series of articles I’ll be concentrating on the two languages I am most familiar with – C# and Javascript – and how exploiting the functional programming features in these can help to make the code you and I write every day more expressive & maintainable, and in some instances dramatically more scalable.

I won’t be trying to explain the concepts behind functional programming – others have done an exellent job of that already; so I’ll just link to them [1] [2]. Rather, I’ll be curating practical examples where a functional style can be applied to everyday programming problems.

  1. Higher order functions – simplifying loops
  2. Implementing the strategy pattern without an explosion of classes
  3. Side effect free functions – code that is easy to test & reuse

[1] – http://en.wikipedia.org/wiki/Functional_programming
[2] – http://www.defmacro.org/ramblings/fp.html


A Defect Exception

Occasionally one comes across a idea that is just brilliant.

How often have you been writing a bit of code, and got to a point where you think “gee, if the program ever gets into this state, then something is really wrong”. Throwing an exception seems appropriate, but what kind of exception to throw?

Enter the following sage advise from Steve Freeman and Nat Pryce in their great book “Growing Object Orientated Software Guided by Tests”:

Growing Object Orientated Software Guided By Tests - pg165

Growing Object Orientated Software Guided By Tests - pg165

A DefectException(). What a simple but brilliant idea!

Thanks guys


Learning functional Javascript through Koans

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.
https://github.com/mrdavidlaing/javascript-koans


Fitnesse Smell – Executable Requirements that look like Scripts

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


Why Pair Programming Doesn’t Reduce Productivity

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:

  1. Customers knew what they wanted
  2. Developers knew how to deliver the features
  3. 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.


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

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.


DTOs: To Flatten Or Not To Flatten?

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.

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.

  1. Flattening with “nulls”

    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.

  2. Multiple specific MarketWithXYZ DTOS

    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

  3. Property Bags

    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