Here are four quick tips:

1. Your first/title slide should include the presentation title, your name, your title, your company and some kind of contact (this all lends credibility);
2. When showing an image on a slide make the image as large as the slide;
3. Limit to 2-3 words per slide; and,
4. Do not read slides, have a conversation (each slide should either remind you of key themes to touch on during the chatter for that slide or evoke a reaction — thought, laughter, emotion, etc — in the audience).

You can do all this with an .htaccess file.

The great power of .htaccess files is that they can include rewrite rules via Apache’s mod_rewrite module. There are loads of things rewrite rules can do, so we decided to create a standard file that would handle a few things:

1. Redirect all HTTPS/SSL traffic to the same URL but to HTTP;
2. Redirect all traffic without a “www” entered to the same URL but with a “www.” added; and,
3. Compress all HTML, CSS and JavaScript files (to speed up website browsing).

The goal is that requests to:

https://example.com/some/page

will be gracefully redirected to

http://www.example.com/some/page

A clean, standard URL with no risk of SSL confusion.

The .htaccess file

# Standard .htaccess file
# – Compress text documents for speed
# – Rewrite https to http and no www to www

<IfModule mod_rewrite.c>
RewriteEngine on
# move off of https
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301]

#move to www if no www is entered
RewriteCond %{HTTP_HOST} !^(www\.).*
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

# compress stuff for faster delivery
AddOutputFilterByType DEFLATE text/css text/javascript application/x-javascript text/html
Header append Vary User-Agent

Sadly, must of these firewall configuration screens are painful to use.

Take the Linksys RV042, a reliable business-class router well suited for a small office. Managing the firewall can involve updates to three separate screens. Even the buttons on the edit rule screen (see right), are confusing: “Return”, “Save Settings” and “Cancel Changes”.

There are probably several reasons why this happens — limited budget, schedule, etc — but the likely explanation is that when the engineers schedule designing the new router they leave the admin interface as the last task, hate doing it and spend as little amount of time as possible on this “tail-end” work.

The ironic part of this logic is that it’s the admin interface where your customers spend 90% of their interaction time with the product. Sure, your customers appreciate (in the broadest sense) how quickly your little box moves tiny packets around, but they really don’t care so long as:

1. It doesn’t crash; and,
2. The admin interface isn’t too painful.

Given this, I’ve come up with a few really simple design guidelines for firewall interface designs.

Firewall configuration user experience design screen rules:

1. No pagination. Pagination of firewall rules is as pointless as pagination on online news stories: there is rarely enough content to justify it.
2. Poor or non-existent labeling. As soon as you write your 11th firewall rule you start to forget for what the first 10 rules are used. Firewall configuration should support both tracking a rule name and labels on individual IP ranges.
3. Allow multiple, user-entered IP ranges. Users should be able to enter in IPs in three formats: single IPs, human ranges (like 2.5.7.1-2.5.7.123) and in netmask form (for the nerds). And you must allow users to enter in a mix of all three.
4. Clear interface. This should be a no-brainer, but loads of configuration screens have glaring UI gaffes. Keep it simple and standard.
5. Combine stuff. Port forwarding, NAT, firewall, etc, can be combined into a single interface for most routers.

Mock-Up Screens

To demonstrate some of these ideas, your correspondent has created a set of HTML mock-up screens. Sure, this interface won’t work for a high-end Cisco router, but it should include the functionality you might expect from a home or small business router.

These are simple mock-ups; there are a few things missing like support for multiple ports and a way to move a rule several positions with one click. However, these screens hopefully demonstrate that firewall configuration screens can be made to be user friendly.

Your correspondent ran into a problem with a CakePHP site where the login and sign-up pages used an SSL connection, but the rest of the site forced non-SSL connections.

Why blend SSL and non-SSL? The application itself didn’t contain any sensitive information, and SSL is a massive CPU drain. So to save cycles, we forced non-SSL for all pages but login and sign up (passwords and credit cards).

The problem was that after the user was redirected from the SSL login process page to the logged-in homepage, the cookie that stored the session reference for the user didn’t exist in the non-SSL site and thus the session didn’t exist and the user was immediately logged out.

A post over at stackoverflow and some quick Googling strongly hinted that that PHP was configured on the server to create secure cookies, that is cookies that are only accessible over SSL. However, your correspondent tried disabled secure cookies with ini_set(), to no avail.

Further digging revealed the real issue: the cookies were being created as secure cookies on login — in spite of my override setting in the bootstrap file — because the core CakePHP routine for cookie creation sets the “create secure cookies” PHP setting on-the-fly just before creating the cookie, whenever a page is running under SSL.

The solution was a foreced modification to CakePHP core, something to be avoided at all costs but something that had to be done.

