Michael Wales

Some would call me crazy, but I love building presentations and speaking to others – especially in regards to subjects I care about. I recently had a reason to start building a deck discussing the benefits of version control systems, specifically distributed version control and Mercurial.

I wanted to gather some non-biased opinions about the current state of the presentation, so I uploaded it to SlideShare and sent out a tweet asking for people’s thoughts. In doing this, I stumbled across two of my older presentations: two years ago I gave a presentation at RefreshAugusta on CodeIgniter and three years ago I created a presentation discussing why I loved freelancing within the CodeIgniter community so much (if I remember correctly this was at the request of EllisLab but I can’t really recall).

Although I only have these three presentations to look back on, the contrast and comparisons between them couldn’t be more apparent. It’s fun to go back and see where you came from to learn where you have arrived. The first presentation, How CodeIgniter Made Me a Freelancer was nothing more than a wall of text. Although the content itself is pretty solid, and reflective of my opinions of the CodeIgniter not only then but now, this is a horrible presentation to give out in front of people. Luckily, this was never presented publicly. On the other hand, my second presentation Introduction to CodeIgniter was presented publicly. There’s still a lot of text to get through but the overall opinion of the crowd was pretty solid, there’s enough gimicky fun in there (the CodeIgniter code in the bottom-right of each slide) and some imagery. In fact, you can watch the video of me giving this presentation still thanks to RefreshAugusta and Vimeo and despite looking up at the screen more-so than I should have, I think I did a pretty decent job (plus, I was nervous as all hell).

My latest presentation, Mercurial: Beginners (v1) is vastly different than either of the previous two presentations and honestly, I believe it’s for the better. In this latest presentation I simply tried to convey emotions and concepts with the slide. In building the slide, I already knew what I would be talking about during its presentation, but the nature of the discussion deserves a visual representation to really “bring it all home” to the participants.

I’d love to hear your comments on my most recent presentation (still in development), as well as those in the past, so I’ve included them all within the post below:

Mercurial: Beginners (v1)

Introduction to CodeIgniter: RefreshAugusta (May 2009)

Video – Introduction to CodeIgniter: RefreshAugusta (May 2009)

How CodeIgniter Made Me a Freelancer

A lot of things have been going on within the CodeIgniter community – well, let’s rephrase that – very little has been going on within the CodeIgniter community and this has brought about a lot of change over the course of this month. I’ve been actively involved in the community for a little over 3.5 years now, worked with the framework for around 4 and served as EllisLab’s first Community Chieftain (a program recently cancelled). During this time I’ve learned a lot, met some excellent people and managed to cause enough of a ruckus that real careers, with real salaries, were just being handed to me. Yet, I look back on this past year and I haven’t had the faintest bit of interest in the community and it got me questioning, “Why?”

It’s not due to lack of time. I’m more readily available now than I was during my military career. Over the past year I’ve actually managed to get myself more “connected” than I’ve ever been in my life (thank you Android-powered phone) – I’m literally on the Internet (actively and passively) 19-20 hours per day. I could count the few hours per day I sleep, but telling you I’m available 24 hours just kind of gets brushed off as if your boss was telling you his open door policy; 20 hours has meaning/impact.

It’s not due to lack of use/programming. In 2009 I was hired by General Dynamics IT as a Senior Web Developer and we used CodeIgniter on a few of the applications we built. I now work for Kforce Government Solutions and although not directly using CodeIgniter, a lot of the practices/influences from that framework reflect in the work I do. I still have my personal projects I work on and many of them use CodeIgniter.

It’s not due to lack of opinion/concern. Just today there were about 10 of us working together to lay out a roadmap for the new CodeIgniter Community Branch, organized by Phil Sturgeon. It became apparent very quickly, I still have very strong opinions of the direction CodeIgniter should be headed. There are concepts/ideas that I would love to see CodeIgniter implement, and there are lots of others, although interesting/nice to have I just don’t agree with being in-line with the framework’s goals.

I try to think back. When did I actually stop caring about what happened to CodeIgniter? The event that comes to mind was when Jamie Rumbelow was appointed Community Chieftain. Now, this has nothing to do with Jamie; nor about me no longer being the Community Chieftain. But, rather, it was the events leading up to that transition that put a bad taste in my mouth.

