Tour De Drupal, come to DrupalCon Amsterdam by bike

When the three orange Dutch guys presented DrupalCon Amsterdam 2014 in Prague, they had a slide (#36) were they joked about that one should come to Amsterdam, The Netherlands by bike.

Two friends were funny enough to take this from "a joke" to "a practial joke". Rachel and Stefan created "Tour de Drupal", a community movement to get as many Drupalista as possible to visit DrupalCon Amsterdam 2014 in 330 days by bike!

If you come to this DrupalCon, there is no excuse, you have to come by bike and put yourself on the map. While you are at it, follow our friends on @TourDeDrupal as well. Even I come by bike, and so should you Dries!

There is bound to be more funny stuff coming from the community in Amsterdam, I hope to be involved in some of this and will post it here as well. There is for example talk of an Eurosongfestival with Drupal songs and a revival of the Kitten Killers so bring your guitar as well.

So in the closing ceremony we now have lists of the amount Megabits used, liters coffee drunken and number of flat tires… :-)

No-one knows how the police officers find their way back to the exact stadium in which they were born.

No-one knows how the police officers find their way back to the exact stadium in which they were born. Yet every year, thousands make this epic journey - battling their way up one-way streets, and through congested city centres - to the very same sporting venue in which they began their lives. They end their journeys exhausted, barely able to complete the final act for which this epic journey was made. It was here that they were born; it is here that they will spawn the next generation of law-enforcers; and it is here that they will end their lives - in the terraces of their ancestral arena, after one of the greatest migrations of the natural world.

via jwz

Want accessability geldt enkel voor websites (niet voor brochures, brievenbussen of HTML mail)

maar als het om mail of offline uitingen gaat, kijkt niemand naar accesability

Ik ben voor een open web. Voor toeganglijke websites. En oprecht van mening dat zeker elke overheids site daaraan moet voldoen. Maar als het om offline zaken als brochures gaat, dan kijkt niemand naar kleurstelling. Leesbaarheid. Of dat blinden ook de brochre teksten kunnen verkrijgen. Want dat is geen doel, daar zijn geen badges voor.

Of bijvoorbeeld mail. Hier een voorbeeld van gemeente Amsterdam, maar geldt voor *elke* nieuwsbrief. Mailclients zijn namelijk niet gemaakt om HTML mail te lezen. Je kan natuurlijk gewoon plain text mail versturen. Zonder plaatje tracker die ziet wanneer ik welke mail waar en hoe laat open. Maar dat wil je niet.

  1. Vele accesability mannen (m/v) gaan enkel voor websites, of een brochure van een gemeente leesbaar is voor kleurenblinden, de tekst beschikbaar voor blinden, de brievenbus benaderbaar is vanaf de rolstoel, daar zijn geen badges voor en dus niet van belang
  2. HTML mail is ondergeschoven. Niemand kijkt naar afschuwlijke HTML laat staan dat de default leesbare plain/text zou zijn
  3. Plaatjes uit de mail gven zijn allemaal voorzien van tracking cookies. Hoe laat ik mijn mai open, wel of niet de nieuwsbrief lees, mijn browsersie... en alles zonder opt in of uit. "Cookie wet" anyone?

... stilte....

Spam wil eat itself, spammer requesting spam comments to be deleted

The site you are watching is rather old. The first posting is from 2002 and that is only because I deleted the database, the first posts were from around 2000.

So I have seen lots of spam attacks on my site, up to the point that I deleted the posisbility to add comments. I know about captchas and bayesian fingerprinting services like mollom, but this is my site with my rules. You want to expres your opinions, hike to facebook, twitter or start your own blog. My site, my rules.

However, back in 2006 I had comments on and there was a posting with some rather lame comments ("yes, I agree, Drupal is great"). Never gave it much thought. However, there was also a link in the users name. ... Indeed spam links. :-(

Now read this mail I got the other day:

Funny right? They have been spamming the internet for ages and now they found out that the postings they have paid for to be placed on sites like mine, are contra productive for their Google ranking and now they wanted to delete the posts!

Here is my answer, lets see what will be happening :-)

(ps I deleted the spams all the same :-)

Zen and the art of innovation

