Sunday 22 January 2012 - Filed under Uncategorized
:: Share or discuss :: 2012-01-22 :: mattr
Tuesday 17 January 2012 - Filed under Tips and Tricks + Work
Lately at work there’s been a bit of an obsession with metrics – I’m not sure it’s healthy. Code metrics can be interesting, but in the wrong hands or used the wrong way, they are misleading and harmful. It’s still to be seen what the outcome will be in this case. I’m more than little worried.
That said, even I like to get some numbers on code, especially unfamiliar code, to help me figure out a few things. For example, I’ve been using CLOC (Count Lines of Code) for years to find out quickly how big a project is and what languages are used in what proportion.
The first metric that’s started to be tracked at work is lines of code added and deleted per release, per author. I’ve occasionally glanced at these kinds of numbers in the past too, and even wrote a little script (git-rank) to get the same kind of info when I was on a code deletion spree. I’ve found these numbers to be useful for getting a general idea of who is most knowledgeable about a project or some files within the project.
However, the numbers can easily be misleading. For example, if someone is committing a lot of style reformats, vendoring code from other projects, or autogenerating documentation, their numbers will be very high but they may know very little about the codebase. For example, for a release to a Rails project I’ve worked on the metrics gathered showed that I had added 248,475 lines and deleted 458,020 lines. That’s obviously suspicious, although it does make me look very active. These are the kinds of numbers that you should dig a little to figure out what’s happening, which is why I wrote my little git-rank script makes it easy to break those line totals down by file, and then exclude files for the next count.
$ git rank v1.1.1..v1.1.9 --all-authors-breakdown --author "Matt Robinson"
Matt Robinson 603061
1 vendor/gems/json_pure-1.5.1/tests/fixtures/fail14.json
1 vendor/gems/json_pure-1.5.1/tests/fixtures/fail12.json
1 vendor/rails/railties/test/vendor/gems/dummy-gem-a-0.4.0/lib/dummy-gem-a.rb
........
21418 vendor/gems/haml-3.0.13/lib/haml/precompiler.rbc
24953 vendor/gems/haml-3.0.13/test/sass/engine_test.rbc
30038 vendor/gems/haml-3.0.13/test/haml/engine_test.rbc
Matt Robinson 603061
It’s pretty obvious that most of what I did was update vendored gems. If you’re trying to figure out who did the most work between the releases I specified, you probably want to ignore the vendor directory when count lines of code.
% git rank v1.1.1..v1.1.9 --exclude-file vendor
Josh Cooper 4
Nigel Kersten 8
Andreas Zuber 11
Michael Stahnke 11
Jacob Helwig 15
nfagerlund 37
Daniel Pittman 283
Max Martin 418
Nick Lewis 543
Randall Hansen 901
Pieter van de Bruggen 1018
Matt Robinson 1661
Now we’re starting to get a more realistic picture. From here we could dig deeper by listing all the files again for all the authors, and then maybe start excluding lines based on a regex if there were automated changes, and then maybe look at additions vs deletions in the count (I’m summing them together for these numbers).
However, I hope people *never* think they can get the whole picture, or even most of the picture, of a code base and who is contributing the most from something as arbitrary as lines of code counts. I feel like that’s almost too obvious to say, but I’ve heard horror stories of managers who tie reviews to metrics like this. I hope I never personally experience such a thing.
P.S. If anyone tries using the ‘git-rank’ project I mentioned above, please keep in mind it’s a hacky little sick project that is probably got some bugs and you should take the numbers is spits out with a grain of salt. What a weird phrase that is.
:: Share or discuss :: 2012-01-17 :: mattr
Tuesday 17 January 2012 - Filed under Education + Open Source + Testing
I’m finally getting around to posting my slides from the presentation I did at Open Source Bridge in June last year. It was fun to present and attend the conference, although next time I hope do to a talk about something more fun. Testing is an important and useful topic, but not nearly as entertaining as a totally RESTful language.
:: Share or discuss :: 2012-01-17 :: mattr
Sunday 1 January 2012 - Filed under Uncategorized
:: Share or discuss :: 2012-01-01 :: mattr
Thursday 29 December 2011 - Filed under Open Source + Work
When I first started working for Puppet Labs, one of the main reasons was that I would get to contribute to open source software as a full time job. However, for much of the summer and fall I was leading a team to create a closed source feature built on top of the open source projects in the Puppet ecosystem, and it turned out pretty well if I do say myself – Live Management. It’s a web app addon to Puppet Dashboard that exposes the command line interface of the cool server orchestration framework MCollective. MCollective lets you execute commands on large numbers of systems in parallel, including doing things like triggering Puppet runs, starting and stopping services, or gathering lots of realtime information about your infrastructure from Facter. It’s like the big red button for your entire infrastructure: so easy to use even your manager can now blow up your infrastructure with a few clicks.
Besides building on the open source Puppet projects of Puppet, MCollective, Puppet Dashboard and Facter, we also used a ton of other open source software directly: Rails, Sinatra, BatmanJS, JQuery and many more indirectly. One of our team members pvande was able to contribute a lot of code and help back to the BatmanJS project – we had to since it’s alpha software and we were using it in a commercial application.
As I worked on the project, I sometimes felt sad that it wasn’t being open sourced. I knew the rationalization that at some point the company has to make a product that people will pay us money for, but that wasn’t the rationalization that helped me accept it most at the end. What helped was knowing that by building on top of other open source projects, we ended up contributing a lot back to them. Puppet got bug fixes and small new features to help us manage resources, MCollective got plugin improvements and feedback on how it can better support web app use cases and scale testing, Puppet Dashboard got some CSS cleanup and UI improvements, and BatmanJS got lots of real world use, feedback and code.
Besides, it’s free to try out for fewer than 10 nodes, and since it’s written in interpreted languages, people can view the source code if they really want to. There’s nothing stopping someone from writing a similar thing open sourced, and now we’ve done some of the hard work of improving the platform they would also build on. This does mean that we’ll have to continue to innovate and improve on our closed source features that sell product, but also on our open source platform that enables anyone to build their own features make their life managing systems easier.
:: Share or discuss :: 2011-12-29 :: mattr
Sunday 18 December 2011 - Filed under Uncategorized
:: Share or discuss :: 2011-12-18 :: mattr
Sunday 13 November 2011 - Filed under Uncategorized
:: Share or discuss :: 2011-11-13 :: mattr
Sunday 21 August 2011 - Filed under Uncategorized
:: Share or discuss :: 2011-08-21 :: mattr
Sunday 17 July 2011 - Filed under Uncategorized
:: Share or discuss :: 2011-07-17 :: mattr
Sunday 5 June 2011 - Filed under Uncategorized
:: Share or discuss :: 2011-06-05 :: mattr