The role of Community Chieftain was not well-thought out, which was understood from the get-go. I approached Derek Jones telling him I wanted to be more involved than just being a user – that I had the time and passion to really help out. Derek had a similar concept he had been mulling around in his head so him and I fleshed out the position of Community Chieftain via email over the course of a week or so. It was known from the beginning that the position would be temporary and would primarily focus on forum moderation and working in the bug tracker. Over the course of my time as Community Chieftain I took on some other “fun” things, like the CodeIgniter Town Hall video chats, speaking at a few local conferences, and really focusing on the forum posts that didn’t receive replies. The job was a blast, I loved every minute of it but exhausting.

I no longer have the emails but I would estimate about 6 months before Jamie’s public announcement as the new Community Chieftain I was hitting a pretty low-point in my personal life. I emailed Derek at this time, explaining a lot of what was going on and informing him I would like to step-down, giving them time to select and announce a replacement. The selection of Jamie happened pretty quickly and then Jamie and I stood by for the announcement… and waited… and waited… and waited.

Now, EllisLab is a for-profit company – they’ve been pretty up-front from the start that their profit generating products are the focus (as they should be). This means, historically, CodeIgniter has been given the back-burner for quite awhile. The company didn’t focus on it much, instead leaving much of the community involvement up to the developers that were passionate about it (Derek Allard and Dan Horrigan specifically, both of which had personal projects built with CodeIgniter). But, I honestly think this one act of delaying the announcement, over and over, is what made me truly realize: EllisLab simply forgets about the CodeIgniter community, and often. It’s not like the announcement of Community Chieftain requires a significant amount of work: a few permissions within the ExpressionEngine control panel that manages codeigniter.com and a 5-minute blog post. No, the only excuse that makes any sense as to why it took so long is, “Whoops – I forgot.” It wasn’t until I got drunk and went off on a tirade during one of the CI Town Halls (not something I’m proud of and I personally apologized to all of EllisLab) that anyone knew Jamie was taking over – Derek then, finally, made the announcement as a measure of damage control.

We all know CodeIgniter was born from ExpressionEngine. The CMS was developed, then EllisLab ripped out the real guts-and-glory, cleaned it off and released it as CodeIgniter. So, when it was announced that ExpressionEngine was going to be rewritten, from the ground up, and based off the CodeIgniter framework us developers were excited. We had come full circle – we were now an integral part of EllisLab’s business plan. We were surely going to see more frequent updates rolling down; hell, we may even be able to improve ExpressionEngine – make it more efficient – and help out EllisLab with our volunteer work within the framework!

But, in our excitement we forgot one key thing: EllisLab simply forgets about the CodeIgniter community, and often. By being rolled into ExpressionEngine now, we have lost our identity. Whereas before, the framework had grown, evolved on its own and was vastly different than the precursor work within ExpressionEngine; now, we are one in the same. Rarely can you respond to, or resolve, an ExpressionEngine issue without involving the underlying framework? Do you duplicate effort now and involve both communities?

From a workload, source management view, rewriting ExpressionEngine on CodeIgniter simply made sense. The work can be completed in one location and it affects both codebases. But, from a community management standpoint, it does nothing to decrease the workload – in an odd twist, it actually doubles the workload by not changing the workload at all (thanks to duplicate effort). If the CodeIgniter community wasn’t around, EllisLab wouldn’t be tackling repetitive community tasks – “do this” for ExpressionEngine, okay no go and “do that again” for CodeIgniter. Monotony is a beast and that is all we are now, an echo of the ExpressionEngine community; and it is with the release of ExpressionEngine 2, that we see the beginning of the end for the CodeIgniter community.

I won’t go into the multitude of ways the CodeIgniter community is being ignored, there are numerous posts that explain it in more detail than I ever could (particularly given my extended absence) but I hope I can shed some light as to why it happened. EllisLab simply can not legitimize the time and expense in maintaining a redundant process. Sure, we may see some future releases of CodeIgniter, but only when those releases fall in line with what is best for ExpressionEngine; and this is the reason for the mockery of the Community Fork. EllisLab has decided to create this as an opportunity for the community to shape CodeIgniter, to implement your ideas into the framework and turn it into what you want. In reality, it’s a farce to give the community the illusion of control, the illusion of change, and the means in which to keep CodeIgniter suppressed so that it may run ExpressionEngine to the best of its ability.

Sadly, the “key players” within the CodeIgniter community just don’t care anymore. Those of us that were the loudest, and dare I say (without sounding like a braggart), most influential have resigned to taking our own little copies of CodeIgniter, tweaked and modified to perfection, into the depths of our own localhost and we’ll just toil away at our duties silently. Of the names that stick out in my head over the past 4 years (and I am sure I will forget some of you, please forgive me) just look:

• Derek Allard: The one person on the EllisLab team that always cared about CodeIgniter, left EllisLab at the beginning of September.
• Dan Horrigan: Left EllisLab at the end of October, working on FuelPHP
• Phil Sturgeon: He’s learning Ruby, working on another PHP framework (FuelPHP) with Dan Horrigan, and continuing to develop his CodeIgniter applications for the time being.
• Elliot Haughin: Although still using CodeIgniter in his daily work, the number of tutorials, blog posts and libraries coming from Elliot has diminished greatly. Apart from a post about a CodeIgniter conference, his last post in regards to CodeIgniter was when CodeIgniter 2.0 was announced in March.
• Jamie Rumbelow: I personally haven’t seen/heard much from Jamie in quite sometime and appears as if he successfully taken his CodeIgniter experience into the ExpressionEngine commercial market (nothing wrong with that at all).

As for me, I’m perfectly content with hacking away for Uncle Sam, much of which are heavily JavaScript-based, Rich Internet Applications, for which I wrote my own PHP framework to deal with months ago. My personal projects in development were frozen at CodeIgniter 1.7.2 a long time ago and I don’t see any reason to upgrade to 2.0. For those projects not yet in development – I’m going to be checking out FuelPHP.

Edit:
Let me go ahead and restate, in case this isn’t obvious – this is not an attack on EllisLab. I think they are a great company with some amazing people working for them, many of which I consider friends and know more about me than I care to share with the public. But, as stated, they must also remain profitable and promoting the growth of a redundant community is not how they do that.

Edit 2:
Added some clarification to Elliot Haughin’s current situation involving his work with CodeIgniter – thanks for the clarification Elliot!

Django has an excellent function that assists in working with models, get_object_or_404. As Python functions tend to, the name of this function is pretty descriptive: we attempt to get an object (from the model) and if we can’t we throw a 404 error to the user.

We can achieve a rather similar effect, and clean up our code, within a CodeIgniter controller. In the following example, we’ll load a model and attempt to retrieve a record, throwing a 404 error if the request fails:

The other key component to this is the model itself, ensuring a value interpreted as FALSE is returned when an object can not be found. Here’s a quick sample:

NULL (along with FALSE, 0, and an empty string) are all interpreted as FALSE by PHP in a loose comparison (== as opposed to ===). When assigning a value to a variable using the OR operator, PHP will assign the first value that is interpreted as TRUE or the last value within the condition. Since our model will return NULL if a record is not found, PHP attempts to assign the return value of show_404() to that variable. This function doesn’t return a value though, instead it send your application’s ./errors/error_404.php (with appropriate headers) to the user – the exact functionality we desire!

EllisLab has just announced they have transitioned away from Subversion to Mercurial and are hosting the CodeIgniter 2.0 source on Bitbucket.

I did a quick glance through the source and here are some of the things I immediately noticed in CodeIgniter 2.0 (this isn’t a comprehensive list, just what I find the most exciting):

• Scaffolding has finally been completely removed.
• The codeigniter directory has been renamed to core and houses most of the absolute necessities. [source]
• System-wide plugins are gone (they were mostly worthless to begin with).
• There’s a new Javascript library that features a driver system, similar to the database libraries. jQuery is currently supported but expect to see more. [source]
• A driver library has been added, to assist developer in creating their own driver-backed libraries. [source]
• You can now enable/disable individual sections of the profiler (it’s also it’s own class, rather than being part of the output library).[source | source]
• There’s a new security library that features CSRF protection and becomes the new home for XSS filtering. [source]
• The Input, Upload and XML-RPC libraries have received new features and make use of the security library.
• The Cookie helper now utilizes the Input class. [source]
• The application directory now contains a third_party directory, I presume would take the place of the old plugins directory. [source]

I’m most excited about the new Security library but can’t wait to see how this release shapes up! What are you most looking forward to in CodeIgniter 2.0?

Edit: Phil Sturgeon and Elliot Haughin have provided their run-downs of CodeIgniter changes as well. One of the biggest changes I missed was the fact that CodeIgniter 2.0.0 functionality is not guaranteed to work in PHP4 and by CodeIgniter 2.1.0, legacy features will no longer be guaranteed to work in PHP4 either.

