In our company, code reviews play an integral part in the development process for making quality software. We opt for a mentor style approach with Wufoo, where a developer works on a segment for a period of time and then passes it up to a more experienced developer for review. We really like this approach because it means more developers become familiar with the foundation of different code level services. More importantly, they act as an additional safeguard against security holes, memory leaks, poor queries and heavy file structures. Unfortunately, these reviews are also very time consuming and in a small team can sometimes be an inconvenience to the reviewer — another developer with their own todo list to accomplish.

Given that all reviews check against the same list of requirements, we’ve found ourselves repeating the same tasks over and over again. We spend a lot of time echoing queries, memory stats and objects to the browser just to see how they are being used in the code. To reduce this repetition, we invested some time creating something we’ve called the PHP Quick Profiler—we call it PQP for short. It’s a small tool (think Firebug for PHP) to provide profiling and debugging related information to developers without needing them to add a lot of programmatic overhead to their code. Now, we only need to toggle one config setting to true and our reviewers have access to an automated tool to help create a faster and more consistent review experience. Since anyone can use it, PQP also gives the initial developer an idea of where their code stands before the review.

We’ve been using PQP for a while now with Wufoo. It’s been so useful that we decided to take some time to package everything, write out some documentation and offer it up for anyone to use.

See it in Action

We’ve created an online example showing a landing page with PQP turned on. The profiler contains a 5 tabbed interface that presents pages for logging messages, measuring execution time, analyzing queries, revealing memory used and showing the files included.

Thanks to Kevin’s help, who did a great job of designing and encapsulating the interface, there’s no need here to add links to external CSS files or Scripts to make it show up right. When included on a page in PHP, PQP automatically inserts the markup, CSS and JavaScript needed to make the interface show up and just work. PQP should work with Internet Explorer 6 and up, Firefox and Safari.

Getting Started

We’ve provided a zip file which contains the entire setup for PQP and some basic instructions for installation.

Download: pqp.zip

Once you’ve downloaded the zip, upload the contents to a PHP enabled web server. Navigating to the root directory in your browser will show the same online example we linked to above. At this point, each tab should work except for the database tab, which requires some additional configuration.

Once you get the example working, the next step would be integration with your own project. It’s important to note that dropping the folder into your own project directory will not work. This is because 5 different aspects of the code are being looked at, and you may handle those situations differently than we do. That said, integration is pretty straightforward, and by following the guidelines for each section below, you should be up and running in no time.

Using It In Your Code

The easiest way to make PQP work in your own code is to include PhpQuickProfiler.php into the page you want to see it on. That alone will enable the console, memory and file logging. Speed and database logging take a bit more work, which we’ll cover later. Now, enabling the default logging is great, but nothing will display to the screen by just including the file. To display to the screen, a bit more knowledge on what’s happening is required.

As code is being executed, details are being logged and analyzed in PQP. Once the code is finished, PQP finishes up also, and displays the output to the screen. The tricky part is knowing when the code is finished, since in an ideal world this tool would work with as little developer input as possible. In this example, we determine that the code has finished by looking at when the parent object runs its destructor. So a timeline would be:

• Landing Page constructor declares an instance of PhpQuickProfiler.
• Landing Page executes all needed code.
• Landing Page destructor tells the PhpQuickProfiler to cleanup and display output.

Of course, this setup would cause PQP to always display, which isn’t ideal for production. To make it more useful, we created a Config flag in our code (debugMode = true) that checks to make sure it is set to true before displaying. Below is a sample class that can perform the steps we just covered:

class ExampleLandingPage {

    private $profiler;
    private $db;

    public function __construct() {
        $this->profiler = new PhpQuickProfiler(PhpQuickProfiler::getMicroTime());
    }

    public function __destruct() {
        if($debugMode == true) $this->profiler->display($this->db);
    }

}

Logging to the Console

Given the code shell above, PQP is configured and ready to be used. We can start referencing the helper functions, starting with logging. The console log is just a step above an echo statement in that it condenses and formats the output using print_r. This is useful for reviewers because it provides a way to view debugging information without blowing up the layout of the page. To output data to the console, just statically call the function:

Console::log($data);

The static function call accepts any data type and is available as long as the PhpQuickProfiler.php class is included. We chose to implement this with a static call so that the class does not have to be instantiated before use. The downside to a static call is that we store the log history in a global php variable. Should you wish to avoid globals, the Console.php class could always hold the log as a member variable given that it is instantiated. But as is, the class just acts as a read and write wrapper around a global PHP variable.

On top of logging variables, the console also has four additional functions.

Console::logError($exception);
Console::logMemory();
Console::logMemory($variable, $name);
Console::logSpeed();

Let’s start with logError(). Logging an error is useful for displaying information related to a PHP exception. In our code, we’ll use a catch block for handling errors so we can silence an exception. We do this because we want that error to be ignored and not affect what the user is doing. An example of this would be logging data that isn’t crucial. If that log fails, the users shouldn’t have to stop what they’re doing. Now, in development, it’s still nice to know those exceptions were thrown, so in the catch block a call to logError() can be made to display the information to the console like so:

try {
    // Execute non critical code
}
catch(Exception $e) {
    Console::logError($e, 'Unable to execute non critical code');
}

Additionally, the console can provide even more value by using some of the helper functions that PHP natively provides. For example, logging debug_backtrace() will print related information about the script at a given point in time. PHP also provides us with magic constants like __LINE__, __FILE__, __FUNCTION__, __METHOD__ and __CLASS__, which allows for printing of script data. Take a look at the screenshot below to see some example usage of this:

Watching Memory Usage

Object oriented PHP is a beautiful thing to behold, but there are definitely a few concerns to keep in mind when it comes to memory usage. These concerns tend to rear their heads when dealing with recursive output (i.e.: exporting to Excel), if there’s a leak in the creation of the objects or if objects aren’t being destroyed properly. All of this can lead to unexpected resource usage and fatal errors that serve to aggravate the end user.

The debugger aids with memory management by displaying the maximum amount of memory used by the script. A simple call to the built in memory_get_peak_usage() is where the data originates. The system setting for memory allowed (through ini_get()) is also shown to see how much wiggle room there is. If an overview isn’t enough, you can drill down into your resource usage with a point in time memory call.

Console::logMemory();
Console::logMemory($variable, $name);

Calling logMemory() in your code without any parameters will output the current amount of memory that PHP is using when the function is called. This is perfect for watching a loop in your script to see if memory is building up during each iteration. Likewise, a variable and a name can be passed in to the function. Doing so will output the memory used by the variable to the console. Knowing that a script is hogging memory is wonderful, and knowing which variable is doing the hogging allows the problem to be fixed. Take a look at the screenshot below to see an example of string concatenation that is slowly eating up memory.

