Steak on Mushrooms with Red Wine Sauce

• 3 tablespoons extra-virgin olive oil
• 12 ounces mixed mushrooms, cut up
• Table salt
• Ground black pepper
• 4 tablespoons butter
• 1.5 pounds steak
• 3 garlic cloves diced
• 1x 6″ sprig rosemary
• 1 cup red wine
• 3/4 cup chicken stock

Caesar Salad from Scratch

How?

From now on, every site that I deliver for clients will have, by default, an IE8nomore header (or variant), which will only show up when a user with IE8 or less browses to the site. If a client specifically wants me to support IE8, they will need to pay extra for it. It’s that simple. Clients need to be educated that IE8 is just bad software. If they have the chance to tell you that a site you created doesn’t work in IE8, you’re too late. You need to put the header in by default so that when they, or their colleagues browse to your site, they immediately see that their browser is outdated. It’s psychological. They need to upgrade. You don’t need to lower your standards.

If you’re a professional web developer, make it your resolution. Let’s rid the world of standard-less browsers. Let’s nail IE8 and please be done with it.

Links

IE8nomore header
IE6nomore header (the original)

1. Storing paths and URLs in the database

This happens in WordPress, Expression Engine and VBulletin. Basically, the idea is that all settings must be stored in a database table because…well…it’s supposed to be easier. The user updates a setting in the admin control panel, and it stores those settings in a database. The problem with storing paths in a database like this is that it makes the app less portable. For example, say you want to move an installation of any of the above-said apps to a different domain, it’s not as simple as tarballing the entire application, running mysqldump and restoring on the other side. You’d think that changing the config file would get it to work but this is only half the battle. WordPress and Vbulletin, for example, stores the actual URL of the application in the database, so when it does any redirect (e.g. when you login to the admin control panel), it will redirect to your OLD site.

WordPress does something else that I consider evil. When you upload images, it stores the full web path in the meta data. This is also a problem when you move to another domain because all your images are now pointing to the old domain. I’ve had to write scripts that change all metadata values and wordpress settings when porting from one domain to another. It’s annoying.

Why is this an issue though?

Development. For most people, the above shouldn’t matter because you have a blog that you installed on a webserver; you update it and all’s well. You never run a local copy of the site for development. As a developer though, I have to usually get local and staging copies of the website running. This means that I’m constantly having to do all kinds of shenanigans to get these instances running on different servers.

I used to think that this was simply a bad design limited to a couple of web apps but it seems like a whole plethora of web apps suffer from this. While working for Gnomon, we bought into Expression Engine, thinking that this would be the silver bullet that kills WordPress. Nada. EE is just as BADLY designed! (not just for the reasons above, but many others)

2. Serializing Critical Settings

PHP has a neat function called serialize(). It takes data and turns it into a string. The data can be read back in easily. This is great for many things. For example, if you have user accounts and each user has their own settings, it’s probably useful to just serialize their settings data and save it as a single string in the database.

Crucial site settings though, should NEVER be serialized in a database. I would go as far to say that as a rule of thumb, if the setting is crucial enough to make or break an installation of an app, it should be in a config file. This relates to my first rant as well. Many settings can be put in the database, but some settings (like paths), should just be in flat config files that can be quickly changed when moving the app.

I was absolutely shocked when using Expression Engine that crucial app-breaking settings like upload paths were not only stored in the database but SERIALIZED. I ended up writing a script that can move an entire installation of EE from one server to another in a single command line, and it’s really long because it had to connect to the database, unserialize the data, make modifications, re-serialize the data, write back to database.

It shouldn’t be this hard.

My recommendation

My recommendation is to follow this rule of thumb: if the setting is crucial enough to make or break an installation of an app, it should be in a config file.

Absolute paths like upload paths, etc. should be stored in a config file.

If the application needs a site-wide URL, this should be in a config file.

Individual asset links in the database should link to the relative location (i.e. minus the hostname.) e.g. not http://leonardteo.com/image1.jpg, but /image1.jpg instead. Even better, just store ‘image1.jpg’ and use a configuration setting to determine what the path to that image is.

The litmus test should be: Tarball an application, dump the database. Copy everything to a different computer/hostname. Restore everything. If you can’t get the site up and running again without accessing and changing values in the database, fail.

A practical benefit – fast deployment

On a closing note, one of the benefits of running critical site settings in config files, is that you can switch configurations based on the hostname.

E.g. in your config file:

switch ($_SERVER['SERVER_NAME']){
    case 'cgacontest.local':
        define('SITE_MODE', "LOCAL");
        break;
    case 'cgacontest.test':
        define('SITE_MODE', "TEST");
        break;
    case '3dsmaxdesign.cgarchitect.com':
        define('SITE_MODE', "LIVE");
        break;
}

With the above code, we can switch between site modes and run different configurations automatically based on the hostname. This means that when it comes to deployment, I simply push any changes to the server without having to change configuration.

Those of you who know me will find the choice of name funny. The previous company I ran while in Australia was called “Ballistic Publishing” (actually it was Ballistic Media Pty Ltd). The choice of name came after weeks of searching for a short, catchy name that people could remember and where we could own the .com domain name without any suffixes (e.g. If the company name was Acme Technologies Inc. we wanted to own Acme.com). I randomly searched for Ballistiq and found the domain was available and that was it. We also did some testing and Ballistiq seemed to stick.

My wife Susanne was not happy with the choice of company name, “That’s like calling your dog Mollie then calling your next dog Molly.” Why yes…exactly.  I will mention something…of all the company names that I had come up with, “Ballistic” was the only one that my father could say properly. Thank goodness.

Click here to view the embedded video.

Click here to view the embedded video.

Pretty much all the models had to be “normalized” in some way by importing the original 3ds into 3ds Max, then exporting it as an FBX. Opening the FBX in Maya, fixing the size and orientation, making sure that the UV’s were correct by applying the materials (my program currently only supports bitmaps, so the texture needed to be re-exported as a bitmap file). Finally, the model was triangulated (if needed) and exported as an OBJ.

First test - M1 Abrams tank OBJ

M1 Abrams tank model from 3DM3

UH Tiger model from Falling Pixel

Humvee model from Blue Brain 3D

US Soldier model from Blue Brain 3D

]]> http://www.leonardteo.com/2010/10/opengl-texturing/feed/ 0 http://www.leonardteo.com/2010/10/dilbert-on-marketing/ http://www.leonardteo.com/2010/10/dilbert-on-marketing/#comments Fri, 01 Oct 2010 16:54:44 +0000 Leo http://www.leonardteo.com/?p=338 After working for a couple of larg’ish publicly listed companies, I’ve grown to love Dilbert. Today’s hit the spot.