Jacob's Garden

If you want to blackout your site in protest of SOPA/PIPA, here's what you gotta do:

(hat tip to http://www.zachstronaut.com for the blackout page).

Important: Keep the url mysite.drupalgardens.com/admin/content handy. 

Once you follow these instructions, your site will go dark (if it is January 18th 2012).  If you want to get it back, you will need to delete the block later.

1. Navigate to Structure -> Blocks
2. Click on "Add Block"
3. In the "Body" use the dropdown to change from "Safe HTML" to "Full HTML" (the buttons will go away)
4. Make the block show by setting a region.
5. Copy the following and paste it into the body:

<script type="text/javascript">
    var a = new Date;
    if (18 == a.getDate() && 0 == a.getMonth() && 2012 == a.getFullYear()) {
        window.onload = function () {
            var cover = document.createElement('div');
            cover.style.position = 'fixed';
            cover.style.zIndex = 9999999;
            cover.style.width = window.innerWidth + 'px';
            cover.style.height = window.innerHeight + 'px';
            cover.style.top = 0;
            cover.style.backgroundColor = '#000';
            cover.innerHTML = '<iframe

The problem

Programmers are like bad criminals in cop movies.  We just like to leave clues everywhere.  Most of the time, we work much like writers, from the outside in.  Develop an outline, stub out the parts which we might get to, and then fill in the core pieces, followed by the extremities.  If you're lucky you get a quick review and edit and then off to the press.  

Often though, we leave in little todo messages like "@todo: Actually write this function" or "@todo: make sure you check for a security hole here".  Or unprofessional error messages like "oops, something didn't work" or even worse "idiotic user doesn't know how to read instructions and forgot to use lower case".  And sometimes, I've been guilty of leaving debug code in which is there for me to look at what is happening in the code, but should never be accessed by others.

In my 13 years of reading other peoples' code, I don't think I'm alone here.

Ever seen "An unexpected error has occurred" or "Oops, shouldn't have gotten here" in an application... yeah, the dev needed this.

The proposal

An extension to your version control system of choice and/or your continious integration tool which checked code for various

The best programmers are lazy programmers.  Drupal, more than many other systems holds that maxim to be true.  Why do lazy programmers have an advantage?

Because Drupal is not a traditional software framework.  It is a framework, but it is a community first and a framework second.  There are over ten thousand existing modules to choose from and thousands more blog posts and online resources to copy code from.  Add to that a thriving community on IRC channels, forums and commercial support companies like Acquia and there are many ways to find solutions.  The last thing you should resort to is writing custom code.

Custom code is expensive to maintain, risky to a project and creates a dependency on the people who wrote it.  So while it is necessary to write some code on the vast majority of large Drupal sites, strive to practice configuration before coding. You can accomplish a lot just by picking the right modules and configuring them to suit your needs.

This article describes how to use regexes and some bash tricks and bad voodoo to split a SQL file into pieces in order to get it into MySQL in a reasonable amount of time. Parsing SQL is notoriously painful and error prone, so if you see mistakes here (I'm sure there are), please comment!

I recently got called in to work on a project for a customer I had never worked with before.  It is a very well known media / retail company and the job was to build a new interface for a media player / video library they required.  Pretty standard stuff, some views a couple quicktabs, a bit of ajax coding and a lot of pixel-f**king.  Anyway, near the end of the week long project when it came time to stage it, I realized I had a pretty big problem.  This site had 2 million users and several tables of profile data and other information.  My SQL file was over 3GB and took 6-8 hours to import.  Eek!  

So knowing that I wasn't going to write my update functions 100% perfect the first time, and I would likely have to import several times until I was confident it was working okay, I needed to find a way to get the DB to import in a more reasonable amount of time.