Missing Features

Your correspondent has worked with loads of different firewall configuration screens over the years, like Linux’s IPTables (command line), various Linksys and D-Link home and small business routers, the Apple OS X firewall, the Plesk IPTables interface and Windows tools like Windows Firewall (classic, Server 2008), BlackIce, Kerio Personal Firewall and on and on and on.

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.

(This is the fourth post in a series of posts on CakePHP tips.)

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);
}

(This is the third post in a series of posts on CakePHP tips.)

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.

A programmer who uses the wrong print format when circulating code for review is like Jar Jar Binks in Star Wars: just plain annoying. The right format is pretty simple, yet your correspondent frequently encounters programmers who don’t prepare the code in the right 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

(This is the second post in a series of posts on CakePHP tips.)

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.

Your correspondent has been heavily developing a side-project for the last month in CakePHP, a MVC, RoR-inspired framework for building web applications in the dreaded language PHP.

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'
);

In the process of designing and managing the development of several web-based applications, your correspondent has come to learn a critical lesson in software development (that many others in the software industry likely already know):

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.

Most programmers are really bad at programming. Grab 10 random students from a computer science masters program and your correspondent will happily wager a case of Brooklyn Brewery Chocolate Stout that at least nine of those programmers will fail a basic programming task.

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.

FogBugz — an outstanding bug tracking tool — has a really neat feature called remind. Essentially, a user can select one or more open cases and have the system send a reminder email to a user.

FogBugz includes links to the tickets you select and formats a draft email body accordingly. Most times you can select a dozen cases and fire off a remind email in under four seconds with just two clicks. Very cool.

This is a great feature for any project manager, as part of the job is frequently kicking the developer about due dates. Your correspondent frequently uses this tool when reviewing a list of past due tickets among his development team.

Here is the remind compose screen:

However, this handy tool does have a really simple, but needed, missing feature: a CC field.

Perhaps the CC feature was overlooked because most people don’t really know what the purpose of a CC field does in an email. Can’t you just use the TO field?

Well, no, not really.

A CC on an email is one of two things:

1. A way to keep a team member informed; or,
2. A handy way to add weight to an email.

While a BCC is a soft notification (in that you let the boss know something but not the recipient that the boss knows the something), a CC is a hard notification in that it adds authoritative weight to any email sent. A BCC is used to let a valued employee save face while still keeping the boss in the loop. A CC is used to reinforce the email with the superior authority of the person CC’ed.

When used correctly, a CC can say Hey! This is important. As you can see, I’m letting the boss know I told you this.

Since the remind feature in FogBugz is really just a quick way to send a you dropped the ball email, including a CC feature can only add to the effectiveness of any emails sent with it.

Seth Godin has a great post today where he talks about how the last impression is far more important than the first impression:

“I recently had some waterproofing done in the basement. The first date was great. The company was professional and had every single element down, from their AdWords to the web site to the way they interacted on the phone and in person.

I think that stuff is pretty important, but I’m way more interested in the last interaction than I am in the first (and if you care about word of mouth, you should be too).

After they finished the job, they left my basement a mess.

Forever, my only memory of the job is going to be the mess.”

Essentially Seth is arguing that his memory isn’t set by the first interaction, but how the closest memory he has — the last interaction — matters most.

This isn’t a new idea. In fact, Seth is touching on a lesson so important to any business that New York restaurateur Danny Meyer was able to build a fine dining empire on top of his complete understanding of this lesson.

What lesson? In this outstanding business-auto-biography of sorts — Setting the Table — Danny talks about the importance of writing your own last chapter.

In a chapter aptly titled “The Road to Success is Paved with Mistakes Well Handled”, Danny tells the story of greeting a Senator one evening. The Senator mentioned to Danny that the night before, at another one of Danny’s restaurants, his salad was served with a live beetle in it.

A free meal or a bottle of wine might be nice way to say sorry, but it won’t change this Senator from telling everyone he knows about the beetle incident. In his own words, Danny instructs the Chef to write a great last chapter:

“Whether or not Senator Kerrey or his guest order a salad during his lunch, I want you to deliver a beautiful salad and garnish it with a small piece of paper. On that piece of paper I want you to write the word RINGO, and when you deliver it, you can tell them, ‘Danny wanted to make sure you knew that Gramercy Tavern wasn’t the only one of his restaurants that’s willing to garnish your salad with a beatle.’”

The lesson here is clear: Everyone screws up, every company makes mistakes. And when a company screws up, a customer has a story worth telling to someone, somewhere, over a beer, about the horror that happened.

But if you take control of that mistake, correct and end it better than expected, you’ve turned a negative story that would have scared patrons away into a positive story that might actual help the bottom line.

Mistakes happen but only you decide how the mistake will end in the customers eyes.