Proposal accepted for ZendCon08

My proposal "Digging Through the Guts of Enterprise PHP: A Case Study," which looks at PHP usage, techniques, and features as used at my day job at IBM, got accepted for the Zend/PHP Conference and EXPO 2008!

An exploration of the features of PHP used in the Ajax-driven user interface of IBM Rational Build Forge, with a focus on inheritance, interfaces, and Iterators. This talk will demonstrate how we built its user interface on a solid foundation of PHP.

I submitted it shortly after the call for papers opened up and this year, I got in. I've never spoken at a conference before, but it'll at least make for an interesting (and hopefully even successful) experience.

Opera Dragonfly (alpha) Released

Over a year ago, I wrote about the Opera Developer Console. This morning (for me, at any rate), Opera posted Dragonfly, which (two years in the making) offers a completely fresh look at browser-based debugging.

It offers most of the familiar tools for DOM inspection (along with a nice DOM editing capability), error logging (with the same granularity as before wrapped in a more polished UI), a JavaScript debugger that rivals WebKit's Drosera, a JavaScript thread logger, and a lot more that I haven't explored yet.

Time will tell whether Dragonfly can get enough developers to use Opera and keep them there, and how much the developers behind the new developer tools listen to the community in the coming iterations, but so far this looks extremely promising.

Edit: Chris Mills from Opera gave me some additional info:

Part of the reason I haven't found the XMLHttpRequest logger/debugger apparently stems from it not getting exposed yet, though it will appear in an upcoming iteration, along with HTTP header inspection (not just for XMLHttpRequests, of course) and a new "single window mode" which sounds like it will make things much more usable! When using Safari's inspector, I almost always find myself attaching it to the window, and I always had the urge to do the same with Opera's developer console.

Chris also mentioned something which makes me very happy to hear: even though the Developer Tools (loaded via the Tools → Advanced → Developer Tools) download from Opera's server, it only does so the first time, and for each following update of the tools. This ensures that it not only saves Opera's servers when usage takes off, but it also ensures that developers can work offline, and the slow loading of the tools will only happen initially, loading from the local drive after installation.

Written in XML/CSS/JavaScript, Dragonfly will run in all browsers including Opera's Core-2.1 rendering engine (except Opera Mini for some reason), and even supports debugging on mobile devices by way of a proxy setup between the device and the desktop Dragonfly installation! This will prove invaluable for developers of web applications supporting devices, as they will have the ability to use their normal desktop tools to debug on the mobile browser without having to use emulation.

You can find more information in an Introduction to Opera Dragonfly and on the Opera Dragonfly product page (which has a very good start of fleshed-out documentation already, feedback and bugtracking, and of course a blog).

Edited to fix the Introduction to Opera Dragonfly link...

Heading to Google I/O at the end of the month

As an added benefit of living in the Bay Area again, I get much easier access to many of the conferences and events that go on around Ajax/RIAs/etc. May 28-29, I'll take BART into the city in order to attend Google I/O, which looks extremely interesting. Somehow, in the short two days, I need to find my way to the sessions on design patterns, performance, HTML5, open source, and chase down some of the speakers and fellow developers to pick their brains for a bit. Fun!

Part 2 of the Advanced Ajax review went up!

In the midst of things, the second half of the review from Agile Ajax went up! It seems that despite the rather heavy use of PHP for the server-side example code, Brian (apparently more into ASP, JSP, and Ruby) still liked it, which makes me very happy.

Back in February, I reviewed the first half of Shawn M. Lauriat's "Advanced Ajax: Architecture and Best Practices" (Prentice Hall, 2008, 360p). The first four chapters of Lauriat's book, which focused almost exclusively on client-side technologies, impressed me considerably. But it's taken me several weeks to get through the remainder of the book, and there's one reason why: PHP.

The server-side portion of "Advanced Ajax" uses PHP code to illustrate its many and varied lessons about Ajax architecture. It's not that I have anything against the popular web-development framework and scripting language. It's just that, after spending my career in the ASP Classic and JSP trenches and slowly ramping up on Rails in the last year, I'm not the ideal target audience for these code samples. Adding "PHP" to the title of the book might have limited its potential audience, but it also would have been more accurate.

That said, there's a lot of value here for adherents of any server-side framework. Lauriat discusses each topic from a general perspective before diving into the code. The technical approach to a given problem would obviously differ by framework, but the high-level approach wouldn't. If you don't mind skimming past the content that doesn't apply to you, Lauriat's advice about developing stable, scalable, accessible and secure Ajax applications transcends framework allegiance.

Read the rest of the review.

Sidenote: On the Ajaxian post for the review (part 2), Joeri left a comment that really hit on what I tried for in writing the book, almost quoting what I told Prentice Hall when describing the type book I intended to write:

I’ve read this since the last review.
It does a pretty good job documenting the best practices when building ajax apps. This is a book to read when you want to move beyond knowing the basics of javascript and xmlhttp to building a real web app using ajax methods.

Thank you, Joeri! I feel glad knowing that people out there have read the book and gotten out of it something resembling what I had hoped they would.

