Reno, NV    +1 (800)0 621-0871

Go back


Building the Commits Calendar

  |  June 5, 2014

As previously mentioned, Kim and I chose to contribute to Gitlab and apply a feature that we later called “Commits Calendar”. It is a calendar where users get to see commit activities within a timeframe.

To be able to contribute, we had to setup our development environment, which wasn’t easy.


For the calendar to show the commits, we investigated where the data containing the logs of the repositories are generated and got the information we need (particularly the list of commits of the user) to populate the calendar heat-map. With the help of the Gitlab-git library and a user’s profile currently being viewed, we tracked the user’s project and filtered only those where the user has git commits.

Thanks to the d3.js library and the Cal-Heatmap plugin, we were able to build the feature. The heatmap plugin is made available via cal-heatmap-rails gem. We made a custom css file so we can add our customizations to the design and layout.

Once we built the commits calendar’s basic functionality and was working well, we made our first pull request. Positive feedback came from one of Gitlab’s co-authors Dmitriy Zaporozhets (a.k.a. Randx), saying that he liked the idea of our feature. He asked us to fix our code quality. So refactoring was the next step for us to do.

We learned tips and techniques on how to refactor code and where to put which lines. We moved large chunks of code to a helper. After these steps, we decided to make an Rspec controller spec because adding tests is part of the contributions’ requirements. When we committed these changes Randx asked us to move improve our code further and offered suggestions to make it mergeable.

We then proceeded to update our first pull request and also decided to add something more to the calendar.  When a user hover’s over a date with commits, the number of commits and the repository to where those are pushed to will be displayed (and shows a message that there is no commit on that day) via an ajax request. We submitted another pull request with the addition of that functionality. Dmitriy commented that we refactor our code again. He particularly pointed out the two large methods so we had these broken down into smaller methods: some were in the file we made under lib and others were in the repository model. Here we experienced the most difficulty in refactoring because the method codes were very complex, and we were doing a lot within just one method.

The AELOGICIANS helped us by teaching us different styles on how to deal with complex code – whether we break it down into smaller methods within the same class or extract the class, among others.

Currently we are waiting on the maintainers to give us feedback on our pull request. Hopefully everything goes well and our feature would be merged into Gitlab.