Runaway Includes

Similar to memory getting out of control, included files (especially on large complex projects) can multiply and take over your app before very quickly. Even worse, too many includes don’t throw the hard errors that memory usage does. Instead, the page just slows down and resources get eaten up on every request served. Avoiding this pitfall is pretty easy—just make sure the same file isn’t included multiple times, and catch any excessive includes of unnecessary files.

The PQP files tab shows the total files included with a count call on get_included_files and their total sizes are summed up. The names and sizes of the individual files are output to the console for easy scanning as well. The largest file included is noted on the left, which clearly points out if a large library is being used when it shouldn’t be. For example, on Wufoo we found out that we had a script always including htmLawed, a fairly decent sized file, when it wasn’t needed.

Also, keep in mind, autoloading classes or using require_once will usually alleviate any problems with file includes. That said, it never hurts to be aware of the situation, especially when using plugins, old code, or borrowed code.

Page Execution Time

Emphasis is always placed on database optimization when it comes to performance considerations (rightfully so), but that doesn’t mean PHP execution time should be ignored completely. The standard method for calculating load time is to find the difference between the time when the script starts and then again when the script finishes. This is where the integration of the debugger into your own project becomes tricky. Since the debugger is called on the destruction of the parent page, we know when the script is ending. But since every project is different, the start time can vary. The example code that you can download sets the start time in the construction of the parent object with a call to PQP’s getMicroTime(). This will work in most cases, but if you have a lot of code going on before the parent is constructed, be sure to specifically set the start time when needed.

$this->profiler = new PhpQuickProfiler(PhpQuickProfiler::getMicroTime());

Given the page execution time, the next step would be to find meaning in the information. A quick glance will show if the time falls into an acceptable range. Assuming it doesn’t, how would we go about debugging the problem? Using the query section of the debugger, we can rule out query execution time (explained more in the next section). If queries aren’t the problem, then some portion of the script is. We can find this with the console.

Console::logSpeed();

A call to logSpeed() will tell us how long the script has taken up until that point in time. For example, imagine we have an object factory that constructs complex objects from a database. We also have an object engine that returns the object names from a database. When displaying 100 objects names to the screen, we would use either the factory or the engine. But using the engine would be much faster because we only need the names, and do not need the logic processing of object creation. If the developer did use the factory, logSpeed() would reveal the slowdown in the display loop, which ultimately identifies the problem.

On a similar note, we recently discovered that xCache improves our page execution time by over 60%. This was compared against other benchmarks by having all of our developers run quick tests against the code they were responsible for using PQP.

A Glance at Database Activity

Getting the debugger to report database information is the hardest part of integration with your own project. This step will only work if your database interaction is abstracted in some way. We talked about a simple database class awhile back, and have also released an example with the zip download (MySqlDatabase.php — you can follow the code in there to see a full implementation). The reason a class is so important is because information about each query must be stored as it happens, and a class allows the queries to each go through the same analysis without additional work by the programmer.

As a query is called, the database wrapper class stores the query and logs the time. The simplified code looks like this:

function query($sql) {
    $start = $this->getTime();
    $rs = mysql_query($sql, $this->conn);
    $this->logQuery($sql, $start);
    return $rs;
}

function logQuery($sql, $start) {
    $query = array(
        'sql' => $sql,
        'time' => ($this->getTime() - $start)*1000
    );
    array_push($this->queries, $query);
}

Using that concept, the class will have an array of all query information available to it. Then, the debugger can take that array and print out the information. The information that is currently stored is the query itself, and the time to execute. The time to execute is not exact — it is the microtime until PHP has a handle on the recordset, which will be slower than the query time if there is network latency with the database server. Viewing the queries at a glance is an easy and helpful way to look for queries that would affect more records than intended, that are being duplicated or those that open themselves up to SQL injection.

One of the most useful database features added to the debugger is the ability to EXPLAIN each query run. Each query is run again using the explain statement, and the results are presented below the query. This makes it easy to identify which queries are using their indexes properly.

Wrapping Up

The end goal of this debugging tool is to present a summary of useful information in an automated format. Usually, finding out about certain aspects of the code would require manual work and thought. And then if a problem is encountered, the debugger will hopefully make narrowing down the problem easier through the use of the extended Console functions. With that in mind, this tool is just an aid and is in no way meant to replace the standard, thorough procedures available to developers. The slow query log, PHP error log and full fledged debuggers and profilers are encouraged on top of this high level view to supplement the tools available to developers.

Now, our funding situation is that we took some initial seed money ($18,000) from Y Combinator and then followed that up with a small angel round ($100,000) to get us to launch. That’s all the money we’ve taken and that was all done within the first 4 months of 2006. Since then, we’ve been blessed to have Wufoo do very well out there and we’ve been able to grow our team, product, user base and profits solely off of the service’s revenues. We did not take VC money because 1) we like control and shares and 2) we just weren’t interested in getting big fast, which meant VC money seemed like overkill to us in regards to our plans for growth. So when these calls started coming in, our stance was (and still is) that we’re not interested in seeking additional funding, but we’d be happy to talk because, well, you never know.

Of course, before every one of these phone calls, we would look up the firm’s web site, we would read their history, we would look at their portfolio, we would look up the associate that we’re going to talk to (there’s always a photo and there’s always a bio) and we would even look up some of the companies their firm had invested in. If the associate we’re going to talk to had a Facebook, Twitter or Linkedin page, we would look at that too. We think of it as basic research and it’s just how we do things. It’s how we write the articles on this blog and it’s how we make all of the decisions in our company. We’re like boy scouts. We like being prepared.

Additionally, we think it’s a basic form of courtesy to show someone else a level of concerted interest, if they’re showing interest in us. This way, hopefully, time would not be wasted on posturing and excessive introductions. Unfortunately, it’s become very clear to us after every one of these exchanges (there are no exceptions I’m afraid) that these investors and associates do not do the same. All of the associates we talk to seem to have three goals in mind when they contact us:

1. To put us into a database of companies their firm is aggregating. From what we understand, most VC firms send out an army of these associates to just gather basic research on companies, but for some reason, their flavor of choice for data collection is via a phone call rather than actually using the Internet to scrape most of the mundane stuff that they’re asking us. We’ve actually had conversations where we can hear them typing into a spreadsheet in the background as we talked to them.

2. To regurgitate the firm’s history and mission statement from their web site. We noticed this early on and that’s why we started going over them ahead of time so we could skip it, but apparently this information must always be passed on orally to a potential company regardless of whether the company is able to finish their sentences.

3. To let us know that they were different, that they give more than just money and that we should keep them in mind when we do decide to take on more funding. Needless to say, we find it very odd (if not funny) to hear every firm state how different they were in exactly the same way as everyone else.

