Using functions to express musical ideas is nothing new: Harmony, time signatures, the relations between notes in a scale and musical form all have their roots in mathematics, and composers have used mathematical abstractions for millennia (see Pythagorean Tuning for a 2500-year-old example).
These abstractions, however, are not always obvious from they way that music is written down, leading to a potential disconnect between composer and performer. In this post, we will use Steve Reich’s 1972 Clapping Music to show how functional programming can be used to capture an underlying musical idea.
I recently attended one of the coding dojos run by the London Scala User
Group. It was great fun, and I’d recommend getting involved to anyone who’s
interested in meeting other developers and learning more about scala and functional programming.
After breaking into groups, we set about tackling the ‘LCD Digits’ problem from cyber-dojo.org. Although fairly
straightforward as a programming challenge, it offers a number of ways to experiment with different
functional idioms. The goal is to write a program that takes an integer, and formats this as a
string composed of the ‘.’, ‘_’, “|’ and ” ”
characters so that the output resembles an LCD display.
I’ve been working through Aaron
Bedra’s set of clojure koans recently in an effort to improve my functional programming
skills and try something new. I’ve found it difficult to make time at my desk for this, so I
set up a development environment on my iPad. It’s worked surprisingly well, so I thought
I’d share my setup.
As mentioned in my last post, I am an ardent fan of the Mockito Framework. Originally developed as a fork of EasyMock, it equips developers with the tools to create mock objects using clean and expressive code. In this post, we will show how PowerMock can be used alongside Mockito (or EasyMock) to create mocks for classes that appear at first ‘unmockable’. Suppose we have the following class:
…which has a dependency on a DataProvider:
Well-established tools like Mockito and EasyMock offer a powerful range of features for defining and interacting with mock objects. I use both heavily in my unit tests, and would recommend them to anyone looking for a mocking framework. Sometimes, however, a _real_ (i.e. non-proxied) collaborator is called for, or adding third-party libraries may not be an option. In most cases, a suitable object could be instantiated by calling the constructor and setting it as a dependency to the object under test.