2006 February

Note: LAMP Isn’t About Perl or Python

I hate to be the bad guy here, but the 'P' in the LAMP stack is about PHP.

I'm not making this up. The Wikipedia entry for the LAMP software bundle points back to the article that coined the term, and the author there clearly states that LAMP stands for Linux + Apache + MySQL + PHP.

Anyone else writing tutorial articles, please make note of this. Perl and Python understandably want to hang out with the cool kids, but those languages are LAMP afterthoughts latching onto the 'P' in LAMP like a puppy dry-humping PHP's leg.

I'm not saying that any one language is better than another, but I just can't stand reading articles that define LAMP as an acronym that includes or originally included those other 'P' languages.

Speaking of acronyms, when is the LAMR software stack acronym going to catch on?

Point, Counterpoint

While most of the comments on my "Walk the Walk" post have been very positive, Scott Johnson wasn't convinced that my points regarding discipline, particularly when working alone, were valid.

Be sure to listen to one of his latest podcasts for his point of view on when it's okay bend the "rules" that I suggested yesterday.

If you're not a regular podcast listener, consider making an exception in this case. Scott has a viewpoint that's worth hearing. It's a little over twelve minutes long, and a good listen.

What do you think?

Walk the Walk Before Talking the Talk

If developers think back (in some cases, WAY back), we can all remember a time when we knew very little about programming. Some will declare that there was never such a time for them, but they've just killed enough brain cells that they can't rememeber.

A question that eventually comes up for programmers who stick with it long enough is: Am I an expert yet? Do I have the chops to throw down with The Big Kids?

In some professions, such as the acting biz (where I came from before I started programming), you can fake it. You don't have to be an expert if you can just act like an expert long enough for a few people to believe you. Halfway decent actors will often become decent actors just by acting like decent actors. After all, they're practicing the craft in pretending to know the craft.

It doesn't work that way in professional development; You've either got the chops to call yourself a pro, or you don't. And more importantly, you either behave like a pro, or you don't. You can't just claim to be a professional software developer, and in the act of making that claim, become one.

I was reminded of my thoughts along these lines today after reading Ian Kallan and J. Scott Johnson's discussion regarding PHP Best Practices.

What professionalism boils down to in software development (and acting, for that matter) is one thing: discipline.

That's it, and that's all.

Thing is, the "that's it" of discipline covers a hell of a lot of ground. To name a few things:

• You must be disciplined enough to write good code. PHP, Perl and others are flexible enough to permit developers to write bad (or in some cases, really bad) code that still functions ... but a pro knows that there's rarely, if ever, a benefit to banging out crap just because it's permitted by the language. Quit blaming the tools. PHP isn't responsible for bad PHP code -- people using PHP are responsible for bad PHP code.
• You must be disciplined enough to write well-documented code. Yes, functionality counts, but if you're hit by a bus (or trampled by your fan club at an ego-rally) tomorrow, someone else has to take over your stuff and make sense out of it. For a pro, documentation isn't grunt work left to the community, or the peons. The pro just does it because it's what pros do.
• You must be disciplined enough to use source control. You don't talk about using it, or bitch about having to use it, you just do it. If you're spending a lot of time constantly fighting Subversion or CVS, and you think you're a pro, you probably need to think again. Source control is as natural to a pro developer as typing with all ten fingers. Get it figured out and adjust to the version-controlled world view if you want to be considered a pro.
• You must be disciplined enough to write unit tests. Pros realize that they're not perfect, and that their code should be tested properly before being rolled out. Bugs should have unit tests written for them to reproduce the bug so that you know when they're fixed, and as your collection of unit tests grows, you'll know that they stay fixed. Most pros don't refer to those who "get it" in regard to unit testing as freaks.
• You must be disciplined enough to write code with error reporting (by whatever name your language of choice calls it) cranked to the max. "use strict", "error_reporting(E_STRICT)" on PHP5 or "error_reporting(E_ALL)" on PHP4, whatever: these modes of development weren't created to annoy you, they were created to save your ass and hopefully help you evolve into a better developer. Writing new code under something as sloppy as "error_reporting(E_ALL ^ E_NOTICE)" should be an absolute last resort.
• You must be disciplined enough to be disciplined even if you're the only one working on a project. After all, we all hope that our next brainchild will either gain a cult following in the open source community, or drum up a truckload of cash via investment or acquisition. At the very least, prepare for the possibility that another developer will join you on a project and may expect some process to be in place. Don't fall into the trap of having an investor pass on your project because you chose not to be disciplined in your development. It ain't 1999 anymore: investors these days actually have real studs at their disposal to conduct due diligence, and word will get back to VCs and the like if your codebase and development habits are unprofessional.