Obviously, we are not against gathering research. We are not against unsolicited introductions. And we actually think the intention of the act—to start an earnest conversation or relationship with a company that appears promising is a great idea. We’d love that. But the execution of these exchanges completely baffle us. Every associate asks us the same surface questions that can easily be answered by reading a few short pages on our web site (specifically our FAQ and our About pages—they are definitely not hard to find). In fact, we’ve actually had people call us with promises of expertise and advice that’s never even created an account with Wufoo or know how we made money (that we have a freemium software-as-a-service subscription model).

Now, we understand that the typical relationship regarding a startup and a VC firm is to have the startup pitch to the VC. It is the startup’s job if they want money to convince the VC that they are worthy of investment. We also understand that the associate that’s calling us is making like a million of these calls a day. It’s probably just a job to them. We get that. We do.

However, if it’s the VC firm that initiated an unsolicited conversation and the company indicated ahead of time that it wasn’t interested in more money, and the VC firm insisted on talking anyway…well, then it’s sort of not cool to not do your homework and effectively make the company do the pitch anyway. Then we’re doing your job. Then, when you show the company how not different you are from everyone else following what is apparently the same lead, you’ve accomplished the exact opposite of what you intended: We do not think you’re different. We are not confident in your ability to establish strong relationships with companies. And we will probably not think of you when we need funding later on.

I know. That’s really harsh stuff. In fact, I’m unfortunately notorious for being rough on venture capitalists during meetings when we were based in Silicon Valley. Which is why 1) I’m not allowed to sit across from potential investors during lunch/dinner meetings so they can’t see the reactions on my face and 2) Chris, Ryan and I rotate returning these calls to VC inquiries. And so, thankfully, it’s not just me. We all feel surprised, which means these firms are probably giving the same impression to countless other companies.

What we find surprising is how every single one of these associates miss the opportunity to be a hero—to truly make an impression. Because, honestly, it’s so bad out there, that it would probably take very little to actually impress us even a little bit. All you would have to do is indicate to us that you’ve at least read the marketing materials on our web site (the thing that you want to pump money into) and tried out our service (the thing that’s potentially going to make you more money).

At least then, you’d be in a decent position to have a conversation that has give and take—maybe even provide criticism that we might find valuable. And that would be the event that would have me write down your name. The moment someone tells me, a person that’s been thinking obsessively about how to improve my company 24/7 for the last 3 years, something insightful about my business, product or future that I haven’t thought of before would be awesome. Also, bonus points would probably be given to the investor that calls us with knowledge of any of the number of articles we’ve labored over for this blog.

Anyway, the take away from all this for venture capital firms is that we’re not really complaining. I mean, technically that’s all I’ve been doing, but I also want you to know that we are definitely honored to be in a position to have VCs that want our attention. We know that’s a rare position to be in and we don’t take it lightly. Which is why we’re actually rooting for you. For that hero associate out there to get a hold of us and maybe knock our socks off with a little insight or even just some good ol’ fashioned genuine enthusiasm. For good reasons, we don’t want our time wasted. And we really do want you to accomplish your goals, which is to be remembered. You don’t have to be our biggest fan. We don’t expect that at this point, but we do think that if you’re asking us to consider handing over a percentage of our soul (a soul that we’ve cultivated with our own blood, sweat and tears) in the hopes of capitalizing on our now apparent successful trajectory, then we’d hope that you’ll at least do us the honor of reading our words and learning our craft.

Now, if you were to give me the same choice today, I probably wouldn’t choose anything specific to technology. I would ask to have inserted into my brain the oft neglected and under appreciated art of Kung-Fu writing well. This isn’t because technology is any less important to our company—we are a software company after all. It’s because I’ve noticed that when a company reaches a certain level of maturity, the business seems to always require just as much communication, both written and verbally, as it does technical innovation.

We’ve been fortunate to have Kevin on hand, who has a literary and editorial background, to help us craft our blog posts, support emails, newsletters, documentation, and presentations over the last few years. And while it’s nice to have that safety net, I believe that when your long term success depends on communication with employees, audiences, partners, and customers, everybody, especially those in leadership positions, need to be able to communicate with people as well as they do with computers. Roy Jacobsen said it best recently on his blog, Writing, Clear and Simple:

“The words you use, either written or spoken, can have powerful effects on your audience‚—if you use them carefully and skillfully. Whether your goal is to inform, to persuade, to call for action, or to entertain, your words and your stories can be powerful. They can be powerful, because language is software for the mind.”

Since most of my adulthood has been spent coding and communicating with computers, my writing, or software for the mind skills, have unfortunately taken a bit of a backseat. Only so much progress can really be made when you don’t take a dedicated approach to learning a new skill, and the default level of writing that goes into a normal day’s work just doesn’t cut it. So in an effort to beef up my writing skills and grow alongside the business, I’ve decided to give my writing the love and attention it desperately needs. There are a number of resources I’ve found useful over the last couple of months, and if you also are looking to improve your writing and, like me, don’t have access to the Matrix, they might be worth a glance.

• Elements of Style - As the introduction states, writing is about saying something concisely, clearly, and worthwhile. This 90 year-old book is still one of the most highly recommended resources by writers, and its tips on the fundamentals of writing are always worth having close by.

• Poynter.org - Poynter focuses primarily on the art of journalism, which is extremely valuable if you want to understand how the media wants to craft a story. Their web site contains a boatload of best practices and tips for journalists, including bloggers, of all areas and on all topics.

• The New York Times - Grammar and Usage - There are a bunch of articles and resources available here, but I always like to keep an eye on the After Deadline section where you can see the mistakes that some of the pros made and how they were corrected.

• The Economist Style Guide - The style guide given to the journalists at one of my favorite reading spots, The Economist.

• Guide to Grammar and Style - From A to Z, this site goes through a listing of words and phrases that are commonly used, but oftentimes misunderstood.

• Guide to Grammar & Writing - Yes, the site looks a little childish, but if you’ve forgotten what a parenthetical element or predeterminer actually are, this basic grammar guide can help refresh your aging memory.

While I’ve highlighted best practices and resources on how to pitch your ideas in the past, I thought I’d take some time to share exactly how we prepare for our demos when we’ve been invited to showcase Wufoo at conferences, events and VC boardrooms. We’ve spent a lot of time refining and practicing our workflow for presentations and after doing this a number of times now, I think we have a method that seems to produce results that we’ve been pretty proud of. While the amount of prep work we do probably isn’t for everyone and might be overkill to some of you, hopefully there will be some tips in here that will help you in your own presentations and demos.

