brentashley

I’ve been reading the IE Blog which the IE development team hosts. I’ve started to notice that every time I see an entry it’s someone else and they’re all “Program Managers”. Is EVERYBODY a PM at MS? Is there nobody that actually DOES anything? Sounds like layered middle management run amok. From the names and titles I can see, IE seems to be divided into so many separately managed projects that they must have program-manager-managers that just coordinate information flow amongst the program managers. Yeesh.

[via David Crow]

BarCampEarthToronto takes place this weekend. I can’t make it for the event itself but I plan to be there with my family for the barbeque on Sunday.

Hope to see you there!

I’ll be at the Bodega on Westgate Road near the Central Station in Newcastle at 5:30 or so on Thursday evening Aug 10th, having a yap with some of the local Newcastle web development community. If you happen to be in the area, be sure to drop by.

I was at DemoCamp 8 last night and as usual stayed later for the social networking. I got into a discussion with Pete Forde and others about who does what.

I have real trouble explaining to people what it is that I do. I often try to explain the nuance between being a scripter (which I am in spades) and a programmer (which I am not exactly) and the distinction falls short of conveying the gestalt that is the technical side of me.

I spend a lot of my time making a whole mess of things work together that were never meant to be integrated. It often takes a wide and deep range of knowledge to figure out the bits. I have variously called myself a technical spot-welder, a duct-taper, a spelunker, and a special-ops data diver, trained to get in under the wire and get out with the data.

Here’s an example – at one of my clients, something we do is give realtime tests against devices in the field. A diagnostic page could tell you, for instance, the contents of the ARP resolution table on a remote router. There is a bunch of magic that goes on behind the scenes to do this (simplified here):

• the user presses the “get ARP table” button
  • the external portal web server (ASP.NET/Win2k3/MSSQL) makes a SOAP call to get the information
    • the soap call is received at an internal webservices server (Apache/PHP/BSD)
    • connection information is resolved against a PostgreSQL database
    • a shell script is invoked on the webservices server
      • the shell script uses ssh to connect over a secure tunnel to an API server at the customer premises that can route to the destination
      • a script is run on the API server (bourne shell, perl, telnet, curl, grep, sed, awk, lynx etc)
        • the script connects to the router, logs in, displays and parses information, logs out
    • info gets routed back to webservices server via the ssh connection
    • php assembles SOAP response
  • ASP.NET receves SOAP, builds result page
• Result received by user

I make all that stuff happen.

Now how do I distill that into an elevator pitch?

Last week I received a complimentary copy of fellow Torontonian Peter Lavin‘s new book, Object Oriented PHP, published by NoStarch Press. I’ve had a couple of really good books from NoStarch (Absolute OpenBSD is indispensable if you use that OS) and this is no exception to that trend.

The book introduces Object Oriented programming to PHP programmers, starting with PHP4’s OO implementation and demonstrating the advances made with PHP5. A simple web application is built by starting small and making incremental changes, sequenced in such a way as to introduce OO concepts and solutions in a natural way, increasing in utility and complexity as the lessons progress.

I’m only a few chapters in right now – there is certainly more to the book and I’m looking forward to the rest.

The companion website has a lot of useful reference material and links to resources, as well as the book’s code and errata.

(via Ajaxian) IBM Developerworks has just published an Ajax Transport Method tutorial that describes a few of the alternatives to XMLHttp and provides example code to make them work.

For a more complete reference to all the available Ajax Transport layers, see my constantly evolving Ajax Transport Layer Alternatives presentation documentation. As someone who has actively used and promoted these techniques since 1998, I can say that I’m pretty familiar with the entire gamut of methods and their pros and cons.

The universal acceptance of the Ajax meme only became possible after more than 7 years of evolution and convergence of tools and techniques – CSS and DOM for presentation, XML and JSON for encoding, and various transport layers.

Much of the experimentation that took place during this time was centred around finding a way to transport data to and from the server in the background. Java applets, frames, layers, hidden iframes, image tags, script tags, XMLHttpRequest and Flash were all put to the test, each solving parts of the problem but mostly failing on compatibility, reliability or unwanted sideffects. XHR’s failure to take hold for the first 5 years of its existence was due to it being implemented as an ActiveX control only available in IE.

When Mozilla, Opera and Safari included the XMLHttpRequest object, it finally became the “good enough” solution upon which the Ajax juggernaut was launched.

While XMLHttpRequest has served to bring us to this stage in the game, it has some serious shortcomings that limit its long-term utility. As far back as 2002, Scott Andrew LePera pointed out an as-yet unfixed implementation problem, and more recently, Alex Bosworth enumerated a whole raft of issues. Harry Fuecks has spoken eloquently about network reliability and latency, the solutions to which would be best addressed with better control over timeouts, retries and error handling than XHR can provide.

As I’ve mentioned many times, Douglas Crockford’s JSONRequest proposal is one of the first real attempts to begin the discussions necessary to bring the changes about that will solve these issues. There was futher discussion at The Ajax Experience that included the major browser vendors, so I’m hoping that some from these beginnings, momentum will build.

Until there is a purpose-built Ajax transport built into browsers, advanced developers may want to learn all of the ins and outs of the different alternatives in order to choose the one that best fits the problem they are solving.

Jordan Frank of eBusiness Applications had an article on Ajax development published last November, in which he describes some of the Javascript debugging tools available.

I met EBA’s CEO Andre Charland at Ajax Experience and we shared some Canadian hilarity, as you do. Seems these EBA guys are all hella brainy.

Michael Mahemoff talks about Ajax transport layers and their problems.

In my Ajax Experience presentation last month, I covered all the available transport layers, their history, pros and cons, and provided some example code. My main intention in doing so was to demonstrate that there has been over 8 years of evolution of Ajax-related techniques to bring us to where we are, and to underline that Ajax is not a done deal, there is still work to be done.

The ReadyState 3 issue that Michael talks about has been well known (well, apparently not well known) at least since Scott Andrew LePera described the problem in late 2002. It really needs to be fixed.

Cross-domain issues also still need to be addressed. I spoke to Brendan Eich from Mozilla about this at the conference and he mentioned that there are other W3C specs that use access control lists, which may provide an existing base upon which to build an XMLHttpRequest ACL model. Laurel Reitman on the IE7 Team was also involved in discussions about this issue.

Douglas Crockford‘s JSONRequest proposal goes a long way towards suggesting solutions to the various limitations of the current state of available Ajax transport layers.

Jesse James Garrett communicated very clearly in his keynote that Ajax is no longer an acronym to be limited to its original initials. According to Jesse, as long as these two basic ingredients are involved, what you have is an Ajax application.

• asynchronous interaction model
• browser-native technologies

Hopefully, organizations like the new OpenAjax Alliance will be able to reach consensus on what needs to be done and how in order to take us to the next level in Rich Internet Application evolution.