Your instinct may be to dismiss my decision as laziness, but hear me out. I built most of the base site with just 1 state: free (remember that unlimited free beta period last year?). That allowed me to — rightly — focus purely on features, functions, bugs, etc. Dealing with subscription tiers at the same time would have clouded everything, slowing everything down and likely leading to more rewriting. Staying focused allowed me to get the cornerstone stuff right before building on top of it.

I applied the same thought process when it came time to offer paid options. The game plan has always been to have three paid options, plus the free account. However instead of initially coding four possible user states, I started with just two: free or paid.

This makes my job as a developer much more focused. There’s a LOT of logic in a service like Fwd:Vault focused explicitly on subscriptions: access permissions, showing/hiding upgrade options, setting quota restrictions, security checks to prevent hackarounds from unscrupulous users. The functionality of almost every page is affected by the user’s free/paying status, and don’t even get me started on the work it takes to process credit cards. You have to be doubly triply careful when dealing with people’s personal data like that. On and on. Getting the basics in place takes a lot of forethought and coding.

So instead of thinking about all this stuff in four dimensions — free, option 1, option 2, option 3 — I can cover most everything in just two — free or paid — and then come back later to fill in the holes for the other tiers.

Complexity is your enemy as a developer. Each task must be as tightly focused as possible. The tighter your focus, the less chance you’ll have to introduce bugs. Adding more later may require rewrites, but they are far far easier than rewriting the big sloppy mess you get when biting off more than you can chew.

With the basic subscription and tier logic in place, it’s a far simpler matter to expand the options out to infinity (though we’ll start with four). Expect to see the new pricing options in a few weeks.

Looking for more to read? There’s a new post on the Fwd:Vault Blog that details the most unobtrusive disk defragmenting process I’ve seen (that I also use for my own systems).

The jQuery team has put together a site devoted to the new version, called the 14 days of jQuery, covering the major version changes as well as infrastructure updates coinciding with the new release. For example, the documentation site has been completely redesigned, and been moved to it’s own subdomain home, api.jquery.com. Links from the primary jquery.com site should be updated within the next week. With video demos of new features, Q&A’s with the core team (including founder John Resig), it’s well-worth checking out for every jQuery developer.

Up until now, my server time was set for the US Eastern, where both I and the server physically reside. Then I started building the code to display local time based on a user’s selected timezone.

Ugh.

Here’s the problem: displaying local time requires at least one time conversion, from server time to the user’s timezone. If the time is initially set to anything other than no-offset GMT, you have two calculations to do, from the server timezone to GMT, then GMT to user timezone. You can do it, of course, but who really wants to write even more code?

Now add to this equation the fact that most data-delivery systems have settled on sending time data in GMT. A very good practice, to be sure, but presents the need to do another timezone conversion when the data come into your systems. Going back to my example, I had to convert payment times from GMT to US Eastern before dropping them into my database.

Finally, add to the mix the potential for time data coming in from more than one source with more than one offset. Again back to my case, payment data is GMT, as is the Twitter feed I store and display on the site. Meanwhile, email was set to US Eastern. This matched the server and MySQL database where all the data ends up residing, so I was still looking at just one time conversion. But what happens down the road, when my server configuration changes, or I move to another timezone?

Tying this information to me makes as much sense as tying it to any one of my users. It’s the same rationale that data service providers use when delivering GMT time data, it applies to me, and it applies to you too.

I’m just too lazy to try and keep all that timezone switching straight in my head.

If you find yourself in the same scenario, save your sanity and your future support efforts. If you run a website that (a) displays time-sensitive data, and (b) allows users to create an account, you really owe it to everyone involved to store time in a neutral fashion and adjust time displays according to the user’s selected timezone.

So while searching the web, I came across an insightful post that discussed PHP’s built-in DateTime object. I try hard to keep up with all the tech in my job, but this one got through the cracks, and I was instantly intrigued. So after some research and fiddling, I came up with the following block of code, which will allow you to easily translate dates/times to and from any timezone.

date_default_timezone_set('GMT');
$datetime = new DateTime('2008-11-25 16:48:13');
$tz = new DateTimeZone('America/New_York');
$datetime->setTimezone($tz);
$time_display = $datetime->format('D, M jS g:ia T');

The process is a little convoluted, so here’s what’s going on. First we must set the system-wide timezone to match that of the date/time we would like to translate. In this example, it’s about 4:50pm on Nov 25, 2008 in the GMT timezone. Next we create a DateTime object with that time (FYI you can use any format accepted by strtotime()).

Next we create a DateTimeZone object. Keep in mind that this step stands completely on its own, and can be performed anytime up to now.

Finally, we pass the DateTimeZone object as the lone argument in a call to the setTimezone() method. This will change the timezone stored in $datetime from GMT to EST, and automatically update the date/time accordingly, which we output with a call to the format method.

Note that I used object-oriented syntax for this process, but there is a procedural style (i.e. functions) as well. I prefer OOP here because it’s just easier to read and follow.

