JVM Calendar: Coder's Little Helper

We all know that feeling: time is of the essence. Deadlines, quality time with your loved ones, and still time for toy projects to keep yourself up-to-date — everything demands time, but the day can’t offer us more than 24 hours. And don’t get me started on sleep.

But wait, there is more. Our repositories bubble over with $stuff, different projects use different build tools, CI isn’t keeping up, deployment processes… AAAAAhhhh.

But fear not, fellow code-warrior. With a few little helpers, you can save yourself and your team a lot of time.

Automate All the Things

It is not just 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 the team can save everyone a lot of 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 reason, 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.

Use Make 

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 has been around since, well, forever. This makes 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 favorite 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 that used 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.

All of a sudden, running make in all of your sub-projects doesn’t seem so silly anymore, does 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, making it easier on my machine and my CI:

all: clean build-frontend build-backend package

clean:
rm -rf out
    ./gradlew clean

build-frontend:
npm run sass

build-backend:
./gradlew build

test:
./gradlew test

package: test
./gradlew assemble

init: clean
rm -rf node_modules
    npm install

run: clean build-frontend
./gradlew bootRun

release: init build-frontend build-backend

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 in regards to how you organize 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.

Use CI for Your Pet Projects

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 creating 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:

language: java
# if you already added a Makefile, simply add the following line
script: make

Easy, wasn’t it?!

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

All These Dependencies

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 too rapidly.

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.

Is There More?

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 has been 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!