Ingredients (serves 2)

• ~900 grams of pork ribs
• 1 bulb of garlic (yes, a whole bulb) – take out all the cloves and peel them
• 5 star anise
• 3 cinnamon sticks
• 1 tablespoon of white peppercorns
• 1 tablespoon of black peppercorns
• 1 teaspoon of ginger
• A pot of boiling water filled about 1/3 – enough to cover the pork ribs

Cut the pork ribs into individual pieces. Throw into boiling water. Throw in everything. Cover, cook for 1 hour. If you lose water while cooking, just add more. No biggie. This is not a precise dish.

Give each person a bowl of soup with pork ribs.

Serve with steamed rice. Make soy sauce available to put in the soup or rice.

The above is super easy and very very tasty.

Ridiculous bug.

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)

Install git using apt-get:

sudo apt-get install git-svn

Install build dependencies:

sudo apt-get install gcc g++ build-essential libssl-dev libreadline5-dev zlib1g-dev linux-headers-generic libsqlite3-dev

Install rvm (Ruby Version Manager)

bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )

Put RVM into .bash_rc file so that you can run it easily:

echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_rc

Reload bash settings:

source ~/.bash_rc

That should install rvm. Now you can use it to install Ruby:

rvm install 1.9.2

Make sure to switch into the correct version of Ruby:

rvm use 1.9.2

Install Rails:

gem install rails

This takes a while….

Install Apache:

sudo apt-get install apache2

Install Phusion Passenger:

gem install passenger

passenger-install-apache2-module

Follow the instructions on screen.

Setup Apache virtual hosting the way you normally do. Make the DocumentRoot the rails public directory.

<VirtualHost *:80>
        ServerName ec2-107-21-154-173.compute-1.amazonaws.com
        RailsEnv production
        DocumentRoot /home/ubuntu/depot/public
        <Directory /home/ubuntu/depot/public>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
 
</VirtualHost>

When deploying an app make sure to run bundle install to make sure all the dependencies are installed. This includes mysql, etc.

Rails 3.1 needs a Javascript runtime.

Add this to your gemfile:

gem 'execjs'
gem 'therubyracer'

Run:

bundle install

Make sure to setup your DB using:

rake db:setup RAILS_ENV="production"

Restart apache:

sudo service apache2 restart

Load your browser and visit the site. Hopefully it works, if it doesn’t, check logs/production.log and trace from there.

Asset Pipeline Gotchas

The new asset pipeline in Rails may cause your app to fail.

When you deploy an app, make sure that you precompile the assets using:

bundle exec rake assets:precompile

If you are including css files that are not in your application.css manifest, you need to manually include them in your config/environments/production.rb:

config.assets.precompile += ['960.css']

Note: After recompiling assets you will need to restart your rails app. Do this either by restarting apache or creating/modifying “tmp/restart.txt” in your rails app. Passenger will look at the timestamp for restart.txt and restart rails accordingly.

Read my paper here

Click here to view the embedded video.

So…here it is.

VBulletin stores two cookie vars that can be used for single sign on:

• bb_userid – look in the ‘user’ table, it is the field ‘userid’
• bb_password – md5(user.password . COOKIE_SALT)

When a user visits the forum, it can login based on the above.

Once you authenticate that the user can login in your app, read the user row from the vbulletin database. Take the password (which is already hashed) and concatenate the COOKIE_SALT constant to it. You can find COOKIE_SALT defined in /includes/functions.php. You then md5 hash this string and set the cookie as bb_password.

When setting your cookie, remember to set the domain to one that vbulletin can read. If you’re using different subdomains (e.g.   www.leonardteo.com for the main app and forums.leonardteo.com for the forums) simply set the domain to “.leonardteo.com”. In VBulletin, you’ll want to go into the admincp and change the cookie domain to the same.

By setting these two cookies, you should be able to login with your app and it will automatically login to VBulletin as well.

Logout
Make sure you set the logout routine as well. Your logout routine needs to clear three cookies:

• bb_userid
• bb_password
• bb_sessionhash

Enjoy.

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.