For all the examples in this article, I’ll be referring to the prep materials I generated for a 7 minute demo we were asked to do this past summer at the National Society of Collegiate Scholars Convention in Orlando, FL. Because we (the founders) have demoed Wufoo countless times, we had one of our new hires, Tim Sabat, do the presentation to get some experience under his belt. Because this would be his first time with the material and because we’re obsessed about polish, you’ll notice that we leave very little to chance and improvisation.

Getting Started

If we’re presenting something completely new, we’ll start about a week before the presentation. If it’s something I’ve presented before and I have the slides and prep work already done, then I can probably get away with looking at stuff a day or two before. Either way, I’m probably going to be working and tweaking the slides all the way up until the moment before it’s time to go on stage. Because I wanted to try a new script (Wufoo had a lot of upgrades since the last time we demoed it) and Tim was new to this, I treated this presentation as if I were creating it from scratch.

We like to start every presentation with a rough outline. In fact, I pretty much start every thing I ever write with an outline and it’s one of the most common recommendations I have for people that have trouble with rambling and organization. It seems obvious, but you’d be surprised at the number of people that try to wing these things. Outlines keep us focused and help us make sure we hit the points that we need to cover like who we are, what we do, who uses us and the major features we want to highlight in the app. Here’s the outline I developed for our NSCS demo.

Introduction

- Particletree
- Treehouse
- Wufoo

What is Wufoo?
- online form builder
- help people collect information over web
- Infopath but friendlier

etc.

The Transcript

If the time allotted for the demo is under 15 minutes, which this was, then I basically take that outline and write out a full transcript—a word for word articulation of what would be said during the presentation. Not going to lie, it’s a lot of work to do this, but it’s definitely worth it. During a 6-8 minute demo, there isn’t any time to waste on finding your words. We believe a good short demo is like a good short story—it’s carefully crafted. Even with material that feels like I should be very familiar and intimate with it (like talking about a startup and application I created from the ground up), I feel much more comfortable knowing that if I have a brain fart on stage, there’s a safety net for me to read from. Here’s a copy of the final transcript I made for Tim for our NSCS demo.

The first version of this transcript is written as fast as possible since I know that it’ll go through lots of revisions when we start timing it and whittling it down. After the first draft is done, I’ll do a time check. Basically, I time how long it takes to read the introduction, how long it takes to read the demo and how long it takes to read the closing. I’m careful to make sure I’m reading slowly but clearly (I actually have a problem with speaking too fast when I’m confident), which is probably the most important part of this process. For me, I know I’m reading at the right pace when it starts to feel a little uncomfortable. Timing and reading out loud will let you know where there’s flow problems and also what needs to be cut or made more succinct.

For this presentation we aimed for about 2:45 in the introduction, 2 minutes for the demo and then about 2 minutes for the closing. Now, when we first launched Wufoo, we didn’t have any of the information on traction and usage and so during those presentations, our intro was obviously shorter and our demo time was then extended to show more features. One thing we’ve learned about demoing features is that it’s impossible to show everything. Even if I took the entire 7 minutes, I couldn’t show all the things possible with Wufoo and so it was important for us to hit the highlights and then compromise by just showing screenshots of other major features to wet an audience’s appetite and imagination for more.

After I was happy with what I came up with, I sent a copy off to Tim so he can look over it and let me know what phrasings didn’t sound like him or felt uncomfortable rolling off his tongue. I’ll also have him do a time check since he’ll actually be presenting. When that’s done, I’ll leave him to practice while I work on the slides.

The Slides

I do all of our presentation work in Keynote. We’re all on Macs and so it’s very convenient. And while I do love the way everything looks on it, I’m pretty sure I could be just as effective with the latest version of Powerpoint. Here’s a copy of the slides from the NSCS Demo.

The nice thing about making slides from a transcript is that it’s much more efficient. When I’ve made presentations based on just an outline in the past, I would usually waste a lot of time making a bunch of pretty slides that ended up being cut out of the final presentation after going through a few rehearsals and timings. In regards to actually designing it, there are so many ways to effectively illustrate a presentation. Since we’ve covered this in past articles, I’ll just share some of the things I like to do when I design one:

• As you can see from the slide overview above, I like to use a lot of bright colors, images and screenshots. I prefer to illustrate rather than explain.

• When showing a web site, I’ll cover a screenshot of the site with the url in large text so it’s easy to read even in the back of the room.

• When I purposely want the audience to feel overwhelmed, I’ll show lots of text or images on a single slide. Otherwise, it’s never more than a short sentence, if that.

• Duplicate the first slide. A tip I got from Tim. This way you can leave it up on a screen without my notes showing or the timer starting.

• Try to use humor when possible. Sparingly and tastefully, of course.

• Add any slides at the end that will easily answer some of the most commonly asked questions (this is why pricing page is added after the Thanks! slide).

Additionally, I try to avoid using any transitions or animations in my presentation. I know some of them can be really slick, but in a demo with strict time limits, not only do I fee like I don’t have any time to waste, but I also don’t want the audience distracted by eye candy that makes them wonder about the software powering the presentation over what’s actually being said.

Using Notes

In Keynote (and I’m pretty sure in Powerpoint as well), you can add notes to each slide that will only display on your laptop when showing slides through a secondary display. Honestly, I think this notes feature is one of the most under-appreciated features in presentation applications. Ever since I’ve started using them, I’ve never gotten lost again or wondered why a certain slide was showing in the middle of a presentation. And so after the slides are done, I’ll start to copy and paste the appropriate sections in the transcript into the notes for each slide. Here’s a copy of the slides with the transcript inserted as notes.

One thing that you’ll notice in the slides with notes is that certain sentences or phrases are copied across multiple slides and formatted with odd line breaks. The duplication is done so that if a sentence is illustrated by multiple slides, the rhythm of a sentence won’t be disturbed during the slide changes. Each new paragraph represents when the presenter should proceed to the next slide.

In Keynote, I’m not a fan of the default layout for showing notes. Thankfully, you can change these settings under Preferences -> Presenter Display -> Edit Presenter Layout…

Obviously, you should experiment and find the layout that works best for you, but I like to maximize the amount of notes I can see and so the presenter layouts for my keynotes are set up like this:

Pre-Recorded Screencast

There are a number of studies out there that show that mult-tasking is a myth. Our brains aren’t meant to do it. It should therefore be no surprise that driving your application and talking about it articulately at the same time is a really hard thing to do well—especially, when you’re under pressure to do so in a narrow range of time. During practices, we’d notice that when we tried this, it was never smooth. There would be awkward gaps of silence whenever any thought processing needed to be done to show off a feature and, for some reason, the ability to type always seemed to escape the person when they were talking at the same time. That’s when we made our demos a two man operation.

One person would drive the application and the other person would do a running commentary of what was happening on the screen. This worked out alright, but it also had its issues. For example, there would be this awkward transition where you have to wait to pull out of the program and then open a browser to start the demo part. Because of this, you couldn’t fall back on your notes inside the presentation software, which means you have to effectively completely memorize this part of the sequence along with your driver.

