Developement

There are a lot of reasons we look to define ‘best practices’ around the way we develop software. The largest reason for me is so I can solve new and more interesting problems, I don’t want to repeatedly solve the same problem I had yesterday. However, ‘best practices’ isn’t a silver bullet and they can at times create new problems. I want to look at some of the problems I’ve seen first hand and possible ways to mitigate them. Problems There is no ‘best’ The world of software is a complex place where we have a vast array of solutions to even the simplest problems. It’s very difficult to pull individual solutions out as ‘best’, there are always trade-offs between solutions and the context that surrounds them. We can often say that ‘Solution A’ is better than ‘Solution B’ given our circumstances, but that doesn’t imply that ‘Solution A’ is the best solution. Under slightly different circumstances the reverse might be true. It’s rare to find solutions that are universally better tha

Windows was the first operating system I ever used and was what I almost exclusively used until the end of my university degree. As part of my studies I dabbled with Linux but never thought I would use it full time and I didn't think highly of OSX. In 2013 I started my first full time job out of university and they gave me a Macbook. The unexpected happened. I couldn't imagine using anything else for software development. Then in 2015 I resigned and gave back my Macbook. So bought myself a windows laptop and installed Linux. That was more than 18 months ago and again, I couldn't imagine using anything else for software development. Today I want to share with you some of the things I've learnt and learnt to love through this journey. My Linux Journey My first introduction to Linux was at university in a course called  Operating System Architecture . We were given a login to a very large shared Unix (I think it might have been Solaris) system that the university hos

Recently at work we've started up two interesting study groups: Haskell and Category Theory. The category theory group we've been going through Bartosz Milewski's series of videos 'Category theory for computer scientists' , and Haskell we've been building a small application. During our category theory session a few weeks ago we were talking about the Kleisli Category and it reminded me of some code in one of our applications. The code is focused around some transformations (some pure, some not) and the error handling for these transformations. We have a collection of objects we want to transform individually and then save them to the database. If we can't transform an object we want to be notified using Airbrake and logging, but everything that can be saved should be. Wrapping the entire thing in a try-catch block felt lazy and I thought we could do better. I'm not going to show what actually happens in any of these transformations, all you need

So I've just started my first foray into Docker in anger. Nothing has made it to production yet but I wanted to share my experience over the last couple of weeks. A little bit of context about what I am doing right now. I'm starting down the path towards small independently deployable services instead of a monolithic application. The services that I am developing will replicate some existing functionality within the monolith but talk to a brand new iOS app. The architecture pattern I am looking to apply is Command Query Responsibility Segregation (or CQRS). The first small services I am developing are the “Query” side of things as it allows us to focus on one thing at a time. These “Query” services won't be truly independent in that they will still talk to the same database as the monolith. This will allow us to solve a whole bunch of problems before we start work on the “Command” services which will actually update data. Again, some of these services will be tied to the

On my current project we've been using DropWizard. For the most part this experience has been pleasant, of course it hasn't been without it's challenges but software development is never without challenges. The most recent challenge has been using Jackson's JsonViews. Due to the domain we're working in we have few models that contain many fields, while we could split these into multiple models it seems unnecessary at this point in time. We're talking 10-15 fields, so not massive but definitely large. This means that at times we don't want to serialise the entire model, one example of this is when we're listing models. The list of models don't need all of the fields, just 4 of the fields in our case. Jackson's JsonViews appeared to be the solution to this problem and you can find the wiki page about them here . The first problem I encountered was that the views didn't appear to be working as they should. Our models make use of the default

I've just started on a new project, it's a short project, around 7 weeks. We had 3 days for iteration 0 to get a few things setup. One of those things was a reliable means to deploy the exisiting web app to a new instance on AWS. The codebase had some exisiting Chef scripts that would install all of the dependencies (Postgres, Nginx, and things like that). While this looked great from the outset we quickly found that these scripts weren't working as expected and spent so much time debugging it that we decided to switch to Ansible as it's known for it's simplicity. We started by looking at the server config. There were quite a few things that required installing on a blank Ubuntu box. We started with the simple things, but quickly decided the amount of time required to configure things like Postgres from Ansible with our knowledge and time frame was not feasible. So we decided to manually configure the server and leave that as something to come back to, the priori

As a consultant even with my relatively small amount of experience I dislike the way that most teams and companies approach agile. They become focused on the practises and processes that often get taught when you introduce a team to agile software delivery. Using the common practices and processes is just one way you could enable an agile software delivery team, but to become a truly agile team you need to understand why these processes get used. You need to have some understanding of the agile manifesto and why these practices are important. Just the phrase 'do agile' frustrates me beyond belief, the fact that it doesn't work grammatically should be the first sign you're using the word in the wrong way. Agile is not a process to follow, it's not something you can simply 'do', it's something much deeper than that. Agile software development is about being fluid in what you do, it's about getting feedback early and often, and then responding to fe