Gearman is a lightweight, high-performance solution for farming out processing work from one machine to another. I’m currently looking at using Gearman as a key part of the architecture of a new web API that I’m doing the R&D for. (I’ll go into why I need something like this, and why I’ve chosen Gearman in particular, another day).

Getting Gearman up and running on Ubuntu 9.10 (Karmic Koala) is very straight-forward and only takes a few minutes, but oddly not clearly documented on Gearman’s own wiki at the time of writing.

  1. Add “ppa:gearman-developers/ppa” as a software source.
  2. sudo apt-get install gearman-job-server
  3. sudo apt-get install libgearman-dev
  4. sudo apt-get install uuid-dev
  5. pecl install “channel://pecl.php.net/gearman-0.6.0″
  6. Add a gearman.ini to /etc/php5/conf.d, with “extension=gearman.so” as the contents
  7. sudo /etc/init.d/apache2 restart
  8. Check phpinfo() to make sure gearman extension loaded

You’ll find that the gearmand process is already up and running, and listening on port 4730 on localhost. All you need to do now is to write some code to take advantage of it :)

2 comments »

Whether you’re looking at your own code before (or after!) you have shipped it, or you’re picking up someone else’s code after they have shipped it, tracking down and fixing bugs is a fundamental part of programming. If you know the code well, perhaps you can make an intuitive leap to immediately jump to where the bug is. But how do you go about tracking down a bug when intuition doesn’t help?

The nature of all code is that larger systems are built from smaller underlying systems and components. They in turn are also constructed from smaller components. The bug you are tracking down will have a cause in one of these systems, and will have symptoms that are visible in other systems. The remaining systems work fine (as far as the bug you’re looking for is concerned), and you can use this to quickly and reliably find where the bug is.

Divide your larger systems down into smaller systems at logical points, such as different server stacks, APIs, major interfaces, classes, methods and if necessary individual lines of code. Test both sides of the divide, with your tests focusing on the data that crosses the divide. If one side works as expected, the bug is not in there, and you can eliminate that side from further testing. Continue testing the remaining systems and components, which you have now isolated, by dividing those up into smaller systems and components. Keep going until you’ve reached the smallest testable system, component, unit, or lines of code that show the fault. Congratulations: you have isolated the fault.

Apart from being a strategy that allows you to work on code you’ve never seen before, this approach also has the advantage that it is evidence-based. This approach eliminates guess work, and it forces developers’ assumptions about how their code actually works in practice to be challenged. The data never lies, but be aware that it can be mis-interpreted!

The approach is iterative, and you’ll find that you’ll often go back and forth between your code and your tests, making your code easier to test and your tests have clearer and more targeted test domains and results. Fix the tests that are relevant to the bug you are tracking down, and make a list of any other issues you find along the way for you to come back and address at a later date. Stay on target, and park potential tangents and distractions for another time.

Although this sounds like a slow process when described on paper, with practice it can be executed at high speed during an emergency situation. However, the need to restore service in a timely manner isn’t always compatible with this approach, and you’re normally better off returning to your test environment where you can study the fault without inconveniencing your customers any further.

3 comments »

Stuart is running a course in Manchester in October immediately before the PHPNW09 conference on how to setup and organise your PHP developers to ensure things run smoothly for you and your customers, which will include looking at how to get the most out of Trac. Learn more about the course, or sign-up now.

When it’s just you, working on one project at a time, it’s easy enough to keep track of the work you’re doing and the work you still need to do to complete the job. Chances are you can keep it all in your head, or at least keep the discussions with your customer on something like Basecamp in your head. You know that you should be using source control and bug tracking because it is “best practice”, but it just seems like too much of an overhead to bother with when it’s just you. After all, you’re working on the customer’s server, and there’s no-one else editing the code anyway.

Some of the folks reading this blog post might be cringing at that, but I’ve lost count of the number of times I’ve come across professional PHP developers who work in exactly this way. Is it because they don’t know better? Maybe. Is it because it has worked okay for them up to now? For sure.

But eventually, there comes a point where one developer becomes a team of two … or more. Having a team means that you can go after larger projects … but it also means that you have to go after larger projects to pay the team. Larger projects mean more complicated requirements, multiple phased deliveries … and a larger, more demanding (and probably a more complicated) customer holding the pay cheque.

Running a team of PHP developers (like all management activity in all walks of life) comes down to three key things: direction, organisation, and supervision. Only now it isn’t just you and a customer, just a list that you can keep in your head. Now you need to keep track of a larger list, of multiple lists for multiple people to work on that need to be brought together in the end, and if anything slips through the cracks it’s your reputation on the line. Getting the customer to come back for repeat business just got a lot less easy to take for granted.

Trac and Subversion have been part of our community’s toolkit for many years now. Used correctly, you can get yourself and your customers well-organised, and grow your reputation when you grow your team. If you haven’t started using them yet, both are open-source, and well-backed with plenty of information freely available around the blogosphere on how to use them.

