I became aware of an annoying little glitch on the Urban Mainframe yesterday. It seems that WordPress, on which this site is running, doesn’t handle the URL http://example.com/index.html on an unmodified install (I’ve confirmed this on a handful of other WordPress sites). This is significant because index.html is a special file on many web-servers, often being the “home” page of a directory on the server. Without special handling, a request for index.html on a WordPress installation generates a 404 (file not found) error — which is obviously something we don’t want our visitors to be presented with.

In my case the impact of the glitch was magnified because I employ a quite aggressive caching policy on this website — and yesterday an unlikely combination of factors resulted in my 404 error page replacing my home page for a complete cache cycle. It went something like this:

• cached “home” page expires
• next “home” page request is for http://urbanmainframe.com/index.html
• index.html file request results in a 404 error
• 404 error page is cached
• all subsequent requests for http://urbanmainframe.com/ — and other “home” page URLs — return the cached 404 error page until the cache is next invalidated

Quite a serious glitch then!

There are two things that shouldn’t have happened here.

1. Requests for index.html should not result in 404 errors.
2. Error pages should never be cached.

I resolved the first issue by adding the following snippet of code to the very beginning of the 404.php file in my WordPress theme:

<?php
if ($_SERVER['REQUEST_URI'] == '/index.html') { header("Location: http://urbanmainframe.com/"); exit; }
?>

For the second issue I’ve filed a bug report with the authors of W3 Total Cache, which is the caching system I use here on the Urban Mainframe.

After four decades, the future of the operating system is clouded, but its legacy will endure.

Regardless of the ultimate fate of Unix, the operating system born at Bell Labs 40 years ago has established a legacy likely to endure for decades more. It can claim parentage of a long list of popular software, including the Unix offerings of IBM, HP and Sun, Apple’s Mac OS X and Linux. It has also influenced systems with few direct roots in Unix, such as Microsoft’s Windows NT and the IBM and Microsoft versions of DOS.

The [Association for Computing Machinery] may have said it best in its 1983 Turing award citation in honor of Thompson and Ritchie’s Unix work: “The genius of the Unix system is its framework, which enables programmers to stand on the work of others.”

A large part of my professional work involves the build and deployment of WordPress-based websites. Now as any designers/developers among you will appreciate, it can be extremely annoying frustrating to sign off a build only to come back later to see that your client has (inadvertantly) messed things up because WordPress has placed too much power in their hands.

I was delighted then to read “10 WordPress Dashboard Hacks” because there are some really useful code snippets presented therein:

• Remove Dashboard Menus: At last I can remove certain menus from the client’s view — whilst obviously still leaving full control for the Admin user
• Define Login and Dashboard Logos: Great for branding.
• Disable the “Please Upgrade Now” message: I never want my clients to do this. I think this is one of my responsibilities.
• Customise Dashboard Widgets: Again, it’s about keeping control. Not exposing the client to things which could be hazardous.
• Provide Help Messages: Because they’re helpful (if done correctly).

Some of these are definitely going to be rolled out on to some of my client’s sites in the near future.

In an article on the web-design advent calendar, 24 Ways, Meagan Fisher advocates setting aside Photoshop and building design comps directly in our preferred flavour of HTML.

That’s how I always work anyway. Only once have I ever built a design in Photoshop before writing the code and that was for the front page of this website — it took ages and felt totally un-natural and counter-intuitive to me. I did it because I understood that that’s how all designers work. I wanted to try it out to see if it made the process any easier for me, it didn’t, at all.

Even so, I think Meagan has overlooked a quite important point: not all web-designers are writers of code.

Continue Reading…

Gearman provides a generic application framework to farm out work to other machines or processes that are better suited to do the work. It allows you to do work in parallel, to load-balance processing, and to call functions between languages. It can be used in a variety of applications, from high-availability web sites to the transport of database replication events. In other words, it is the nervous system for how distributed processing communicates.

Sounds awesome. I’ve got to make some time to experiment with this.

