Agile Development

Scaling Business Application Development with Play and Scala

Yesterday evening, I went to see a presentation by Peter Hilton at Skills Matter on using Scala and Play for small-scale development.

In an affable and down-to-earth manner, Peter went through two case studies that his company had handled, both  web developments in Holland, where he is based. This is somewhat unusual for Scala in particular and any JVM-based language in general: normally much “lighter” technologies, such as ASP.Net or PHP, are used.

He highlighted the use of a stack of technologies, Play, Scala, Slick (for database connectivity and access), PostgreSQL and MySQL for the database and Bootstrap for the website layout. In particular, he went through the use of Slick, which he recommended, as it has an unusual, more SQL, feel compared to other ORM’s.

He also emphasised the speed of development and that the amount of code needed was much smaller than previous applications he’d developed: the first application was ~4000 lines and the second ~2000, which are both a lot smaller than the applications I’ve worked on. It was interesting to see how his team short-cutted: using social media for security (why not?) and Excel spreadsheet integration for record maintenance.

Overall, it was a good presentation about using Scala in a different way.

Mockito – An Elegant Stub for a More Civilised Age

In software development, we make use of something called “stubs”. These are bits of code that don’t do anything at the moment, but allow us to continue coding elsewhere as if they do. They are also used in testing to substitute for more complex objects, and this is where “mocking” (creating “mock” objects) has been developed in object-oriented programming and test-driven development.

As an extension to the college work I’ve been doing, I’ve been looking into using mock libraries for unit testing and I’ve come across Mockito:

The mock objects it creates are, well, amazing to say the least. Say we’ve got an interface that, in turn, allows us to create a read I/O stream and a write I/O stream, for networking. The interface would look something like this:

//simple interface wrapper around a network socket
public interface MySocket {
    //creates a read I/O stream
    public BufferedReader getBufferedReader() throws IOException;
    //creates a write I/O stream
    public PrintWriter getPrintWriter() throws IOException;
    //indicates that a connection has been successfully made
    public boolean isConnected();
    //closes the connection
    public void close() throws IOException;

Now I can actually mock this interface with Mockito in the unit test:

import static org.mockito.Mockito.*;
MySocket socket = mock(MySocket.class);

You can now use this mock socket interface in whatever need the interface, so:

SocketThread socketThread = new SocketThread(socket);

Now, unfortunately, the mock doesn’t really do anything other than just record what happens to it. Say SocketThread calls socket.close internally when it runs:

//this is in
//if this isn't true, you'll get an exception

Useful, but it becomes a bit more powerful when we add mocks for the input and output streams:

PrintWriter printWriter = mock(PrintWriter.class);
BufferedReader bufferedReader = mock(BufferedReader.class);

You can control exactly what the mock does and when it does it. Very useful for unit testing (and I haven’t even begun to use all it’s capabilities).

A Skills Matter Presentation – Continuous Delivery Gone Bad

At the invitation of of a former colleague, I went to a presentation by Gojko Adzic at Skills Matter regarding his experiences and recommendations for continuous delivery, one of the corner stones of agile development.

In quite an interesting, if earnest and intense, presentation, Gojko related some interesting anecdotes, and a few novel ideas.

Notable was that to do justice to continuous delivery, it has to be done with multiple versions, allowing mistakes to be made and features to be added without interrupting the work flow of the customers using the applications. There were a few intakes of breath from the audience, and he didn’t disguise the difficulties of this strategy, particularly regarding data versions.

Another was the idea of using fast prototyping techniques, often without any coding whatsoever, to be able to sort out business issues, and that feedback and measuring are also important elements, especially if the project is a success.

All in all, it was quite a good presentation, if a little slow in places.