Zoe invited me to go down to IBM Hursley yesterday to deliver my talk about building Twittex from PHPNW and to also meet the Project Zero team. I had a great time, and the folks from IBM made for a very engaging and collaborative audience. It was particularly nice to meet Ant in person; he’s currently one of the better bloggers about PHP imho and as a community we sure could use more folks writing to his standard 🙂

If you haven’t heard of it before, Project Zero is a new implementation of PHP running on top of J2SE. It gives you the ability to run PHP in an environment that eventually should out-perform the Zend Engine (which will be very welcome here), plus the ability to pull in and make use of many excellent Java libraries that have no equivalent in the PHP world (like, for example, a SOAP client that isn’t a toy …)

Higher performance is important to ISVs in particular, because as you get away from non-trivial apps and get your caching strategy mature, the bottleneck moves from the database back into the amount of CPU available for the web server. Over here in the UK, servers are expensive, and hosting them even more so. There is real money to be saved by not requiring extra servers.

But my personal interest with Project Zero is evaluating it as a platform for API integration and development. Many of the products I need to integrate with are .NET based, and their APIs make a fairly rich use of SOAP. So the first thing I’m going to try with Project Zero is a little app to merge data between our ERP platform and our project management platform – two platforms that PHP’s SOAP client struggles with at best. I’ll let you know how I get on 🙂

Be the first to leave a comment »

Job Vacancies at Gradwell

Posted by Stuart Herbert on December 15th, 2008 in News, PHP In Business.

I’m currently looking to fill two new vacancies at our office in Bath. I’m looking for a Senior Sysadmin (permie) and a Storage Engineer (contract) to come in and help us as we grow our award-winning business in 2009. These roles will be assisting us with our email and hosting platforms. If you’re interested, drop me an email. No agencies, please!

Who are we? Gradwell is a rapidly-growing ISP who focuses on broadband, email, web hosting and VoIP solutions for the UK SME market. We are a pioneer in VoIP, and are the leading VoIP provider for UK business. We also do fun things like Twittex, which I talked about recently at the PHPNW 08 conference.

Be the first to leave a comment »

The motivation for this blog post came from reading an article today touting the meme that cloud computing is coming. That’s the message from Sarah Perez over on Read/Write Web. The “classic geek” (which presumably includes many of the folks reading this on Planet PHP) will no longer be the ones “working with the CEOs to execute the vision and direction via information technology,” according to Sarah.

Presumably because the companies will have gone bust from a lack of good leadership. Something we’ve seen before, and will see again.

The successful IT departments in the sort of larger organisations that can provide food and shelter for your true “classic geek” have been part of the business for the last decade, if not longer. Before we had the sexy CTO and CIO titles, there were IT Managers and Operations Managers who did all this stuff with little fan-fare and trumpet blowing. They did it on a budget, so they had to have financial management skills. They managed staff, so they had to have people skills. They delivered results, so they had to have project management skills. They made sure the business could do its job, so they had to have quality assurance skills. They implemented approaches such as ITIL and more lately CoBIT to ensure that the IT department was aligned to the business and relevant regulation. And they did this whilst still groking computers. In fact, they did this because they groked computers.

I’ve seen this sort of nonsense before when Java came on the scene, and the rise of the Web 2.0 blogger means I’m seeing it again. “Everything is new, everything is different; the old skills and the old lessons no longer apply, so don’t bother learning them” – that is the seductive siren call. Any student of management history can trace this echo back hundreds if not thousands of years. The core skills of good governance – direction, organisation and supervision – have not changed. You can read the works of Confucius from over two thousand years ago, and the principles behind the lessons for the leaders of the time are no different than the principles behind the lessons for the leaders of today. Practices have changed, but not principles.

There are no secrets, no short-cuts for those-in-the-know; not in business, engineering, or the arts. You have to know the basics, and you have to do the basics. Hard work and dedication is always the key, and you won’t find a single leading member of the PHP development team who doesn’t reflect that reality.

So what does this have to do with our favourite punch-bag here on Planet PHP, Ruby on Rails? For me, the rallying call of Rails is different from the Java and Web 2.0 hype/bullshit machines. I cringe every time Terry takes a swipe at it. Whilst I’m as sick of the term ‘agile’ as can be, Rails doesn’t try to claim that the old skills don’t matter. Quite the opposite. What they have done is to take the old skills and put them into one approach that can, and does, really work exceptionally well for a lot of firms and a lot of problems. They’ve worked out what the basics are, and they’ve designed a whole paradigm that ensures the basics are done well. They’ve executed in a way that the PHP community should be in awe of, not taking the piss out of.

They are years ahead of us in so many important areas, and yet PHP is thriving more than ever. They must have done something wrong, because they sure didn’t grow the market for web applications. What did they do wrong?

