Stuart Herbert | Gentoo

Here is a link to the LWN article about allow_url_fopen that Robin was referring to. This link works for non-LWN subscribers too.

(Although, why do you need a link for non-subscribers? You’re subscribed to the Linux world’s finest news site already, right? )

Chris, you’re completely missing the point about objects and PHP.

Classes and inheritence are not new to PHP 5; PHP has had these for many many years now. PHP 5 brings with it new features, such as interfaces, class constants, and access controls (although it’s still got a ways to go to catch up with both Python and Ruby). It also changes the semantics of objects; in PHP 4, objects are passed by copy, but in PHP 5, objects are passed by handle.

You can - and plenty of folks do - write object-oriented code in PHP 4 just fine.

PHP’s runtime behaviour - that each page starts afresh - is one of PHP’s killer features. You’ve obviously got no idea about just what a difference it makes. Every time your script runs, you’re guaranteed to start with a clean slate. The only state you have to worry about is the state you’ve stored for yourself. This simplicity makes it almost trivial to create deterministic code, without which you cannot produce high-quality code.

Managing state between pages is very straight forward in PHP. If the state matters only for the user’s current visit, put it in the session. If you need state to persist between visits, or it is information that other visitors need, put it in a persistent datastore (such as a database). Use a local cache (files on disk, memcached) to reduce the amount of time you have to get state from the persistent datastore. That’s the PHP way.

Folks who follow design patterns religiously are missing the point. They’re not hard and fast rules (that way lies Java, and its hideous and pointless complexity); they’re guidelines, meant to make you think about the natural structures that arise in your code. They’re not meant to be a cult. Anyone tells you different, they haven’t read enough Suzuki. When all you have is a hammer (or a set of design patterns), everything starts to look like a nail.

And that’s the beauty of PHP over many of the other tools that you have. If you want to write a system that’s entirely object-oriented, you can. But you don’t have to. You can create and use objects where they make sense, and you can continue to use global functions where they make sense. PHP’s neutral philosophy gives you the freedom to just get on with it, and do what’s right for your needs, your skills, and your tastes.

I’ve just added an ebuild for activeCollab to the Gentoo Web-Apps overlay, in the experimental branch.

activeCollab is shaping up to be an open-source alternative to 37 Signals’ Basecamp, written in PHP instead of Rails.

Enjoy!

Santos, the thing to remember about activeCollab is that it’s starting from the position of being a free clone of / alternative to Basecamp, the simplistic project management tool from the folks behind Rails.

Customers love Basecamp. It has a very clean user interface that doesn’t scare off folks who aren’t all that comfortable using computers. This is really its strong point; it allows you to engage those customers you’d normally spend hours on the phone with instead.

But, for project managers, the downsides quickly add up. In the office, many of our developers describe Basecamp as a just another bulletin board. The lack of structured data makes Basecamp easy to start using, but when you need to run off a progress report, maintain central action plans, or manage risks and issues, the lack of structured data starts to bite. Oh, and you currently can’t get all your data out of Basecamp either, which puts a bit of a dent into your business continuity planning. (To be fair, you can get a lot of it out, but the process isn’t a one-click solution atm).

In this context, ActiveCollab’s current behaviour makes perfect sense. You don’t want everyone and anyone being able to sign up by themselves, and suddenly be able to see what your project plans are. I’m sure your defense and public-sector customers would just love that! (Or any of your customers, come to think of it )

But I hope the ActiveCollab folks read your blog entry. One of my personal pet peeves about Basecamp is that it’s a stand-alone island. It’s not integrated with anything (including other products from 37 Signals); and there’s nothing causes confusion on projects like duplcation. It’d be great to see ActiveCollab provide a plugin architecture, so that folks can add stuff like wikis, bug trackers and more. Being able to mix & match features, so that it be tailored to what each organisation wants, would be a killer feature imho.

Oh, and if you want to be able to “just” install trac and use it, without having to mess about with dependencies or anything else, you should be using Gentoo

I’ve been playing about with using PDO to work with mysql. Something’s not quite right in there, and it’s resulting in a segfault when I run some local unit tests.

I’m not all that hot on PHP’s internals; I only tend to go digging in there when work needs a runkit bug diagnosing and fixing. But I’m pretty sure that what I’m seeing needs some TLC.