Or join me in Manchester in early October, where I’ll show you how they fit into an overall approach to running your team of PHP developers.

2 comments »

October in Manchester is home to the PHPNW09 conference. Last year’s conference was a great event, and this year’s promises to be even better. And I’m not just saying that because I’m a conference sponsor this year, honest :)

Immediately before the conference, I’m running a two day tutorial in the fundamentals of setting up and running a team of PHP developers, covering:

  • Keep your promises to your customers using written specifications
  • Organise your team using Subversion and Trac
  • Control quality using code reviews
  • Deliver to your customers using release management and follow-up support arrangements
  • Where to go after the course for additional learning

Places are limited to just 25 people, and there is an early-bird discount for anyone who signs up before 21st September. You can find out more on the course website, and sign-up online.

Comments Off

… as recommended by readers of Planet PHP :)

Most Recommendations

There were six Firefox extensions that folks repeatedly recommended …

  1. ColorZilla – advanced eyedropper, color picker, page zoomer and other colorful goodies.
  2. FireBug – live DOM & CSS inspector. The single greatest web developer add-on for Firefox.
  3. Live HTTP Headers – view HTTP headers of a page and whilst browsing.
  4. Web Developer Toolbar – adds a menu and a toolbar with various web developer tools.
  5. YSlow – Yahoo’s tool for analysing web pages and telling you why they are slow. Requires Firebug.
  6. Zend Studio Toolbar – debugging assistance for Zend Studio 5.5 and earlier. Isn’t mentioned on the Zend Studio 6 pages, so does that mean it is now obsolete?

… and after that, there was a lot of variety amongst the other extensions that were recommended.

Also Recommended

  1. Cache Status – easy cache status & management from the status bar.
  2. ChatZilla – IRC client for Firefox.
  3. Duplicate Tab – clone a tab along with its history.
  4. Edit Cookies – edit your cookies right in Firefox.
  5. Fasterfox – performance and network tweaks for Firefox.
  6. Firefox Accessibility Extension – test your web pages for functional accessibility features based on the iCITA HTML Best Practices.
  7. FirePHP – print to your Firebug console using a simple PHP function call.
  8. FireShot – take screenshots of web pages, and a whole lot more.
  9. Google Toolbar – Google’s famous in-browser search toolbar.
  10. GreaseMonkey – customise the way a web page displays using your own Javascript add-ons. See also Lifehacker’s Top 10 Greasemonkey User Scripts, and their Better GMail and Better Flickr add-ons to get an idea of just what can be done with Greasemonkey as a Firefox extension tool.
  11. HTML Validator – add HTML validation to your browser.
  12. IE Tab (Windows only) – open Firefox tabs using IE’s rendering engine. See also the popular IE View alternative.
  13. LocationBar2 – adds additional features to Firefox’s address bar.
  14. Lorem Ipsum content generator – Generate “Lorem Ipsum” dummy text, for when you need to fill a page with content for testing purposes.
  15. MeasureIt – draw out a ruler to get the pixel width and height of any element on the web page.
  16. NagiosChecker – see the status of your services and servers in Firefox’s status bar. You do monitor your servers, right? ;-)
  17. PrefBar – power user toolbar for Firefox.
  18. Regular Expressions Tester – testing tool for regular expressions with colour highlighting.
  19. RefSpoof – easy spoofing of the HTTP referrer header.
  20. ReloadEvery – reloads a web page every so many seconds.
  21. Save Session – save your current browser windows & tabs for the next time you open Firefox.
  22. Scrapbook – save web pages locally and easily manage collections. (Like OS X web archives, as supported by Together, DevonThink, and so on, but cross-platform).
  23. Selenium IDE – record, edit and debug tests for Selenium, the automated UI testing tool for web developers. See also PHPUnit’s support for Selenium. You do have reproducible testing for you web apps, right? ;-)
  24. Stylish – fix ugly sites, customise the look of your browser or mail client by using your own CSS files. Stylish is to CSS what Greasemonkey is to Javascript.
  25. Tab Mix Plus – tab management on steroids.
  26. Tamper Data – view and modify HTTP/HTTPS headers and POST parameters.
  27. TimestampDecode – treats the selected number as a timestamp and displays a decoded date/time.
  28. TitlebarTweaks – tweak Firefox’s titlebar text.
  29. User Agent Switcher – Adds a menu and a toolbar button to switch the user agent of the browser.
  30. Venkman – Javascript debugger for Firefox.

Stu’s Recommends

To round off the list, here are a few extensions that I find useful, but which weren’t recommended. If you haven’t heard of these before, give them a try.

  1. Flagfox – display a country flag in the status bar for the location of the current website’s server.
  2. Server Switcher – easily switch between development and production servers.
  3. Show MyIP – display your current external IP address.
  4. SQLite Manager – Manage any SQLIte database on your computer.

Are you a web developer? Got a favourite Firefox extension that isn’t on this list? Let us know in the comments below.

23 comments »
Page 3 of 41234

This Month

July 2014
S M T W T F S
« Jan    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Recent Comments