Tuesday, 29 October 2013

NRUG October 2013 Review Foxes and Badgers


When Pete Roome and Rob Barwell left Norwich for their big break in the big smoke, you could be forgiven for thinking that NRUG might die there and then. This is not the case. The group is now in the very capable hands of Matthew Bennett-Lovesey.

There were lots of new faces tonight or at least faces that were new to me at this NRUG event. Ben Hammond works at Further and has moved from Perl to Ruby. Mark Hannant is a senior SEO consultant, also at Further. Kieron Johnson is a freelance ruby developer. Rob Anderson works for Payment Card Solutions, a Rails and Ruby shop, who also sponsored the refreshments this evening.

The venue for this NRUG was Further, an award-winning online marketing & SEO agency. Their offices are in The Old Church on St. Matthews Road in Norwich. They were very nice indeed.

Rapid Development with Ruby, Sinatra, Bootstrap CSS, DataMapper and SQLite

Phil Howard

Sinatra is an alternative to Rails. Phil took us through a simple example of how to create a basic web application, complete with security. The process looked very quick and easy and the application itself was aesthetically pleasing, but then Sinatra use Bootstrap, so you would expect it to be.

Data Mapper is an ORM (Object Relational Mapper) implementation of Active Record. Unfortunately it is no longer being developed. Phil took us through an example where he use Data Mapper to persist Fox objects and Badger objects, both types of Animal object to a database. In true ORM style, Data Mapper took care of creating the database tables and relationships and generated the code to persist and retrieve them. Phil modified the retrieval code to bring back either animal randomly and then pitched them against each other in a Top Trumps style.

There was lots of discussion about how ORMs work and how people either did or didn't like writing SQL. The example Phil demonstrated used single table inheritance and there was some discussion on about the pros and cons versus multiple table inheritance.

One drawback of Data Mapper is that it doesn’t support pagination. Surely every ORM should support that?

Beer Driven Development

Matthew Bennett-Lovesey

Matt explored the differences between TDD (Test Driven Development) and BDD (Behaviour Driven Development) although he replaced Behaviour in BDD with Beer for comic effect.

There appear to be two camps of people when it comes to BDD. Those who see it as a better TDD and those who see it as more than a development practice and as a wider process of requirements capture that involves lots of collaboration between the customer and the development team.

Matt started off by describing to us what TDD is and then went on to describe how it differed from BDD at a practical level. There were lots of examples, including lots of Ruby code. Ruby is often described as being better than Java for one reason or another, but I think Java has the upper hand in unit testing frameworks due to its use of annotations, while Ruby still uses inheritance to create test fixtures.

There was a lot of discussion on the real benefits of using TDD over not using it. Some people still struggle with the idea that the extra time taken to write the tests can save you exponentially more time later that would otherwise be lost to bug fixing.

These really were two excellent presentations and with all the banter and audience participation it was 10.30pm before people started to leave.

Thursday, 24 October 2013

NorDevCon: Winter Is Coming (Part 1)


One week from now tickets for the Norfolk Developer’s conference (NorDevCon) go on sale. NorDevCon is a one day Agile and tech conference in the heart of Norfolk, in the heart of winter. Details of the keynote presentations and speakers, as well as some other highlights from NorDevCon can be found below.

From 1st November you can buy your ticket here: http://nordevcon2014.eventbrite.co.uk/

Opening Keynote: Software Apprenticeships: This Time It's Personal

There has been much talk about apprenticeships for software developers, but between employers, academia and practitioners we've struggled to find a model that works for proper long-term apprenticeships. After nearly a decade of personal research into the problem, I'm embarking on my first apprenticeship with Computer Science undergraduate Will Price, applying an experimental model where experienced practitioners like me coach and mentor young programmers directly. In this presentation, I'll outline our simple apprenticeship model and the experience we're having with it, as well as discuss the wider problems of long-term software apprenticeships, and how our model might let us finally have our cake and eat it.

Jason Gorman


