Given the fantastic resources available for PHP development, and the possibilities for desktop applications, PHP-GTK- and WinBinder-based desktop applications written in PHP could be really powerful. Sure, they’re not terribly efficient, but I suspect in the next few years these applications - especially PHP-GTK, thanks to Glade - will really take off.

Keep your eyes peeled on the DT homepage for an interesting overview of desktop application development in PHP; if you really can’t wait, head to gtk.php.net and amuse yourself with the vast array of UI elements you can draw in just two lines of PHP. Where do you think PHP is headed? Will desktop apps really take off, or are they just a passing craze, like Wiimote-powered media players?

It seems every organization I visit falls down in one of the areas I’m outlining below. Yet, if you want maximum happiness and productivity from your developers, there’s not much choice. Happier developers can also think clearer and avoid costly mistakes.

This is sort of a general set of suggestions for anyone managing or employing developers. I’m writing this in the context of corporate development shops, but it’s also important for developers working remotely. So, here are some basic tips for keeping your developers happy.

1. Start with the tech
This might seem a little obvious, but I’ve seen an entire floor of developers working on some cheap Dell desktops struggling to cope with their development tasks. Now that you’ve found good developers, don’t throttle their potential with terrible hardware. I’ve seen a small development shop with top of the line $4000+ beasts, three monitors attached to each machine and more memory and CPU cycles than you can shake a stick it: hardware that just worked. Productivity was fantastic.

Of course, one often forgotten area here is the internet connection. If you can avoid it, don’t plug your developers into the same 2mb pipe servicing the entire office; let them run their own servers if they want to, as opposed to relying on the information systems department (unless your developers are the information systems department). Internet filtering is a definite no-no: think about it, web developers having their internet filtered? There’s nothing wrong with filtering as such, but I’ve heard of one workplace blocking php.net. Goodbye, absolutely essential manual.

2. Let them take decisions
They’re your IT guys. Make sure sales don’t start promising unreasonable production deadlines, feature offerings and the like. Find good developers and give them the freedom and power they need to do their job well. If that means having the lead developer sit in on a client meeting and insist on an extra week on top of the sales-guy’s deadline, so be it. Involve them in the decision making that directly affects them.

3. Encourage experimentation
Face it: they’re geeks, and they do their own thing. If they want, let them spend an entire day wandering off and trying out new things. It’ll cost you a day of development, but it’ll repay itself easily when they’re back at it, and their new knowledge might prove useful in your project. Encourage experimentation.

4. Create culture
This is IT: it’s got a culture of it’s own. From internet memes, to geek terminology, to the consumer tech, it’s all there. Don’t block it out and force them into the same boring desk jobs of your other employees. I typically order a box of various geek toys from thinkgeek.com, encourage them to decorate their workplace as they like and so on.

For the finer touches, try making the office itself a little more suitable. For example, developers work well in wide open offices (no cubicles!) with lots of desk space. Take regular breaks from development to discuss amusing stories only a geek would understand. Maybe even run a mini hack day event, although that’s probably pushing the bounds of time spent at company expense.

1. Read books, write code.
There’s a lot of PHP books out there. So many, in fact, that even if you read one per night you’d take over a year to get through them all. Find specialized PHP books - Packt Publishing and No Starch Press have a few. Read through them, and write some code with them. Next time you update your resume, point out some of these new technologies you’ve used.

2. Attend conferences
They may be terribly formal, long and abstract, but attend as many conferences as you can, especially PHP-specific ones. Here you’ll find a multitude of presentations on new ideas, from technologies to methodologies. If your employer will pay for you to attend, all the better

3. Take courses and qualification tests
The state of PHP training today is somewhat dismal. Most training courses are run over the internet, the live ones can require you to be up at ungodly hours, and their effectiveness is limited in general. Still, if you can find a decent PHP training course, give it a go. Also, the Zend Certified Engineer qualification is a general benchmark, so study up and try it when you have the time (a Christmas break, maybe?).