The solution is to comment out this snippet in /cake/lib/session.php, around line 420:

if ($ini_set && env(’HTTPS’)) {
ini_set(’session.cookie_secure’, 1);
}

CakePHP has a handy helper to redirect users to another page, used in controllers:

$this->redirect(’controller/action’)

Be careful: Apparently in CakePHP 1.1 and earlier this->redirect() doesn’t call exit() after the header redirect is set, so the PHP code after the redirect in your controller will get executed. Yikes! That’s a major security hole.

Happily, this issue is fixed in CakePHP 1.2, which defaults to calling exit after the redirect. Even so, the proper syntax for writing a CakePHP redirect is:

$this->redirect(’controller/action’,null,true);

The second parameter lets you specify an HTTP response code to return with the redirect command. The last parameter (which defaults to true), specifies whether to call exit() after the redirect. Even though it defaults to true, you really should write your redirects this way.

Here are the dead-simple requirements for preparing code for circulation:

1. Make it a PDF
2. Make the page orientation landscape*
3. Include line numbers!
4. Color the code
5. Include the filename at the top of each page
6. Include page numbers at the bottom of each page
7. The file name of the PDF should be the filename of the code

If you are a programmer and you don’t follow these guidelines then all you are doing is putting your reviewer in a foul mood. Not the best way to start a review.

* After all, code tends to be wider than it is longer

The CakePHP link helper is a handy tool to create links in your application. Here is the basic syntax:

