Latest sites

  • 2017-11-26: New Drupal 8 site at Rue du Commerce, architected and tech-led by OSInet, just went throught Black Friday week with flying colors thanks to RabbitMQ
  • 2017-05-26: New headless Drupal 8 / Symfony 3 site at FranceTV Sport, architected and tech-led by OSInet, with RabbitMQ
  • 2017-02-20: New Drupal 8 site galaxy (+/- 70 sites) for Agences Régionales de Santé architected and tech-led by OSInet, delivered by Klee
  • 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

Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

Debug vanilla

Most of the time, when working on some piece of code, I'll resort to the configured debugger in my current Zend Studio configuration. And you probably do too :-)

However, I often have to access debug-type information on live sites where installing a debugger is out of the question, and I find myself often resorting to parameter dumps like the following:

<?php
// lazy version for simple cases
function foo_bar($x, $y, $z) {
 
dsm(func_get_args());
 
// [...]

// less lazy version for more hairy cases
function foo_baz($x, $y, $z) {
 
dsm(array('in foo_baz, x' => $x, 'y' => $y, 'z' => $z));
 
// ...
?>

You've probably being using it too and, of course, after the first few dozen times, it becomes a bit used. So here's a tiny snippet that makes such dumps simpler to type and use :

<?php
function foo_quux($x, $y, $z) {
 
dsm(func_get_args_hash());
 
// [...]

/**
* Provide a better func_get_args()
*
* @return array
*   Hash of parameters, keyed by parameter name
*/
function func_get_args_hash() {
 
$stack = debug_backtrace();
 
$stack = $stack[1];
 
$rf = new ReflectionFunction($stack['function']);
 
$params = $rf->getParameters();
 
$ret = array();
  foreach (
$params as $index => $param) {
   
$ret[$param->name] = $stack['args'][$index];
  }
  return
$ret;
}
?>

Knowing next to nothing about

Knowing next to nothing about reflection, I can't see what makes this better than vanila dsm() or dpm(). What does the output look like?

Parameter names and default values

When using dsm(func_get_args_hash()) instead of dsm(func_get_args()), you get:

  1. the names of the parameters along with their values, which you don't get with a normal dsm(func_get_args()).
  2. the values taken by default parameters (those not passed in by the caller, which you don't get from func_get_args

When you're bug-hunting, it's often useful (to me at least) to know which parameter is being represented by a value in the args dump, and which values all the parameters have, default or explicit.

Sample use on _locale_import_one_string_db() below.

Difference between func_get_args() and func_get_args_hash()