Fortunately, there are ways to get scripts to download without blocking any other resources in the page, even in older browsers. Unfortunately, it’s up to the web developer to do the heavy lifting.

There are six main techniques for downloading scripts without blocking:

• XHR Eval - Download the script via XHR and eval() the responseText.
• XHR Injection - Download the script via XHR and inject it into the page by creating a script element and setting its text property to the responseText.
• Script in Iframe - Wrap your script in an HTML page and download it as an iframe.
• Script DOM Element - Create a script element and set its src property to the script’s URL.
• Script Defer - Add the script tag’s defer attribute. This used to only work in IE, but is now in Firefox 3.1.
• document.write Script Tag - Write the <script src=””> HTML into the page using document.write. This only loads script without blocking in IE.

I’ve just started experimenting with LESS for a new web development project. With my programmer head on, LESS looks like it has the potential to speed up my CSS coding (which I do by hand) as well as enabling me to abstract my CSS with variables (very handy), nested rules, mixins and even mathematical operations (yeah baby)!

However, installing LESS on my OS X “Leopard” machine wasn’t quite as simple as advertised. I should just be able to go:

sudo gem install less


But that resulted in an error:

ERROR: While executing gem ... (Gem::RemoteSourceException)
HTTP Response 403 fetching http://gems.rubyforge.org/yaml


I ended up scratching my head for a moment — before turning to my good friend and problem-solving guru, Google, for help. I was advised as follows:

wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
tar xzf rubygems-1.3.1.tgz
cd rubygems-1.3.1
sudo ruby setup.rb
sudo gem update --system
sudo gem install less


That worked a treat.

Then, in Terminal, I navigated to my source directory, renamed my style.css file to style.less and issued the following command:

lessc style.less --watch


LESS then generated a new style.css from my .less file and went into watching mode — automatically compiling my .less file into its .css counterpart whenever it detected changes in my source (ie: when I hit save in my text editor) which is a rather cool.

It’s early days yet, but so far LESS is looking like a tool that I can really make use of. I don’t need to change my workflow (aside from starting the watch/compiler process) and I get a degree of CSS flexibility and freedom that I didn’t have before. That’s neat.

A great essay from Aaron Swartz:

The traditional programmer hiring process consists of: a) reading a resume, b) asking some hard questions on the phone, and c) giving them a programming problem in person. I think this is a terrible system for hiring people. You learn very little from a resume and people get real nervous when you ask them tough questions in an interview. Programming isn’t typically a job done under pressure, so seeing how people perform when nervous is pretty useless. And the interview questions usually asked seem chosen just to be cruel. I think I’m a pretty good programmer, but I’ve never passed one of these interviews and I doubt I ever could.

Ah now this is pure gold, 21 things to keep in mind when coding for MySQL. Most of these I knew but it was good to be reminded. Some of them are entirely new to me though:

• Use ENUM over VARCHAR: ENUM type columns are very fast and compact. Internally they are stored like TINYINT, yet they can contain and display string values.
• Store IP Addresses as UNSIGNED INT: Many programmers will create a VARCHAR(15) field without realizing they can actually store IP addresses as integer values. With an INT you go down to only 4 bytes of space, and have a fixed size field instead.
• Do Not ORDER BY RAND(): This is one of those tricks that sound cool at first, and many rookie programmers fall for this trap. You may not realize what kind of terrible bottleneck you can create once you start using this in your queries.

Priceless information. I’ll be referring back to this list over and over again.

DIagrams Through ASCII Art:

ditaa is a small command-line utility, written in Java, that can convert diagrams drawn using ASCII art into proper bitmap graphics. ditaa interprets ASCII art as a series of open and closed shapes, but it also uses special markup syntax to increase the possibilities of shapes and symbols that can be rendered.

Works as advertised. I’m not sure if it has any worth outside of its curiosity value. I found it quicker by far to flowchart with a GUI application than to laboriously create ASCII artwork equivalents for ditaa to process. Neat hack though! [via]