Coder’s Little Helper

It is not all about servers when we talk about automation.

Onboarding is always a pain. Getting everything set up on your developer machine, getting access to all systems and getting that extra little helper tool no-one knew about before joining that team but is saving everyone so much time.

Well, on a server more and more companies go down the automation route which makes sense and saves tremendous amounts of money. But for some reasons, I barely came across an automated set up of our local machines.

The easiest and least painful way of achieving this is to use Ansible. All it needs is Python. That’s it. And all developer-oriented operating systems come with Python pre-installed.

Fair enough, you also need the versioning tool of your choice to get the latest set of playbooks, but you need it anyway.

Want to have a look for yourself? Ansible’s documentation is neat, but there are a lot of fantastic playbooks available already. For our Mac-fans, check out the Mac Development Ansible Playbook and for our Linux warriors have a look at this Ansible Ubuntu GitHub repository

Paired with the next tip the rest is just one make call away.

I am not kidding you, and yes, we are still in the 21st century.

This is a hack I came across at one of my previous places. And trust me, I am sure your reaction is pretty similar to mine.

So, let’s put that prejudice aside and look at from a practical view.

Make is around since, forever. This makes the tooling pretty awesome and easy to use. Nearly all operating systems bring shell completion (if not, please go and install WSOL or Git Shell). Sure, we can install the needed bits and bobs for our favourite JVM-language build and dependency management. But it requires extra time and is sometimes not that straightforward.

On top of it, in nearly all projects I worked in, there were multiple projects, using different build tools that need execution in a particular order. That order is easily achieved on a CI server, but locally it is an entirely different story.

Out of the sudden, running make in all of your sub-projects doesn’t seem so silly anymore, doesn’t it?

It also makes the life of your CI/CD set up easier. All a CI server needs is the correct set of targets.

Here is an example for a Makefile I created to build one of my pet projects easier on my machine and my CI:

In Makefiles, the first target found is the default one. So, executing make with this Makefile is the same as running make all.

The all target depends on most of the other targets. This is for convenience and entirely up to you, how you organise it. The most important thing is that all your projects should have a sensible default target that compiles the whole project in the correct order.

Why? Well, because this way, even the new junior developer who just joined can get everything compiled and tested quickly.

And yes, your developer machine automation project should have a Makefile and the default target should set up everything with sensible defaults.

You hopefully use a CI in one way or the other for your main projects at work. But going through all this trouble for your pet project? You want to hack away, possibly create a showroom for potential future employees.

Well, fear not. There are so many great CI-as-a-Service services out there to help us. And as long as we code in the open, they won’t even cost a thing.

One of the best-known services is Travis CI. It is simple, straightforward and surprisingly flexible.

By default, just adding a .travis.yml to a branch of your project and signing up with our GitHub account is all it takes.

Try adding the following config to your project:

Now, go and sign up on travis-ci.org, give it access to our public repository of choice and activate the project on your Account Overview.

All that’s left is to commit everything and push our branch with the shiny new YAML configuration file.

Easy, wasn’t it?!

And as a reward, we can add a Build-Badge to our project README.

Another pain in the back is keeping ahead of security issues.

Even in our pet projects, you should make sure you are not relying on vulnerable dependencies. Who knows, maybe our project becomes a dependency for someone else in the future?

Checking all the dependencies, especially the dependencies of your dependencies and then the dependencies… is nearly impossible for a single human being. The dependency tree is growing way too much.

Thankfully, there is a service for that. It is called Snyk and guess what, to get you covered you do not even need to borrow Santa’s platinum credit card.

It is free for open source projects (defined as openly available on GitHub), and you get a fair number of checks per month for private repositories.

Again, integration couldn’t be easier. Sign up with your GitHub credentials, head over to the Integrations page, click on GitHub and select your project. All set.

This is not limited to GitHub of course. You can choose from quite a variety of services or use the CLI tool and make it part of your build 😉

The CLI and all its dependencies are already on your machine, as your local environment automation script took care of it!

The last thing to do is to add your Badge and to integrate the results with your Slack Channel.

There is so much more out there that can help us be more productive.

Frameworks, libraries, services, IDE plugins and even command-line frameworks like Oh-My-Zsh are ready when you are.

In essence: We should stop reinventing the wheel over and over again. And even if we do, we should take all the help we can get on the way. Time will always be limited, but this shouldn’t be an excuse for lousy security, horrible code or not doing that fantastic project that is brewing in our heads for months now.

Of course, not all of us can use all the shiny things everywhere. But we can use them as a starting point and start looking for other little helpers that will make us more effective. And we are not alone. We should show off our little time savers and speak about ways to improve within our networks.

Happy coding.