I got such a great response from my previous “worst practices” post (thanks for all the great feedback!) I thought I’d forge on ahead with a few more to add to the list. A few pointed out that most of the recommendations from the first post could apply to just about any language out there – that’s great news to me. That tells me that PHP developers are just like any other developer out there, regardless of the language they “speak”.

On to the next round! Here’s four more “worst practices” that, if you care about being any sort of good developer you’ll avoid like the plague.

• Speed is King (except when it’s not)
  Everyone wants their applications to perform well. It’s a well known fact that customers are wanting more and more each second and putting up with delays in a web app is almost unacceptable. They want it all and they want it now. Easy, right? All you have to do is make your apps work the best they can and do it as fast as possible. But which way is the fastest? We’re talking speed here, and you should do all you can to get those load times down and the customer satisfaction up. Optimize the hell out of those methods and cache whatever you can. Good planning (see “Unplanification“) from the start can make these kinds of decisions easy and smooth out the wrinkles that might pop up. Be careful, though…keep optimization in mind from the start, but don’t make every decision about shaving those seconds off. This can lead to some pretty bad code if you’re not careful. Good structure and standards should never be ousted by over-optimization.

  While I’m on the topic, there’s also another so called “silver bullet” that a lot of blogs, tutorials and books set up as a good option for making your site run faster: micro-optimizations. I’m sorry, but most of the things they suggest are really only doing one thing – giving you a false sense that your application will get a huge speed jump from using them. Granted, there are special cases where shaving one billionth of a second off the execution time can be helpful, but in most applications, that’s just not that helpful. If you’re serious about optimizing your applications, look into things like memcache or other caching tools so you don’t have to go all the way out to those databases/resources and pull down that data each time. Your application will thank you for it.

• Be a Hermit
  Want a quick way to lose interest in a language? Don’t talk to anyone else that uses it. I know, I know – there’s lots of developers out there that have gotten very good at their language of choice, but there comes a point when they come across something even they don’t know. They get stuck on it for hours trying to figure out why changing the value of this one variable is breaking everything. What’re is options? He could keep trying, working for hours, even days on the issue before figuring it out. He could also take a look at the manual and see it shines any light on the problem – but that’s pretty limited. What’s the next step? Something that, sadly, a lot of developers just don’t do – ask!

  I’m not even talking about real-time communication here, this can even be just hopping on a forum and posting your question. Remember, as much as you’d like to think it, you don’t know everything. There’s going to be issues you come across (sometimes even bugs in PHP itself) that someone else out there has come across in the past. The collective knowledge of the PHP community is so vast that, given the right place and time, I’d dare say that just about any question could be answered. There’s even people out there that are happy to help you figure out the answer even if they haven’t come across it before (bless them)! Trust me, you can only benefit from having more than one developer poking and prodding your code into submission. Forums are just one teeny tiny slice of the pie when it comes to resources for help. There’s even *gasp* “face-to-face” things like IRC, local user groups and conferences where you can hit up other developers for ideas and suggestions. Don’t limit yourself! Use the mass brain power of the community to your advantage….after all, they’ll do the same!

• Slight the Newb
  When was the last time you talked with someone just starting out with PHP? Last week? Last month? How did you treat them? Were you helpful and did you take the time to look at their application before slapping them with a big, fat RTFM about their problem. Don’t forget – you were a newbie once too.

  Have I made you feel a little guilty yet? If not, then you’re a better person than I. I’m guilty of this just as much as a lot of developers out there are. We forget that there was a point in time when we didn’t understand PHP’s object model or some of us even know how to use an array (yup, they’re out there). Some of us have come a long way since those early days of the endless “hack, reload, hack, reload, hack, reload” cycle spent learning the inner workings of that latest bit of code we grabbed from freshmeat. Those long sessions tend to blur together into one big fading memory of our early times with PHP and that’s where we get in trouble. We forget how much hard work and how many lines of code we’ve put in to know what we know. It doesn’t matter how far along you are in the process of learning PHP, I’m willing to bet there’s someone that knows less (“I just finished my first ‘hello world’ script!). I’m begging with you – pleading to you – that you don’t forget your early days. Remember how hard it was for you to wrap our head around that one feature, and be willing to help when someone comes looking for help.

  Give help when you can – a language is only as good as the people that make up the lifeblood of its workings and providing a well-lit path to the answer someone needs is an excellent start. This is the other side of “Be a Hermit” – you can be the one that’s there to provide the exact answer someone needs if you just take the time and work with them. Trust me, they (and the community) will thank you for making their code a better place for data to live.