<?php echo $html->link(’help!’,'/help’); ?>

And there’s a helper for creating images, too:

<?php echo $html->image(’add.gif’); ?>

But what if you want to use an image in the link? If you try this:

<?php echo $html->link($html->image(’add.gif’),’/customers/add’)?>

You won’t get the image, but the HTML code of the image as the link. Lame!

CakePHP has built-in protection against SQL injection and cross site scripting attacks, so it doesn’t like outputting HTML without making it safe. So you need to turn off the HTML escaping to make the image work:

<?php echo $html->link($html->image(’add.gif’),’/customers/add’,array(’escape’=>false))?>

Just pass in and set the escape parameter to false and you are home free.

Overall, it’s a great framework. There are some sore points (documentation is solid but there are lots of gaping holes), but overall your correspondent is confident that any PHP programmer who uses CakePHP for the first time will quickly be in the I’m-never-doing-PHP-again-unless-I-have-some-kind-of-framework camp. Seriously, never again.

Still, there were some things your correspondent wished he knew when he started. This will be the first is a series of posts on CakePHP tips for newbies.

CakePHP Tip: Start in UTF, everywhere

Character encoding sucks but you kinda have to know about it. To save yourself pain, just start on day one in UTF8 and there won’t be any encoding pain down the line.

First, add this to your layouts to have your pages output an HTML header that screams to the browser I’m fucking UTF, OK?. Put this line at the top of your layout (before any other output):

<?php header(’Content-type: text/html; charset=UTF-8′) ;?>

Just in case the first message fell on deaf browser ears, add this inside your HEAD tags as a backup:

<?php echo $html->charset(’utf-8′); ?>

Then, make sure you set your MySQL collation to utf8_general_ci before you start building your database. If you started your database in some kind of latin collation, sucks to be you. You will have to update the collation manually in every table and every column that is text, varchar or char.

Lastly, there is one more little gem you need to do. You need to set the encoding on your CakePHP MySQL settings to utf8 to ensure that when Cake talks to MySQL, it’s using UTF. In your config/database.php file add this line as the last property for each connection:

‘encoding’ => ‘utf8′

So each database connection looks something like this:

var $default = array(
‘driver’ => ‘mysql’,
‘persistent’ => false,
‘host’ => ‘localhost’,
‘login’ => ‘username’,
‘password’ => ‘password’,
‘database’ => ‘dbname’,
‘prefix’ => ”,
‘encoding’ => ‘utf8′
);

Your software is only as good as the testing you perform.

Your correspondent worked on the team that recently released an online chat tool called University WebChat. Powered by jQuery, University WebChat enables college and university admissions recruiters to easily host web chats for talking with prospective students.

The Bug

The application was working great during beta testing, except when more than 20 chatters joined a room. Once we hit north of 20 chatters, odd things started to happen: chatters got booted from the room, some couldn’t join the room at all, others just got an endless connection waiting when trying to load the room URL.

But none of these issues happened consistently, only consistently intermittently. We couldn’t regularly reproduce the issue, so it was impossible to fix. We focused on other bugs.

A few weeks went by and we still had no luck in finding the cause of the issue. Then we decided to really test out the application by hosting a high-profile chat where we expected more than 75 chatters.

What a difference a little pressure makes. We were forced to take a different approach to debugging the issue. So we ran a more complex test on the bug, and dug a bit into how Apache works (it’s a LAMP application). Eventually we found the source of the bug, fixed the issue and felt confident that the application would support 80 chatters in one room.

Test, Debug, Refine and Repeat

If we hadn’t been forced to test the application harder then the true source of the bug would never have been identified, the software wouldn’t scale as well as we needed it too and (worst of all) customers would have had problems with our software.

Your software won’t get better on its own – you have to force it to become better with great developers, useful features and most of all hard testing. Over and over again. From different angles and vectors. From different computers, networks, browsers, operating systems, locations, monitors and processors.

This isn’t a new revelation, granted. But an important one.

Missing features axiom #7: Your software is only as good as the testing you perform.

Guns Don’t Kill People, Bad Code Kills People

Why should anyone care if most programmers are bad? Well, what if the same were true of surgeons? Or commercial airline pilots? Sure, human life doesn’t depend directly on the daily work of a programmer. But the software they create sure does.

Think about all of the bad code in the control systems of nuclear power plants or in the computers under the hood of your car as you speed down the highway at 115 mph.

Are You Experienced?

Experience has little to do with programmer productivity or even in determining if you are a good programmer. But good programmers do have one trait in common: good programmers work very efficiently.

Why? Well, it mostly boils down to two things:

1. They are really smart;
2. They are really good at figuring things out.

When a smart person who is good at figuring things out asks him or herself how can I do this faster? productivity gains are realized.

Zen and the Art of Being a Productive Programmer

Whenever your correspondent teaches a web technology class — be it a course on project management or XML-based web services — there is always a class spent talking about how to work efficiently.

Beyond tips for basic productivity gains, here are some specific techniques for web programmers:

1. Use ALT-TAB to move between your code and your browser;
2. Use keyboard shortcuts;
3. Use a good IDE;
4. Isolate and toggle when debugging;
5. Use small successful iterations; and,
6. Use a good query editor.

ALT-TAB is straight forward enough. Don’t waste time moving your hand from the mouse to the keyboard. Sure, it only saves a second. But you are making this motion hundreds — perhaps thousands — of times per day. It adds up.

The same goes for keyboard shortcuts. Learn how to outdent. Learn how to highlight an entire line of code. Learn how to highlight all of the code from your cursor to the end of a file. Learn how to save the file. Again, it adds up.

My IDE Can Beat Up Your IDE!

It’s quite simple to know if you are using an IDE that will make you more efficient:

1. You like to program in it;
2. It’s not VI;
3. It tells you the parameters (and data types!) for built-in methods;
4. It tells you the parameters (and data types!) for the custom methods in your application; and,
5. It colors your code.

Isolate and Toggle

The concept of isolate and toggle is a helpful way to speed up bug fixing (don’t worry, you will still spend more time fixing bugs than actual programming).

When you have a bug in your code, it’s caused by one or more outliers. Your job as a debugger is to eliminate each outlier until you find the root cause. You can only do this by eliminating each possiblity one at time. If you don’t, you might miss something.

Identify all the possible causes of the bug, isolate each one individually, and test (read: toggle your code) to eliminate each possible cause. One at time: isolate, toggle and test. Eventually, you will find the cause of the bug and you will know how to fix the issue.

Sure, sometimes it takes a little longer to fix a bug this way. But most of the time it takes a lot longer if you don’t.

One Step at a Time

Understanding and using the technique of small successful iterations is probably the single easiest way to be a more productive programmer. The idea is simple: when you code, code a little bit at a time then save (use a keyboard shortcut!), switch to your browser (use a keyboard shortcut!) and refresh (use a keyboard shortcut!).

Not even Carmack writes perfect code every time. You will make stupid mistakes frequently. So if you code just a few lines and test out those lines right away, you will know immediately where you need to look for the bug.

Query Editors

Using a good query editor is also a big help to productivity. MySQL has nothing compared the productivity gains from using Microsoft SQL Server’s outstanding SQL Management Studio. It is simply the single best platform for SQL development on the market, and a big competitive advantage for the Microsoft SQL platform.

The reason having a great query editor to use during development is a big productivity boost is that the alternative — writing the SQL in your application code — introduces a layer of abstraction complication between the database and your query. And this layer of complication isn’t designed to make debugging your SQL query any easier.

You can’t comment chunks out, run two similar queries at the same time and compare the results or see the results in the same window as the actual query. Worse still, it typically takes three commands (save, toggle and refresh) to see the results of a change to a query in your application code while you can get the same result in one command (execute) in a query editor tool.

Get Your Own Money Bin

The secret to becoming more productive at anything is to remember the lesson we learn from Scrooge McDuck: work smarter, not harder.