outaTiME

We released Adium 1.2.4 today. This is a minor release including improvements to several IM services (AIM direct connect, Yahoo! file transfer, Google Talk buddy icons, ICQ status notes, and MSN contact visibility), as well as crash fixes, visual improvements, and the long-requested ability to make the contact list completely transparent. The full change list is, as always, available on our support wiki.

(Via Adium News.)

The moment has arrived. I’ve been anticipating this since the first new fixes to trunk were made, shortly after the 1.0 release. I am proud — no, elated — to announce what marks another solid run of around-the-clock development: The Dojo Toolkit version 1.1

There were two goals: Preserve API Compatibility, and continue to innovate. With over 800 marked bugs addressed, and countless DojoX enhancements landing, it’s easy to forget exactly what has been going all this time. We’ve written up 1.1 release notes to browse as a starting point, the changelog is available, and most importantly, the download is in place. Check it out, give it a test drive.

Its difficult to not sound giddy — a lot of hard work has gone into making this the best Dojo release to date: Over 30 core developers and countless numbers of new community contributions — all working in parallel for the good of Open Source, to make available to you a high-quality DHTML Toolkit, free of charge and free
of restrictions. We’re proud to roll this out today, and hope you enjoy this next iteration of Dojo excellence.

There so many new things, it is difficult to pick a starting point. Rather than duplicate the release notes, I’d like to take a second to point out some of my personal favorites:

Client-side syntax highlighting – The highlight.js project was contributed under CLA by Ivan Sagalaev. If you aren’t using Dojo, the original highlight project was toolkit independent. We’ve enhanced Ivan’s already cutting-edge highlighter by making it work transparently with the Dojo Build system, and scoping the namespace pollution down to a single variable. One of the most interesting aspects of the highlight system is automatic language detection, something not seen in other highlighting engines. Ivan is a JavaScript hacker and Django contributor / enthusiast, and it’s been a pleasure working with him to port this code (though our own talented Eugene Latzukin did most of the heavy lifting). We look forward to other new innovations from Ivan. We’ve introduced a number of new theme sets and language definitions as well.

“Teh Sexy” – Another great CLA contribution that appears in the 1.1 release: The entire set of flash easing functions originally written by Robert Penner in ActionScript, and ported to work with Dojo’s Animation system by SitePen’s Bryan Forbes (whom I refer to as my ‘maff mastermind’). These functions easily and subtly add an element of flair to any rich web application. The functions appear in the dojox.fx project, and can be passed directly to any _Animation instance with the easing: property.

BorderContainer – My new favorite Dijit. BorderContainer is the new LayoutContainer of Dojo. It’s just _good_. Making window-level Applications just got a whole lot easier. Specify a region, pass it a ContentPane (or eight), set some options and it’s good to go! The reusability of ContentPane and the power of dijit._Templated makes for really easy custom containers. BorderContainer is slightly more exciting to me now than StackContainer, though the nature of BorderContainer allows us to embed StackContainers and other BorderContainers — pretty much any widget — as children to become their own defined “region”.

dijit Themes! – Tundra received a lot of polish, and Nikolai Onken wandered in from the Dojo community one day — carrying a brand new theme (Nihilo), and an updated version of Soria. He’s been a great gain for the Dojo Community – tirelessly working with me on DojoCampus, and continually enhancing the overall look and feel of the toolkit. It’s great to have him on board, as well as the other newly active contributors that troll #dojo and otherwise continue to make Dojo rock. Its a big team effort, and a lot of work, and the quality of the 1.1 release is a testament to that effort.

Its important to note that while all this great new stuff has landed in Dojo since 1.0, we’ve still managed to maintain near perfect API compatibility. There seems to be a misconception that a transition between Dojo versions is difficult. With our growing list of porting-guides, it definitely seems as though there is a lot going on and a lot to keep up with, but rest assured: The 0.4 -> 0.9 transition was a one time deal. Porting from 0.4 -> 1.1 is nearly identical to Porting from 0.4 -> 1.0, or to 0.9 for that matter. If you are using a legacy 0.4.x code base you don’t need to “port to 0.9 first”, though reading the guide written during the 0.9 transition will be infinitely helpful. We’ve made the changes we needed to, and will once again maintain API consistency, following our own deprecation cycle rules from here out. You can have that peace of mind.

