- 2015-08-21: 50% less server load with MongoDB on the Drupal 7 site factory at France Télévisions
- 2015-07-15: Our first Drupal 8 production site at France Télévisions is live
- 2014-08-18: 400% speedup in 3 weeks for http://france3-regions.francetvinfo.fr/ : who said Drupal back-offices had to be slow ?
- 2014-02-07: Sotchi Olympics traffic not a problem for http://www.francetvsport.fr/ , which I rearchitected on Drupal 7 in 2013
- 2011-09-14: Completed migration of FranceInfo.FR from SPIP to Drupal
- 2011-07-13: The new social network features of Le Figaro are now powered by an OSInet-designed MongoDB implementation
- 2010-12-21: Madame Figaro brand new site by OSInet and others
- 2010-08-16: France.FR is back online with OSInet and Typhon
- 2010-06-15: the new France Culture, which OSInet helped reach its performance goals, is now online
Git tip of the day : show the hottest files in a repo
When auditing or reviewing an unknown code base, I often have to decide which files to examine in priority. Beyond the usual heuristics for Drupal projects (hint: look at templates in D7), how can one find the parts most likely to contain problems ? This simple command set can help pinpoint troublemaking files quickly.
The idea is simply that is a file contains problems, they are likely to have been identified and worked on more than other files, leading to a higher number of commits. And for this, Git can help us, by giving the most often changed files. Turns out this is really simple by massaging the
git log with some shell commands:
Which can give us something like this example, taken from the recently created Beanstalkd module for Drupal 8:
$ code_heat.bash 7.x-1.x..8.x-1.x
The results are interesting : the top-modified class (
BeanstalkdServer) just recently broke the cyclomatic complexity warning threshold, and is on my list as the next refactor target. And the Drush plugin is coming next. So, at least in this case, the results are definitely relevant.
The check for relevancy, I also tried this on an unpublished entreprise-class project with a dozen developers, and found the results on thousands of commits instead of a few dozen to be just as relevant, so this seems like a good zero-cost trick to keep in mind.
Going further, assuming your development group sticks to a formalized commit message format including ticket references with issue types, it is possible to group issues by ticket by using a slightly more complex version of this log filtering, and use Brandon Carson's Defect Density Heatmap to get a 2-dimensional heat map as a cloud of files to analyze, relying on size for the number of commits and color for the type of commits (e.g. features vs bug fixes).