Jason has worked with teams at the BBC, City Index, Electronic Arts, Higher Education Statistics Agency, BUPA,  British Standards Institute, The Post Office, Merrill Lynch HSBC, Freshfields Bruckhaus Deringer, Orange, Lloyds TSB, AOL, Reed Business Information and Symbian, and many more.

Jason chairs the Software Craftsmanship conference in the UK, and is a contributor to other conferences including QCon, Software Practice Advancement, XPDay, Agile Finland, JAX London and CITCON Europe.

His web site, parlezuml.com, has been visited by more than a million software professionals since 2003, and his free tutorials on use cases, UML, OO design and Test-driven Development have had more than 500,000 downloads.

Closing Keynote: Building on SOLID Foundations

Why can't we just add a feature to our system without tearing the code apart or, worse, patching around it? It ought to take just a few lines. We know the code is supposed to be modular and coherent, but too often it just doesn't turn out that way.

We don't believe it should be this hard to change object-oriented systems. We've seen examples where it really is that easy to add a new feature. The difference seems to be in the intermediate level structure. The design principles that most programmers rely on don't address the middle ground where the complexity lies. We know about principles and patterns at the small scale, such as SOLID, and the large scale, such as REST. We're less familiar with the structures in the middle.

This talk is about design principles that we’ve learned help us develop mid-scale code structures that are easy to read and easy to change. At the lowest level, this means well-known patterns such as avoiding globals and following SOLID guidelines. At larger scales, this means assembling those SOLID objects to avoid hidden coupling so that the system as a whole is amenable to change. We focus on how objects fit together and communicate, and on being clear about how capabilities and information flow between objects in the running system.

Nat Pryce


Nat Pryce is a co-author of Growing Object-Oriented Software Guided by Tests. An early adopter of XP, he has written or contributed to several open source libraries and tools that support TDD and was one of the founding organisers of the London XP Day conference. He has worked as a programmer, architect, trainer, and consultant in a variety of industries, including sports reportage, marketing communications, retail, media, telecoms and finance. He has delivered systems ranging from embedded devices to large compute farms supporting global business.


Steve Freeman


Steve Freeman, author of Growing Object Oriented Software, Guided by Tests (Addison-Wesley), was a pioneer of Agile software development in the UK. He has developed software for a range of institutions, from small vendors to multinational investment banks. Steve trains and consults for software teams around the world. Previously, he has worked in research labs and software houses, earned a PhD (Cambridge), written shrink-wrap applications for IBM, and taught at University College London. Steve is a presenter and organiser at international industry conferences, and was chair of the first London XPDay.

10 years of Doing Behaviour-Driven Development All Wrong

10 years ago, Dan North first came up with the idea of BDD: using examples in conversation to explore the behaviour of systems, then carrying those examples into code. Since then, we've learnt a lot about how BDD works, how it works best, and how it can fail horribly! Even the most experienced BDD practitioners have learnt a lot from their failures... but what were they? And how are we failing now?

In this talk, Liz takes a look at things we said back then which we shouldn't have, ways in which we abused BDD more than we used it, and things that we're still doing all wrong today. Come along to see the mistakes, listen to the stories, and hear the apologies!

Liz Keogh


Liz is an experienced Lean and Agile consultant and well-known international speaker. Coming from a strong technical background, her work covers a wide variety of topics, from software development and architecture to psychology and complexity thinking. She is best known for her involvement in the BDD community, and was awarded the Gordon Pask award in 2010 for deepening existing ideas in the space and "coming up with some pretty crazy ones of her own".

Continuous Delivery at 7digital - An Experience Report

An introduction to Continuous Delivery, it's purpose and benefits, and how we achieved it at 7digital.  An overview of the technical and people changes we made, and the impact these had - both good and bad, followed by a "A Day in a Life of a Change at 7digital".


Chris O’Dell


Chris O’Dell is a Lead Developer at 7digital, one of London’s premier digital download companies, where she heads up the API team. She has nearly ten years experience working on the back-ends of web based services, primarily in .Net, most recently focussing on Web APIs.

