standards

The Drupal Way™

The Drupal Way

I've worked with a wide variety of developers, designers, content managers, and the other Drupal users in the past few years, and I'm pretty sure I have a handle on most of the reasons people think Drupal is a horrible platform. But before I get to that, I have to set up the rest of this post with the following quote:

There are not a hundred people in America who hate the Catholic Church. There are millions of people who hate what they wrongly believe to be the Catholic Church — which is, of course, quite a different thing.

Forgive me for diverging slightly into my faith, but this quote is from the late Fulton J. Sheen, and is in reference to the fact that so many people pour hatred on the Catholic Church not because of what the Church actually teaches, but because of what they think the Catholic Church teaches. Once someone comes to understand the actual teaching, they are free to agree or disagree with it—but there are comparatively few people who disagree with teachings they actually understand.

Similarly, the problems most people have with Drupal—and with systems like it—are problems not with Drupal, but with their perception of Drupal.

Java Jane: One-off vs. Flexible Design

A Java developer (let's call her Jane) is used to creating a bunch of base object classes and a schema for a database by hand, then deploying an application and managing the database through her own wrapper code. Jane is assigned to a Drupal project, takes one look at the database, and decides that no sane person would ever design a schema with hundreds of tables named field_data_* and field_revision_* for every single data point in the application!

Why does Drupal have So Many Database Tables?

In reality, Drupal is doing this because The Drupal Way dictates that things like field data should be: flexible (able to be used by different kinds of entities (content)), able to be translated, able to be revised with a trackable history, and able to be stored in different storage backends (e.g. MySQL, MariaDB, MongoDB, SQLite, etc.). If the fields were all stored in a per-entity table as separate columns, these different traits would be much more difficult to implement.

Thus, The Drupal Way is actually quite beneficial—if you want a flexible content management system.

I think a lot of developers hate Drupal because they know they could build a more efficient web application that only has the minimal required features they need by simply writing everything from scratch (or using a barebones framework). But what about the next 72 times you have to build the exact same thing, except slightly different each time, with a feature that's different here, translation abilities there, integration with Active Directory for user login here, integration with a dozen APIs there, etc.?

There's a maxim that goes something like: Every seasoned web developer started with plain HTML and CSS, or some hosted platform, then discovered a dynamic scripting language and built his own CMS-like system. Then, after building the CMS into a small system like many others but hopelessly insecure and unmaintainable, the developer realized that thousands of other people went through the same progression and ultimately worked together on systems like Drupal. Then said developer starts using Drupal, and the rest is history.

I know you could build a small system that beats the pants off Drupal performance-wise, and handles the three features you need done now. But why spend hours on a login form (that probably has security holes), session handling (ditto), password storage (ditto) forms in general (ditto), content CRUD interfaces, a translation system, a theme layer, etc., when you can have that out of the box, and just spend a little time making it look and behave like you want it? The shoulders of giants and all that...

.Net Neil: Letting Contrib/Bespoke Code Let You Down

A .Net developer (lets call him Neil) joins a Drupal project team after having worked on a small custom .Net application for a few years. Not only does he not know PHP (so he's learning by seeing the code already in use), he is also used to a tightly-controlled application code structure, which he knows and owns end-to-end.

PSR-0 PSR-1 PSR-2, Drupal, and You!

For the past couple years, discussions about 'PSR-0', PHP standards, and some sort of framework standardizations have been popping up here and there. It wasn't until a bunch of 'PSR-0 Interoperability' patches started popping up in the Drupal core issue queues that I decided to take a closer look at PSR. (The latest? PSR-1 (Basic Coding Standard) and PSR-2 (Coding Style Guide) have been accepted).

Switched back to Safari from Chrome... Again

Google Chrome No MoreGoogle lit up the hornet's nest yesterday when they announced that they were dropping built-in support of H.264 for their own 'open' WebM and OGG video formats.

I reconfigured Xmarks on all my computers (to sync all my bookmarks between FireFox, Safari and Chrome), and I'm back to using Safari full-time, with FireFox as my main backup. (FF 4.0 can't come soon enough).

It was good knowing ye, Chrome. I actually had my sights set on using Chrome indefinitely until yesterday.

A Good Reason to Not Use Flash

Flash resource hogging bytes

Need I say more? This is from a cookie-cutter Wordpress site with some flash mixed in with a template. The flash was only added to make a little transitional animation for the navigation bar.

HTML5, and heck, even CSS3 or simple JavaScript (using jQuery) would enable the above-mentioned site to quickly and easily enable the same animations and transitions, using only a few hundred bytes of code. Seeing that jQuery was already loaded on the site, it makes a heck of a lot more sense than using Flash.

We need to educate web designers on how they can break free from their Flash comfort zone, save a few hundred bucks in software licenses every year, and make their websites load two to three times faster (not to mention, more quickly and without requiring buggy third party extensions).

95% of Flash use is avoidable and unnecessary, in my opinion.

Benchmarking Safari on the iPad

Since purchasing the iPad, I've constantly been amazed by how fast everything works—switching between large apps is no longer a game of roulette, and browsing the web is a breeze.

I ran some tests on Safari on my iPad, just to see how things compare to my MacBook Pro...

SunSpider Javascript Benchmark

Here's the screenshot from my iPad (14068.6ms):

Sunspider Results - iPad

And from my Mac (406.8ms):

Sunspider Results - Macbook Pro

The MacBook Pro (2.53 Ghz 15" with 4 GB of RAM) is about 34x faster than the iPad in raw JavaScript performance... not too surprising, but I'd guess this margin will be trimmed in the next five years, when everyone's carrying around a tablet :-)

W3C Validation & Why You Should Use It

Whenever you're designing a website, one of your primary goals, besides communicating the mission of the organization for whom the website is being made, should be to make the website accessible to all visitors, no matter what kind of computer or browser they have, and no matter what kind of disabilities they have (whether it be blindness, deafness, or other problems).

Luckily for you, there's a free and easy-to-use tool on the web that lets you check how well your website conforms to coding standards:

W3C Markup Validation Service Banner

The W3C generously provides this service to further their mission of having an open, accessible and free web. The tool is dead simple to use: just type in your website's URL, and click Validate. Errors will then show up, and you can go back to your source code and fix the little mistakes you've made. But there's a lot more about Validation that needs to be said!

Subscribe to RSS - standards