- 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
Graylog is, in the words of its creators, a tool to
Store, search & analyze log data from any source, and it puts a lot of power in our hands to slice, dice, and generally combine, gather, and parse content from various sources, notably syslog and Gelf sources, as well as many file-type sources thanks to the Graylog Collector. Which means it makes it a snap to build event-oriented dashboards like the left part of this example, and even some event volume graphs like the topmost one on the right.
The problem: logging non-event information
This covers only logged events, which is fine overall, since Graylog is a log analysis platform, not a graph-oriented monitoring system like Munin / Cati / Ganglia et alii. However, in many cases, especially when building dashboards instead of performing some specific research, one may want to keep an eye on average system load, or other non-event information, if only to know when to switch one's attention to the monitoring system.
So how can one add system load information, which is not event-based, to a log dashboard like the three bottom-right graphs on the previous dashboard ?
When running tests on a server using the recent versions of the MongoDB module for Drupal, and more specifically the MongoDB simpletests, the simpletest runner may leave droppings in your MongoDB Drupal database, which have no business remaining there. How to remove them while keeping the good collections ?
The typical case will be after a failed test runs, looking like this:
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.
One of the big trends during the Drupal 8 creation has been the replacement of info hooks by two main mechanisms: annotations, and YAML files. In that light,
hook_drush_command(), as the CLI equivalent of the late
hook_menu, replaced by various YAML files, looks just like a perfect candidate for replacement by a
commands section in some
mymodule.drush.yml configuration file. Turns out it is incredibly easy to achieve. Let's see how to kill some hundred lines of code real fast !
I've been doing a lot more Meteor these days, especially working on Drupal 8 SSO with Meteor, and could not find a reasonably complete and up-to-date (for Meteor 188.8.131.52) list of the Tinytest assertions, so I updated, reordered, and completed the existing gist on the topic.
So here is the Meteor Tinytest cheatsheet: https://gist.github.com/FGM/8075e9e249d453d8601b : complete list of assertions and helpers for your test methods.
Autoloading in D8 is much more convenient that in previous versions, however, it still has limitations. One such issue is with
hook_requirements(), which is supposed to be present in the module install file, not the module itself: when called at runtime for the site report page, the module is loaded and the PSR/4 autoloader works fine. However, when that hook is fired during install to ensure the module can indeed be enabled, the module is not yet enabled, and the autoloader is not yet able to find code from that module, meaning the
hook_requirements('install') implementation cannot use namespaced classes from the module, as they will not be autoloadable. What are the solutions ?
One nice thing during Drupal 7/8 development is the ability, thanks to the
devel module, to get a list of all SQL queries ran on a page. As I've been working quite a bit on MongoDB in PHP recently, I wondered how to obtain comparable results when using MongoDB in PHP projects. Looking at the D7 implementation, the magic happens in the
// Start logging on the default database.
// Get the log contents, typically in a shutdown handler.
$log = \Database::getLog(DB_CHANNEL);
With DBTNG, that's all it takes, and devel puts it to good use UI-wise. So is there be an equivalent mechanism in MongoDB ? Of course there is !
While porting (well, actually rewriting) an old PHP library to Go, I had to use a CRC (cyclic redundancy check) on a buffer. In old-school PHP, the standard is well established since PHP 4: just use
crc32 from the
strings package, and beware of the sign bit or, to be a bit more current while still compatible, use the
hash() function from the
hash package, like this example:
One of the interesting aspects of the revamped menu/links system in Drupal 8 is the fact that menu links are now in easily parseable YAML files, the "(module).links.menu.yml" in each module, in which each menu link can be bound to its parent link, hopefully producing a tree-like structure.
If you program in Go, you've probably written a lot of packages, and probably split packages in subpackages. Maybe even more than idiomatic Go would really advise... And you may have been grumbling just like I did at the fact that the
go test command requires a list of packages, and does not recursively dive into all the subpackages, like PHPunit would, and does not seem to have a working recursion flag.