For all companies who write software of any kind the source code is one of the most valuable assets the company owns. But what about the dependencies? What about those third party libraries that are downloaded by tools such as NPM and Maven?

About 3 months ago, after nearly 6 years at Caplin, I decided to move on to pastures new. Caplin is a fantastic company to work for and a great place to both start and grow my career. Having now started my new role, I thought a good time to reflect on my time at Caplin and think about what may be on the horizon.

If you're writing Java code the chances are you're probably using Maven. What if you need your own repository for dependencies that aren't already hosted publicly? Here's how to host a public Maven repo for free.

I recently had a discussion with a colleague about why squashing commits in Git pull requests, or any source control for that matter, was bad. The discussion was started with a suggestion that developers (at work) should start to follow a specific commit message format. This was so that release notes could be automatically generated based on the commits in a given release. Now to do this, and have a release note that looks sensible, it relies on very few commits per feature or bug fix, which in turn involves squashing developer's commits. While I don't object to a standardised commit message and automated release notes (in fact I'm a massive supporter of devops and build/task automation), I believe that squashing commits is a bad idea. Here's why.