# A simple circuit, an Arduino, and Haskell

I recently had loads of fun attending a Nodebots AU event in Sydney. (Thanks a lot to Damon and Andrew for organising, and NICTA for the venue!) I got to muck around with some simple circuits and drive them with Javascript. Towards the end of the day I was running out of time and creativity to do anything fancy, so I decided to see if I could get one of the circuits working with Haskell.

# F# assertion libraries

There are a few different libraries that provide test assertions for F#. I went through a couple today and tried a trivial example in each.

# Digitising hand drawn sketches

Every so often I want to quickly sketch out what should be a simple diagram. Irrespective of what drawing program I use, I always seem to take much more time than I intend for a result that does not even remotely resemble what I want.

So I decided to give up and find a way to use hand-drawn sketches instead. Here’s the method I ended up with, based almost entirely on Marc Liberatore’s "Whiteboard Diagrams as PDFs" post and the wonderful ImageMagick and Potrace utilities.

My drawings still look fairly terrible, but at least they convey what I want them to and are quick to produce! :)

# Some regex help from the F# compiler

tl;dr: Make invalid regular expression strings and attempts to access non-existent capture groups a compile-time error, thanks to the Regex type provider.

# A hasty introduction to the Either type

The Either type, also called Choice in F# parlance, is a way of representing a value that can be either one of two types. This can be extremely useful. For example, retrieving a date of birth from a textbox could be expressed as Either<ParseException, DateTime>. In other words, the result is a value that is either a valid DateTime, or is a ParseException.

Being a hasty introduction this post is not going to do justice to how useful this type is, but hopefully some of its goodness will shine through despite my rambling prose. :)

# Stayin’ alive with .NET GC

Most of the time .NET GC just works. Occasionally when dealing with things like interop with unmanaged code, things go wrong. Things I learned today from this aforementioned going wrong include:

• Variable scope can be greater than the lifetime of the object it points to
• Mark-and-sweep GC marks objects for survival, not for collection
• GC.KeepAlive(object) is a no-op
• Finalisers from collected objects can break active objects
• Use a release configuration build for reproducing GC issues, running without the debugger attached
• Non-deterministic finalisation makes me confused

# Splitting responsibilities by abstracting type details

One thing I’ve battled with in my OO, TDD adventures is useless abstractions. I find it very easy to churn out class like the PaddedSingleWidgetList described below in an attempt to follow the Single Responsibility Principle and write testable code, but in doing so I end up with lots of classes that don’t really make much sense in isolation, and that are not inherently reusable. (Just me?)

Instead of my usual approach of splitting a problem in terms of somewhat arbitrarily chosen responsibilities, what if we divided it into the parts that need knowledge of specific types, and the parts that can have the specific types abstracted away?