22 Feb 2006
Needing to pick out some bits from a smallish (40 lines) XML document studded with namespaces, I first turned to DomXPath:
$doc = new DomDocument();
$doc->loadXML($xml);
$x = new DomXPath($doc);
$x->registerNamespace('one','first-namespace-uri');
$x->registerNamespace('two','second-namespace-uri');
$nodes = $x->query('/one:tag/two:*');
Worked great, code’s concise, XPath expression is simple. But I had the nagging thought that using DOM traversal functions should be faster. So I tried:
$doc = new DomDocument();
$doc->loadXML($xml);
$firstNode =
$doc->getElementsByTagNameNS('first-namespace-uri','tag');
$nodes =
$firstNode->item(0)->getElementsByTagNameNS('second-namespace-uri','*');
The DOM traversal code is about four times faster than the XPath code. I’m going to use the XPath code, though.
That 4x speed multiple translates into about a half second to execute for the XPath code and about 0.13 seconds to execute for the DOM code when each is run 10,000 times. Since a typical use of this code will involve it running maybe 10 or 20 times during a request, I’m happy to sacrifice a few microseconds of processor time in exchange for simpler code. (Since, to me, the XPath expression is simpler and has the handy property of scooping up all the nodes that match – the DOM code would have to be modified to loop through multiple nodes in $firstNode to get that behavior. If XPath gives you the willies and you prefer using the DOM functions, then you’re in great shape.)
Whenever performance evaluation issues like this come up, I’m reminded of Adam’s mini-rant that I wrote about in 2004.
20 Feb 2006
I’ll be chatting with Marcus on the Pro:PHP Podcast this Friday, Feb. 24 at 1pm ET. Tune into the live webcast and ask questions!
16 Feb 2006
We released a new version of Ning today. (Well, for me in NYC it was today. For the crew in Palo Alto, it was a last-night-and-this-morning experience. For the Australian connection, I’m not sure which day(s) we covered!).
Lots of neat new stuff in this release:
- Totally revamped and rewired UI for browsing around the playground, profile management, looking at your app's stats, and other system functions. As someone whose expertise tends towards the "functional but not so pretty", I am really in love with all of Paul's hard work on this design.
- That redesign extends to the Developer Documentation too -- I think it'll be easier and more pleasant to find tech specs and API docs now.
- Speaking of developer stuff, there are a bunch of new skeleton apps that make building web services apps ridiculously quick. Yoz has also put together a snazzy screencast on building a basic photo sharing app with Flickr integration.
- All the Example Apps have been given thorough overhauls, too. Jon did a lot of work on all sorts of color palette arithmetic and GD wizardry so apps now have slick setup pages that let you tweak colors and have that automatically update your entire app.
So take a peek at what’s there and what’s coming and let me know what you think.
14 Feb 2006
I got my OSCON proposal (“I’m 200, You’re 200: Codependency in the Age of the Mashup”) in under the wire. The theme of the talk is thinking about all the dependencies your web app has – some you’re probably aware of and some you’re not – as well as strategies for minimizing those dependencies and routing around failure.
I’ve got a bunch of examples I’m planning on talking about (if the talk is accepted), but I’d be interested to hear other folks’ experiences in solving related problems – do you have novel methods for caching information, application or network architecture, code structure, or anything else that helps you layer reliability onto a distributed set of resources not all under your control? Let me know!
OSCON is getting bigger every year – it’s interesting to see it grow as the world of open source encompasses more and different kinds of hackers, business people, and others. Like Adam, I’m not picking PHP track talks this year for OSCON, so you can consider this post a relatively unbiased conference plug.
14 Feb 2006
This demo is stupendous. Changing interaction-with-“mouse”-pointer from serial to parallel provides such a wider information flow between you and the computer.
I look forward to when the screens in the demo are commonplace!
10 Feb 2006
lxr.php.net has been around for a while, but since I’ve found myself using it a lot recently, I want to point it out. It’s such a quick way to find the particular file a built-in (or extension) PHP function is defined. Coupled with the revision graph that cvs.php.net can display, it is handy for tracking down exactly when a function was added or a bugfix was committed.
Thanks, lxr!
07 Feb 2006
The new issue of International PHP Magazine is out, with the cover story I wrote on building Ning apps.
The article provides an overview of working in the Ning playground – in addition to all the regular PHP you know and love, it covers using the Ning Content Store, simplifying file uploads, and using our Ajax components.
27 Jan 2006
From with a PHP program, I’d like to make an HTTP request and use the response body in my program. What could be simpler? PHP has a zillion ways to do it, not limited to: file_get_contents(), fopen() and fread(), fsockopen(), curl, and PEAR HTTP_Request.
One additional requirement that makes this slightly more interesting: I don’t want to waste any memory on a response body that’s too big. If I slurp in a giant request body, I might run over my memory_limit.
Here’s what I came up with to solve this problem:
Continue reading “Parsing Reasonably-sized HTTP Responses”
24 Jan 2006
We’re looking for a Sr. Developer at Ning.
If you’ve got solid PHP (or Ruby, or Python) chops, this is a superb opportunity to spend every day working on neat stuff with smart, friendly folks.
Check out the job description and e-mail me (david [at] ninginc.com) if you’ve got any questions.
23 Jan 2006
So there was this inflammatory Techcrunch post about Ning. Diego has already done a good job of walking through the inaccuracies, so I won’t repeat that. The interesting things to me about this whole episode are:
- When it comes to developer relations, (just about) no question or comment should be dismissed. There are the obvious areas -- folks asking for support for new features, reporting bugs, making suggestions on how things could work better. The slightly less obvious category of comments not to dismiss are ones that are just factually incorrect (such as "there's no support for key web service APIs out there that people are really excited about mashing up"). That's still an important piece of feedback to deal with. Ning supports just about whatever web service API you want, since you can stick random PHP code in your app and have it mash up the universe. If someone thinks otherwise, it points not to a technical failing, but a need to educate users and developers more.
- The alternative to constantly tooting one's own horn is not total horn silence. When it comes to publicity, hype, marketing, whatever, I have a pretty typical programmer attitude: no thanks. Show me the code. I'd rather have something silent and functional than lots of promises about the future. To be frank, that's one of the things that made me excited to work at Ning in the first place. The emphasis has been on doing things, not talking about doing things. I can see why people are critical of this approach, but the alternative of pouring too much hype on an early product is worse. I'll join Diego in pledging to blog a bit more about what we're doing. Yoz and I are giving a talk at Etech, too.
- The old saw is true: "all publicity is good publicity." The conversation that sprung up due to the Techcrunch post was pleasantly positive -- lots of great things said about Ning, the repeated point that the product is only three months old, some constructive criticism, and even a suggestion that the back-and-forth about Ning can be an inspiration for political hot-heads.