• Trust the Everyuser
  You’ve built an amazing application. Every feature is where it should be and everything has been tested to the last little drop. You’re caching things right (see “Speed is King”) and the server is humming along nicely. You’re ready to sit back and wait for the fame and fortune to come rolling in except…wait…where’s all your data? It was here just a second ago. Panic rolls over you as you frantically search for a backup or something that can help you recover from this mess. It’s too late, though – they’ve gotten in through a exploit in your code you never saw coming and have wiped the database clean. You’re hosed.

  At this point it doesn’t matter what the actual problem was, the real issue here is that, at some point in your code, you trusted someone who either A) wasn’t you or B) wasn’t someone who works on the code. That’s right – you forgot to filter, and this is one of the cardinal sins of web development. Think managing user input (filter in, filter out) is too much trouble? Tell that to the guy that just lost all his data in about 5 seconds. There’s even things in PHP that make it easier! There’s no excuse for filtering the things that users hand off to your system to be parsed. Depending on the data, it can even be something as simple as a filter_var or a regular expression check to be sure the format’s correct. Trust me, whatever time you spend adding in input variable filtering and escaping functions for the resulting output, the happier you’ll be. It might seem like a lot of trouble on the front end, but it’d all be worth it when that random user decides to run a SQL injection on one of your form fields.

  We’d all like to think that our users will all play nice and that there’ll won’t be a need for any kind of data protection. Back in reality some users are out for just one thing – your data. Don’t give them the satisfaction. Protect that data the best that you know how. And if you don’t know how, ask (“Be a Hermit”)!

So, there you have it – four more horrible things you can do if you’d like to crush any of your PHP hopes and dreams into the dust. Hopefully, combined with the previous list, these can provide the opposite – a handy reference of things to push you to be a better developer and to become a strong member of the PHP community as a whole. Trust me, the language is fun but the people in the community, they’re…er…funner!

We’ve all seen design patterns and heard about best practices in PHP development, but there’s a darker, more sinister side to the “practices” examples that is usually just the stuff of folklore and legend. Many a PHP developer brushes off their existence with a quick “oh, I’d never do that…” or “I’ve seen other people’s code like that…” What am I talking about? Why, only the very things that threaten to tear apart the language and the community as a whole! That’s right – PHP Worst Practices – and they’ll sneak into your development as quick as you can bat an eye. I’m here as a guide through some of these. The way I see it, if I can share as many as I can, you can see them coming a mile away and code around them.

So let’s get on with the list – the sooner the better:

• Beware the Outsiders
  This practice (“Not Invented Here”) can be particularly deadly if you don’t keep an eye out. As developers, we’re tempted to have a “I can write it better” mentality. Don’t try to deny it – you’ve looked at an application and thought it just the same as the rest of us. It’s even worse when you’re starting something new. There’s fresh clean horizion out there and who would want to muddle it with someone else’s code (SEC)? Our code would be more pristine (and probably work better) if you take out an unknown like that – our would it? Stop and think for a second about this one. Sure, you could cobble together your own library to add that feature and yes, it might integrate excellently with your code, but what does that gain you? One of the points of Open Source development is to share your knowledge with the rest of the community. One way to do this is via code – posting your library so other can use it and *gasp* contribute to it for future versions. Its this shared knowledge that you’ll miss out on if you block SEC from your application. Sure, it’s not all good code, but there are some great sources out there (PEAR, PHPClasses, Freshmeat) to pick up just what you need. Plus, it’s win-win…you get a quick solution to your issue and you don’t have to maintain that library in the future.