The fundamental mistake the Rails designers have made, and one that they still haven’t groked en-mass that I can see, is architectural, not philosophical. Rails is a classic application server, with all the deterministic, concurrency and big-iron-needed-here problems that stopped J2EE from squeezing out PHP at the turn of the century. For many of the problems of the web, the PHP execute-again architecture has repeatedly been proven to be superior to the application server architecture.

  • PHP is easier for average-skilled folks to deploy. What’s the point of creating applications if you can’t figure out how to run them anywhere but your bedroom?
  • It is easier to track down and eliminate bugs in PHP applications. No persistent processes mean that PHP applications are deterministic. PHP code is also much simpler to work through and debug.
  • It is easier to scale applications written in PHP. Folks have done it, and other folks have repeated it. The Rails community as yet has not.
  • It may be quicker to create applications in Rails, but the operational costs once the application goes into production quickly erode that advantage. If you’re not in the US, servers cost real money, and application servers need more iron than the equivalent PHP code.

The Agile community likes to talk about “smells”, so how come they don’t see something like mod_rails and gag on the stench of trying to mask architectural failings with such cleverness?

Before I make it onto Terry’s Christmas card list, I should state that I firmly believe that Ruby itself is a programming language that is vastly superior to PHP, especially when you get away from Apache and are creating the behind-the-scenes plumbing required. The OO in Rails continues to leave PHP for dead, and OO brings many advantages to a thriving development community. There are real advantages to being able to share code between both the must-be-real-time web front-end and the non-real time backends, and to be able to easily reuse whatever external open-source libraries save you time and effort. And I believe that solutions such as the Ruby gems are vastly superior to PEAR and PECL. PEAR/PECL should have been our CPAN, or our RubyForge. They deliberately chose not to be, wrongly believing that CPAN was a negative feature of Perl. They believed that one high-quality solution would prove the superior model over time. They failed to execute, and the paradigm was plain wrong in the first place.

My prediction is that a Rails-like framework, but built using a PHP-style mod_ruby and execute-again architecture, would have a real chance at displacing PHP. RoR the application server hasn’t a snowball’s chance in hell of achieving that. Their market firmly remains the same market that .NET and Java already fight over, and it’s a market they’re very welcome to.

Be the first to leave a comment »

The end-of-life announcement for PHP 4 has prompted a lot of discussion about whether PHP 5 is worth adopting at all, and even whether or not PHP 5 has hurt PHP as a whole. The technical arguments have been debated (and, alas, that will continue no matter who says what) on the Net for some time now.

What I’m not seeing are the commercial arguments to move to PHP 5 (/me points an accusing finger at the folks from Zend, with whom this discussion has been had before). Businesses will only make the move when there is something to gain from the effort, when the rewards of switching are more than the cost of doing nothing. So let’s see if we can find some reasons to chivvy them along!

Here are the arguments I’ve been making for the last 3 years to pointy-haired bosses that many technical folks ultimately have to answer to. What commercial arguments have you tried in your workplace? Post the good ones that have worked in the comments below, or on the Net on your own blogs for us all to share.

— Stu

Be the first to leave a comment »

I’ll be making the bleary-eyed trek over from Cardiff on Friday morning (I’m more liking to be heading off to bed at 5am than getting out of one!) to the PHP Conference in London. If you’re going to the conference too, and you’d like to meet up afterwards (or over lunch) to talk about the Why PHP effort, please head on over to the group and let us know.

Be the first to leave a comment »

In my last post, I asked whether there was any interest in there being a resource that makes the business case for PHP. Many thanks to everyone who replied, especially David Goulden at Zend.

To turn this from an idea into reality, I’ve setup a Google group where anyone who is interested can join in, and help build this resource. Please come along with your ideas and concerns, and let’s see what we can achieve together.

I don’t know what other folks think, but I think the first step is to draw up a list of topics that the business case needs to cover. Run into a question from a customer that stops you selling your PHP solution? Let us know.


At work, we make and sell software written in a number of languages; our flagship product is written in PHP. During pre-sales, we’ve always had to handle some questions about our choice of PHP – normally from IT staff with a preference for Java or lately .NET – and we normally manage to convince the potential customer that PHP isn’t the bad choice that they’ve been led to believe.

But one of the unfortunate side-effects of Stefan Esser’s much-publicised (self publicised? 🙂 ) departure from the PHP Security Team has been an increase in the number of IT staff we’re coming across who “believe” both that open-source is inherently insecure, and that PHP in particular has incurable problems. These “beliefs” hurt ISVs trying to sell PHP-based applications into skeptical organisations.

Why isn’t there a central resource containing the answers to “Why PHP?” in a business-oriented way? Something that ISVs can refer their clients to, and it not only promotes the excellent advantages of PHP (and include success stories from vertical markets), but also include substantial rebuttals to the FUD that ISVs have to deal with during the pre-sales process.

I’m not surprised that PHP.net doesn’t contain such a resource (it’s not really the place for it, one could argue), but it’s disappointing to see that Zend doesn’t provide one. What’s good for ISVs should be good for Zend, after all, and this is an area where they could help all the ISVs that they want to sell their products to 🙂

Is there interest from other folks in having a resource like this? Or maybe working together to build such a resource?

Page 2 of 212

This Month

May 2020
« Sep