Of course, there are a lot of other things that define a pro, but they all come back to discipline.

The other key ingredient of a professional developer? Humility.

That's right -- know when to say "I don't know." It's okay to say it more often than you may think. No one's expected to know everything.

Recognize that your peers and co-workers may have something valuable to contribute -- don't be afraid of them. Remember that it's all a learning process, and admitting mistakes and learning from them is more well regarded than pointing fingers at others and never fessing up to writing code that is bad, buggy, terminally broken, or incapable of handling even minor degrees of scale without a room full of hardware to run it.

The most professional developers I know -- the guys who really know what they're doing -- happen to be the ones who do the least amount of strutting around shooting off to the masses about how professional they are. Funny how that is.

To tie this all back into the discussion at hand, I'll say:

Ian, you sound like an excellent developer. Haven't had the chance to meet you yet, but I look forward to the day we eventually do meet. Take a look at SimpleTest as well as PHPUnit2 and plain 'ol .phpt -- I've found SimpleTest to be invaluable in the Feedster frontend re-write. Also, in your framework exploration, be sure to check out SOLAR; it's very well done, and E_STRICT compliant.

Also, I don't think it's necessary for any of us PHP developers to define Best Practices -- after all, the basics of Best Practices should apply to any language. Shelves full of books have been written on the subject; we shouldn't have to re-define it. Those who want to practice Best Practices will take the time to read that stuff and apply it to PHP development.

Since some will consider this post to be an arrogant one, I'll be the first to tell you that I am faking it. I'm a New York University-trained actor who's a "crossover guy" -- I started programming freelance when I didn't want to wait tables in Los Angeles.

I have never had formal development training, and I lieu of such training, I have devoured books like Code Complete, Rapid Development and Software Requirements. Only within the past two years have I added version control to my daily routine, and I finally got around to adding unit testing to the mix regularly about six months ago.

Becoming a true pro is an evolutionary process, and even though I've been developing since 1995 and using PHP(/FI) since 1997's 2.0b6, I've still got a long way to go and a lot more to learn.

Until I get there, I'm doing what actors do: "living the role" of a professional developer and focusing on walking the walk as closely as possible. I hope that what comes out of each day of refining my "performance" as a pro results in incrementally better code. Take stock at the end of each day, and try to improve the walk the next day.

Feedster Gains Some Killersoft

As some may know, and some may not -- but I'm pleased to formally announce* that I recently joined Feedster.com as a Senior Software Engineer.

In doing so, I inherited a lot of legacy PHP4 code, a mishmash of procedural code, third party OOP bits, and an instance or two of OOP attempts that shouldn't have been. A bit of a mess, in other words.

Like many start-ups, the original Feedster code (the PHP code, at least) was done quickly, with the focus being on functionality rather than cleanliness. With any start-up, the initial goal is survival, and now that Feedster is into its third year (at least on the calendar), the original code did what it needed to do, and did it well enough that Feedster is still a viable company.

However, every codebase has to grow up or die eventually, and in the case of Feedster, both have happened. The original code has been purged, and I've re-written (or am re-writing) all of Feedster's PHP code from scratch in PHP5.

Now that the new Feedster.com website has rolled out phase one of a multi-phase release, I figure it's time to dust off the 'ol blog and write about some of my experiences in writing an enterprise web application that really scales in PHP5.

It ain't your big brother's Feedster anymore, and I'll share what I can of what's new under the hood.

Note: Feedster didn't buy Killersoft or anything like that ... They just convinced me to hang up the contractor hat for awhile. My side projects like Pearified.com will march onward ... probably more steadily now that the paycheck is steadier.

* Why'd it take so long to announce? Well, I've been busy -- rewrote all of Feedster.com's front-facing code in PHP5 in two months. Sorry about the delayed announcement.

Blog Overhaul In Progress

I've switched to WordPress from Serendipity for a variety of reasons. Those of you who get my feed via Planet PHP, sorry about the double-posting if that's what winds up happening. Heads up to those wanting to switch to WordPress from s9y via "import from RSS" functionality: WordPress will not follow the links in your s9y-exported RSS.

So, I'll be importing comments made to old posts as time permits.

This blog theme is also temporary -- I'm in the midst of a complete site makeover with the aid of the talented Matt Brett. So stay tuned for the next incarnation; this is just a design intermission to make the site more readable in the interim. Meanwhile, bbbrrrrryyyy brrrreeeport and all that.