Add new post

content/post/2019-05-03_hits-of-code.md

@@ -0,0 +1,78 @@
++++
+title = "Hits-of-Code Badges"
+description = "Building a web service for readme badges"
+date = "2019-05-03T16:00:00+02:00"
+publishdate = "2019-05-03T16:00:00+02:00"
+draft = false
+categories = ["rust", "programming"]
+tags = ["rust", "actic-web", "hits-of-code", "code metric"]
++++
+
+There are few metrics that try to evaluate a codebase. Some give a
+glimpse about the code quality like cyclomatic complexity, code
+duplication, dependency graphs and the most accurate of all, [WTFs per
+minute (WTFs/min)](https://www.osnews.com/story/19266/wtfsm/).  Others
+are less well fit to actually evaluate the quality of a code base such
+as [souce lines of code
+(SLoC)](https://en.wikipedia.org/wiki/Source_lines_of_code). Counting
+SLoC might seem like a good metric for the amount of work invested in
+a piece of software at first, but when you think about it, things like
+refactorings and removal of duplicate code through new abstractions
+might reduce the SLoC even if work was invested.
+
+[![WTFs/m](/static/images/wtfm.jpg)](https://www.osnews.com/story/19266/wtfsm/)
+
+
+## Hits-of-Code
+
+A few years ago, [Yegor Bugayenko](https://www.yegor256.com) proposed
+[Hits-of-Code](https://www.yegor256.com/2014/11/14/hits-of-code.html)
+as an alternative to SLoC. The idea is to count the changes made to
+the codebase over time instead of simply counting the current amount
+of lines. By looking at the commit history, you can calculate the
+metric and it gives a better overview about the amount of work, that
+was invested to implement some project. The score grows with every
+commit you make and can never shrink.
+
+While this has nothing to say about the code quality, I think this is
+a useful metric, so I decided to implement a small web service to
+generate badges for everyone to include in their readme files:
+[hitsofcode.com](https://hitsofcode.com).
+
+[![Hits-of-Code](https://hitsofcode.com/github/vbrandl/hoc)](https://hitsofcode.com/view/github/vbrandl/hoc)
+
+Currently only repositories hosted on [GitHub](https://github.com),
+[Gitlab](https://gitlab.com) and [BitBucket](https://bitbucket.org)
+are supported. The service is implemented in Rust using the
+[actix-web](https://actix.rs) framework and deployed as a Docker
+container. It is possible to self-host everything using the [Docker
+image](https://hub.docker.com/r/vbrandl/hits-of-code) or by building
+the [source code](https://github.com/vbrandl/hoc) yourself.
+
+The service simply creates a bare clone of the referenced repository
+and parses the output of `git log`. I also implemented a simple
+caching mechanism by storing the commit ref of `HEAD` and the HoC
+score. Consecutive requests will pull the repository, compare the old
+`HEAD` against the new one, if the `HEAD` changed, the HoC between the
+old and the new one is calculated and the old score gets added. If
+`HEAD` stayed the same, the old score is returned.
+
+I have some ideas for the future, e.g. calculating the metric using a
+git library instead of invoking a git binary like in the [reference
+implementation](https://github.com/yegor256/hoc/blob/master/lib/hoc/git.rb#L41)
+and implement nicer overview pages. But for now the service works
+fine and is already used by some repositories.  If you got any feature
+requests or bugs to report, just open a [issue on
+GitHub](https://github.com/vbrandl/hoc/issues) or [contact me
+directly](/contact).
+
+
+## Final Words
+
+I think HoC is a cool metric and it is a fun project to work on and
+improve further but always keep in mind:
+
+> Responsible use of the metrics is just as important as collecting
+> them in the first place.
+>
+> <cite>[Jeff Atwood](https://blog.codinghorror.com/a-visit-from-the-metrics-maid/)</cite>