• Unplanification
  That’s right, I said unplainification. If you’ve ever charged into a project full force without taking even a single second to think about its structure, you know where I’m coming from. It’s that sinking feeling you get in the pit of your stomach when you’re half way through the second library and you realize there’s a much better way to do things. This revelation is usually followed by a whispering in your ear….”I told you so.” This would be the combined voices of everyone in your past that tried to teach you the mantra: “Plan First, Code Later”. Sure, you can get away without planning for the small stuff – test scripts, little cheesy two-page websites – but when you start talking web applications a plan is a must. It doesn’t have to be much, even some scribbles on the back of a napkin counts. Just something to say you’ve thought through the structure and pieces that’ll make up the application. Obviously, larger applications call for larger plans and it may require a team of people to work on the resulting project. If you’re not familiar on how to work with a development team, you’d do well to read up on it a bit. There’s nothing quite like a good development team firing on all cylinders and drawing up a unified plan for the development to come. Planning is a good thing and, while it might seem to be a hassle when all you want to do is code, do yourself a favor and take a deep breath and plan before a single line of code is written.
• The Documentation Wasteland
  We’re all guilty of it. If you say you’re not, be prepared to be called a liar and to have ASP.NET stickers applied all over you and your computer. Scripting is just so much damn fun that writing the code is what it’s all about – make it work and make it awesome. Isn’t that what really matters in software development? I hate to break it to you, but that’s only half the story…really about three-fourths. If you’re writing your code without any sort of documentation, you’re dooming you and possibly future maintainers of the code into many a pointless search to try to figure out why method a() returns two completely different value types depending on which parameters it’s given. Sure, you can trace through the code and figure out what’s getting executed, but wouldn’t the world be a happier place if all you had to do was read a description. Just a few little lines of comments (like something phpDocumentor would parse) and the problem is solved. Sure, it’s not going to provide every step the data takes, but it lets you know the “why” instead of just the “how” the code gives you. Automatic documentation generation is a great step in the right direction (and dead simple too) as well as external documentation sources like wikis or standards documents. Do yourself a favor – as you write your code, add some comments and write up some documentation. You’d be surprised how often you’ll find yourself referring to it once it’s reliable.
• Free Your Mind
  This one goes hand in hand with “Beware the Outsiders” but takes a slightly different turn. It’s too easy to get used to what you’re doing and focus in on just those technologies. You get used to the way your code works and you think that that’s the only way it can work. Except you’re wrong. You, as a developer, know that there’s always more than one way to solve a problem. Take that and carry it up one level and think about all of the technology that PHP can work with. Your LDAP authentication might be working pretty well for what you’re working on, but what if there’s another component out there that could make it even easier (and more customizable!) Don’t let yourself get fooled into thinking that you have to stick with “your way” to do things just because that’s how it’s “always been done”. There’s too much awesome PHP code out there to be so narrow-minded. There’s even frameworks like the Zend Framework or CakePHP to give you some great ideas on component and framework structure. Leave the confines of your cozy IDE and version control repository and look around – there’s plenty of great code out there to learn from!

These are just a few…there’s many, many (many!) more out there that could be added to this list to avoid. We’ll always be tempted as developers to slip into these worst practices when its the easy way out. You can your code deserve better, though. Focus on the best practices, the right ways to do things and make them maintainable and easier to work with overall.

There’s something that most people’s parents taught them from the beginning – to share. You’re supposed to share your toys and be nice to the other kids and they’ll share with you. So, you’re all grown up now – do you still share?

I’m talking about knowledge in this case (of course. though sharing toys could be fun too) and how you share it with those around you. As a developer, you have two charges in your professional life – to make the best damn software you can with the time given you and to spread what you’ve learned through out the rest of the community. No one person can know everything – sure, lots try – and so they have to stand on the shoulders of giants and glean what they can from those around them. Thankfully, the web is flowing over with tutorials, articles and comments in general about the development methods and languages of your choice.

I want to focus on the PHP community here – I know it best. So, what can you, a member of either the general web or PHP community do to help the cause? Here’s a few suggestions:

• Share a tutorial – just learned something awesomely cool as a part of the work you’re doing? share it! Trust me, you don’t have to be eloquent to make a good tutorial author. All you have to do is be willing to copy and paste a bit of code and explain it. No, really – it’s that easy, I promise. Post it and they will come, especially since Google Finds All. The best part about sharing knowledge is that it keeps it from dying. If you keep all the cool stuff to yourself, the community as a whole suffers. What to make the community flourish? Spread the word!
• Share the code – this one’s pretty obvious…write some code and share it with the world. This can go hand-in-hand with my first example, but doesn’t always have to. To coders, sometimes how the code all works together is more interesting than reading an article about it. They’re the ones that immediately download the source of a new, cool application just to see the pieces mesh. The comments in the code are enough for them to know what’s going on (you do comment your code, right?) and they like it that way. Put your code out there for the world to see – it doesn’t have to be perfect. In fact, it’s usually better if it isn’t…more room for contribution!
• Be a mentor – believe it or not, there’s a little bit of a mentor inside each developer out there just begging to get out. The second you switch from writing the code to showing someone else how to use it, you’re being a mentor. Most people think that mentors have to be experts in their field and know-it-alls. The real truth is that anyone – and I do mean anyone – can be a mentor. This goes hand-in-hand with the two previous points in my list and can provide the human connection between them. Write the code, write the tutorial and be there when others have questions – either via email, in-person or on something like IRC. Everyone has something to give back because everyone has different experiences. You may know the best practices for combining Oracle and PHP while another developer might know the ins and outs of your PHP-based content management system. Join forces! All of a sudden the knowledge grows and you both are learning from each other. Thankfully there’s groups like the PHP Women that have forged the way and have set up formal mentoring programs to help spread the knowledge around.
• Share yourself – Don’t feel like you’re qualified to be a mentor? Think your code isn’t quite where it needs to be to release it? You can still contribute! Trust me, there’s a lot of developers out there that can do some good works just by being there and being themselves. It takes all kinds to make up a community and not everyone can be all about the code. Yes, I know that PHP is a language and that it’s really all about the code (or is it?) but there’s plenty of room for those members of the community that focus on the community. They’re some of the glue that holds things together and can most easily be identified by keeping an eye out at conferences and other social gatherings (like your friendly neighborhood PHP user group) for the social butterflies. They know their code and they know the community – they’re just happy to bring the two together. Becoming one of these sort of people is easy…don’t try to. Just meet people, talk with them and enjoy being around them. All it takes is one “hello” and you’re on your way…

These are just four points out of a long list of ways that you can give back. There’s a huge list (maybe I’ll add another list in the future), but this’ll give you a good place to start. Don’t be afraid to put you and your code out there!

At the risk of alienating some of my readers out there…who am I kidding – most of you liked Firefly, didn’t you? Having just watched Serenity yet again and recently seeing several episodes of the canceled-before-its-time series Firefly, I noticed that there’s some similarities between it and PHP as a whole. So, here’a quick list of a few I’ve noticed – feel free to add some of your own in the comments:

• Just because it’s not the latest and greatest version, it doesn’t mean it’s not good. Sure, everyone wants to run on PHP 5.3 – we all love the thought of late static binding, namespaces and the whole list of lovely enhancements that come with this latest PHP version, but for some it’s just not a reality. Most of use are using a ship…er, code that’s been around for a while (except the fortunate enough to be doing new development each time) and has been coasting along in the land of PHP 5.2.x series. It’s not the latest model and it’s probably going to take a little doing to get up to the sort of things PHP 5.3 has to offer, but that’s not an excuse to abandon the code and not try to get as much out of it as you can. Squeeze that last boost that caching that data gives you, refactor that part of the code you just found a better method for – but don’t forget where the code came from and all that you’ve been through to make it exactly what it is
• Just because you don’t understand something, it doesn’t mean you shouldn’t embrace it. Sometimes the real power of something sits just under the surface and without really getting to know it, you might miss out. Much like the skills of a certain female in the TV/movie, only the right situation brought out the real value of her skills. There’s features in PHP that you might now be using, but don’t dismiss them just because you haven’t used them before. Sometimes there’s a hidden gem in there that you might not see unless you took the time to check it out. So you’ve been using simplexml for a while? Why not see what kind of things XMLReader can do for you. Never checked into the Standard PHP Library? You should! You might never know what you’re missing out on unless you look around and find the right PHP pieces for the right situation.
• There’s nothing stronger than a bond between those who care. Much like the crew of the Serentity, there’s nothing more powerful than people helping others when they really care about the outcome. A lone PHP developers is only as good as his own skill level. As soon as he reaches out to other developers, he interacts with a whole new skillbase and a whole world of new people. It can be posts on a forum, chatting in IRC or even attending a conference – as long as the bonds are formed, that developer has something more than they did before. Before long, they’ve made connections with other developers with other skillsets that can help to broaden their knowledge and make them stronger as developers.
• It takes all kinds to make the ‘verse go ’round. Despite what those hiring PHP developers lately want to think, there’s divisions in PHP developers in the same way there are in any other social group. Some developers focus on how the language works and adding features the entire web will enjoy. Others look at the current feature set and think of ways to to squeeze every drop of performance out of it. Still others are working their way up, trying to do their best with the code they’ve been given. PHP developers are as varied as population in general, and it’s definitely a good thing. The PHP language will only develop into something even more robust with a panel of varied developers at the helm.
• Use only what you need. Just because there’s something out there that’s shiny and looks good to use, it doesn’t mean your application really needs it. Remember, the real key to applications is the performance – that’s what the world tests it on. Don’t worry about the latest and greatest if it’d not going to help. Features shouldn’t be included if they’re not needed – they’ll only cause trouble otherwise.
• A good team is nothing without good leaders. The PHP community has some excellent “captains” at the helm – people like Cal Evans, Keith Casey, Eli White, Derick Rethans, Andrei Zmievski, Chris Shiflett and Stefan Koopmanschap have helped to shape the PHP language and community into what it is today. There’s countless others (largely ones with the CVS….er, SVN access needed to make updates to the C code that powers the language) that have made their marks on PHP to help it grow and evolve into the powerful development language that it is.

As it can be said that life imitates art, so it can be said that programming, in this case PHP development, shows the same strong points as those that flow from the mind of Joss Whedon – emphasizing the good, venturing into the unknown, the power of a human-to-human bond, diversity is good, use just what you need and, of course, a community is only as good as those who lead.

This past week I was fortunate enough to attend this year’s php|tek PHP conference up in Chicago. It was four days packed with some great PHP-related content and included two major events for the PHP community – a “standrds session” and a meeting of several core developers of the language to hash out some standing issues face-to-face. The week saw a nice blend of both sessions related directly to the language an more periphery topics like MySQL tuning, project management and version control systems.

In the midst of all of this, there was something else I saw that, I have to admit, slightly caught me off guard. See, I’ve been a part of the PHP community for years now and I’ve seen some of the good and the bad along the way. Last week I saw something that gave me hope about the community and the future of the language – I saw that PHP (and its community) is growing up.

Back when I first started out in the community, PHP wasn’t taken quite as seriously as it is now. Sure, there’s those that dismiss it as “one of those languages” that’s not ready for anything more than small sites or little jobs. The truth is, PHP is running lots of major sites out there and running them very well. A shift in perception like this is all well and good but, especially with an Open Source language like this, there needs to be the people there to back it up. Lots of the other languages have corporate backing to keep them going, but PHP is in a strange place. Zend, the company most people associate with PHP, is not a direct supporter of the PHP project. They provide resources (and some of their staff) to help work on the language, but it’s not a direct involvement as a “sponsor”. Instead, PHP relies on the strength of those in the community to support it through those good and bad times and to help it weather any major storms that might come its way.

