php5

AWS PHP5 Libraries as svn:externals

Many of Amazon's official PHP5 libraries for Amazon Web Services are now available (unofficially) for use as Subversion svn:externals.

To add to your SVN-managed project, just do something like this:

svn propedit svn:externals library

And add:

Amazon http://killersoft.googlecode.com/svn/AWS/tags/update-2009-05-15/Amazon

This assumes, of course, that you're keeping your external libraries in a directory called "library" (many Zend Framework-based projects are laid out like this). Adjust to suit your own needs if necessary.

I'm not wild about the code layout of Amazon's official libraries. They're more verbose and cumbersome than a many other wrappers that have been created around Amazon services. However, in the end I choose to use them despite that, for one reason: they're the official libraries.

They're updated more often than any other set of PHP libraries for AWS. In fact, they're often updated on the same day that API changes are released for the underlying services. And, they're comprehensive; many AWS libraries wrap "the easy stuff" or "the commonly used" stuff, but leave you on your own if you actually need to do something non-easy or uncommon.

So, my suggestion is to use these. Hopefully having them in all in a single, easy-to-include place will make life easier for you. It has for me!

My plan for keeping these current is to create a new "update-[date]" tag whenever any of the libraries are updated, with the date of the most recently updated library as part of the directory name. Details about what's actually changed within the update tag will be documented in a README.txt file in the top level.

You can find the "ground zero" update for the AWS libraries in update-2009-05-15, browseable here.

Build a Cool App

My post yesterday struck a chord that many others were also hearing, as Andrei's post and the comments that followed it indicate.

Potential developers of new frameworks, take note: Your announcement will be followed by wholesale eyeball-rolling.

Stephan and the Stubbles folks feel that my reaction and Andrei's are somehow knee-jerk, and that if we really looked at their framework, we'd feel differently. Perhaps this is true, perhaps it's not. I can say that if I spent time browsing code for every new framework that came out, I'd never have time for anything else (what with three n00bs in the last couple of days).

What I always wonder when these things come out is: why are people pouring their talents and energies into frameworks that will probably never have a critical mass instead of building something cool with existing frameworks?

Yes, it's hard to build applications. There's all that unpleasant user interface work and design considerations to think about, and you actually need a relatively complete package before you can announce/release something. But, given the landscape of PHP frameworks, there is no less work to building the next "everybody uses it because it's so damn handy" application than there is to building the framework that everyone will eventually use.

Seriously.

Build a cool app. Forget about your own personal stamp on the framework world; you missed the boat on that one. But, if you want to make a mark, the world is wide open for new and cool applications. Pick an existing framework, start building your app, and contribute fixes back to that framework's community as you find shortcomings in your needs for your app.

OR, if you're not an application guy, and only feel comfortable with the plumbing, then pick a framework that has a shortcoming and fix that shortcoming. If you're afraid that your work will not be accepted, or that there will be too many contribution political hurdles, then pick another framework (there are plenty to choose from, after all).

We need better tools, and better applications. We DO NOT need more clean slate starts.

Rails-Free Living

As I said awhile ago, and as others have said more recently ... I feel compelled to say it again:

• Pipes (not the Yahoo! kind)
• WebMesh
• Stubbles

.... yeah. PHP will definitely never have anything unifying like Rails.

Meanwhile, I encourage you to join up with the Solar community (as I have done instead of launching my own framework) ... you'll be glad you did.

Mashery is Hiring

Mashery, the company I recently co-founded with Oren Michels, is looking to add a multi-talented PHP developer to its engineering team. The job description is below. The posting hasn't gone out widely yet, as I figure the really good people read the Planet PHP feed that picks up my posts in this category.

So, hop on this now if you're interested, before it goes out to the teeming hordes.

Stellar PHP Developer

We're looking for a kick-ass PHP developer. Someone who's done a lot, and seen even more.

Someone who's intimately familiar with PHP 5 OOP practices (we require PHP 5 E_STRICT clean code internally). Someone who doesn't necessarily love writing unit tests, but loves what unit tests provide. Someone who strives to produce better code every day, and who's open to new ways of doing just that.

Our ideal candidate will be someone familiar with the pros and cons of SOAP vs XML-RPC vs REST. Someone who knows what JSON stands for, and why it's cool. Someone who's a Savant, not a Smarty. Someone who cares about documenting their source carefully, and believes in decent commit messages (at least 85% of the time).

We think that a good fit for our team is someone who can (and does) compile their own builds of PHP for local development.

We're looking for more than just a code guru, though. We're looking for someone who can work well with others. Someone who understands that "perfect" can't get in the way of "pretty damn good." Someone who can accept suggestions for improvements from team members without getting defensive. Someone who understands that we're a business--so we have to ship to generate revenue.

