PHP 5.3 Adoption: Some Numbers

Posted by Stuart Herbert on January 30th, 2010 in Conferences, Toolbox.

Last year, I ran a series of polls via Twitter to try and learn a bit more about your plans to move to PHP 5.3, and whether or not you actually followed through. A huge thank you to everyone who voted!

I’m not talking at any conferences this year, so I’ve published the planned PHP 5.3 adoption talk online for anyone who’s interested in what the PHP user community told us via these polls. As well as the raw data, I’ve included an analysis of what the data might mean, and some talking points about what the PHP Group might want to do differently when PHP 6 (or PHP 5.4 if there is one) is released.

You can find the talk online at Slideshare, along with all of my older talks. I hope you find it useful and informative.

Be the first to leave a comment »

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.

Be the first to leave a comment »

Buy My Old MacBook Pro!

Posted by Stuart Herbert on September 28th, 2009 in Toolbox.

It has been my ever-faithful companion for the last three years, but now sadly the time has come to part ways with my old MacBook Pro. The only reason I’m selling is that I need longer battery life on occasion. The machine works fine, and I’ve just fitted it with a 500GB HDD (taken from my new MBP; sorry, but I’m keeping my SSD 🙂 ). The outer casing’s finish is worn in one spot; not bad considering this machine has been with me all day every day for the past three years.

Full details are in the listing on eBay.

Be the first to leave a comment »

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.

Be the first to leave a comment »

What Do You Develop On?

Posted by Stuart Herbert on September 11th, 2009 in Toolbox.

At work, we have quite a variety of kit that we use for development:

  1. Cheap and cheerful desktop machines w/ multiple monitors and plenty of RAM, normally with AMD CPUs. These machines mostly run some form of Linux … Ubuntu and Debian are both popular.
  2. Various laptops, a fair mix of MacBook Pros and other kit running Linux.
  3. Virtual machines running on the desktops and laptops, used for cross-browser testing.
  4. Virtual machines running on HP servers and blades, used for system testing, release testing and production.

It gives us a lot of flexibility, allows us to develop and test on standards-compliant environments (but still use Windows for testing IE), and most of the time the developer is the bottleneck not the equipment 🙂 Recently, I’ve added both a netbook and an Atom-based mini-itx machine into the mix, and this blog post is my attempt to recommend that you consider doing the same.

Netbooks are incredibly popular in the wider computer-owning population. Over here in the UK, they come free with many mobile broadband packages, making them cheaper than many low-end laptops. They’re sold in the supermarket and the high street. Their small form factor and relative lightweight makes them appealing to people who would never willingly cart a traditional laptop around. And they run Windows, which most people are familiar with.

After an initial explosion of innovation, the specs have settled around a 1.6GHz Atom processor, 1 GB of RAM and a 10″ 1024×600 resolution screen. That’s not a lot of power, and it isn’t a lot of screen estate. How do your websites look on a netbook? Does your home page or your landing pages make an impact at that size, or is your site’s message partially or completely below the fold? How do the rest of the pages look? If you’re creating an app, does the user have enough of a working area to comfortably do their tasks? Try using Google Reader or Zimbra on a netbook to see examples of what to avoid.

And how do your websites run on a netbook? Too much Javascript, and the pages won’t be snappy. The CPU won’t keep up, and the different latencies and throughput of mobile broadband make round-trips back to the server much more noticeable. Javascript that fires at regular intervals (e.g. rotating marketing spotlight images) can force the CPU to switch execution speeds, and so drain the netbook’s battery much quicker.

Testing on a netbook is one way you can spot and deal with these problems before your customers do.

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. Learn more about the course, or sign-up now.

Be the first to leave a comment »

Poll: Have you adopted PHP 5.3 yet?

Posted by Stuart Herbert on September 1st, 2009 in Opinion, Toolbox.

Earlier in the year, before PHP 5.3 was released, I asked the community a series of questions about their attitudes towards moving to PHP 5.3, and had a fantastic response. I’m going to turn all of those answers into a new conference talk that I’m working on.

Now that PHP 5.3 has been around for a few months and we’ve started seeing plenty of blog posts covering all the new features in PHP 5.3, I’m wondering whether or not you have actually moved to PHP 5.3 yet. I’m especially curious to see how this compares to what people said they’d do before it came out 🙂

Please vote on twtpoll to let me know if you have moved to PHP 5.3, and if not, what’s still stopping you. Many thanks in advance!

Be the first to leave a comment »

I’ve been running a series of polls as research for a new conference talk that I’m currently putting together. The first two polls have had over 1,200 votes between them so far, which is a fantastic response! Now I just need your help with one final poll 🙂

Please vote on twtpoll to let me know where will you get your PHP 5.3 from? Many thanks in advance!

Be the first to leave a comment »

A huge thank you to everyone who voted in my last poll about when you’ll adopt PHP 5.3, and everyone who has provided feedback on the problems caused by the way individual distros package PHP. I’ve had much more feedback than I could have hoped for! This is all useful research for a new conference talk that I’m preparing.

My next question for the PHP community is about where you’ll use PHP 5.3. I’m wondering: which server platforms you’ll choose to put PHP 5.3 on when the time comes? This new poll is multi-choice, allowing you to vote for all of the operating systems that you choose.

Many thanks in advance for your answers 🙂

Be the first to leave a comment »

As part of the research I’m doing for a new conference talk, I’m running a poll to find out when people are planning to switch to PHP 5.3. After the very slow uptake of PHP 5.0, I’m very curious to see how quickly PHP 5.3 will be adopted.

Many thanks!

Be the first to leave a comment »

I’m putting together a new conference talk, and I’d like your help and input.

Most Linux distributions ship with packages for PHP, but not everyone is happy with these packages. If you’re not happy with the PHP packages for a specific Linux distro (no matter how obscure), I’d love to hear what you think the problems are and (if possible) what the correct solution should be.

If you have something to say on this, please leave a comment below.

Be the first to leave a comment »
Page 7 of 9« First...56789

This Month

October 2018
« Sep