You could bring two laptops, but most displays at conferences aren’t prepared for this setup and you end up with an even more awkward transition that has the potential for a dreaded AV malfunction. Additionally, this also added two additional variables to your presentation: another person and another piece of software. In addition to having to pay for two people to do every demo, you and your driver both have to be in sync and your application just has to work. Even though we would run everything off a development localhost on our laptop so we wouldn’t have to rely on an Internet connection, it always made us nervous. And so after a few presentations run like this, we decided that it would be better to just pre-record the demo as a screencast. Here’s a copy of the movie used in the NSCS demo.

Using a screencast solved the awkward transition problem, allowed us to still utilize notes, eliminate the variables of another person and software and made sure that we would not go over on time for that part of the demo. Keynote makes it very easy to insert movies into presentations. Just drag the movie into a blank slide and it’ll work pretty much like you expect. The only problem I have with it in Keynote is that the movie only plays on the secondary display and not in the presenter layout view and so you have to make sure you’re looking on the screen behind you so that you start speaking at the same time. But when it’s done right, it’s a pretty smooth experience.

The down side, of course, is that you have to do a lot more work ahead of time in prep. For the NSCS demo, I had Tim read off the demo portion of the script while I recorded myself doing the screencast with Snapz Pro X without the sound. It took us about 10 takes to get it just right and in the time span that we wanted.

Keynote Display Preferences

And that’s pretty much how we do it. After all the prep work is done, it’s pretty much up to the presenter to practice it enough for a smooth delivery and to memorize enough of the material so that they don’t have to rely on the script. Before I leave you to make and modify your own demos, I’d like to quickly share with you one last tip. Make sure you set up your presentation display settings ahead of time if you’re using Keynote. Here’s our settings:

Basically, have it set up to Present on secondary display and then definitely check your Display Preferences to make sure Show displays in menu bar is checked off so you can easily make adjustments on the spot. When you’re plugged into the secondary display, then you’ll want to make sure your Mac is not mirroring the primary display (done in display preferences). If that’s done right, your presenter notes will show properly on your laptop and keep you from looking like a spaz when the projector isn’t doing what you expected. Alright, good luck and happy demoing!

One thing that’s really nice about working with Wufoo is that the attention to detail doesn’t stop at just our UI. Whether it’s the efficiency of a query or the tools we’ve developed for backend development and benchmarking, the team is equally fanatical about making the code on the inside as beautiful as the design on the outside. In fact, whenever one of us is creating a brand new feature or interacting with an old, inflexible piece of code, we’ll take the additional time to ensure that it’s clean and readable for any future programmers working on that code.

The thing I like about our rewrites is that the focus isn’t solely on making it work. We also always strive to make it easy to work with—basically, creating maintainable code. Now, making sure our new code is clear and easy-to-read can be a tedious process that slows down the initial pace of development. But, we’re all firm believers that while the last programmer to write a piece of code might not have known any better, it pays off when Alex, the Programmer of the Present, is nice to Future Alex, the guy that’s going to have to fix the bugs left behind.

While reading through lots of code can give you an appreciation of what well-written code looks and feels like, the ability to create it is a skill that is developed from experience and frustration. Luckily, there are a number of excellent articles and books out there to help the aspiring code perfectionist. The following resources are ones that have helped me personally strive to write code worth looking at :

Articles

• Seven Pillars of Pretty Code - Sage advice from the developers at Perforce. A great article and example giving credibility to the fact that maintainable code is essential to a software development companies bottom line.

• Code Brevity - Advice on the benefits of being succinct. Learn about the dangers of over thinking your solution and overestimating your problem.

• Style is Substance - “What benefits do we get from freedom of style that outweighs the cost we pay for it?”

Books

• “Creating Code as an Essay”, Beautiful Code - A description of the principles that guided Yukihiro Matsumoto’s goal of making Ruby a language that creates happy productive programmers.

• Domain Driven Design - Stresses the importance and benefits of clear communication in a development team’s code, design, and even speech. Describes a ubiquitous language and design as the base of a products distilled knowledge.

• Refactoring: Improving the Design of Existing  Code - A guide to improving program internals from with the wisdom of lifelong programmers’ experiences. “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

• Code Complete 2, Themes in Software Craftmanship, Chapter 34  - “Communication with other people is the motivation behind the quest for the Holy Grail of self-documenting code.”

Hi, my name is Chris Campbell and I have a color vision deficiency. Like roughly 7-10% of all males, my deuteranomaly makes it difficult to differentiate between some colors, like red and green. Color deficiency, or color blindness as it’s commonly referred to, doesn’t mean that I or people with similar conditions cannot see certain colors. They’re not invisible and I don’t see in black and white (a condition that is actually very, very rare). I can still use crayons effectively, find meaning in beautiful sunsets and even enjoy clear blue skies. What it does mean is that certain colors in the visual spectrum look a lot like one another and so I have a hard time sometimes telling the difference between certain colors and even shades.

Because of this, designing software and interfaces that will also work effectively for people like me takes a bit of concerted effort. Of all the elements of design (line, shape, size, texture, etc.), color is probably one of the most used elements to pass on informational states. This is probably because it allows a designer to say many things without having to change the form or layout of the design. While there are a number of simulators and plugins that can help you “visualize” what a color deficient person might be seeing, I honestly don’t recommend spending a lot of time with them. Instead, I’d like to propose just a few simple guidelines along with plenty of examples to help you effectively ensure that a good percentage of your audience won’t misinterpret your message.

Avoid Using Colors Alone as Visual Cues

Using color and color alone as a visual cue is appealing because it’s usually an aesthetically pleasing and a minimalist design technique. Calls to action and visual cues are critical to interface designers because users, especially on the web, have limited patience and are looking to process information and make decisions quickly. Since the brain recognizes and forms an emotional bond with colors almost immediately, colors are a natural choice for visual cues. Unfortunately, it’s easy to alienate or confuse some of your users when some of those aesthetically pleasing colors look very similar. To point out a few interfaces that use hard to differentiate colors as visual cues, here are a few examples that have given me some trouble.

Bad Cues

As you can see, all three of these interfaces use only red and green (two of the most misinterpreted colors) to convey states or provide information to the user.

• Apple’s iPhone availability indicator uses color alone as a visual indicator. Interestingly enough, they state in their usability guidelines:

“Although color can greatly enhance a user interface, make sure it is not the only source of information. A color blind user may not be able to distinguish between two objects that differ only in color.”

Now, what they do provide is a legend of what red and green are supposed to look like for each state. But for me, it’s still barely possible to match their indicators to the live data, and so the example remains pretty frustrating. It is, however, slightly better than the other two examples.

