I've long been receiving quite high volumes of comment spam on this blog, which is why comments have always been pre-moderated. And, of course, there is usually not much to think of it. Not so with one of the spam messages posted today, which unwittingly provided an unexpected insight into the current mechanisms uses by spammers.
Go syntax has some funny peculiarities which are not immediately obvious, like methods on primitive types. Let's have a look.
Anyone with a few hours of Go is familiar with the basic object notation, like this example:
One litle-publicized feature of the BeeGo Go framework is its admin dashboard.
Although it may look quite raw visually (think MIME: text/plain), it contains a wealth of information about goroutines, threads, memory usage, and request statistics. It even allows devs to add to a "healthcheck" list, and admins allowed dashboard access to run "tasks" defined in code. The diagram belows shows the hierarchy of features in the version coming with Beego 1.3.0.
Some days ago, at the AWS Summit 2014, DamZ renewed my long-sleeping interest for the Google Go language with wonderous stories about its use in infrastructure of the new Commerce Guys Platform they were launching that same days, so I've been doing my homework getting up to date on Go programming: that's what holidays are for, aren't they ?
Doctrine Annotations is a central part of the Drupal 8 Plugin API. One of its conceptual annoyances is the need for a separate autoloading process for annotations, which in some scenarios leads to duplicated path declarations. Let us see how to remedy to it.
Among the interesting features of Phing is its extensibility, and of the hallmarks of that exensibility is the ability to define new Task types as PHP classes, which are by default located in the default namespace only. Can we do better ?
At the simplest, Task classes are created by embedding ad-hoc tasks like:
A few days ago, while I was writing a bit of Silex code and grumbling at Doctrine DBAL's lack of support for a SQL Merge operation, I wondered if it wouldn't be possible to use DBTNG without the rest of Drupal.
Obviously, although DBTNG is described as having been designed for standalone use: DBTNG should be a stand-alone library with no external dependences other than PHP 5.2 and the PDO database library
, in actual use, the Github DBTNG repo has seen no commit in the last 3 years, and the D8 version is still not a Drupal 8 "Component" (i.e. decoupled code), but still a plain library with Drupal dependencies. How would it fare on its own ? Let's give it a try...
The WebProfilerServiceProvider brings the Symfony Profiler to Silex apps, and with it the nice "Timeline" feature, detailing for each request cycle the time spent handling each event dispatched by the EventDispatcher, from kernel.request to kernel.terminate, with detail time spent in each individual listener.
The timeline looks like this one:
This is all nice and well, but there is a problem with this timeline: although the beginning and end of the request cycle is profiled in depth, it represents less than half of the total time spent for this request.
More than half of the total request time is spent in the controller, and this example does not even perform any database access, which would make the controller represent event more of the total time, making the detailed analysis of the beginning and end of the request cycle less relevant.
What would make sense would be to subdivide the time spent in the controller in much the same way the time spent in the event listeners is already plotted. Is there a simple way ? Sure: let us see how the profiler works.
Yesterday, Seldaek committed PSR-4 support to Composer, as his New Year's Day gift to the PHP community.
So, since I always supported PSR-4 in FIG discussions, and after the tl;dr discussion about it regarding autoloading in Drupal 8, I jumped on the occasion and converted the code base for PlusVite to PSR-4 to get an idea of how PSR-4 "felt" in practice.
So DrupalCon Prague is almost over, and I can now share with you the video of my session about the history of the Drupal block system, from drop.org to Drupal 8, just as recorded on wednesday.
The session page is available on https://prague2013.drupal.org/session/blocks-drop.org-drupal-8-and-beyo… where you can also rate it. Please to it over there, or add your comments here: it is very useful for me to see what needs to be adjusted for upcoming presentations. Based on the overall feedback, it seems that: