Archive for July 2008

PHP Women Best Practice Contest Posts

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’ »

ElePHPant!!

It's here!

Are we still arguing the merits of code comments?

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.

[Net Perspective Cross Post] Time is Money: Save Time With Automation And Phing

(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...

PHP 5.3 and Closures

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.

Updates

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.