• Warhammer Online, a video game, and MAMP, a development server application, exemplify the worst culprits because not only do they use similarly contrasting red and green colors as cues, but they don’t give you a reference or legend to help distinguish or label what “red” and “green” are even supposed to look like.

In order to avoid an angry mob of color deficient users, or to just ensure that you and your users are on the same page, here are some aesthetically pleasing interface examples that use text and icons, in addition colors, to communicate what’s going on.

Good Cues

• Dropbox users know the status of their files because of the colored circles and icons attached to each file. The colored circles can be confusing to a small percentage of viewers, but it’s pretty hard to misunderstand what’s going on unless you’re both colorblind and not familiar with their commonly used icons.

• The Wufoo and Versions screenshots pretty much leave no room for misinterpretation because they, like a stop sign, use combinations of shape, color, and a word / icon to give their visual cues meaning and context. You’re sure to leave very little to interpretation when you use three visual cues to convey a single message.

More Good Cues

• Again, Apple uses the hard to distinguish red, yellow, and green orbs as visual cues throughout their OSX windows, but this time they help those with color deficiencies by providing icons whenever you hover over the colored orbs. Since a user is only going to be interacting with those orbs when their mouse is hovering over them, it doesn’t hurt to hide the icons and keep the interface aesthetically pleasing until the user is clearly interacting with them.

• The TiVo interface is strapped for space, and in order to give multiple visual cues using color by itself, a recorded show is represented with a full, green orb, and a show that is currently being recorded is represented with a smaller, red orb. Even if somebody cannot differentiate the colors that Tivo is using in this situation, they can tell the difference between a small and large circle.

Use Contrasting Colors

Of course, as an interface designer, there are going to be times when you do not want to use icons or text as a cue due to space or aesthetic constraints. While I recommend using icons or text when you can, sometimes color and color alone is the most logical way or only choice to convey different information. Maps, for example, often use colors to display separate areas of information about a location. Also, sometimes designers want to indicate state by coloring just the text itself.

If you are going to use color alone, the best way to accommodate for the color deficient viewers out there is to get familiar with contrast. Kevin wrote an excellent article recently on programmatically finding good contrasting colors. Additionally, a couple of great resources about how to choose proper contrasting colors can be found over at lighthouse.org and 456bereastreet, but to give you a quick overview of what works and doesn’t work in my world, here are a couple examples.

Bad Contrast

• This New York Times map is frustrating because the “Yes” and “Did Not Vote” colors are extremely close in contrast, and they basically look like the same thing to me. I wouldn’t even recognize there are four colors being used on that map. And actually, the classic example for bad contrast for the color blind in Wikipedia is this NY Times Map.

• Trulia’s maps are sometimes extremely tough to interpret for me because they not only use red, yellow and green, but they use multiple shades of those colors. I see this a lot of times in graphs and pie charts, and it’s probably the most frustrating example of all the screenshots I’ve documented in this article.

• The red/black and red/green text are sometimes used as hyperlink colors on web sites. They can be problematic because certain combinations are colors that those with a deficiency often have trouble seeing.

Good Contrast

• In this map, the New York Times does a better job because red and blue are easy to differentiate, and while light yellow and light blue can be confused by an extremely small percentage of people, the stripes they use clearly separate the states.

• While this pie chart in Wufoo does use red and green, the colors in this example are contrasting enough to tell apart, especially when viewed directly next to another.

• Here’s another set of text examples that are again a red/black and red/green combo, but they’re more distinguishable due to their higher contrast differences.

Conclusion

For the most part, this isn’t a call to arms. I’m not on a quest to change the world, fight discrimination or demand visual equal rights. As you can see, if you want to avoid making color blunders, all you really need to do is to take a minute to make sure you provide a legend, use icons or words when possible and make sure your visual cues are high contrasting. You probably do not need to run your designs through a color checker and stress over whether or not your interface is going to offend your viewers. In fact, there’s a pretty good chance you’re working near or know somebody with a color deficiency, so having them give your design a once over is a great way to ensure your message is seen properly.

Additional Reading

• Blindness - A series of images that are shown in both normal vision and how they appear to someone with a red/green colorblindness.

• What about Traffic Lights? - Daniel Flück writes about why traffic lights do not confuse him. Wikipedia also notes, “Usually, the red light contains some orange in its hue, and the green light contains some blue, to provide some support for people with red-green color blindness.” This explains why color blind people do not actually need to memorize the location of where green and red lights are located, especially in the dark when you cannot pinpoint the location of where a light is coming from.

• Emerson Moser - In 1990, Moser was Crayola’s most senior crayon moulder and retired after 37 years. After moulding approximately 1.4 billion crayons, he revealed that he is actually color blind.

• Camouflage Detecter - There is an upside to being color blind and it’s that you have the super human ability to detect camouflage like U.S. soldiers did in World War II. That might also help explain why most animals have some form of color blindness.

• Colorblind gaming or: Table Tennis is impossibly hard! - A color blind video gamer explains why Rockstar’s Table Tennis may be the most difficult game ever.

• Seeing Through the Eyes of The Color Blind Shopper - “Many consumers throughout the United States have impaired or limited information processing capabilities as part of congenital or illness-related disabilities, yet their specific problems and needs are often not formally considered by firms, by researchers, or by students preparing to enter the business world. I learned this quite by accident in my own Consumer Analysis class when I gave a routine assignment to my students.”

Adobe AIR

Adobe AIR has made great strides in providing a cross-platform application architecture that sets a new benchmark for web developers dreaming about making things “better.” This environment provides a way for web developers who are comfortable developing in Flash, Flex or HTML to easily port their apps to a desktop environment. Like other frameworks that produce installable code it can install shortcuts on the desktop and interact with the file system. In the hands of someone familiar with creating Flash interfaces, AIR is capable of utilizing beautiful UIs that are not confined to the browser. AIR can also use SQLite as a database, which allows a developer to create a truly disconnected system. Additionally, using a specified coding model and an Adobe server product called LiveCycle, offline data synchronization can be handled automatically, freeing the developer the burden of writing this code alone.

One of Adobe Air’s strengths, the inclusion of an out-of-the-box synchronization, is ironically one of it’s downfalls. While this technology may save the developer loads of time, the configuration and maintenance of a J2EE-compliant server like jBoss (LiveCycle must run in a J2EE container) may prove to be overkill for a lot of organizations.

Another downside of Adobe AIR is the lack of true multi-threading. Plugins like Google Gears and Silverlight both expose multi-threading out of the box. The AIR framework, on the other hand, runs on a single thread. System threads to perform database operations are spawned separately, but once the data is returned, the processing of this data occurs on the same operating thread as the UI. While patterns exist to minimize the impact on the user, they may lack the sophistication veteran desktop programmers are used to working with in other environments.