4. Watch the web
This is probably the most important. Chances are you aren’t a PHP developer, but a web developer. A big mistake many PHP coders make is sticking to PHP alone. All very well, but when you have to build an application on your own, are you familiar with CSS selectors, HTML tags, or Javascript DOM techniques? Watch the web for articles and tutorials on all the areas you use regularly. Digg is a good place to start - for example, if you regularly visit Digg, you’d have seen this fantastic list of CSS techniques.

Follow these and you’ll be well on the way to becoming a master developer.

The main advantage of jQuery for us PHP developers is that it utilises our existing knowledge. When PHP code brings you closer to the HTML and other UI needs - CSS, for instance, - jQuery leverages that knowledge. It takes a little while to get used to functional programming, of course, but with CSS selectors, basic method chaining, and an approach to event handling that just works, jQuery is an ideal framework for PHP developers getting started with JavaScript interaction design.

So, next time you’re looking to get your hands dirty with DOM, DHTML and AJAX, head over to jQuery.com and give it a go.

When it comes to web hosting, I never run my own servers. I’m a developer, not a sysadmin; I leave server management to the professionals. Shared hosting costs less than a cup of coffee, managed VPS is pretty decent ($7 for LAMP VPS ready to go is pretty good), and these days you’re more likely to hire a sysadmin before a dedicated server.

I’ve seen perfectly good hobby projects by experienced developers run aground because of server issues, when a shared server would have been perfectly good. For root access there’s always VPS.

So, in my mind, when you’re next getting started on a project, don’t spend time getting servers setup. Leave it to the professionals, get a simple shared hosting account (or maybe managed VPS), and get coding.

Take a look at the following scenario:

while($var)
{
foreach ($var as $val)
{
if ($val) break 2;
}
}


Now, consider all this is inside another while loop. If someone else comes in and refactors, taking out the foreach loop, your ‘break 2;’ suddenly not only breaks out of the while($var) but also the loop outside of it. Big trouble.

Of course, GOTO is associated with Bad Things. A GOTO of sorts is coming to PHP 6, and is actually a good thing. It’s not so much a GOTO as a named break - it allows you to use your break statements to go to a particular point in code execution, as opposed to all this messy nested looping and loop numbering. Here’s a sample:

for ($i = 0; $i < 9; $i++)
{
if (true) {
break blah;
}
echo "not shown";
blah:
echo "iteration $i\n";
}
?>


I believe it was discussed at a meeting some time back; see here for the meeting notes. In any case, it’s a useful addition, provided it isn’t misused; hopefully we won’t end up with the spaghetti code messes of years gone by.

First, here’s a bit of background. Rails is a web application framework for the Ruby scripting language. Until a few years ago, Ruby wasn’t very widely used in web development, but the Rails framework changed all that. At this point, web application frameworks weren’t terribly popular, and PHP frameworks in particular were, for the better part, non-existent (Mambo/Joomla and Drupal don’t count.). Rails favoured convention over configuration, and as a result was very quick for basic application development.

PHP developers were moving over to Ruby on Rails, as PHP simply didn’t offer this functionality out of the box, and the PHP frameworks available weren’t much use. Over time, CakePHP, Symfony, CodeIgniter and various other frameworks developed, and we finally had the power of Rails in PHP. Of course, given the size of the PHP community, PHP frameworks matched Rails and surpassed it; we now have mature PHP frameworks for almost any purpose and any development style.

Now, inevitably, language wars debates between Rails and PHP developers ensue, and the common defense of PHP developers was that “PHP isn’t Rails, it’s Ruby.” Fair enough, some suggested; PHP and Ruby were languages, while Rails is a framework. Most PHP development happens without a real framework, while most Ruby web development happens on Rails (there are a handful of other Ruby web application frameworks, but none as successful as Rails).

Here’s my take on it: it may not be fair, but it sure is reasonable. When you think of Ruby web development, you think of Rails, and what can be achieved with it. On the other hand, PHP bundles a lot of its functionality in the core, and with most application development happening on top of this core, it’s the only reasonable comparison you can make.