Vienna + PHP (source code) + iUI

Source posted! BSD License. From the README:

You'll need to do a few things to get this working:

1. Move the extracted vienna directory to /Library/WebServer/Documents
2. Download iUI (http://code.google.com/p/iui/) and put the main iui directory into the extracted vienna/ directory
3a. Setup a cron job to copy ~/Library/Application Support/Vienna/messages.db to the extracted vienna/ directory
3b. For the adventurous: mv ~/Library/Application Support/Vienna/messages.db to the extracted vienna/ directory and sym-link it back to ~/Library/Application Support/Vienna/
4. Make sure to enable web sharing
5. Go to (your computer's name).local/vienna

Book review up on Agile Ajax

Book review: Advanced Ajax by Lauriat (Part 1 of 2) went up earlier today (also linked to from Ajaxian), and so far Brian Dillard (RIA Evangelist @ pathfinder and project lead for Really Simple History) seems to like it:

Because Ajax moves so much application logic from the server to the client, it forces many developers to master a wider range of web technologies than ever before. To work effectively on Ajax projects, front-end developers have to concern themselves with database performance, business logic and other server-side concerns. Back-end and middleware developers, meanwhile, have to make friends with XHTML, CSS, JavaScript and a wide range of browsers. Sure, it's possible to develop Ajax apps in a siloed team environment. But it's not the easiest way, and it rarely provides the strongest results.

Shawn M. Lauriat's "Advanced Ajax: Architecture and Best Practices" (Prentice Hall, 2008, 360p) bridges the gap between developers with exclusive client- or server-side skills. By exploring tools, technologies and best practices for every layer of the Ajax programming model, this solid new programming manual promises to plug the holes in any developer's resume. Lauriat's tops-to-tails approach offers something for almost any developer, but it also guarantees most readers will find some sections remedial. As this two-part review will demonstrate, that's not necessarily a liability.

Read the full review

Vienna + PHP + iUI

So, sick of not having the ability to feed my XML addiction when away from my machine, I took an hour this morning and hacked together a quick'n'dirty iPhone/iPod Touch UI for my Vienna database using MacOS 10.5's standard PHP (with SQLite PDO), iui, and my Vienna database (stored in sqlite3). I gave it read-only access to the database, partly so I wouldn't have to worry about screwing it up, partly because I didn't feel like bothering just yet. I just need to add a "Mark Read" button to make an Ajax call.

I'll ask the Vienna devs if they'd like a copy of the source to toy with and generally improve, since I blatantly stole reused Joe Hewitt's design and markup for iui-enabled Digg.

Note: though my uploaded demo does pull from a copied Vienna database, it does not pull from a live one, since I wrote the code to run on a desktop MacOS 10.5 machine and not a Linux server. I then just made a bookmark on my iPod Touch to my iMac on the local network.

Announcing Universe Conflict!

Posted to the new project space on SourceForge.net:

An implementation of Space War!, one of the first digital computer games, created in 1961 on the PDP-1 computer, as recreated using the <canvas> HTML5 element and Ajax. It uses the Frozen Toolkit for the client-server communication and currently renders all images and animation using canvas and JavaScript objects.

I had always intended to release this as an open source project, but then realized that I didn't really have the full time to dedicate to it. It also currently exists more as sample code and an interactive demo than anything else, and I figured I should just post it for all to see and hopefully for some to contribute. I initially posted the introduction to it on my blog.

The client-side of this game currently works in Firefox and Opera, though gravity and shooting do not yet exist. The server-side of this currently works insofar as the absolute minimum required to send messages from one browser to the other in order for the two players to fly around each other.

At any rate, check out the code (svn co https://@webspacewar.svn.sourceforge.net/svnroot/webspacewar), play around with it, and feel free to submit patches! :-) I would love to see this completed and fully playable. "Space War!" doesn't have a lot of (base) rules, so it shouldn't take much to get there.

Edit: I've also finally, finally checked in the source code for a link checker I started...oh, I think back in 2002... I created the Cocoa/WebKit branch in order to do two things:

1. Learn Objective-C and Cocoa
2. Use the Cocoa/WebKit API in order to take care of the HTTP handling

Opera Developer Console

It figures I would find this as I wrap up the initial draft of the chapter on client-side debugging, but it makes me extremely happy to see it: Opera has started work on a Developer Console, which (among many other things) logs XMLHttpRequest calls.

The Opera Developer Community runs through some of the DOM, JavaScript, and CSS tools, and the Opera Desktop team posted about it over a month ago when they initially started putting it into their development builds.

From what I can tell by peaking at the source (since, like most Opera extensions, they wrote it in JavaScript), it looks like they made a simple wrapper object and replaced the native object (after storing a backup reference for when logging gets shut off again) in order to create hooks into each of the events so it can report everything as it happens.

This means that I can now debug XMLHttpRequest usage in more than one browser, which makes life much easier than either guessing how it went or using a standalone traffic sniffer.

Edited two minutes later to add: you can get it from the Opera Developer Tools page.