Chris has a keen interest in Test Driven Development, Continuous Delivery and Agile development practices. She lives in London and in her spare time has begun learning to play the Cello.

Tickets

Ticket go on sale on 1st November at 9am. There are 50 Super Early Bird tickets at £50 + fees and 450 Early Bird tickets at £75 + fees. We are offering significant discounts for students and the unemployed. Please email paul@nakedelement.co.uk for details. There are 80 places for the conference dinner (3 courses, 2 glasses of wine and speakers!) and tickets are £35 + fees. The Virgin Wines reception is free to attend for conference attendees and there are 80 places. You can buy your tickets here: http://nordevcon2014.eventbrite.co.uk/

Original article published at: http://wp.me/p41ugV-68

Wednesday, 23 October 2013

You Can't Win Them All

Since I started Agile East Anglia in December 2011 I am very happy to say that everything I’ve been involved with (SyncNorwich, Norfolk Developers, SyncConf, East Anglia MongoDB User’s Group, MobDevCon etc) has been very successful. We’ve built it and they’ve come, but my run of good luck had to end sometime and almost two years is a pretty good run.

It would appear that now is not the right time for C# Training in Norwich. Naked Element Ltd. has sold a single place out of a eighteen places, with a required minimum of sixteen places and the trainer has found some other solid work for the same week. Therefore it is with a lot of disappointment that I have been forced to cancel the training (the one place sold has of course been fully refunded).

They say these things come in threes (although I’m not really in anyway superstitious). Along side the training, I also had a poor turnout to my session at Agile Cambridge and we had to move the Norfolk Developers hack day as we couldn’t pull all the groundwork together in time. I’m hoping this is my three and (I know, I said I wasn’t superstitious) and the Norfolk Tech Journal will continue to grow and NorDevCon, next year’s MobDevCon and the rescheduled hack day will be a resounding success.


The Norfolk Developers Conference is Coming


This is the new NorDevCon advert designed by Shelley Burrows at smellyrabbit.

Thursday, 17 October 2013

Are singletons just misunderstood?

In around 2002 I read the Gang of Four [GangOfFour] and discovered the Singleton Pattern [SingletonPattern]. The gang of four describe the intent of the singleton pattern as:

Ensure a class only has one instance, and provide a global point of access.

Like most green developers I thought it was brilliant and used it to hold the database connection for my application as it was expensive to create, I didn’t want to create it until it was needed and I used it everywhere (my application was poorly abstracted).

I’d been a member of the ACCU [ACCU] for a little while and had made quite a few friends there who all told me Singletons were bad. I couldn’t see the problem and continued using it happily and didn’t think the extra compile and link time (I was using C++) when I modified the singleton was a problem. Until one day, when we introduced a second database for the application and I needed another version of the same singleton.  I didn’t see at the time that I could have used one singleton to serve up both database connections, but if I had I would have soon found just how tightly coupled to the singleton’s access function my code was.

The tones of “we told you so” are still resonating eleven years later and I have avoided singletons like the plague in favour of Kevlin Henney’s Parameterise From Above [PfA], where you create an object once in one place (for example in the main method) and then pass it around your code to every other object that needs it. Of course this doesn’t ensure that there is only one instance, it relies on the understanding and discipline of the developer.  It’s served me well for many years, but there have been a few isolated occasions since where the language or library I was using has restrictions where only a singleton would allow me to achieve what I needed to achieve. Happily this has mostly been in integration test code.

At a recent Norfolk Developers [NorfolkDevelopers] I chaired a BBC Question Time like panel on software development. The questions were very much based on my own views and prejudices about software engineering, so naturally there was a question on singletons. This was the first time we’d tried this, so I assembled a panel of what I thought were safe hands and asked this question to one of the safe pair of hands accordingly. We’ll call him Richard, mostly because that was his name. Much to my surprise, what I got back was advocacy of singletons!