PDO objects themselves are created and destroyed when I’d expect them to be, as the objects go out of scope. The problem is that the PDOStatement objects aren’t doing the same. According to gdb, PDOStatement objects are only getting cleaned up when php_request_shutdown() runs; never before.

Surely we should be seeing PDOStatement objects being destroyed before their corresponding PDO object? The segfault is happening because php_mysql_stmt_dtor() is calling mysql_more_results() after the PDO object has been destroyed. We’re passing garbage data into the mysql client library … which chokes and segfaults as a result.

I think there’s two bugs here. The first problem is that PDOStatement objects appear to be persisting even though they’ve gone out of scope. php_pdo_stmt_delref() only gets called during php_request_shutdown(), never before. That doesn’t seem right to me. Why aren’t PDOStatements being destroyed when they go out of scope?

The second problem is that PDO objects are being destroyed before their corresponding PDOStatement objects. I couldn’t find (or, most likely, I didn’t recognise it any code that handles reference counting between PDO and PDOStatement objects. Maybe I’ve got it wrong, but I’d expect PDOStatement objects to add/subtract the corresponding PDO object’s reference counter, to ensure that PDO objects don’t get destroyed until all of their PDOStatement objects have been destroyed.

Anyone else got an opinion on this?

Kristi and I have just come back from the lovely town of Skien, Norway, attending the php|vikinger event organised by Zak Geant. It’s the first time I’ve attended an event like this, and I thought that Zak did a good job of running the unconference with the mighty power of Thor.

It was great to meet Sebastian for the first time, and to pick his brains about PHPUnit test suites. I confess I spent most of the weekend hacking away on my tests, rather than actively joining in the sessions; I now have unit tests for most of my Datastore PHP library. Need to track down and fix a PDO segfault, but otherwise it’s getting to the point where it’s actually useful. I hadn’t seen Hartmut’s PECL_Gen package before; I’m looking forward to when it can throw exceptions back into PHP (grin).

If you’ve never been to Norway before, it’s well worth the trip … especially if (like me) you’re used to how dirty and grey the UK can be. Don’t worry if you don’t know enough Norwegian. I think we met just the one person who didn’t speak English, and we’re pretty sure they were tourists too!

I’ve disabled write access to the Gentoo PHP Overlay for the moment. We’re moving the site to the new Gentoo Overlays box soon.

I’ll announce the new address once everything is up and running.

Thanks to Sebastian, I’ll be going to Zak’s PHP Vikinger unconference in June. This’ll be my first trip to Norway (heck, it’s my first trip to mainland Europe), although I doubt there’ll be any time to do the tourist thing this time around This’ll make quite the contrast to the last PHP conference I attended (Marco’s one and so far only php|cruise).

Kristi’s coming too … she’s going to do the tourist thing for both of us.

PHP Vikinger is (obviously enough) a PHP conference, but if anyone who’s going wants to discuss anything at all about PHP on Gentoo, let me know in advance and that’ll help me be prepared for it.

Today has served as a timely reminder to me that not everyone understands that it’s perfectly possible to have both PHP4 and PHP5 installed in Apache at the same time. A lot of folks just stop when they learn that you can’t load mod_php4 and mod_php5 at the same time into Apache. There’s no solution in the excellent PHP Manual that I could spot this afternoon (maybe I’ve just missed it?), and a lot of folks just don’t get any further along than that.

(I think it’d be very interesting if it was possible to work out just how much this one issue is holding up wider adoption of PHP5)

Andreas Korthaus has kindly written some instructions explaining several different ways to configure Apache to work with PHP4 and PHP5 on Gentoo. He’s covered running one as an Apache module + one as CGI, as well as running one as an Apache module + one as CGI via mod_suphp. There’s also a list of other approaches with links for further information. Although the document was written for Gentoo, it should be easy enough to translate the instructions into your favourite distro.

Thanks, Andreas!

I’m currently designing an additional layer of caching for Amaxus (which I now have running on Gentoo ) and for clickdensity. Delivering a performance boost is great, but I’d also like the cache to gather some useful information on how well it is working. The stats are partly to impress management/customers … but I’m much more interested in stats for developers.

So far, my list of stats includes the obvious stuff - hit/miss ratio, CPU & RAM saved (when compared to the uncached version of the page), and a set of counters to keep track of each reason why the cache missed. But what other stats would you find useful, if it was your code?