ErkanaAuth, although in a very alpha form, is simple to use and already extremely powerful. Protecting a portion of your website behind the authentication system is as easy as one-line, a call to the library’s required() method.

In this example, we are protecting an entire controller behind the authentication library:

When a method within this controller is called, the user’s session will be validated. If the user has not authenticated they will then be forwarded to your application’s accounts controller, where your login and user creation methods should reside.

To protect individual methods, just call the required() method in the first line of the method you want to protect.

CodeIgniter comes with an excellent Form Validation library right out of the box. This library features a number of validation and preparation functions that are executed on posted form fields when the run() method is called. If you need additional functionality, it is also very easy to add your own validation/preparation functions to your application, without modifying any of the underlying CodeIgniter codebase.

If you have a decent level of experience with Microsoft’s Excel, you may have had to develop a custom cell format from time to time. This basic format syntax provides a very loose, but functional, method of defining the format of the input you expect. In this tutorial, we’ll define a new form field validation rule (called matches_pattern) that excepts one argument that will define the pattern we want the user’s input to match. Our goal is to make something very simple to use, but moderately powerful, so we’re going to stay away from having to use regular expressions within our validation rules. Instead, we’ll create a set of replacement characters to use within our rules instead: # to represent a number, ? to represent an alphabetical character and ~ to represent any character.