I discovered a long time ago that understanding context is one of the most important parts of life, especially when it comes to understanding why people say and believe the things that they do. I think back to a memory from when I was a child, of a piece of film where you see a punk barging an old man out of the way; and then you see it again from another angle and realise he’s saving the old man from a heavy falling object.

When the panel was asked: “Are singletons evil or just misunderstood?” I read out something I had prepared previously, to give a little more context, explaining that Singletons lead to tight coupling; can be difficult to instantiate in threaded environments; and that it was difficult to know when to destroy them. Richard picked up on this and asked me to read it again, which I did.

Richard explained that all of these issues, and more, can be mitigated with the use of modern techniques such as dependency injection [DependencyInjection]. Dependency injection is a method of coupling objects at runtime, rather than at compile time.  As Kevlin Henney pointed out to me dependency injection is a classic, although sometimes verbose and poorly cohesive, application of parameterise from above.

For example, an option pricing engine may get its instrument prices from a number of different sources. You might have one class that retrieves Reuters’ prices and another that retrieves Bloomberg’s prices. They share a common interface, so, the pricing class doesn’t need to know which it is using; it just needs to know about the interface. In traditional systems, determining which object to use at runtime would be done within the code.

In recent years Inversion of Control (IoC) [IoC] containers have become popular.  The main concept behind IoC is, that, the responsibility for creating objects is taken away (inverted!) from the developer and the code; and delegated to a library which constructs objects on demand.  The IoC container knows about (through its configuration) dependency chains and supplies objects with appropriate dependencies for the entire object graph being created through dependency injection. IoC containers do more than construct objects however, they manage the entire object lifecycle and clean up and destroy out of scope objects.

So, in our example, when the IoC container creates the pricing object it will see that it has a dependency on an instrument object and look at its configuration to see which instruments object it needs to create and injects into the pricing object using dependency injection.

Creating an instruments object for Reuters or Bloomberg might be an expensive and time consuming operation and it makes sense to only do it once and then inject it into other objects that need to use it. Enter the managed singleton! One of the configuration parameters you can give to an object managed by an IoC container is: singleton. This means that the container will only ever create one instance of that object.  This doesn’t of course stop someone creating another instance of the object outside of the IoC container, so it doesn’t enforce a single instance programmatically, as with the Gang of Four singleton. However, it does remove tight coupling between the singletons and their dependants.

IoC containers can usually create singletons in a thread-safe manner, which is not the same as making the singletons thread safe. The IoC also container manages the lifetime of the singletons - in fact using an IoC container seems like a pretty good solution to many of the issues associated with singletons.
Richard had changed my mind, so I decided to write about it as I felt this was quite profound, for me at least. However, now that I have written about it I am no longer convinced. I started off describing Gang of Four singletons and then how I favoured parameterise from above.

Managed singletons, as I hope I’ve clearly explained, are very different. They don’t ensure a class has only one instance and do they really provide a global access point? Ironically, in at least one IoC container implementation I know of the container itself is a Gang of Four singleton and has a static access method that must be used if you want to use an object managed by the container outside of the container. Dependency injection too is a form of ‘parameterise from above’.

Maybe common thinking has shifted from considering Gang of Four singletons alone and now managed singletons (or similar) are considered singletons too. Personally, I don’t buy this. Singletons are still dangerous and should be handled with care. Remember, always parameterise from above.

Acknowledgements

Thanks to Geraint Williams, Kevlin Henney and Richard Featherstone for their contributions to the article.

 [GangOfFour] Design patterns: elements of reusable object-oriented software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. ISBN-13: 978-0201633610

[SingletonPattern] http://en.wikipedia.org/wiki/Singleton_pattern

[ACCU] ACCU: http://www.accu.org/

[PfA] Paramaterise from Above: http://accu.org/index.php/journals/1411, http://accu.org/index.php/journals/1327

[NorfolkDevelopers] Norfolk Developers: http://norfolkdevelopers.com

[DependencyInjection] Dependency Injection: http://martinfowler.com/articles/injection.html

[IoC] Inversion of Control: http://martinfowler.com/articles/injection.html