So, with that I leave you. Enjoy the 1.1 release! Back to work for me … time to go make 1.2 even better than 1.1.

I joke and say “real men work from trunk” – so if you are interested, don’t forget to visit: http://archive.dojotoolkit.org/nightly/ for daily updates.

(Via The Dojo Toolkit blogs.)

Today a new release of clubbers compilation comes, to play the record click here.

Track list:

1. Martin Solveig – C’est La Vie (Original Club Mix)
2. Robbie Williams – Lovelight (Soul Seekerz Vocal Mix)
3. Mariah Carey – Touch My Body (Seamus Haji Club Mix)
4. Alex Party – Read My Lips (Chris Ortega and Thomas Gold Remix)
5. Buzzjunkies ft Elesha – If You Love Me (Moto Blanco Mix)
6. Mary J. Blige – Just Fine (Scotty K. Vocal Klub Mix)
7. Whelan & Di Scala – Never Let Go (Tom Novy Remix)
8. Kelly Rowland ft Travis Mccoy – Daylight (Joey Negro Club Mix)
9. Hot Chip – Ready for the Floor (Album Version)
10. The Whitest Boy Alive – Golden Cage (Fred Falke Remix)
11. Bajofondo Tango Club ft Gustavo Cerati – El Mareo

The launch of Adobe Photoshop Express has been much anticipated. We are seeing the move of a large software company going from desktop to Web for a major application.

As Erick Schonfeld points out “Photoshop Express is by no means just Photoshop ported onto the web.”

I am a big fan of Picnik and for awhile was using it quite regularly, so I wanted to see how they compared.

It seems like Photoshop Express is pretty limited and seems very much focused on taking images, putting them online, and doing little touch-ups. One of the things that I am always doing is taking a picture and adding text and shapes to it, and this isn’t available, so I kinda don’t know when I would use this other than for simple cropping and resizing.

The interface is sleek and Flash-y but somehow doesn’t feel as nice as Picnik to me…. I don’t know why.

View Source has some fun though:

What do you think?

(Via Ajaxian.)

Thierry Parent has released a new version of TraceTool, his open source tracer program, with a JavaScript client.

The javascript TraceTool API is a cross browser (tested under Internet Explorer 6, Internet Explorer 7, Firefox 2 and Opera for mobile) and cross domain tracing solution (maybe the first one). The viewer can be installed on any windows PC (localHost for example) while you are displaying a page from another server. Debuging a Web page from your mobile is very easy. Just configure the TraceTool JavaScript client to use the viewer on the network.

To allow sending traces to another server as the original page (Cross domain communication), the API does not use Ajax (Single domain) but dynamic script creation. Traces are encoded and passed in parameter to the viewer. Large trace messages are split into multiple scripts.

With this API , you can send simple traces, objects , dump, call stack, manipulate traces (sub traces, delete, append,…) and more.

An ideal complement to firebug and a great enhancement to IE debugging with one API for Java, JavaScript, .Net, Delphi, C++ and ActiveX.

(Via Ajaxian.)

Alex Russell, one of the writers of the Bayeux protocol, says that Michael’s complaints are fundamentally flawed.

Part 1: Greg’s explanation of the need for Bayeux
Part 2: Michael’s criticisms of the current state of Bayeux
Part 3: Greg’s response to Michael
Andrew Betts’ thoughts (from a related article)
Part 4: Michael’s response to Greg
Part 5: Kris Zyp’s thoughts
Part 6: Alex Russell’s response to Michael

Vaguely Correct vs. Precisely Wrong

My attention was drawn today to re-reading the Battle of Bayeux series again, and as I re-read Michael’s response to Greg which said that Bayeux has an “unrealistic agenda”, I couldn’t help but feel that Michael (and many others I’ve talked to) have simply missed the entire point of Bayeux, which is to specify enough structure to grow the number of interoperable Comet clients and servers while leaving enough to the implementations to allow integration of piecemeal evolution until such a point as the protocol itself is unnecessary.