Our person is someone who realizes that what goes into production must fail gracefully on the rare occasions that it fails.

Our person is also very likely an open source contributor -- someone who may already know the PHP community people we have on the team now.

Our person is someone well versed in a wide variety of tools and techniques, but is someone who's had experience with Prototype and script.aculo.us, and has spent some time basking in the rays of the Solar PHP 5 framework. Our person probably even has some C and/or Python chops stashed in the closet.

Finally, our person is someone who lives in the San Francisco Bay Area.

Are you our someone?

If so -- and you know who you are -- introduce yourself to us at jobs [@] mashery dot com.

Pro::PHP Podcast Follow-up

Just a quick post to follow-up on my enjoyable chat with Marcus Whitney last Friday on the php|architect Pro::PHP Podcast.

• The pops and occasional gaps in my responses were a result of my headset (I think). As a podcast and VoIP rookie, I'd just purchased the headset the day before the interview. Sorry about that; I think the issues were on my end, not php|a's.
• One more shout-out to Paul M. Jones for Savant3, as well as Solar. We use Savant3 for the Feedster templating engine, and it's truly a great templating package. Simple, elegant, easy. Highly recommended. While we didn't use Solar in Feedster's rewrite, several of the design decisions we made in the quickie frontend controller system we implemented were influenced by Paul's work on Solar.
• A huge shout-out to Greg Beaver for his work on PEAR 1.4 and PEAR channels. In the midst of our lively discussion about Pearified.com, I realized listening after the fact that Marcus and I failed to mention Greg. I don't think Greg can be thanked enough for his work on PEAR. He's certainly made my life easier, and the hundreds of people who've installed packages from Pearified.com owe Greg a "thank you" as well.

Finally, thanks again to Marcus Whitney and Sean Coates for their invitation to do the interview. I appreciate the opportunity to share my experiences with PHP 5 in a demanding production environment, and always enjoy spreading the word about Pearified.com.

Thanks, guys!

No Sun-shine for Killersoft?

Like any other red-blooded, oxygen-breathing developer on Earth, I'd like a free Sun Fire T2000, please.

Yes, a roughly 9.6Ghz server would be just swell. Not just for grins, but to see how much performance I can squeeze out of my PHP5 applications. After all, like many PHP developers I shudder at the mere mention of the possibility of Java running better/faster/more than what I can get going with PHP5, and I'd like to see what kind of difference a server that is so fast it's classified as a munition by the US Government will make.

While some scary comments relating to installing PHP5 on Solaris give me pause, they do not fill me with dread.

I have also read about how Apache2 plus PHP5 with a threaded MPM is scary and ill-advised. This also doesn't scare me, as I've read that PHP5 in a FastCGI configuration is fine in a threaded environment. Plus, I hear that lighty plus PHP5 under FastCGI will smoke Apache2 any day, so I'm interested giving that a go as well.

Finally, I know squat about Solaris (any version), having done the last nine years of PHP development on BSD and Linux machines. I'd like to learn more about Solaris, and what better way than with a free Niagra? Perhaps Solaris 10 will make me a switcher from mixture of Mac OS X Server, Debian and Red Hat that I've been running my own sites and client sites on recently.

With these goals in mind, and the confidence that I fit the profile of someone eligible for the offer (I'm blogging this, right?), I filled out the application on the Sun website, which asks just a couple of questions. Here are the questions, and how I answered them in bold.

• Do you have a Solaris 10 application to run on the Sun Fire T2000? (Yes/No)
• Is your application multi-threaded with low floating-point content? (Yes/No)
• Have you read the Try and Buy Agreement? (Yes/No)
• Do you accept the Try and Buy Agreement? (Yes/No)
• May Sun contact you with general product and service information? (Yes/No)

All of this is true, of course--I don't have any Solaris 10-specific applications to run on the Sun Fire T2000. However, I've got a significant number of PHP applications that I've built up over the years that currently run on any system I've been able to get my hands on that run Apache and PHP. So ... I think "no" is the correct answer to the first question, as I have no applications that require Solaris 10 (thus making them "Solaris 10 applications") to run.

Unfortunately, this honest assessment of my situation resulted in this message:

Thank you for your interest in the Sun Fire T2000 Server. Your application is under consideration, but your 'no' responses to our qualification questions require us to review it further. A Sun sales representative will contact you to further discuss your requirements.

Ouch. Perhaps I should have fibbed? The questionnaire claims to be a three-parter, and I thought maybe I'd have a chance to explain myself in part two or three. But no, the swift boot came down instead.

I hope this doesn't squash by dreams of the fastest-running PHP applications on the planet, but we'll see. Stay tuned.

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.