Tower Of Power

PHP 4's end-of-life is today.

With that I bid adieu to the half-assed OOP support and general primitive nature of the platform.

However I cannot be so callous as my first forays into PHP were with 4.0 releases...

Now the question is how much faster will the dumping of PHP 4 (and 5.0/5.1) be and the adoption of PHP 5.2? Granted most major services are already at the latest/later versions of PHP 5.2 (5.2.5 seems to be most common, but quite a few have 5.2.6 installed), I hope the prevalence extends even further as I'm writing an app that requires 5.2.3+ (damn you Doctrine and your shiny ways!)...

Often times when doing web development one has the need to categorize things. And not only basic categorization, n-deep hierarchical categorization. I've already discussed storage and retrieval of such data, but there comes a time when one needs to display this information.

Sometimes people build systems to only account for their current requirements. If the software calls for only 2 levels of categorization (Parent and Child only), a simple nested for loop will suffice. However, software requirements change and you'll soon find yourself up shit creek without a paddle if you need to support 3 or 4 levels of nesting.

For those of us who have formal computer science training, the answer comes rather quickly. To those who's training is less formal (most web developers I meet have practical training, not formal), I'll help you out: Tree Traversals (or if you are completely lost, Recursion). If you know absolutely nothing about recursion, I would suggest you familiarize yourself now. A recent, easy to read example can be found here.

Continue reading ‘Displaying N-Deep Trees (Remember Your Algorithms Course?)’ »

I made a few posts to the PHPWomen.org Article Competition and felt I should share them here.

I wrote three entries:

1. Flash Your Errors: It's Illegal In 28 States! on combining flash messages and error reporting
2. David Copperfield Wasn't This __magical: __autoload() is Awesome! on using the __autoload functions and PEAR style namespacing
3. Path Secrets Of The Most Awesome on making your path operations indestructible across operating systems.

Continue reading ‘PHP Women Best Practice Contest Posts’ »

It's here!

So I see a link on reddit today to an article entitled No, your code is not so great that it doesn’t need comments. The article site was down so I started reading the comments and was very disheartened to see an actual debate over whether pro developers put comments in or left them out.

For example, we have this from "ckwop":

I find that the number of comments a developer puts in to their code is inversely proportional to the amount of experience they have.

I believe the reason for this is two fold.

Firstly, as you become more experienced you become fluent in reading code. You're not expending mental energy trying to grok the syntax and the flow of the program. It just comes naturally.

Secondly, as you become more experienced, you learn how to layout you code in a more readable way. You name classes and variables such that the code is, for the most part, self-documenting.

I don't quite know how to describe the absolute FAIL in this particular statement. While he does go on to say:

The only comments left in programs written by experienced programmers are comments which document decisions. Why one approach was taken over another, for example.

It still doesn't redeem himself. Comments like his betray a staggering amount of arrogance that poisons the mind of developers and turn otherwise good programmers into spaghetti-spewing monsters that take on government jobs so it'll take longer for them to get fired.

This person (and sadly many others) assert that well written code is intuitive. These people are the same people that try and tell me Python is perfect for everything and I shouldn't work in any other language unless I'm working in the embedded space, in which case I should write myself a Python-To-Assembly script prefixed with the cute little "py".

Comments are meant to provide a quick overview of code flow and reasoning behind particular decisions. Comments should be clear and concise and allow a developer to spend 5 minutes figuring out where in the code base they need to be to fix the rounding issue rather than spending 40 minutes tracing program flow.

Comments are meant to help developers who either have limited experience in a language, who are new to a language, or who haven't used a particular language in quite some time. Your Haskell code may be clear and simple to you, but I can't read a single damned line of it: comment it!

Comments are meant for the developer who puts down a project to focus on something else for a few months only to pick the original code back up. The sign of a mature developer is one who accepts the fact that when he puts down code for a few days, he forgets the "why". No developer is immune to this, and anyone that tries to tell you they are different is not worth the time you wasted listening to them.

So, to "ckwop" and all the other developers out there that think code should speak for itself I have a few things to say:

• If code could speak for itself, it wouldn't be called code
• You will not remember your design decisions, and in some cases even code flow, after a month
• Comments make it much easier for me to debug when your company hires me to fix your failures both as a programmer and as a human being.

In closing: The debate has long been over, comment your fucking code.

(Originally posted on my company's blog)

I've been talking a lot about automation as of late and posted a generic, overload broad view of the tools and utilities I use here at Net Perspective. However, I wanted to go into detail about my real world uses of a particular tool, Phing.

In my time with Net Perspective (and our previous existence), I've completely dreaded live deployment days, and yes they were full days. An entire day dedicated to waiting for FTP to finish uploads, chmod'ing directories (because Plesk hates me), setting up databases, and testing. All of this despite the fact that we did periodic staging deployments on the same server!

I guess a lot of thanks goes out to Pro PHP: Patterns, Frameworks, Testing, and More by Kevin McArthur. While I found this book to feel more like a Zend Framework tutorial, it did provide a brief introduction to 2 utilities I use here at work, only one of which we care about at the moment: Phing.

Phing is a build environment based on Ant (familiar to those in Java world). For those not familiar, Phing uses XML based build files with tags representing tasks and task groupings. At Net Perspective, I use Phing build scripts for everything from packaging up tarballs of utilities we've published (simple jQuery plug-ins, etc.) to automating the live deployment of client sites. The latter I'm particularly happy with as my deployment time has been reduced from a few hours between 10 minutes max (for a brand new, fresh upload) and about 30 seconds (for an update).

Basic Phing usage is pretty self explanatory, however you may wish to search Google for Phing tutorials, or read my post I linked above.

Further more, my build scripts make use of custom command executions requiring both the execution environment to be *NIX based and for you to read this article on using rsync over ssh without a password (using pre-shared keys).

Read the rest of my post here...

I'm fairly excited because as of only a week or so ago I found the closures rfc, and not only did I find that the rfc has a working patch, apparently it's already in PHP 5.3.

You see, apparently it's not good enough that we get name spaces and late static binding, oh no, we get closures too!

I downloaded the Win32 snapshot from PHP snapshots page and indeed, closure support was included.

 
<?php
$closure = function ($args) use ($global) { /*Body*/ };
?>
 

According to the rfc, one must manually define external variables used within a function, however in my own tests you can still use the global keyword. The difference between the two is the use statement preserves the value of $global at creation and the global keyword would work as you would expect it to with a normal function. For example:

 
<?php
$global = "Global Variable";
 
$closureUse = function ($arg) use ($global) { echo $global . " - " . $arg; };
$closureGlobal = function ($arg) { global $global; echo $global . " - " . $arg; };
 
echo "Basic Closure Tests\n";
echo "-------------------\n\n";
 
echo "\$closureUse('test'): ";
$closureUse('test');
echo "\n";
 
echo "\$closureGlobal('test'): ";
$closureGlobal('test');
echo "\n";
 
echo "\n";
echo "Global Closure Tests\n";
echo "--------------------\n\n";
 
$global = "Global Variable (Changed)";
 
echo "\$closureUse('test') (changed \$global): ";
$closureUse('test');
echo "\n";
 
echo "\$closureGlobal('test') (changed \$global): ";
$closureGlobal('test');
echo "\n";
?>
 

Would output:

 
Basic Closure Tests
-------------------
 
$closureUse('test'): Global Variable - test
$closureGlobal('test'): Global Variable - test
 
Global Closure Tests
--------------------
 
$closureUse('test') (changed $global): Global Variable - test
$closureGlobal('test') (changed $global): Global Variable (Changed) - test
 

You can, as well, return references with a closure by putting the & between the function keyword and the parenthesis.

 
<?php
$closureReturnsReference = function & ($args) use ($global) { /*Body*/ };
?>
 

Just one of many shiny fancy things to look forward to in PHP 5.3.

Edit 7/23/2008:

I should mention to the people that trashed my examples on reddit, I'm sorry for assuming you knew what closures were and the the real world uses of them. I will try to refrain from giving a concise example of how a new language feature interacts with existing features and conventions, especially in PHP where things are a bit disorganized.

I apologize about the month without updates. Our business manager and lead designer ("Director of Operations" and "Creative Director") both had to go to the hospital at about the same time and the shortest stay was almost 2 weeks. They both pulled through just fine and everything is back to normal.

I hope to be back sometime later this week with some visible signs of awesomeness on a side project of mine.

In the mean time I've been playing with Flex Builder 3 (hooray for free Educational licenses) and while it's cool, so far the documentation is hindering my development efforts. I have a project planned where I intend to have an AIR client and am evaluating using Flex instead of HTML+JavaScript. We'll see how far that goes.

And finally I've been playing around with FriendFeed and have an account setup. I, for one, welcome our new stalker overlords.

One of the guiding principles I have lived by the came from my middle school swimming coach. He told us:

Don't do more work than you have to.

On first glance, it doesn't seem to be very good advice. However when you realize that what he was getting at was we shouldn't waste energy on a poor stroke, the quote takes on a much deeper and more profound meaning. It is this principle that takes a good developer and makes him great.

Profile of a Good Developer

Good developers are almost a dime a dozen. Walk in to any computer science course or web development shop and you'll find that the majority, if not all, are good developers.

These "good" developers can sit down and work through an object oriented architecture, they can construct their SQL queries, and can write an application that just works.

A "good" developer checks in his source code at the proper times, he comments his code as well as could be expected, and you can usually be guaranteed his code will compile and execute with very little fuss.

Profile of a GREAT Developer

What separates the great developers from the good developers is LAZINESS! You will find that the good developers, while producing clean, working code, operate much slower than great developers, and for the reason that separates the good from the great.

Good developers are set in their ways of just manually working with everything. A good developer handles deployment with FTP, and updates database structure by hand. In the end, the good developer ends up wasting time doing menial tasks. FTP alone can kill up to 30 minutes of your day. Good developers are very set in their ways and do not like new things introduced.

Meanwhile GREAT developers HATE menial tasks. They abhor having to drop into the console every time they wish to test or deploy, and loath dropping into the database to manually update structure. So these GREAT developers begin to write scripts and integrate all their tools to reduce their menial overhead as much as possible.

The GREAT developer is lazy because they do not want to do things themselves, so they spend 20 minutes automating their tasks so they'll never deal with it again. And when you think about it, when you could spend 20 minutes once writing automated deploy scripts but instead spend 20 minutes every deploy in FTP, you are doing more work than you have to.

What Does This Mean For Me?

All of us developers should strive to be as lazy as possible. Do you have a task you have to do more than 3 times total? Write a script or a build task for it. Do you spend a lot of time testing features? Automate your testing. And if possible, integrate the systems so you never even have to run those scripts manually, reducing user intervention to one step.

I know I try to be as lazy as possible, do you?

Edit 6/10/2008:

I feel I should make sure everyone knows that I am to an extent being facetious with the word "laziness" but I'm being completely serious on the "don't do more work than you have to." While a good developer can handle long, arduous tasks that are prone to human error, a great developer avoids them in the first place.

I recently had fun with an all-to-common issue with SQL driven websites: hierarchical data. For those who don't like big words, think trees. Other people have already discussed storage methods, and I would actually highly suggest you read the writeup if you haven't already.

While it is fairly straightforward to deal with, in our case we use HTML_QuickForm to handle our forms and are using QuickForm's hierselect to select a category.

The issue starts showing its face in 2 distinct areas: (1) the client is not yet sure how deep they need their categories to go, and (2) the hierselect requires a very specific format of data to be passed in.

Continue reading ‘Hierarchical Data With PHP and MySQL’ »