The first two blog posts in this series covered my introduction to Growing Object Oriented Software Guided by Tests (GOOS), and my first, overly challenging attempt at implementing its worked example in JRuby which resulted in me mothballing that implementation until I'd completed it in Java. This post describes my approach at tackling it in Java; the challenges I faced, how I hope this blog might benefit others, and how I'm now ready to dust off the JRuby code and have another go. My approach Following the challenges I faced using JRuby, I decided to follow the auction sniper worked

Continue Reading...

In the first post of this series I summarised my introduction to Growing Object Oriented Software Guided by Tests (GOOS), and why I decided to revisit it in late 2013. This second post summarises my first attempt at the Auction Sniper worked example in JRuby, how things didn't work out too well, and my approach to dealing with these issues. I'm still to complete the worked example in JRuby, but as you'll see, I took a 'brief' detour... The auction sniper The worked example in GOOS is based around the auction sniper; an application that bids in auctions at Southabee's

Continue Reading...

This is the first of several blog posts I am going to write about Growing Object Oriented Software, Guided by Tests (GOOS) by Steve Freeman and Nat Pryce. In this post, I describe my introduction to the book, and why I've decided to commit a fair bit of time to completing the book, and its worked example - the Auction Sniper. Paul, meet TDD I discovered automated unit testing in around 2003, and test first development a year or two later. At this time, my tests were primarily integration tests written in C# using NUnit. I developed a few systems

Continue Reading...

After reading Shaun's excellent post about Top Down TDD, I'd like to share my views on top down and bottom up development. Now, I've never enjoyed the database first design processes so commonly followed in waterfall projects. My experience with projects following a broadly bottom up approach have generally suffered from overly complex data models designed to satisfy edge cases that may or may not exist in the real world. These overly complex schemas make consuming components overly complex, often right up to the UI (user interface) tier When I discovered agile software development, I particularly latched onto top down

Continue Reading...

I attended the Agile Staffs January session on Thursday which took us back to  the halcyon nights of coding katas. It's been a while since we've done a kata, mainly due to speaker evenings, the Christmas break and Alien Invasion. Why this kata? Anyhow, back to the kata... We've decided to alternate between coding sessions and speakers at Agile Staffs to gain variety, exposure and generally to mix things up and add a little more structure and predictability. Katas are obvious challenges / activities for single night coding sessions and previous katas have been good fun, and educational for the group.

Continue Reading...

I've always disliked database integration. I've also disliked shared development databases, just as I've disliked shared development environments. And it's not just me that thinks like this. https://twitter.com/marcjohnson/status/193495187799019520 https://twitter.com/jeremydmiller/status/309353109300326400 Databases are great at persisting data reliably and securely, and can provide a workable integration point between systems, but why is this choice commonly the wrong one? It ensures tight coupling between systems Encapsulation (or don't "expose your privates") is a key tenet in object orientation, SOA (service oriented architecture), and other architectural styles that advocate loose coupling and high cohesion.

Continue Reading...