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.

Permission error with Gradle on Travis CI

What happened?

I was setting up the continuous integration for a project that used Gradle as build tool on Travis CI.

The first build failed due to a repeated permission denied error running the gradlew wrapper file.

The important part it’s 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.

The solution

Obviously the first thing to do is searching on google about the problem.

This lead me to this stackoverflow answer, from wich I used the second solution proposed.

Basically the problem is due to the fact that the the gradlew wrapper file it’s not set as executable.

I liked more the solution of adding a before_install call to chmod +x on the file in question.

So from this .travis.yml

I just ended up with:

Which is fine.


JUnit test class names are important with maven



I came across a funny issue on utils (available here) today, basically 2 unit tests were not executed by Apache Maven on Travis CI.

It’s funny beacause it happened to me before, so I knew how to fix this problem.

On my machine I usually run JUnit tests with the JUnit plugin integrated into the Eclipse IDE because it’s nice, green/red, failure log, stacktrace and stuff.

Instead, when calling from the command line mvn test, Maven uses the maven-surefire-plugin to execute the tests. In its documentation it says that the default configuration, which I can’t be bothered to change, is to pick up every file name that matches this expressions:

  • **/Test*.java
  • **/*Test.java
  • **/*TestCase.java

A typo like NullCheckerTests, instead of NullCheckerTest prevents the tests in the class from being executed because the class it’s just ignored during test execution.

The solution it’s easy, following naming conventions, I think it’s nice to call all my test with an ending *Test in the name of the file and class, after all if you’re declaring an xxx test class, so it should be called XxxTest in a file named XxxTest.java.

An example of the problem and the relative solution can be found here.

I thought that sharing this issue could be useful if anybody encountered the same problem.

By the way, because of this issue I released version 1.0.5 of utils.


Long time, no see.. It’s been a very busy year to say the least.

I always liked to solve problems, to write code and experiment with stuff, so as you do, I developed some personal projects to try out new things.

I usually develop in Java, using Apache Maven as my build and dependency management tool, in my spare time and at my job too. I’ve noticed that I usually keep my general purpose utilities classes under packages like *.utils or *.helper.

This led to a lot of copy-pasted code all over the place. A lot of methods were also untested. I couldn’t even be bothered to look inside the other projects if there was already what I needed, so I ended up re-writing already existent stuff, that’s for sure.

I finally decided that I’m done with this mess.

I started a project called utils, and I choose that it should be open source and available under the BSD 3-Clause License.

The source code is hosted on GitHub and I put the project under continuous integration testing with a service called Travis CI. I use another service called Codacy that provides automated code analysis. I also discovered another service called JitPack looking around for a quick way to share my artifacts online. The home page of JitPack reads “Easy to use package repository for Git” and I can say that’s really great! It uses maven as the build tool, provides artifacts for sources/javadoc and it’s integrated with GitHub release system (just tag your code on git and you’re good to go basically, artifacts are online usually the order of seconds).

All this services are free for open source and it’s a great technological stack to write good code, check them out.

Here’s what i’ve setup for the project:

utils is open source and in development so, of course suggestions, critics, contributions and whatever are welcome.