Valid arguments for date_default_timezone_set() and DateTimeZone() come from PHP’s list of supported timezones.

So now that we can translate timezones, let’s apply it to my Twitter example…

status as $key => $status) {
      $datetime = new DateTime($status->created_at);
      $datetime->setTimezone($tz);
      $time_display = $datetime->format('D, M jS g:ia T');
?>
text . '' . $time_display; ?>


more...

Sidenote: While I was working on this I found GMT and UTC used almost interchangeably. For all intents and purposes, they are identical. But there is a technical difference: GMT is based on the rotation of the earth (less precise), while UTC is based on an atomic clock (more precise). Don’t worry, you and I are not the only ones who got confused.

Build a slick Twitter feed on your site

1. Display Twitter updates on your website
2. Calculate dates and times in different timezones (translate Twitter timestamps)
3. Parse URL’s in text, create links

require() and include() are identical in every way except how they handle failure. They both produce a Warning, but require() results in a Fatal Error. In other words, don’t hesitate to use require() if you want a missing file to halt processing of the page. include() does not behave this way, the script will continue regardless. Be sure to have an appropriate include_path setting as well.

At first glance, this looks great! Since most files are only ever parsed once—did you know that it is legal to load the same file repeatedly?—these functions will save you from screwing up your code. No more worrying about reloaded files, repeating actions that cause aberrant behavior or flat out fatal errors.

Obviously the dynamic coding newbie uses these functions as training wheels. “I may have loaded, but I’m gonna load it again, just in case.” That’s understandable, and all well-and-good. If this is you, don’t make it a habit, learn to structure your code properly so that files that should be loaded once only ever have one opportunity to do so.

At the opposite end of spectrum, there are big-time PHP projects that prefer the _once versions exclusively. My own beloved Zen Cart has slowly been making the switch (new major revisions on the horizon do it more sweepingly). The CakePHP Coding Standards actually demand the use require_once():

When including files with classes or libraries, use only and always the require_once function.

Here the rationale is completely different, and completely informed. Because these projects are designed to allow extensive 3rd part manipulation, the chances for a file collision are fairly high. Think about situations where two different mods require the presence of a third “standard” mod library. They trade off a fair amount of performance to offer this flexibility, but at least they know what they’re doing.

If you’ve read this far, chances are you are not a newbie, but you sure as hell aren’t Zen Cart or CakePHP either. So, what business do you have using include_once() or require_once()? None, truth be told. And if you use them extensively, then the title of this article was written for you. Congrats!

The problem that these functions introduce for most developers is two-fold. First, there’s a performance penalty for using these functions, because the function must first check to see if a file has been loaded. Standard include() and require() statements don’t perform such checks, they simply look for the file and load it. Any type of dynamic system setup is going to use these functions quite a bit, and the penalty is incurred each time the function is used. It only takes about a dozen or so calls to see a difference.

Second and more importantly, it feeds laziness. If loading order and structure don’t cause code to fail, then you’re naturally tempted not to worry about them. This leads to unnecessary calls—”Did I load file yet? Ah screw it, I’ll do it again to make sure…”—which feels eerily similar to the rationale of the newbie coder I described above.

I’ve learned that code naturally snowballs in one direction or the other. If you write good clean code, optimize where possible (without going overboard), and completely smash bugs, the code you write and your ability to code will only improve. If instead you opt to ignore formatting, write just until “it works” and move on, and/or create logic that fixes a bug symptom rather than the bug itself, you will not improve and your code will suck.

That’s really the great tragedy; you’ve bypassed an opportunity to potentially improve your code, to potentially improve your own ability. Any shlub can half-ass it; take the high road and do the work. That will put you ahead of said shlubs when it comes time to look for a new job or get a promotion.

I’m not saying any of that is true for you (is it?), but include_once and require_once definitely fall squarely in the lazy coder category as far as I’m concerned.

So, if you need to get the timestamp of an RFC2822 e-mail header—or most any RFC-based timestamp—into MySQL DATETIME format, it’s easy:

$timestamp = strtotime('Tue, 30 Sep 2008 10:30:00 EDT');
echo date('Y-m-d g:i:s a', $timestamp);

Keep in mind that if there are differences between the timezones of your server and the timestamp, the date() function could screw with your desired output. You should probably take a look at date_default_timezone_set().

What? Seriously?

Yes. Writing clean code is much like any other type of writing exercise, but with slightly different rules. Periods go at the end of a sentence, while semicolons go at the end of a line of code. You get the idea.

We don’t have to browse far in order to find that a lot of projects place a lot of importance on good syntax: Mambo, Drupal, PEAR, phpBB (a lot of projects, including Zen Cart, are based on this one), C++ (the big daddy), plus countless others.

The commonality between all writing formats is that you need to maintain discipline and consistency in your vocabulary. The establishment of consistent writing behavior allows your audience to focus on comprehending your message, and not waste time and brain power on first deciphering the words of that message. Again, the same rules apply to all readers, whether they be blog readers (hi there!) or fellow developers.

Even if you’re one of those coders who does his work from a dark basement, code by its very nature is supposed to be a shared. Unless you code only for yourself, your code will be viewed by other people at some point. Your work takes on an instant professional look when it’s well-formatted. Professional look means professional jobs, means professional-level fees, means 2009 Mustang GT (I’m working on that last one).

The only way you gain that ease of reading in your code is to practice and stay militant about sticking to your accepted conventions. The exact conventions you adopt are not as important as acting to own them in your coding.

The idea is much like the chores that Mr. Miyagi gave to Daniel LaRusso in Karate Kid (“wax on, wax off,” remember?). Miyagi made Daniel do the chores because they helped him develop specific muscle memories, which he applied directly to his technique training. Stick to your guns, and even when you adjust conventions, your code will still read nicely.

Want some good starting points? Listen up, Daniel-san.

Indent using spaces, not tabs.
I see tab indentation a lot in both young projects, and older, established ones, and there are several problems that come with them. Tabs display differently at different screen resolutions, on different displays, on different systems, in different programs. It may look alright on your screen, and horrendous on another.

In general, a tab pushes a ton of whitespace in front of the start of your code; in the worst cases there’s more whitespace on the line than actual code! Your uber 1900×1200 screen running Eclipse with tab stylizing enabled has no problem with 10 levels nested for loops and switches, but take pity on the 1024×768 guy, especially since he’s still holding the lion’s share of screen res on the web.

I use two spaces per level in my code. This is plenty using a fixed width font for display, though some projects do prefer four.

Keep nested logic in line with code at the same level.
All that talk about spaces over tabs means nothing if you don’t actually do it. Any code editor worth its salt will have auto-indent, which pushes the cursor to match the indentation of the previous line when a newline is created. Start there, and make sure you keep track of your nesting levels (e.g. for loop, inside an if statement, inside a switch).

Place a header comment block at the very top of every code file.
I’m talking about those blocks of code you find at the top of most files in an established project. Mambo has a very good layout description. These are important for one reason: they let people know that you made this.

You should put them in every file because never know which file a person will open first. A newbie will start high, naturally, somewhere like the index. But if they’re debugging, chances are they’ll go right to the class or function that’s throwing the error.

Plus, you never where your code may end up. If someone borrows your code, most are nice enough to give you the credit. But even if they grab the whole file, someone else may eventually wander into it. And you always hope the person who does see your stuff appreciates work, and is willing/able to pay for something custom. I want that person to know how to reach me.

Bottom line: there’s nothing wrong doing everything you can to get credit, however small, for your efforts.

Avoid inline comments ( // or # ) in favor of comment blocks ( /* */ ).
It just looks better, reads easier, and is way easier to use when you have more than one line of comments at a time. I find it useful in isolated cases to make short inline comments, however most of the time I use full-on blocks, with the opening /* on one line, the closing */ on another, and the comments in between.

Starting out go for comment blocks. It sets a good precedent and will avoid the bad habit of using single line syntax for multi-line commenting. You also must use this syntax if you intend to use a documentor with your project, such as phpDocumentor.

Use camel case or underscores, but not both.
This one deals with how you assign multi-word variables and elements. With camel case you capitalize the first letter of a new word, usually with the first word lowercase (e.g. “$myVariable”). This is the standard adopted by JavaScript. Otherwise you can break apart words with an underscore character (e.g. “$my_variable”). The choice is completely personal, neither is better than the other. Camel case saves an extra character between each word, making your total variable shorter, while underscores are typically easier to read.

Again the case can be made for both in different situations; some developers use underscores in the database tables / fields, and camel case in variables. However establishing standards is hard enough without using different ones in different circumstances. Pick one and go.

Stay standard with spacing and newlines around parentheses ( ), brackets [ ], and braces { }.
This is the biggie, which is why I saved it for last. What you decide to do with the wrapper symbols will have the most impact on your code’s overall legibility. Parentheses go around evaluation statements (e.g. “( (1 + 2) * (9 / 3) )”), function calls (e.g. “myFunction($argument)”), and control structures (e.g. “if ((condition1) || (condition2)) “). Brackets get used most often in arrays (e.g. “$myArray[$key1][$key2] = $value;”). Braces are the walls of your logic nesting, wrapping classes, functions, and nearly every control structure.

Personally, I use spaces around parentheses and braces, because they often contain complex logic. Brackets often hold nothing more than a key, so they’re not as necessary. The opening brace of a class/function/whatever stays on the same line as the starting code (e.g. “myFunction() {“), while the closing one will get its own line and match indentation with up with the opening brace (see tabs and nested logic above).

The goal here is to use whitespace to adequately pad your code for easy reading, while not making it overly elongated. I avoid placing the opening brace on its own line because the code just gets crazy long, making for lots of scrolling. phpBB elected this style, but as their own standards state, “This one is a bit of a holy war.” The basics of this rule can be expanded to include all spacing around everything, such as equal signs, commas, and mathematical symbols.

That should be more than enough to get you started. For more ideas, refer to the project links I provided at the start, and just poke around other people’s code.