At php|tek, through all of the sessions and after-hours activities (oh yeah, we like to party), I could still see people stepping up to fill in spots that were needed. You could see it in the leadership of the core development team, in the community support both from countries here in the U.S. and overseas and, most importantly, in the words and actions of long-time members of the community willing to take the steps needed to get the community flowing. I’ve seen these people come from humbler beginnings – some joining the community after me – to become a strong foundation for the rest of the group to build on.

PHP’s future is bright with this solid crew at the helm. To all of you who have made and are making PHP and its community what it is today, I thank you.

In one of my previous posts I mentioned a little pet project I’ve been working on. I had an initial version out the door and things were working pretty well. It needed a little something else, though. The layout was functional, but not so easy on the eyes. I put out the call to see if there was anyone out there that might want to lend some time to giving the site a bit of a touch-up and, thankfully Jan Sorgalla answered the call.

He’s been working over the past few weeks on a new look and feel for the site to bring it up to that next level. Personally, I think he did an excellent job in both integrating some of the flow of the previous version of the site with a better styling to make the site more usable.

Development on the site is still continuing and more new features are in the works. The system is open to any events, not just PHP-related, out there that might want to have make their lives easier by letting attendees give the speakers their feedback directly.

Check out the new site!

If there’s one thing I don’t understand about programming communities (online and average joe coder on the street) it’s the competition that’s everywhere. Sure, I can see how there’ll always be the zealots that think their language can do everything. Well, I hate to break it to you guys but there’s just no such thing. Every language has their own feature set and their own strengths. There’s not one that’s going to work in all situations.

Repeat the mantra after me: “Use the right tool for the right job”.

Now, I’m a PHP developer so my views are a bit slanted that way, but I’ll be the first to admit that there’s things that the language just isn’t good for. I like to get feathers ruffled as much as the next guy, but there comes a point where you just have to concede. PHP is excellent for web development – it makes creating sites easy and there’s some great frameworks built on it but there are things it just doesn’t do well. Other languages like Python and Ruby are a bit more modular and, according to what I’ve read, and do a lot of the same things for the web that PHP does. There’s one thing to remember, though – it’s not really about what they do that’s the same, its the differences that matter.

You a Ruby developer can argue with the PHP developer all day long on how one handles objects versus the other or the “dumb syntax” that the other uses, but remember the mantra. There’s things that Ruby does that PHP just doesn’t do well and vice versa. Focus on these other things – that’s why you choose one language over another.

Don’t let your language choice get the better of you and put blinders on – expand your horizions! Don’t be afraid to check out other languages/technology/etc. You might actually learn something in the process that can make you an even better developer than you are.

So, a few weeks back Keith Casey and I were talking about conferences and feedback. One thing we both (and various others that happened to be in the #zendcon IRC channel at the time) agreed on was that paper slips and verbal polls just aren’t the way to go when it comes to providing feedback to speakers on how they’re doing.

Automation is the way to go – bring the attendees directly back to the speakers and let their voices be heard. Obviously, a web site is the medium of choice and so I present to you Joind.in.

Joind.in provides the missing link between the people attending a conference and the ones that presented. The usual method of handing out paper forms is outdated and needs to be replaced. That’s where we come in – attendees can post their comments directly to each of the talks they attended, giving the speaker direct feedback on how they did and what they can do to improve. Joind.in also has something to offer the speakers – you can track your record across the conferences and see how changes in your talk might have made a difference in your ratings.

Things are still running in beta mode right now as I work out some of the kinks with both the code and with the interface (any designers that want to help out and contribute a few ideas, drop me a line), but I’m hoping that this can become a great asset for the speaking community – and not just the PHP one.

The idea is to make it as open as possible to allow for conference planners from any topic to come in, add their events and talks to get direct feedback from their attendees.

Here’s a list of a few of the stats for the site:

• It runs on the CodeIgniter framework
• It allows for “stubs” for conference names (ex. http://joind.in/event/phpapp08 for PHP Appalachia ’08
• Speakers can “claim” their talks from each event and see how the same talk did at various events
• The commenting system supports both public (viewed by all) and private (viewed by speakers and conference admins) comments

I am always open to suggestions about the service, so if you have comments either leave them on this post or submit our contact form.