One thing to keep in mind about developing an installable application like AIR, is the responsibilities that comes with the power of developing with AIR’s API, which is rather extensive. Just like any other application run from an installer, the user makes one choice at the beginning of the process to explicitly trust the application developer and the application. Because AIR has access to the file system, a developer with the wrong intentions could do great damage with it. While the AIR HTML security is designed to protect developers from writing applications that could be exploited by third parties, the up-front contract between the user and the AIR application still gives the developer a lot of opportunities to do evil. Check out Lucas Adamski’s article to get an understanding of the AIR security model.

Google Gears

Google Gears is a framework that adds powerful desktop functionality to the browser through a toolbar or browser plugin. Google Gears exposes three major components: LocalServer, which allows developers to cache and serve application resources (HTML, JavaScript, images, etc.) locally, Database to store data locally in a fully-searchable relational database powered by SQLite, and possibly the most important offering, the WorkerPool, which makes web applications more responsive by performing resource-intensive operations asynchronously.

From a security perspective, your users end up making a smaller commitment with Google Gears. Gears runs within the sandbox of the browser, storing data BLOBs and the SQLite DB within a protected area. Unlike an installed application, Gears does not have arbitrary access to the file system.

One promising feature in Google Gears is the BLOB API, which provides a way to reference binary data in web applications. Google’s Chris Prince explains in this video how the BLOB API can allow the developer to manipulate a memory stream that the browser can interact with to create an elegant solution for large file uploads.

Google Gears does find itself lacking in two areas: easy offline synchronization and advanced integration with the desktop. No framework is provided for synchronization like AIR. The architecture documentation explains to the developer how to check online status, but leaves the synchronization code up to the developer. Additionally, Gears is confined to the browser and so an application developer has no way to adjust the user experience outside the confines of the page. While the new Gears API has desktop shortcuts and Growl-like / Growl compatible notifications (depending on your OS), an application designer is very limited in creating the controlled experience you see in most desktop applications.

Microsoft Silverlight

Silverlight is a Rich Application Architecture designed by Microsoft meant to topple Flash as the leader in rich online content. Like Google Gears, it installs as a plugin and runs in all the major browsers. It offers slick vector graphics support, a sandboxed offline data storage component, and most importantly, access to a reduced version of the .NET runtime. Like all Microsoft development tools, the framework is steeped in Microsoft-specific buzzwords, but the concept looks compelling.

Silverlight consumes XAML documents that act as the UI layer instructing the instantiation of objects written in one of many of the languages supported by the .NET framework. This multi-language support is a key selling-point of Silverlight. It allows developers from an enterprise to contribute their pre-written libraries to a Silverlight project, provided they meet certain specs.

One major con to the development of a Silverlight project is the barrier to entry set up by the IDE. Unlike the other dev environment listed here, Microsoft stands alone in charging thousands of dollars for a single developer seat. For example, outfitting your single designer with Expression Blend, the creatives tool for working with XAML, and two of your developers with Visual Studio 2008 costs over $1700.

One other major concern is the install base and market penetration of Silverlight. Microsoft is pushing hard to power big-name events like the Demographic National Convention and the 2008 Olympics, where they reported that of the 50 million visitors nearly 50 percent of them had the Silverlight plugin installed. Compare that with the over 80 percent of browsers running Adobe’s Flash and it is easy to understand why website developers may be reluctant to serve a page that requires users to install another plugin. That said, with Silverlight 2.0 slated for a October 15th release date, you can be sure that Microsoft will be finding bigger venues to show off their shiny new plugin.

Further Reading

While this wasn’t a comprehensive review, I hope it’ll give you a nice jumping-off point for your own research. For more information, definitely check out the following articles:

• Silverlight Pros and Cons
• Adobe Air Pros and Cons
• Synchronization with LiveCycle
• Gears 0.4 Release
• Facebook uses Gears to Power Messaging

One of my favorite implementations of using programming to supplement the color picking process was done by the clever Canadians over at Dabble DB. All you have to do is upload your logo and their application will automatically pick the colors based on the information contained in the image and create a theme for their web app that will match the logo.

It’s an impressive feature that helps the user focus on getting things done rather than worry over the details. While I won’t be going into all of the ideas they used to implement their feature in this article, I do want to take some time to talk about how you can get a legible contrasting foreground color for a piece of text when given a specific background color.

When we were working on the Wufoo Form Gallery, I wanted a way to represent the pre-made color palette themes in a concise format without having to go through the laborious process of making a screenshot for each one. After a lot of trial and error, the following format is what we came up with for the gallery to represent themes:

The problem that we ran into after coming up with a structure that we liked, was that the text inside each color swatch needed to have some sort of logic applied to it so that it would show legibly regardless of whether it was a dark swatch or a light swatch behind it. This is when we turned to color theory to help us out.

According to the W3C, when you’re evaluating your web site for accessibility, you should ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. How does one know if two colors will provide sufficient contrast? Well, the W3C, being the fastidious folks that they are, provide the following definition and formulas to make what seems subjective very quantifiable:

Two colors provide good color visibility if the brightness difference and the color difference between the two colors are greater than a set range.