In fact, it’s certainly not a fair argument, but that doesn’t mean it’s an invalid argument; there’s nothing wrong with Rails:PHP comparison.

That’s not to say Rails is a better framework than, say CakePHP or CodeIgniter; a proper comparison might find that PHP with a mature framework on top is a superior development platform than RoR. But Ruby developers can point to Rails as a demonstration of Ruby web application development, and all us PHP guys have to show for our framework efforts is a medley of different frameworks serving different purposes with no single, accepted way to write applications.

Wikipedia has probably the definitive list of major PHP frameworks, covering everything from CakePHP to Drupal to the Zend Framework, and includes a few notable yet less-known options. Of course, this doesn’t tell you much about them; the comparison table is a little more helpful, although it isn’t restricted to PHP-frameworks.

There are a few important features to look for in frameworks:

• MVC: the Model-View-Controller design pattern, one of the more popular patterns, and certainly an effective one. Many of the big OO frameworks use this, and it’s good for those new to framework-based development.
• Templating: a templating engine is pretty much standard, if only through the V in MVC, but make sure it’s there.
• Caching: save yourself writing your own caching system when you find yourself dugg or slashdotted.
• Form validation: one of the most common yet most frustrating features of building PHP web application, a framework that simplified form validation is invaluable.
• Inbuilt CMS: depending on what you’re building, having a CMS ready-built for your framework can be really useful. Drupal and Joomla both come with CMSs.
• Inbuilt auth: Many frameworks choose not to include authentication, but not having to write your own user authentication system is a fantastic time-saver for basic application development.

Beyond this, take a look at the options out there. If you’re familiar with Rails, take a look at CakePHP and CodeIgniter. If you’re more of a .net person, Prado might interest you. If you’re looking for a CMS that you can code on top of, take a look at Joomla. One website even has a feature-by-feature comparison, although beware of following it entirely, as it doesn’t really reflect the true power of each framework.

Of course, while you may be undecided on your choice of framework, one thing is certain: you should be using a framework, if only one you hacked together in a couple of hours. Most frameworks will help you code quicker and more consistently, code reuse is suddenly the drop-in-place approach it should be, and it’s always handy to be familiar with a dev shop’s adopted CMS when sending them your resume.

(Note that a few of these may not be available depending on your PHP/GD setup, check the manual)

1. Get the size of an icon file, with getimagesize() (also works on all standard image formats)
2. Apply a gaussian-blur to an image, with imagefilter()
3. Rotate an image, with imagerotate()
4. Flood-fill an area of an image, with imagefill()
5. Grayscale an image, also with imagefilter()
6. Draw polygons and arcs — maybe for mathematical diagram? — with imagepolygon() and imagearc()
7. Copy and resize a section of an image, with imagecopyresized()
8. “Sketchify” images for a pencil-illustration-style effect, also with imagefilter() (see a pattern here?)

The phpied blog has some cool demos of the imagefilter() function in particular.

1. Plan. Do some design mockups, work out what functionality will go in what classes. You can never plan enough, and good planning can save you days of code rewriting later.
2. Research. This is probably one of the most-forgotten areas of project planning. Chances are what you’re building has been done before, so do a bit of research on existing applications similar to yours. Consider any problems you may encounter and see how other applications handled these challenges. SourceForge is a great place to start.
3. Future proof. Depending on your application, this might not be terribly important, but consider what technologies are being used at the moment and may start being used. This article has a few suggestions. For example, maybe in future you’ll add a microformat-export function, and your code needs to be structured differently to support that?
4. Don’t reinvent the wheel. Most developers I’ve seen simply don’t practice this enough. Sure, you’re using your framework for some common tasks, but many people assume they’ll need to write a lot of their own code for complex routines. Before you start, check out PEAR and PHP Classes.
5. Set some timeframes and get into it! Now that you have a good idea of what you’re going to build, and how you’ll make it happen, set some goals and get coding!