Matchlogger: March summary and stats!

It is April already, so it’s time for some summary on my „Get Noticed” contest results so far. Did it go as I expected?

Application

First of all, things go a little bit slower than expected. 8 commits to the repository in March isn’t a great result. By now I have a working login and an ability to add teams (which I still want to restrict so that users could propose teams and an admin needs to accept them). My immediate goals are adding matches and, of course, deployment. BTW, did I mention that I own matchlogger.com? 馃槈 I would like the application to be available to the end users as soon as possible to be able to iterate with further development.

In total, the project now has 837 lines of code:

  • Java – 14 classes, 437 LOC
  • XML – 3 configuration files, 177 LOC
  • HTML – 5 files, 158 LOC
  • .properties – 6 files, 43 LOC
  • CSS – 1 file, 7 LOC
  • .yml – 1 file, 7 LOC
  • JS – 1 file, 6 LOC
  • .md – 1 file, 2 LOC

Blogging

I wrote 7 blog posts with tag DSP2017 in March. That’s around the planned amount. The most popular were:

  • Choose your Licence, Luke! – 41 views
  • Google OAuth2 login with Spring Boot – 37 views
  • Spring Boot: saving OAuth2 login data in DB using PrincipalExtractor – 11 views.

Those three were also the most popular posts on my blog during March. Looks like if the posts are focused on explaining one topic and have examples, they are the most popular. Likely this update post won’t be nearly as interesting as those three 馃槈

Extra stats

Time spent

In March, I spent 14 hours, 11 minutes and 10 seconds on Matchlogger development (data thanks to Toggl). Further 12 hours, 24 minutes and 56 seconds were spent on blogging – mostly for this contest. That means that in total, I spent around 51 minutes daily on the contest.

Code frequency

Looks like I tend to work in bursts. Those bursts are likely the days where I didn’t have any other plans, so I spent a lot of time on Matchlogger.

Branching

I’m not using full git flow, but branch my code and merge it to master through pull requests. It is enough for my project needs. As you can see, I usually have up to two branches open. You can also notice that there’s one case where a branch didn’t get merged – that was my modern approach to Vue.js development that turned out to freeze my IntelliJ on assets lookup even before I could exclude node_modules from scanning.

Timeslots

Nothing too unexpected here. On weekends I work throughout the day (I’m writing this post at 9 am), during the working week I tend to sit and code in the evening as during the day I’m at work.

Even if not everything goes as smooth as expected, I really like my pet project. I already learned new things and it can be satisfying at a time. 10/10, would participate again.