Reading many of Michael’s complaints about Bayeux, I’m struck by his ardent desire for the protocol he’s implementing to be the right one. Or rather, for the description to be so air-tight as to enable full automated testability, interoperation, and even the integration of concerns such as URL mapping and eliding handshakes as first-order priorities for any “worthy” spec. Perhaps if the authors-to-date who have contributed to Bayeux could count on the world not changing, we might agree that Bayeux should define client APIs or that it should get super-specific about how to handle multi-frame. But why? And why right now? And who is that good for?

Let’s assume for a moment that Bayeux specified a multi-frame strategy. Today, given the limits of browsers, any such specification will be writing into stone what is essentially a series of browser-specific hacks. Indeed, while the entire Bayeux spec is a reaction to browser deficiencies, it seeks to avoid prematurely writing those bugs into stone tablets. Had we fully specified a multi-frame solution when we started work on Bayeux clients and servers, the demands of terseness and clarity would have demanded that we write into stone an “IPC over cookies” protocol which uses timers in cooperating frames to send/receive packets of encoded data which is re-constructed and re-evaluated on the other side. Today, the “duh” thing to do would simply be to use the HTML 5 DOM Storage provision and notify library authors to hack around it for old browsers for the time being. In another 18 months, the entire point will likely be moot as browser vendors get wise to Comet and provide us with ways around the 2-connection limit at an HTTP level. When that happens, multi-frame concerns are just legacy features. The point here isn’t that one solution is better. It’s that 18 months ago, we didn’t know the future, but were sure enough of our own fallibility to avoid wild goose chases for what is, essentially, a client concern. The “right” solution has changed in the last 18 months. More to the point, how multiple Bayeux clients in a single process communicate to a server has zero bearing on the semantics of the messages which Bayeux exchanges. Addressability amongst peering tabs is, from one view, purely a client issue which clients should be free to experiment and iterate on. Indeed, much of Michael’s argument seems to be predicated on the supposition that he can do things better. Of course he can! That’s the whole point!

The furthest down the path of picking sides that the protocol currently goes is to specify that servers MUST implement at least the long-polling transport, and leaves the API which is exposed on either end to implementers. Clients and servers may then implement other transports and negotiate which one to use via the specified mechanism (although this can also be elided without violating the spec). This is entirely by design, and we expect that there will be revisions and addendum’s which outline recommended APIs once enough clients and servers exist to know what the right thing to do is. The long-polling transport is the small, critical, core of network-level semantics that when combined with client-level semantics can serve to guarantee interoperability. Not only do we expect that the long-polling transport will be the worst performing transport for a given combination of client and server, we also anticipate that it will be the least likely to be used in large-scale production sites. But you don’t have to care about that if you’re just adding Comet to a small blog….all you want to care about is that your server and your client can talk to each other. It is this entry-level sector of the market which Bayeux is aimed at enabling, while still providing enough play in the joints to enable those with different requirements to handle them within the loose framework of the spec. This isn’t not doing the hard work, it’s being smart enough to know that the hard work we do today will not survive long should we over-adapt to a particular environment only to find that is changing underneath us.

As with many kinds of engineering, the best performance requires the greatest adaptation to the current environmental constraints. Bayeux seeks to enable that evolution to local constraints without over-burdening the market with fundamentally incompatible clients and servers over the long haul. Where Bayeux “waves its hands”, it does so for good reasons; ones which we feel outweigh the short-term costs (which Michael is quick to enumerate).

Bayeux, as a spec, is built with the understanding that the environment is changing, and that competition amongst implementations is good only insofar as it doesn’t cause huge amounts of lock-in. By specifying a thin layer of semantics about messages and transports and by building extension and plug-in points directly into the protocol, Bayeux has lead to successful evolution already. From cross-domain long-polling using JSON-P to Flex clients which speak optimized wire formats to a profusion of interoperable servers in many languages, Bayeux is succeeding by leaving enough play in the joints to meet reality, today’s and tomorrow’s, half way and then letting implementations figure out the rest.

There’s a long way to go in making Bayeux better, and we know we’re not done yet, but let’s be clear that by omitting things from the core of the spec, we are not calling them unimportant, just unsettled and not absolutely required for interoperability.

(Via Comet Daily.)

As part of Mozilla Corporation’s ongoing stability and security update process, Firefox 2.0.0.13 is now available for Windows, Mac, and Linux for free download from http://getfirefox.com.