These characters will allow us to validate a user’s input matches specific cases. For instance, phone numbers could be forced to match (###) ###-#### or a date field could be forced to match ##-##-#### (MM-DD-YYYY).

The first step in extending CodeIgniter’s Form Validation library is to create our own Form Validation class within our applications libraries/ directory. By default, the prefix for your own extending classes is MY_, so we’ll create libraries/MY_Form_validation.php and stub out the following code:

We've now extended the default Form Validation library and we have a function, called matches_pattern() that we can call from our set_rules() method. Let's start fleshing out this method and translating our characters into their regular expression equivalents:

We're now using str_replace() to translate our special characters into their regular expression equivalents. Finally, we run through preg_match() and return a boolean as to whether the user input ($str) matches. You may wonder why we're just not returning the value of preg_match(). Unfortunately, preg_match() returns a 1 or 0 (at least on my development server) and CodeIgniter expects an explicit boolean, therefore we run it through the conditional really quick.

Our last step is escaping some of the standard regular expression special characters. In regular expressions, characters like (, ), [ and many others have special meanings. We don't want to make use of these special meanings within our patterns though; if our patterns contains an ( we literally want to match on that character (rather than capturing a successful match). We'll implement this by modifying our character arrays and replacing these special characters with their escaped versions:

The final step in this process is to define the error message that is reported when our validation function returns FALSE. This is done by defining your own language file within your application at language/english/form_validation_lang.php. The content within this file will be appended to CodeIgniter default form_validation_lang.php file:

The %s within this language definition will be replaced by the field name in which you include this rule. To use our new rule, we just append it to the rule set for any of our fields within our controller:

It's very easy to create your own validation rules. If you find yourself writing callback functions to do the same things over and over, consider bringing that function out into your own Form Validation library. The matches_pattern() function we wrote here provides an easy-to-use, yet simple, way to match a specific pattern - just remember to inform your users of what that pattern is! If you wanted, you could an include another %s within your language definition that would insert the specific pattern in the error message.

In November 2007 I released an authentication library for CodeIgniter named ErkanaAuth. It was very simple to use since it just provided a few methods to make authentication simpler for you – it didn’t hijack the entire process. The post announcing that library, and the code, has long since been lost but you can still read the original post thanks to Archive.org’s Wayback machine.

Recently, I’ve taken on a personal project of a rather grand-scale and have started factoring out the authentication logic into a library of it’s own, which I am referring to as ErkanaAuth 2.0. I am now releasing the library in its current state which is vastly unfinished! Nonetheless, I would love to hear your thoughts on the direction the library is headed and features you would like to see.

I don’t think I can reiterate this enough at this point in time, this is hardcore alpha – I should have called this ErkanaAuth Version 2.0ha-dont-fucking-use-me-in-production-code. I mean, in theory you could use this, and if its a library you want to use in future applications I strongly encourage you to give it a go. The authentication mechanism is secure but the library as a whole is sorely lacking in features at this point and is pretty hard-coded to a strict environment.

Features

• Authentication via username or email address and password.
• Account creation using username or email address as unique identifier.
• Locking of controllers/methods to logged-in users in one line.
• Passwords are hashed with a salt prior to storing in the database.
• User token stored in session is a hashed representation of the user’s ID and their password hash. Encrypting the session cookie via CodeIgniter’s config/config.php file adds another layer of security against altered session data.

Planned Features

• Exponential delay on failed login attempts.
• Group-based authorization system.
• Require email validation on account creation.
• Optional Captcha on account creation.
• Linking of Facebook / Twitter authentication to Erkana Auth Account.
• Forgotten password resets.
• Extensive account API for building of authentication administration panels.
• Extensive group API for building of authorization administration panels.

Installation

The downloadable package includes a number of directories and files within those directories. It is advised to extract the archive in a temporary location, ensure there are no naming conflicts with your current application and then move the directories into your CodeIgniter application’s directory. The most common naming conflict will be with the models/account.php file. The list of files included are:

• helpers/erkana_auth_helper.php
• language/english/erkana_auth_lang.php
• libraries/Erkana_auth.php
• models/account.php
• sql/1-create_accounts_email.sql
• sql/1-create_accounts_username.sql

After installing the library within your application directory you must decide whether your application will authenticate based on username/password or email/password and run the correct SQL file on your database schema. This file will create a table named accounts, the statement run by sql/1-create_accounts_email.sql is:

If you run sql/1-create_accounts_username.sql the following statement will be executed:

Usage

ErkanaAuth aims to be as simple as possible in its usage. As of this version, this is primarily due to the limited scope of its functionality, but the overall feel for the library will differ as little as possible from what can be seen as of now. Many of the limitations on the library (i.e., strict naming of form fields) will be corrected as development continues.

ErkanaAuth does not assist in the creation of any front-end related code (i.e., user registration forms, login forms) at this time. ErkanaAuth simply provides a powerful set of methods to be used within your controllers to assist in getting an authentication system up and running as quickly as possible. Additionally, there is a helper function to display useful error messages to your users for invalid form submissions.

Creating a User

The create_account() method accepts a single string parameter of either email (default) or username, which should reflect the authentication mechanism you opted for during the installation and execution of the SQL file earlier. This method will return TRUE or FALSE if the user was created and can be used similarly as to how the standard form_validation library is used.

The library currently requires the following form fields to be present with the corresponding rulesets:

• email: Only if you select the email authentication mechanism (required|max_length[120]|valid_email|trim)
• username: Only if you select the username authentication mechanism (required|min_length[4]|max_length[20]|trim)
• password: Always required (required|matches[passwordconf])
• passwordconf: Always required (required)

The controller method that displays and processes your account creation form should call the create_account() method and redirect on TRUE, otherwise loading the view file that contains your account creation form. In the following example, the user is redirected to accounts/index() which would display our login form.

Validating a User’s Login Credentials

The validate_login() method accepts a single string parameter of either email (default) or username, which should reflect the authentication mechanism you opted for during the installation and execution of the SQL file earlier. This method will return TRUE or FALSE if the credentials are valid and can be used similarly as to how the standard form_validation library is used.

The library currently requires the following form fields to be present:

• email: Only if you select the email authentication mechanism
• username: Only if you select the username authentication mechanism
• password: Always required

The controller method that displays and processes your login form should call the validate_login() method and redirect on TRUE, otherwise loading the view file that contains your login form. In the following example, the user is redirected to announcements/index() which would display a “dashboard” like page and only be accessible to logged in users.

Validating a User’s Logged-in Status at Page Load

The required() method provides a simple, one-line, way to validate a user’s session and ensure the user is logged into a valid account. This line should be placed within the constructor of any controller class you would like to complete protect or as the first line of a method you would like to protect. The following example is a controller named Announcements that currently only has its index() method protected. Any other methods added to this controller would not be protected without either moving the required() method to the constructor or placing a call to the required() method within the controller methods themselves.

Displaying Errors on Invalid Form Submissions

The library includes a helper with the function authentication_errors() to assist in displaying errors upon form submission. This function will return all errors, delimited by a
. If there are no errors, NULL is returned. In the following example, we are displaying a login form that will display errors at the top of the form if any exist from prior submission attempts:

Technical Details

During account creation an alphanumeric string is randomly generated to serve as the user’s salt. This salt is then hashed with the user’s password and the resulting hash is stored in the database to validate against.

On a login attempt, the database is queried for a record based on your authentication mechanism (email or username). That record is then compared against the user submitted data for validation. On a successful validation, session variables are stored consisting of the record’s id and a hash of the record’s id field and password_hash field.

When a user visits a protected page the session is first checked for the variables that are set by a successful login. If these session variables exist, the database is queried for the record identified. If this record exists, the session is further validated by comparing the stored hash of the record’s id and password_hash with the data that is stored in the record.

Download

Erkana Auth 2.0a is available for download. At this early stage of development a version control repository has not been made publicly available. In the future, Subversion and Git repositories will be made available.

License

ErkanaAuth 2.0a is licensed under the BSD License as defined by the Human-Readable Creative Commons Deed.

In mid-December I was asked by Packt Publishing to read and review their latest CodeIgniter book, ingeniously titled CodeIgniter 1.7, by Jose Argudo and David Upton. As you all know, my blog has been down for quite some time; although, I read the book (and subsequently gave it away to a friend), I am just now able to write the promised review.

This book targets the absolute beginner developer and it does an adequate job filling the niche, as previous CodeIgniter books on the market are drastically outdated. Unfortunately, I don’t feel this book differentiates itself significantly from the well-written CodeIgniter User Guide and many people who buy this book will feel as if they have been cheated out of $36.

Chapters 1-3 explain what frameworks are, what CodeIgniter can do for you, how to get up and running with CodeIgniter and the basics of the MVC development pattern. It’s not until Chapter 4 that we discover some truly unique CodeIgniter content with the Active Record pattern, but it doesn’t last as we drop back to some pretty basic HTML material in Chapter 5 as we build out some forms.

The rest of the book does a very good job of reiterating the content outlined in the user guide, ranging from sessions and security to the XML-RPC library. There’s even a bit of content on the Cart library which is a welcome addition since it’s relatively new.

The shining star for this book though is Chapter 7, CodeIgniter and Objects. Argudo and Upton do an amazing job describing the CodeIgniter super-global object, as well as explaining copying by reference in plain English. Unfortunately, it just kind of creeps up on you out of nowhere with very little lead in or warning that shit’s about to get deep. It’s a worthy addition to the book though and serves its purpose in separating the “restating the easy stuff from the user guide” from the “restating the object oriented stuff from the user guide” sections of the book.

All in all, if you feel as if you need the user guide read off to you in plain English, by all means buy this book. There’s nothing else on the market today that will explain virtually every aspect of the framework to you as a beginner. If you’re comfortable in reading and understanding the user guide, possibly with a bit of help from the CodeIgniter Forums, you’re going to want to pass.

Last but not least, this is one of the few books whose eBook version actually provides a legitimate value (other than just being a good option for the broke audience). If you fall between the two aforementioned groups (i.e., you are comfortable with the user guide but you don’t quite understand the CodeIgniter object model or how to best write your own libraries) buy the eBook now. You’re going to save some money and Chapters 7-9 and 15 are well worth the $28 price tag.

Facebook announced their open source project HipHop PHP yesterday and the web development community has been in a whirlwind of discussion about what this means, particularly for the PHP community.

HipHop PHP is essentially a compiler (although Facebook calls it a transformer) from PHP to C++. Only a subset of PHP functionality is compatible with the compiler but the developers say they only omitted some of the lesser used functions like eval(). The C++ code is truly cross-platform and can be compiled and run on virtually any server, the primary benefit being decreased CPU usage and therefore increased speed when delivering content to the end-user.

So, what does this mean for the CodeIgniter community? In short, absolutely nothing. Most CodeIgniter developers are building applications that will run on shared hosts, virtual private servers or a cloud-based virtualization system. Of that very large group of our community, an extremely small number have the capability to compile the HipHop binaries or alter their configuration in order to serve HipHop pages.

There are a very small number of CodeIgniter applications that are running on a couple of dedicated servers. Even these developers have no need for HipHop! The performance benefits gained by running HipHop on these server would be marginal at best, if even noticeable. These sites just don’t have the traffic to see measurable gains in performance by focusing on CPU usage. Their time is much better spent focusing on the standard bottleneck: input/output (database queries and caching of output).

It wasn’t until two years ago Facebook had enough traffic to make optimizing CPU usage a worthwhile focus of developer time. Compete won’t let me go back and look at traffic two years ago but I think the graph above speaks for itself: Facebook has more than doubled its monthly unique visitors in the past year. Most of us will be lucky to see .01% of that traffic on our applications (to put it more in perspective, codeigniter.com currently received .03% the traffic Facebook does).