Commodity sinks, innovations rises. An old rule. That is the reason why the drop has to keep on moving, have shorter release cycles and adopt new technologies faster to make sure we don't become what we replaced; old outdated systems that are slow to adapt and fast to extinct.

There are two sides to this, we have to grab new technologies faster and dump older technologies sooner. And so be sure that adopting new technologies faster doesn't create a legacy we have to release faster. Or at least, this is my opinion.

"Nobody" in the world logs in with openID anymore. Many appliaction to application in backend still might be using it, but nobody uses it to authenticate anymore. The last bastion Janrain just announced that it will close the doors. Drupal will drop OpenID form core as well and might have done this as well a long time ago. So when Drupal 8 will see the light in janury 2014, and we still would have release cycles over a 1000 days, the maintainers will still be dealing with an OpenID implementation and supporting it in Drupal core 7 up to the time D9 ships, somewhere around Q4 2017. Extrapolating our current release cycles most likely later, much later.

This is not to criticise anyone,I think it was a wise step to include OpenID back in the Drupal 6 days and it is a wise step to remove it from D8. But the time between making these releases and hence these decisions should be shorter. And especially the time that it impacts the code to maintain.

You want to know another example of an innovation that was once great and is now holding us back? gzipping pages. In core ever since 4.5 and was a great feature (though I had some problems back then :-)) But it is wrong. Holding us back in duplicate functionality that has to be maintained and is better being served in another OSI layer.

Back when webservers didn't compress pages and elements by default, it made perfect sense to do so from Drupal. A great way to save bandwidth and deliver the pages faster to the user. But now all webservers compress pages (and other elements like a big word document as an attachments served form /files/ !) by default, it is code that has to go. The innovation was great, but it sunk down to lower in the stack and became a commodity in all major webservers. And thta is the risk with all innovations and if one keeps holding to innovations that are already commodity, one ends up over there as well.

This holds true for many elements of frontend performance. Right now is seems like a good thing to combine multiple CSS or JS files in to one file. But once SPDY becomes mainstream this can better be done in HTTP protocol, not in the CMS.

And traditional frontend performance states that we have to use sprites in the template.

While if we add one module and one line of code this is all done at the webserver level with image sprites.

And we should use selective DATA URI's in our template. Most frontend devs will puke; binary data in a template? We are some old ugly old tchnology.
Again, with one command, the webserver layer will migrate these smaller images from flat files to inline DATA URI's.

Take a look at this impressive list of options where modpagespeed -a webserver module- can help you with:

  • Optimize Caching: Canonicalize JavaScript Libraries, Extend Cache, Extend Cache PDFs, Local Storage Cache, Outline CSS, Outline JavaScript
  • Minimize Round Trip Times: Combine CSS, Flatten CSS @imports, Inline CSS, Combine JavaScript, Inline JavaScript, Move CSS Above Scripts, Configuration file directive to shard domains, Sprite Image, Pre-Resolve DNS
  • Minimize Request Overhead: Rewrite Domains, Configuration file directive to map domains
  • Minimize Payload Size: Collapse Whitespace, Combine Heads, Elide Attributes, Minify JavaScript, Optimize Images, Prioritize Critical CSS, Deduplicate Inlined Images, Remove Comments, Remove Quotes, Rewrite CSS, Rewrite Style Attributes, Trim URLs
  • Optimize Browser Rendering: Convert Meta Tags, Defer Javascript, Inline Preview Images, Lazily Load Images, Move CSS to Head, Optimize Images, Convert JPEG to Progressive, Rewrite Style Attributes
  • Other: Add Head, Add Instrumentation, Inline @import to Link, Make Google Analytics Async, Insert Google Analytics Snippet, Pedantic, Run Experiment

Now for some of these actions there might be a Drupal module (lazyloading), for some functions one has to write good CSS/HTML/JS (CSS above scripts), some need good content editors or backend processes (de-duplicate inline images, progressive jpeg's) and some are just not doable yet in the frontend in an easy way (DATA-URI's).

So as a frontend dev (ops), do yourself a favour and do use the page speed module out for Apache and nginx AND keep writing good templates. And as a community Drupal community member, make sure that we keep innovating on the top , and let code free at the end where it is better being served outside of our hands.

(btw Mike Ryan, more retro future at this pinterest board :-)