We strongly recommend that all Firefox users upgrade to this latest release. If you already have Firefox 2.x, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting “Check for Updates…” from the Help menu.

For a list of changes and more information, please review the Firefox 2.0.0.13 Release Notes.

If you are still running Firefox 1.5.0.x, you are highly encouraged to upgrade to the Firefox 2 series as Mozilla ceased supporting Firefox 1.5.0.x in May 2007. Simply choose “Check for Updates…” from the Help menu to begin the upgrade process.

(Via Mozilla Developer News.)

I spent last week holed up writing part 4 of Ajax Overhaul, my series of articles for IBM developerWorks. Aimed squarely at Ajax beginners, the series shows how to progressively enhance Web 1.0 sites with jQuery and Ajax. Each installment starts with the pre-Ajax version of an example e-commerce application and takes readers through the steps of retrofitting it to improve and modernize the user experience. The tagline for this installment is "Streamline multi-step processes with tabs and Ajax forms," a topic that allowed me to employ two of my favorite plug-ins for the jQuery open-source Ajax toolkit:

• jQuery Form, which gives jQuery several methods for serializing form data and submitting the results via Ajax.
• jQuery UI Tabs, which turns a series of divs and unordered lists into a tabbed interface.

I feel like I’ve run on and on about my enthusiasm for jQuery on this site, but I can’t help it. One of the cool thing about its plugin ecosystem is the ease with which you can cross-pollinate a couple of plugins to create novel effects. In this case, I wanted to take a series of web forms – the checkout process for my example shopping site – and turn them into a single-page, tabbed interface in which each tab represented one step of the process. The biggest additional requirement was progressive enhancement; with JavaScript absent or disabled, the checkout process has to work like it did before I retrofitted it. All it took to accomplish these goals was a judicious mix of my two plugins.

jQuery UI Tabs allowed me to pull several individual form pages into a single HTML shell via Ajax. It also allowed me to control which tabs were selectable at any given time; that way, users could jump back in the process to re-submit one of the earlier forms but couldn’t jump forward to fill out forms out of order. This was important because in my example application, input in the earlier forms can affect the output of subsequent forms. Jumping back allows you to change your input, but it forces you to repeat all the intermediate steps over which you skipped.

Luckily, jQuery UI Tabs allows you to enable and disable tabs with ease. You can disable them as a group in the options bundle you use to initialize the tab set. Then you can enable or disable individual tabs by calling the appropriate methods on them. In my example code, it made sense to disable all but the first tab by default. Then I provided a custom callback function that executes each time a new tab is selected, cycling through the list and disabling all but the previous tabs in the process. The resulting code, executed when the DOM is ready, looks like this:

var tabSet = $('ul.navTabs').eq(0).tabs(	{		/*apply a nice visual effect to tab activation*/		fx: { height: 'toggle', opacity: 'toggle' },		/*disable all but the first tab by default*/		disabled: [1,2,3,4]	}).bind('select.ui-tabs', function(event, ui) {		/*		ensure that each time a new tab is activated		all subsequent tabs are disabled. This will		prevent users from jumping around in the process		*/		var currentTab = parseInt(ui.tab.id.substring(3));		var tabSetLength = 5;//hack; UI tabs doesn't know its own length		for (var i = 0; i < tabSetLength; i++) {			if (i > currentTab) {				tabSet.tabs("disable", i);			}		}});

jQuery Form, meanwhile, provided the plumbing for the individual forms that I plugged into the tabs I’d just created. It allowed me to redirect the submission of each form so that it occurs via Ajax and the response gets rendered inside the next sequential tab. This all happens thanks to the power of the ajaxSubmit method that the plugin adds to the jQuery object. jQuery Form does offer a simple Ajax submittal method, ajaxForm, but the more versatile ajaxSubmit method provided the flexibility I needed. It let me pass in a target DOM node in which to render the response, override the action URL of the original form tag and define a custom callback function to enable and select the tab representing the next step in the process. The code for each individual form varies a bit, especially for steps in the process that include detours (such as logging in or applying a discount code). But here’s a typical example:

//bind the form and provide a callback function$('#sform').submit(function() { 

	//submit the form via ajax	$(this).ajaxSubmit({ 		target:     '#billingDetails', 		url:        'checkout3-fragment.html', 		success:    function() { 			var tabSet = $('ul.navTabs');			tabSet.tabs("enable", 2);			tabSet.tabs("select", 2);		}	});

	//don't actually submit the form normally	return false; });

As always, it will take a few months for my draft to make it through the editing process and onto the developerWorks site. But you can take a peek at the above-quoted code in action over at Pathfinder Labs. FYI for anybody peeking under the hood: My example app is just a front-end mockup with no server-side code to support it.

If anyone’s remotely interested, you can also monitor the Ajax Overhaul page on developerWorks to see when the actual installments get published.

(Via Agile Ajax.)

Aptana Jaxer has been updated to 0.9.5 providing increased performance for server-side JavaScript and a host of other enhancements to make End-to-End Ajax development easier.

Aptana Studio users can get the latest via Help > Software Updates. Otherwise, download the latest now.

• Increased Performance
  • Aptana Jaxer’s core is now based on Mozilla FireFox Beta3 and thus delivers improved JS performance and memory management.
  • Jaxer now pre-parses scripts to bytecode for faster execution during callbacks.
• More Natural JS Environment
  • Window and document objects on the server-side now parallel more closely how you work with them on the client-side. This means a more natural coding style with server-side JavaScript in Jaxer and a more browser compatible experience.
  • Jaxer no longer inlines external scripts to the page, this allows for correct use of browser cache on client side content and makes ‘view source’ a much more pleasant experience. This also applies to Jaxer’s ClientFramework (the client-side JavaScript Jaxer puts in pages to facilitate callbacks and remote method invocation). Instead such external scripts are cachebusted with the buildnumber so that upgrading the server will automatically expire any old client side cache copies.
  • A new Autoload feature has been added to allow for a script to be cached so that during callbacks the script does not have to be loaded on demand (thus faster) and the previous oncallback function used to setup the callback environment is no longer needed for library loading. A configuration option is provided to expire the script every time the containing page is accessed. This is allows for simpler development and is the configuration with which Jaxer show ships.
• Improved Platform Support
  • Significantly improved Unix support. Jaxer now builds and runs on Solaris too!
  • mySQL support is now also provided for Mac OSX
  • A number of Windows Vista security/UAC related problems have been addressed
• API Enhancements
  • Jaxer’s file system API has been updated — mostly around the ‘quick’ static method. For example: Jaxer.File.chmod(‘myfile.tx’,0400)
  • A simple Stopwatch timer API now allows for timing measurements in code.

(Via Aptana Blog.)

Nitobi ran a survey on Ajax technologies, and you (Ajaxian community) helped out in giving them your feedback.

They just released the results which consists of 570 answers. You must always take results with a grain of salt, since there are quite a few more designers and developers than 570 our there, but it is always fun to analyze. Often the results tell you more about the niche of people that the surveying group has access too than the global truth (e.g. the Ajaxian group skews to a slightly more advanced user base that doesn’t mind getting dirty).

The responses that called out to me were:

Which development platforms are you using?

Java and PHP took the server side piece home (many said they were HTML/CSS front end folks). If you aggregate the Java technology (Java, JSP, Servlets, JSF) you get 394 versus PHPs 296, although it is hard to compare since you could choose “all that apply”. I am willing to bet that if you are doing JSF now, you may well have done Servlets, JSP, and other!

Which development tools do you use?

Eclipse and Dreamweaver had the most votes here, with a large number of Notepad people (teasing?). Textmate was that low?

What causes you the most pain in designing and development websites?

• Browser compatibility: 303
• Testing: 114
• Javascript: 65
• CSS: 36
• Deployment: 34

Why do you choose to use Ajax?

• Improve user’s experience: 276
• I want to build slicker applications: 38
• Easy to use: 29
• My boss wants it: 25
• Saves time: 13
• Saves money: 2

What toolkits or frameworks are you using in your projects?

This was quite a different result than from our last survey.

• jQuery: 144
• Prototype: 143
• Scriptaculous: 127
• YUI: 99
• Ajax for ASP.Net (Atlas): 91
• Mootools: 65
• Dojo: 63
• ExtJs: 61
• Nitobi: 61
• Spry: 29
• GWT: 19
• JMaki: 6
• Mochikit: 2

Here is the spreadsheet of the full results

(Via Ajaxian.)