walk-stats (part 2)

Let’s configure some services

Changing .gitignore

I’ve developed different projects with Java, git and Eclipse  and I’ve come up with a .gitignore I use in my projects, it’s quite useful and it’s becoming more complete with time, so It’s something I just put it there and everything it’s fine committing.

Here it is:

 Keeping things logical

When I work on a project I tend to get stuck on little details instead of focusing on keeping the work flowing and worrying about the details later.

A nice way I found to solve this it’s using tools designed to help keeping track of what needs to be done and how.

Issues and milestones

I like github‘s issues and milestones mechanism to plan what to do and when to do it, you can find more about this in the linked documentation.

It’s actually much more than this, an issue tracker for people to discuss and plan integrations, bug fixes and ask questions about a project.

Yes it’s pretty cool stuff and for open source public projects it’s free to use under the github terms of service.


As I go along I’ll plan to release this series of post about developing walk-stats directly here.

Here is this episode milestone.

I’ve created different issues for the arguments I want to talk about on this episode, it reflects the needs of the project too, so here we go:

Choose and configure a build automation tool for the project

There are various ways to write and compile a program in Java as in every other language.

You can simply create a class then call javac on the source code and java on the class to run it.

This is all fine and dandy, teaches the basics of how interpreted and compiled languages works and the steps needed to create something executable from just text.

Anyway, as the project you’re working on becomes more complex than a simple main method it’s much easier to manage it with a build automation tool.

This tools are useful because they minimize the chances of forgetting something (a machine does what it’s supposed to do instead of a human), and most of them also open up an opportunity to stand on the shoulders of giants, giving you automatic access to a huge library of already made open source projects to use as dependencies to solve problems people have already analysed, tested a kindly shared with the world.

Examples of build automation tools are:

Each one has its nice things and its weakness, the perfect one does not exist.

I’m pretty much familiar with Maven, I’m using it at work and makes a lot of sense, but I’m willing to try out Gradle, it’s a young tool, powered by a Domain Specific Language powered by the language Groovy.

Everybody it’s talking of it as the solution to all evil, so a look at it sure can’t hurt.

Cloning the repository on my local machine

The first thing to do is cloning the repository from github to my local machine.

I won’t focus on the procedure to install and configure or usage of git on any platform, it’s well detailed in the git documentation.

Let’s start actually adding something to this empty and lonely project 🙂

git clone https://github.com/scompo/walk-stats.git

Let’s change directory into the project itself with

cd walk-stats

An easy way to start using gradle it using its wrapper so let’s configure the project to use it (again, I suppose you have a working installation of gradle on your machine, more information on how to install it can be found here).

gradle wrapper

will generate a directory structure like this:

│ .gitignore
│ gradlew
│ gradlew.bat

│ └───2.11
│ └───taskArtifacts
│ cache.properties
│ cache.properties.lock
│ fileHashes.bin
│ fileSnapshots.bin
│ outputFileStates.bin
│ taskArtifacts.bin


If that’s the case we’re good, it will be also a good time to commit the changes on a branch as I did here.

Let’s then init the project with a build.gradle file and commit again with

gradle init

And you finally should have all the files I have here.

Creating a stub of the project for further configuration

Let’s start writing some code, nothing fancy, pretty boring I’d say.

I just want to create a Java class and a couple of test cases that fails and pass  to have a basic structure for the project and get it compiled for the next steps.


The first way to keep the code readable it’s organizing it in packages, this helps understand where to find what you need and it helps also not having a horrible mess of files around in the main folder.

Lets create some folders:

mkdir src/main/java/com/github/scompo/walkstats
mkdir src/test/java/com/github/scompo/walkstats

Now let’s create an empty Java Class and a JUnit test for it.

Here’s Application.java

And here’s ApplicationTest.java

I know, it’s pretty sad for the first time I wrote some code on this project, but now I’m ready to move on with the remaining phases for the configuration of the project.

The project now should look something like this.

Setting up a Continuous Integration testing service

Setting up a Continuous Integration testing service used to be a pretty demanding operation to do.

Luckily for everybody today services like Travis CI exists, they make a developer’s life much easier! (especially on open source code hosted on github 😉 )

To prepare the project to be under CI testing at each commit just sign in with your github credentials in Travis CI, click on the plus icon and flick the switch on the project.

The next thing to do is creating a .travis.yml and place it in the project root folder.

There’s actually not much about it apart from telling travis that this is a java project and that I wanted to use the oracle JDK version 8 to compile it.

Mine looks something like this:

Well, commit and push, and what do you know, the first build failed like this.

No problem, stuff goes wrong all the times, I’m used to it, it’s one of the ways you can learn something.

The interesting part is the following:

$ ./gradlew assemble
/home/travis/build.sh: line 179: ./gradlew: Permission denied

The command “eval ./gradlew assemble” failed. Retrying, 2 of 3.
/home/travis/build.sh: line 179: ./gradlew: Permission denied

The command “eval ./gradlew assemble” failed. Retrying, 3 of 3.
/home/travis/build.sh: line 179: ./gradlew: Permission denied

The command “eval ./gradlew assemble” failed 3 times.

At least I can’t say that he didn’t try it 😛

Jokes apart it looks like the ./gradlew file hasn’t got the right permission to be run by Travis CI.

You can find more details about it here.

The solution is to add to .travis.yml some pre build commands to set it executable, to make it look something like this:

Now the build still fails, but just because of the failing test I created!

This is what I call a success 🙂

Setting up a test coverage service

The next thing to do is setting up a test coverage service, it’s nice to know that your code is covered by tests, this gives you confidence in what you’re doing and prevents unwanted collateral regression.

First of all let’s remove the useless failing test from ApplicationTest because I don’t want my tests to fail for no reason anymore leaving just passingTest.

We are now good to set up a coveralls.io test coverage listener for this project.

The procedure to do this is similar to the one illustrated for Travis CI.

Log in with the github credentials, click on add repos and add the one for the project.

To keep things simple I choose to use the coveralls-gradle-plugin.

I needed to do some editing to a couple of files:

.travis.yml again to add a after_success phase to post the results to coveralls.

build.gradle to add the jacocoTestReport task

It worked, of course there’s no code so the report it’s pretty sad, but this means nonetheless that everything’s talking together as expected.

Setting up a code analysis service

This is probably a bit anal…

Anyway, it’s nice to have an eye on how your code is written, typos could result into vulnerabilities or headaches later.

I’m going to use Codacy to analyze my code.

The procedure to set this service up it’s basically the same as the 2 I discussed earlier on.

Log in with github credentials, choose the repository and enable it.

Here’s the result of all my efforts.

Summing things up

I’ve configured all the stuff I wanted as a service on my project.

A nice touch is to add badges to the readme.md file to see the status live from github

This is the result.

After all this configuration stuff I think it’s time to write some code, tune in next time for data modeling and other fancy things.

You can find the code, like it has been written at the time of this post here.

See you later.