Color brightness is determined by the following formula:
((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000

Color difference is determined by the following formula:
(max (Red 1, Red 2) - min (Red 1, Red 2)) + (max (Green 1, Green 2) - min (Green 1, Green 2)) + (max (Blue 1, Blue 2) - min (Blue 1, Blue 2))

Techniques For Accessibility Evaluation And Repair Tools

And so, if you’ve got two colors and their color brightness difference is greater than 125 and the color difference is greater than 500, you’re in the clear. Unfortunately, the formulas are only a starting point. They can evaluate whether your colors are made to be together, but they can’t actually decide your colors. Thankfully, the Internet is filled with a number of wonderful people that have tackled the problem head on. One of our favorite solutions we looked at was created by Patrick Fitzgerald over at BarelyFitz Designs. His CSS Color Class allows you to refer to colors using abstract names like base and highlight, automatically generate color gradients from a single base color and also adjust the contrast of foreground colors so they can be legibly seen on top of background colors.

While the CSS Colors Class is great and comes highly recommended by us (we’ve been able to do some pretty neat experimental stuff with it that we’ll hopefully use in the future), we thought for our purposes in the gallery, it was a bit too much overhead. Eventually, we ended up creating our own Smarty Modifier plugin based on code we found in the PHP documentation on the hexdec function—boy, do we love that community. Here’s the code we came up with, which can be easily be rewritten if you don’t use Smarty in your development environment.

function smarty_modifier_contrast($hexcolor, $dark = '#000000', $light = '#FFFFFF')
{
    return (hexdec($hexcolor) > 0xffffff/2) ? $dark : $light;
}

It’s very simple and very lightweight, which was exactly what we were looking for in a solution for the problem. The way the code works is that given a hex color like #FFFFFF or #CCCCCC, it will return either the hex for black or white depending on what’s appropriate. You can also pass in variables for $dark and $light in case you want the function to return colors other than black and white. In our Smarty template, we call it in our markup structure like so:

<span class="palette">
    <var class="w" style="background-color:{$bgHtmlColor};
        color:{$bgHtmlColor|contrast}">W</var>
    <var class="l" style="background-color:{$bgLogoColor};
        color:{$bgLogoColor|contrast}">L</var>
    <var class="i" style="background:{$bgInstructColor};
        color:{$ftInstructColor}">I</var>
    <var class="f" style="background:{$bgFormColor};
        color:{$ftFieldTitleColor}">F</var>
    <var class="h" style="background:{$bgHighlightColor};
        color:{$ftFieldTitleColor}">H</var>
</span>

Notice that the code doesn’t take those color difference and color brightness formulas into account. Basically, it crudely (yet kind of elegantly) divides the RGB color spectrum into two halves and if the color you give it is on one side, it returns one value, otherwise, the other. Here’s a very rough visual approximation I mocked up to illustrate the concept:

And so while it’s not perfect, in 99% of cases, the function does what you need it to do without a lot of number crunching or programming overhead. Here’s an image showing off the function in action on a number of the themes we created in the gallery.

We’ve even recently reused the functionality when we made some upgrades to our graphing system in Wufoo. Now, our graphs automatically determine and use the appropriate color for the grid lines based on the background color a user has selected from their themes.

This way, the graphs are easy to read and follow even on a dark theme palette. It’s a small detail that we think makes a lot of difference in an application. If you want perfect contrast, then obviously CSS Colors is the way to go for you, but for us we’ve been really happy with the results.

Gavan Fitzsimons and Tanya Chartrand, professors of psychology and marketing at Duke University, did some research on the topic by subliminally priming over 300 subjects with either an Apple or IBM logo. They were then given a brick and asked to come up with as many uses for the brick as they could. The results of the study revealed that brands and our environment influence our thoughts quite a bit. Apparently, the subjects exposed to the Apple logo “generated significantly more unusual uses for the brick compared with those who were primed with the IBM logo.” You can watch the researchers talk about the study in the following video:

While Fitzsimons has focused some of his conclusions toward the marketing departments behind these brands, it’s more interesting for us to know that the personality of a company can influence and filter down to users by logo alone. And so the argument can be made that purchasing tools that are aesthetically pleasing and innovatively designed by companies with similar attributes can help inspire our subconscious to also want to create aesthetically pleasing and innovative software.

Here’s some anecdotal data that will help emphasize the point. J.J. Abrams, one of the creators of Lost, gave a talk at TED about why he’s so interested in the power of mysteries. A little after the 8th minute, he presents exactly why he uses Apple’s products when he writes:

I love Apple computers. I’m obsessed. So the Apple computer. The powerbook. It challenges me. It basically says, “What are you going to write worthy of me?” I can feel this. I’m compelled. And often I’m like dude, today I’m out. I got nothing.

J.J. Abrams - Mystery Box

Chris has written about this before in an article about the role of design in businesses, but the Japanese believe that all products should strive to have this inspirational quality in their work. In order to have a quality product or service, it needs to be created in a way that satisfies two different ideas of quality:

The first, atarimae hinshitsu, which is roughly translated as “taken-for-granted quality,” is the idea that things will work as they are intended. The second, miryokuteki hinshitsu, which means “enchanting quality,” is the idea that things should have an aesthetic quality that appeals to a person’s sense of beauty.

And if you’ve ever picked up a katana—a Japanese sword of the finest craftsmanship, then you’ll know exactly how this manifests. The thing to take away from this, of course, is not that Japanese products or Apple computers are the only things to use if you’re going to be innovative. It’s that context and environment matters in ways that people sometimes don’t even realize. Because humans are relationship-making creatures, we are emotionally influenced by the things we encounter over and over again and tools obviously fall into that category. And so, maybe, the choices we make regarding our tools shouldn’t come down to price alone. And maybe, as the developers of tools, we should strive to make products that inspire others with equal passion and energy.

The Benchmarks

Basically, we set up a simple PHP page to iterate over a loop and create 1) a giant concatenated string, 2) an array of arrays containing the word ‘test’, and 3) an array of objects with one variable set to ‘test’.

As the table shows, creating objects takes a good amount of memory and time when compared to a string or array. And since 7.7mb is nearing the default memory limit for PHP, the page is about to time out. Sure, the memory limit can be increased, but the point is that there is still a maximum. For most pages, 11,000 objects is overkill. But in some cases, like exporting a hefty database to CSV format or returning data from a public API, we may want to return 50,000+ records.

Workarounds

The good news is that the memory limitation does not put us in a place where the advantages of reusable code is completely removed. We just have to take a few precautions when writing code that has intensive looping or object creation.

• unset() - Avoid getting at objects through the accessor, and work directly with the recordset loop. After each iteration, unset the object that was just created. After a quick test, 45,000 objects could be created and unset using 1.43mb of memory at peak.

• Static Method Calls - A static method can be called without the need to instantiate an object. For example, if our desired output is an XML string, but we need some of the objects helper functions, we can still call functions off of the objects statically with Object::function(). Doing so only increased memory usage from 1.45mb to 1.46mb in the string example.

• Paging - The downside to unset() and static methods is that we have to bypass our accessors to get at the objects and work directly with the loop. A third option is to be strict with paging, and never allow for more than X number of objects to be returned. This will keep the code 100% consistent, but may be a bit more intensive on the database and increase page execution time.

Why Does this Matter?

Many development techniques, such as domain driven design, keep a set of value objects along with an accessor to each of those objects. The accessors act as an API that make retrieval of the objects easy and consistent. For example, let’s say we have a User object, and a UserAccessor — we would call UserAccessor->loadAllUsers(), which would return to us an array of User objects. Then, we can loop through the array, and display a list of all users and have access to the member variables and functions.

This is great because all developers work with the same objects, and SQL queries are constrained to accessors. Even if this isn’t your preferred development style, chances are your object oriented approach strives to achieve similar levels of consistency. That said, we can see from the benchmarks above that there may be situations where a portion of code we’ve created cannot return an array of objects because of memory limitations. Overall, object memory usage is far from a deal breaker, but it is something every developer worried about scaling should be aware of.

For more information, here are a couple of links that may provide some more insight.

• Practical and impractical PHP Optimizations

• 40 Tips for optimizing PHP

• Use Profiling to Determine Bottlenecks