5 Tools Every PHP Developer Should Master
Dear Reader,
If you know me, you know that PHP is my passion. Talking about PHP is fun, working with PHP is fun, helping others work with PHP is fun. Heck, I love PHP so much that I’ve worked it so that my day job for the last 3 years has been working with PHP and developers.
Over the past nine years of having fun with PHP, began to see that there are five categories of tools that I rely on more than any others. Sure, I’ve got a code beautifier, a standards checker, and a hand full of hand-written scripts I use for various things to make life easier. However when it comes down to it, there are five that I rely on every day.
So here they are in acceding order of importance. Let me know, what are your five? (let’s not start a meme or anything though, ok?)
5: A Unit Testing Tool
Whether you prefer PHPUnit or SimpleTest, Unit testing has proven it’s usefulness in the development process. As a professional PHP developer, you should be familiar with the concepts behind Unit Testing and Test Driven Development. You should also be able to identify when unit testing is a good idea and when it’s a bad idea. (Yes, there are times when it’s a bad idea)
4: A Debugger
As with unit testing tools, there are multiple options for you when it comes to debuggers. dbg, Zend_Debug and xdebug all provide professional PHP developers with tools to break down their code and find problems. Debugging tools allow you to step through your code, stop execution and examine the environment at any point. Debuggers are a developer’s best friend and every developer should have one installed on their development server. Bonus points if you’ve also got FireBug installed. Find you a good debugger and invest the time necessary to use it, it will be time well spent.
3: A ERD Tool
If you are doing serious PHP work then chances are good that you are working with a database. At some point your database structure will grow too large to keep in your head, you will need a tool to keep everything straight; that’s where an Entity Relationship Diagram (ERD) tool comes into play. Tools like MySQL Workbench help you visualize your database structure. More expensive tools like ERWin or Embarcadero’s ER/Studio give you more options for importing and exporting models and keeping your database model in sync with your actual database.
No matter whether you are working on your personal project or the corporate database, an ERD Tool will help you manage it.
2: A Version Control System
CVS, SVN, Git, or a host of other options both free and commercial will help you keep your code safe. Whether that’s safe from your development server’s hard drive crashing or safe from you next coding binge where you change something at 2AM that you really shouldn’t have; keeping your code in a version control system will help. Which system you choose will largely depend on how you or your team work. You need to research the options available and work with your team to make choices like central vs. distributed.
1: A Framework
The most important tool any developer can have in their tool box these days is a framework. Let’s talk about two different types of frameworks.
The first type of framework is a Content Management System. These days CMS systems are complex enough to be thought of as specialized frameworks in their own right. You need to know one good enough to get it installed, up and running and extend it to get the job done. If your needs are easily definable and your CMS of choice has extensions available to fit more of the functionality then learning one could pay for itself in only one or two projects.
PHP has a lot of good CMS projects available and listing them here would simply mean that I would forget one so I’m not going to try. Dig around on Google and you’ll find one.
The second type of framework that PHP programmers need to have in their toolbox is a more generic programming framework. In the PHP world we have a lot of frameworks from which to choose. Most developers chose one of three or four major frameworks.
The framework you chose will largely depend around the type of projects you work on your style. Each of the above frameworks has it’s own strengths and weaknesses.
Regardless your choice, you need to know one framework well enough so that when a project comes along, you don’t burn a lot of time “Yak Shaving” but can get the project up and running quickly.
The Mission Option
There you have them, my 5 tools that every PHP developers should have in their toolbox. One thing that did not make the cut was an IDE. An IDE is great for those who use them. However, if you don’t wall the overhead of an IDE, there are a lot of good Programmer’s Editors out there for you to use.
For me, I use Komodo. Yes, I know Komodo bills itself as an IDE and it has all of the important features of one. However, it doesn’t force me to code it’s way. I can use Komodo to write PHP or edit my hosts file. Active State realizes that every file is not a project and that a developer should only have to use a project when they actually want a project.
Until next time,
(l)(k)(bunny)
=C=
Related posts
Tags: Cal Evans, FireBug, PHP, php developers, test driven development, testing tool
February 9th, 2009 at 2:49 pm
I personally miss the issue tracking system in your list. Trac, Mantis or Jira are must-haves for keeping track of issues and tasks you (need to) work on. But I can understand your list of tools as well. Excellent list.
February 9th, 2009 at 3:14 pm
I would replace debugger for an IDE. I have been a PHP developer for 0 years and I never had the need for a debugger. xdebug trace and var_dumps have been my friends.
But now I can’t live with a real IDE.
February 9th, 2009 at 3:35 pm
btw, XDebug is a debugger, and Trace is a fundamental part of the debugging procedure. An IDE without a debugger is absolutely nothing.
February 9th, 2009 at 3:42 pm
Nice set. Personally, I feel ERD tools encourage bloated design in data structures just like a refactoring browsers do for your code. But that’s a difference of opinion.
To me an IDE and a debugger are interchangeable.
One caveat is that if one uses a text editor, one should be aware of how to use it as an adequate substitute to an IDE (for instance, if you use VIM, know the stuff in Andrei’s talk). Not doing so is the programming equivalent of not knowing to touch type as a writer. Sure you can get away with it, but why make your life miserable.
February 9th, 2009 at 4:05 pm
And Vim…… i used in past years Zend and PhpEclipse, but when this IDE’s are using more of 100mb of RAM y change these for Vim and his wonderfull plugins…. and in this moment i can development at same speed at past, jejeje
(sorry for my english)
February 9th, 2009 at 9:49 pm
Nice set of tools – how about an example of when TDD is a bad idea.
February 10th, 2009 at 3:35 am
Thank you all for the thoughtful replies.
@stefan
I actually thought about a bug tracking system but since this was me looking at my development process and the tools I use to code, I don’t use a bug tracking system daily for coding. it is an important tool but just not in *my* top 5.
@Stuardo
That’s a valid comment. IDEs are important. As I said in closing, I use Komodo and don’t really consider it an IDE. (it is, but I don’t use it that way) But IMHO, learning to use a debugger is much harder than learning to use and IDE. So while you are correct, an IDE/Editor is important, I still think a debugger is more important. 9and afterall, the blog post is *MY* opinion) :)
@cprieto
I totally agree. Without a debugger, you might as well be using Notepad.exe
@terry
Hi!
Yes, an ERD tool can lead to over designed databases. Lord knows I’ve done enough of those myself. In the hands of someone who understands the problem they are trying to solve though, it can be a useful tool. However, and I didn’t touch on this i the article, my favorite use for an ERD is for reverse engineering. When I take over a project, sucking the database into an ERD and spitting out a wall-chart helps me get a handle on what data is where.
@Rastino
Yes, modern IDE suck up a lot of resources. you have to balance the value to your personal development style with the impact on your system.
@Tarique
I would say that unit testing is a bad idea when you are prototyping or building version 1 of anything. (This is strictly IMHO, feel free to disagree) If you are not really sure what you are building (and spare me the “get proper specs” speech, in real life, it happens) then building, and eventually re-building your unit tests are wasting your teams time. Once you know what you are building and things are carved in stone (or at least in a really firm gelatin like substance, then building unit tests is a good idea.
I’ve seen a lot of professionally developed and deployed systems go wrong because after it was built, they didn’t bother to build the unit tests and the next round of changes had unintended consequences. Unit testing and regression testing are both very important once you have reached at least M1. Building them up front wouldn’t have helped because the system they deployed wasn’t exactly what the client originally speced out. Specs change and until they stop changing, you are just spinning your wheels building unit tests.
Thanks again everyone for the great comments!
=C=
February 10th, 2009 at 7:09 am
Go Netbeans!
February 10th, 2009 at 7:24 am
Hi, Cal. I pretty much agree with you, with one exception: I gave MySQL Workbench a try a while ago, but it was incredibly annoying. It had too many bugs at the time and the installation process on Linux demanded jumping through a lot of hoops to get it done. On top of that there’s always the issue about it being designed for one RDBMS alone.
One thing the OSS world needs badly is a decent, free of charge, Database Modeling tool. I use Azzurri Clay (a plugin for Eclipse) nowadays, which is a great tool but lacks the basic functionality of printing.
Kudos on the IDE comments, I agree with you on the fact that “considering everything a project” is one of Eclipse’s main sins. I was a long term Komodo fan once, I believe it’s time to give OpenKomodo another shot.
Hope to see you in Brazil this year.
Cheers,
Galvao
February 11th, 2009 at 3:06 am
The best ERD tool is SQLYog http://www.webyog.com/en/sqlyog_feature_list.php (but only for mysql)
I use seagull framework that it’s an application framework (ready to use with a db schema, user handle, autenthication, permission e menu nagivation fully customizable from admin panel).
February 11th, 2009 at 3:25 am
Hey Cal, thanks for the reply and you need not be so defensive :D
I fully agree with Unit test after M1 and specs do indeed change
/me sighs, leaves the spec changing rant for some other time and bookmarks this page to show to clients
February 11th, 2009 at 11:37 am
Hey Cal,
I saw the headline on my rss aggregator and I thought it was going to be some crappy write up saying smarty is a must know. Glad to see it was actual a worthwhile article. When I first came to Panasonic their web team’s idea of source control was zip files with a “master” owner. yikes!
February 13th, 2009 at 7:36 pm
“Active State realizes that every file is not a project and that a developer should only have to use a project when they actually want a project.”
I couldn’t agree more. I left Komodo to try out Aptana, NetBeans, even IntelliJ and several others. Almost to a T, they can’t open an individual file from another source for quick editing. Project this, project that.
Give me a break. Sometimes, you JUST need to EDIT.
February 17th, 2009 at 3:06 am
[...] eles já se consideram programadores, e logicamente, as coisas não funcionam bem assim. Inspirado num post do Cal Evans (se você nunca ouviu falar nesse nome, google-for-it ! agora!) em que ele diz 5 ferramentas que um [...]
March 8th, 2009 at 8:46 am
Excellent find, I will make a note to mention it on our site.
March 17th, 2009 at 5:16 am
A good read which touches the most important tools in a concise, yet powerful writeup.
Regarding the IDE thing, I’ve been using NuSphere PHPEd for around 2 years now and it has been my good friend throughout the time. Like the Komodo you mentioned, it doesn’t force the project thingy and boosts all my fav features including a nifty terminal window.
About the Unit testing, do you think it’s best to first start writing the tests with personal projects instead of writing them for the projects in the job (assuming your company doesn’t force you write unit tests at work) ?
Thanks everybody!
March 17th, 2009 at 5:21 am
5 Tools Every PHP Developer Should Master | Postcards From My Life…
Over the past nine years of having fun with PHP, began to see that there are five categories of tools that I rely on more than any others. Sure, I’ve got a code beautifier, a standards checker, and a hand full of hand-written scripts I use for variou…
March 17th, 2009 at 6:32 am
I completely agree with you Cal. Unit testing can be a really bad idea when the specs keep changing. In real life this happens way to often.
April 5th, 2009 at 11:35 pm
@Milan
On the contrary, I believe the Unit testing can actually be your life-saver on real projects with defined deadlines et all, especially when specs are a-changing !
The unit tests will help you identify issues in the code logic whenever you change implementation, so it’ll help you.
I do agree with Cal and others here that it’s overkill and way too resource-consuming to use it on a mere prototype. Not version 1 though….