Pro Tip: Check It Yourself

Yesterday I was pushing a module of new code to the blog site of a moderately famous celebrity that is still creaking along on Movable Type (the site, not the celeb). I've not really had to work with Movable Type much before so it was a little bit interesting and I learnt a few bits and pieces.

The code module was working exactly as expected on the development site so I was a bit surprised when it failed on the production site, truncating the rendering of some posts.

Debugging code on a production server is a tricky business (especially when you can't find the error logs), but I tracked it down to this:

PHP Fatal error: Call to undefined function: file_put_contents() ...

The function file_put_contents() was introduced with PHP version 5, so this error indicated the production server was running some version of PHP4. This kind of disparity between production and development environments is certainly not the optimal configuration, but it's not entirely uncommon when working with legacy systems. The problem for me yesterday was that it took me a lot longer to identify and fix the problem because I was sure that the production site was on PHP5...

I'd asked the rest of the development team if the sites I was working on with this module were on PHP5, they were pretty sure they were, but recommended I checked with the ops team. A member of the ops team told me they were all on PHP5 too. I don't know if the error was due to a chat-window miscommunication, lack of familiarity with the site, or just a genuine mistake - it's not really a big deal. In reality, it probably would have been quicker to just check the phpversion() myself when I first thought to ask about it - I would have discovered it was on PHP4 and altered the module's code before I tried to push it to the production environment.

Managing WordPress Filters

WordPress filters offer a great way to control many aspects of the way the WordPress engine processes or publishes information, without hacking any of the core code.

In recent projects I've found filters to be the easiest way to manage many of the functionality requests the client has made. Some examples of the are: RSS formatting, custom Avatars, auto rendering images/links in comments, controlling the Category used in permalinks, reformatting legacy data in posts, and even tweaking the behaviour of Admin pages.

All these changes can add up to quite a chunk of code and functions.php was getting quite large and difficult to maintain with all the other general functions in there. I decided to move all the filter functions and add_filter statements into a separate file called functions_filters.php and include it from functions.php. This made it much easier to add/maintain filters and localised the changes to that dedicated file.

It's an incredibly simple idea, but I highly recommend taking this approach if you are implementing filters to any degree.

If you've not used filters but want to learn more, you can find a good introduction here: http://codex.wordpress.org/Plugin_API/Filter_Reference

WordPress Theme URL Tip

Lately I've been putting a lot of hours into developing a couple of sites using the WordPress and WPMU platforms. These platforms are a solid starting point for pulling a content/post based site together relatively quickly - the wealth of useful plugins also helps reduce the chance of you having to re-invent the wheel.

Having said that there is still a lot to do to create a professional website that has it's own look and feel - much of this can be achieved by creating a custom theme.

If you are creating a custom theme you will probably need to link to multiple elements within that theme's directory structure. The most common approach to do this is somthing like this:

<img src="<?php bloginfo('stylesheet_directory'); ?>/images/myimage.png">

<?php
echo '<img src="'.get_bloginfo('stylesheet_directory').'/images/myimage.png">';
?>

I've certainly been using a lot of the latter style, until today.

I decided to clean up my code a bit and put the following line at the top of my theme's functions.php file:

<?php
if(!defined('WP_THEME_URL')) {
define( 'WP_THEME_URL', get_bloginfo('stylesheet_directory'));
}
?>

Then I replaced all the get_bloginfo('stylesheet_directory') instances with the constant WP_THEME_URL. Now my code is a lot more readable and there is less typing.


<img src="<?php echo WP_THEME_URL; ?>/images/myimage.png">

<?php
echo '<img src="'.WP_THEME_URL.'/images/myimage.png">';
?>

Using a constant like this should provide a slight performance increase here too - I haven't done any performance tests, but the current get_bloginfo() process is a fairly convoluted chain of function calls.

Note: Just in case the WP platform does start using this constant in the future, the constant's value is not set if it is already defined.

UPDATE: After this post was made I discovered WordPress defines a TEMPLATEPATH constant, but no constant currently exists for the TEMPLATEURL.

Top Tips: Problem Solving

There will come a time when all your problem solving skills will hit a brick wall. These are some simple but effective tips to help kick start the process whether you are debugging, optimizing performance or whatever it is you're working on.

Scribble It
I'm a firm believer that nobody can hold everything in their head, this is why I recommend using a whiteboard or notepad to scribble out ideas, notes, lists and diagrams that can help your problem solving. Seeing everything laid out before you can also help give a clearer picture of a problem or reveal relationships you had not considered.

Discuss It
Vocally describing a problem to somebody else is a great way to spark ideas. The act of talking about it seems to allow your brain to follow new trains of thought and find new inspiration. It doesn't even matter if the other person fully understands what you're talking about. Inanimate objects don't really work for me, but if nobody else is available then even your cat or dog might help get you back on track.

Find Your Thinking Place
Everybody has a special thinking place where the ideas just seem to flow better. It doesn't really matter where it is, it only matters that you've identified it so that you can use it to your advantage. It could be walking to the local coffee shop, riding a bike, driving home, or walking the dog in the park. For me it's in the shower, I get all my best ideas there and actually write most of these posts in my head in the shower.

Sleep On It
Sometimes the best approach is to step away from a problem and leave it to background processing. If you've been thinking about something for a large part of the day, your subconcious will keep trying to make sense of it while you sleep. I couldn't count the number of times the answer has suddenly come to me at 3AM.

Always get a Baseline first

As developers, we often spend time optimising, tweaking or redesigning to increase performance. It's fairly easy to measure performance increases when optimizing code or systems, but it's a lot harder to gauge the effectiveness of User Interface changes.

In many cases the UI choices we make are subjective at best. In some cases, our design decisions can actually make things worse, not better. There are some interesting anecdotes about this in this recent post.

In order to make sure we are making the right decisions, rather than just a bunch of assumptions, we need to measure the effectiveness of the current implementation in order to compare with the improved version.

Depending on what it is that you're changing, this could impact on conversions, page hits, or data collection rates. You'll need to decide the best way to measure the effectiveness of the changes, but without data to measure it, you'll never really know if you're doing it wrong.

It seems like a simple idea, but it applies for all optimisation and is often overlooked. A simple rule to follow is to remember to ask "How will we know if this works?" before you implement a change.

Repositize it!

If you write or maintain code for any number of projects on an ongoing basis, then you should be using a version control system. If don't already use one, then quite simply, you're needlessly working without a net. Shame on you!

The benefits of using a version controlled code repository include:

• Keeping track of changes in source code/documentation
  
• Maintaining historical versions of source code/documentation
  
• Stopping developers from tripping over each other's changes
  
• Assigning authorship to changes
  
• Storing comments regarding each change
  
• Branch and tag management
  
• Rolling back to "clean code"

There are a number of version control systems available with the most common being Concurrent Versions System (CVS) and it's assumed successor Subversion (SVN). Subversion is my preferred system due to it's atomic commits (they either completely succeed or completely fail).

Golden rules to using a version control system

• Always update from the server before you commit your changes
  
• Always comment your changes (I like to use the "line 36: fixed text typo" format)
  
• Use logins and passwords
  
• Don't forget to back up your server regularly

Related links:

• Comparison of revision control software
  
• SVN website: http://subversion.tigris.org/
  
• CVS website: http://www.nongnu.org/cvs/
  

Tortoise Windows shell extensions
If you're working on Microsoft Windows you should check out TortoiseSVN and TortoiseCVS. These free clients integrate into Windows Explorer. TortoiseSVN won the SourceForge.net 2007 Community Choice Award for Best Tool or Utility for Developers.

• TortoiseSVN: http://tortoisesvn.net/
  
• TortoiseCVS: http://www.tortoisecvs.org/

HiPPOs and A/B Tests

This 20 minute video from videolectures.net is good food for thought. It's got some great anecdotes about some big industry players and how hard it is to guess how users will react to UI changes. Well worth watching when you get a chance.


Practical Guide to Controlled Experiments on the Web:
Listen to Your Customers not to the HiPPO
Ron Kohavi

How to disable Ad Blockers

Last week I posted an article about Ad Blocker Detection. Once you have an estimate of the potential advertising impressions lost, you can decide if you want to address it and how you wish to do that.

Some websites think of visitors employing ad blockers as content thieves. Some sites even go as far as forcing users to accept adverts to browse their pages. Personally I believe most sites don't have strong enough content to warrant this and they will only alienate users.

I believe the only way to get visitors to disable their Ad Blocker on your site is to ask them, nicely. All you can do is encourage them to support your site.

Have a look at these two banners. If you have an Ad Blocker currently enabled, then they will be identical. If not, then you will see an old Amazon banner I exhumed, and then a clear and polite message asking for support.

Both banner slots have the message set as the background image, but it is not visible for top slot as the Amazon banner is in the foreground.

To ensure the the background message is not displayed to users when no Ad Blocker is employed, the first frame of the image is transparent and is displayed for 5 seconds. Even the slowest advertisement should load within that timeframe.

If you are concerned that this message might be displayed to the user when no advertising inventory is available for this slot, then I would suggest you address the lack of ad availability before you try and reclaim more impressions. Beyond that, the prudent approach would be to set the background property for the banner slot with JavaScript only after you have detected the user is using ABP.

Emotional Investment

A few years ago I was working for an internet startup. One of the developers there had a bit of a prickly temperament. He was fine if everything was going as he expected, if his efforts were noticed or rewarded, but when he had to fix other people's mistakes, or disagreed with decisions made by management team, he vented pure vitriol.

Some of the staff started to avoid dealing with him, the management team started wondering about his loyalty. His skills were never in doubt, but his attitude was causing problems. There are enough politics in a small startup without this kind of behaviour.

The problem was that he was taking it all too personally. He'd heavily invested emotionally into this business idea and wanted it to succeed, so when others made decisions he judged as incorrect, he took it as an affront to the extra effort and the time he'd poured in.

I know that's what the problem was, because a few years ago that guy was me. Luckily, I managed to snap out of that mindset before I got too bitter about things, or before got fired.

I am a perfectionist, and sometimes a bit of a control-freak because of that, coupled with my natural directness, you can imagine how I had reached that state of mind. The trouble is it's often hard to see it when you are there. The interesting thing for me is the number of times I've seen similar behaviour in others.

It's strange that over-commitment can result in such negative impacts. Emotionally based over-reacting can cause bad decisions.

In companies where the product is heavily dependant on the technical team (common in internet startups), it is easy to assume your opinion should carry more weight. But business decisions may often overrule - technical excellence alone won't stop a business from failing. The best you can hope for is that any advice you offer is considered. Those other departments exist because they are required to some degree. A successful company is a machine of many parts working together.

Being commited to what you're doing is important, but we need to remember that ultimately it is just a job. That can be hard to do when so many of us measure who we are by what we do. We're paid for the time we put in, that should be enough.

Making A List

Low-tech solutions are often underrated by developers and their technically minded brethren. We tend to look down on things that aren't bleeding edge, or are designed for the technically inept. It's true that I have little respect for Frontpage, or Powerpoint or anybody who saves HTML from Word.

But low-tech is the wildcard that always trips us up. How many times have you spent hours debugging a hardware/software problem, only to finally find the cause was less technical than you imagined?

Oh, the stories I could tell: Cache files ate all the drive space.., The LAN cable fell out.., They rebooted the wrong server... Twice!, We've been Slashdotted...

One of the simplest and most effective tools that is often overlooked by developers is a daily To Do List - on paper, right next to your keyboard.

Electronic To-Do lists have their place. They really shine when you want to look back at what you did and when, and for logging chargeable time, and automated reminders, but for managing just today's tasks, I don't think you can beat a real lined page on your desk.

Here's my top reasons why I think you should adopt this practice:

• Quick glance access avoids Alt-Tab disruptions
  
• Less stuff to hold in your head - don't rely on your memory, write it down and then you can fully concentrate on what you're doing
  
• Helps you set an appropriate work-pace for today's tasks
  
• It doubles an idea scribble space
  
• Doodling can help you concentrate
  
• It's a great prop for declining new tasks, "Sorry, I can't fit that in today, I've got to get through all this..."
  
• The tactile satisfaction of drawing a line through completed items
  

And here's some tips on making the most of your list:

• Don't spend more than 20 minutes planning your day
  
• Don't use too much detail
  
• Create sub tasks for complex tasks
  
• Prioritize tasks in groups
  
• Note which tasks depend on others
  
• Quickly reprioritize after completing each task
  
• Start a new list each day. Transfer uncompleted tasks from the previous day
  

How to beat Jetlag

Every few months I make a 5,456 mile pilgrimage to Head Office. That's a twelve hour flight going against the clock and arriving four hours after I left, relatively speaking. That extra eight hours in the day can really screw up your body clock.

I've worked out a system to beat desynchronosis that works well for me, so I thought I'd share it here:

• Direct Flight: Get a direct flight. Changing planes and layovers will just make transit time longer and jetlag harder to deal with.
  
  
• Don't Sleep: Keep yourself awake on the plane. Cram in as many movies as you can, or if books are your thing, take a real page turner. Don't get drunk in the lounge or on the plane, it'll just make it worse.
  
  
• Arrival Time: Arrive in the late afternoon or early evening and keep yourself awake until at least 9PM. This shouldn't be too difficult with the process of getting from airport to hotel, if you get the arrival time right.
  
  
• Eat Before You Sleep: Once you have arrived and checked in to your hotel, eat a proper meal. This is crucial to success. Your body-clock will still think it's 4AM at this point, but if you eat a decent meal and then go to bed, the meal can trigger a reset in your circadian rhythm. You should sleep a good eight hours and be ready to face the world the next day.
  

Admittedly, westward jetlag is easier to deal with than eastward, and I am still learning to best way to combat that. Ultimately the same principals should still apply.

The "3 Times" Rule

I like breaking new ground. Making new things is exciting and engaging, sometimes it's challenging, but it's generally rewarding and fun.

What I don't like is doing the same thing more than once, particularly when it's because somebody couldn't be bothered articulating what they wanted properly. Usually taking a zero-assumption approach and asking a couple of carefully worded questions will avoid this.

But sometimes it's a long and involved task that just keeps landing on your desk. That's the reason I developed the "3 Times" rule (actually I might have stolen it from my brother-in-law).

• The First time you have to do the task, it's an adhoc task.


• The Second time you have to do the task, it's still adhoc, it's just an anomaly.


• The Third time you have to do the task, it's likely you'll have to do it again, so build a tool, or automate all the parts that you can.

Let me clarify that I'm not talking about doing something three times because somebody made a mistake. I'm talking about running the same process on three different sets of data on three separate occasions.

This approach seems to work especially well with reports. Often it only takes a little more effort to throw the results into a webpage that the user can access on their own. The great thing about this approach is that the user feels empowered, and the task doesn't land on your desk again.