Tools: Posts

This. Is. Brilliant.via ajaxian:

Steve Souders, performance architect at Yahoo!, announced today the public release of YSlow.

Stoyan Stefanov reviewed it briefly and gave tips for custom scoring at his blog.

What’s YSlow?

It’s an extension to Firebug (yes, correct, Firebug, not Firefox) that helps with performance optimization efforts. It scores your page on the scale A to F, based on compliance with Yahoo’s performance rules. It’s a tool that has been used internally at Yahoo and is now released to the world.

Steve is going to be speaking about YSlow at the Ajax Experience that just kicked off. I am looking forward to meeting him and check out the tool. We should give it a run on your sites and post how you did (don’t run it on Ajaxian ;).

Over on the Mootools forum digitarald (a contributor to Mootools) has posted date.js, a date parsing script that converts just about any date a user could imagine entering into a field into an actual date. I'm probably going to add this to our /mootools.extensions/Native folder and integrate it in with our own date.picker.js.

History Manager

Here's another digitarald script that I'm eyeing with a bit of interest, a state manager for ajax environments. From his site:

“Ajax History”, “Back-Button”, “Ajax Bookmarks”, call it however you like. This is an unobtrusive MooTools plugin to allow history handling for multiple modules, try it out. It can handle back/forward history actions and bookmarks with the location hash.

Features

• Allow users to bookmark your ajaxified application in the current state
• Forward/Backward history browsing for your Accordion and every other
• Save states of One-Page-Applications over sessions
• Change easily default options and customize the behaviour with Events

New Mootools Blog

The Mootools site now has a nifty blog and it's got some great stuff on it already. First up is a quick set of reference links to everything you need to learn javascript. Many of these things are stuff I've linked to in my side-bar or in various posts, but it's a nice collection for sure.

SlickSpeed

You might have seen this show up on Ajaxian, but the Mootools gang released Slickspeed, a set of browser tests for dom selector comparisons for various browsers:

IE Debugger: My DebugBar

Here's a new debugger for IE that looks promising. I haven't fooled around with it yet but if anyone has or does, post a comment with your thoughts!

Google Gears

If you've followed ajaxian in the last two weeks no doubt you've seen this already, but Google launched Google Gears a week or two ago. In their words:

Google Gears (BETA) is an open source browser extension that enables web applications to provide offline functionality using the following JavaScript APIs:

• Store and serve application resources locally
• Store data locally in a fully-searchable relational database
• Run asynchronous Javascript to improve application responsiveness

Sounds promising. Here's a nice little write up from Uriel Katz.

Fx.Morph

Was glancing through the demos at http://demos.mootools.net and stumbled on to Fx.Morph, a short little Fx class that transitions an element's properties from one css class to another. I wrote something like this a few months ago but ultimately decided I didn't really need it but now I'm giving it a second thought.

We're working on an internal build system here at CNET that is a mixture of things like Mootools download builder and Dean Edward's /packer/ so that we can quickly include just the javascript that's needed on a page.

Today's post at Ajaxian shows that we're not the only ones working on such a thing. Our solution though will likely be very specific to our application development, so I don't know if we'll be able to release it. In the comments of the post below, I also found a link to packtag, which seems to be an open source Java version of this very same functionality.

Via ajaxian:

We love to play with the plumbing don't we. jscsscomp is the latest compressor that uses Nicolas Martin PHP version of the Dean Edwards JavaScript Compressor.

With a swish of mod_rewrite:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*\.)(js|css)$ jscsscomp/jscsscomp.php?q=$1$2 [L,NC]

you can get your JavaScript like this:

PLAIN TEXT

HTML:

<script src = "/jscsscomp/yahoo.js, dom.js, event.js, effects/dragdrop.js, slider.js"></script>

So over at Ajaxian today they have a post on Dean Edward's latest update for his excellent packer javascript compression tool:

Dean Edwards has released Packer v3.0, one of the top utilities to squeeze your JavaScript like a lemon.

• respects Microsoft conditional comments
• new option to shrink variable and argument identifiers
• removed the special chars feature
  
  (except the ;;; feature which people seem to like)
• some bug fixes:
  • packer no longer closes spaces between the +/- operators so code like this is safe: c = a++ +b;
  • the throw"error"} bug that affected Safari (this is a Safari bug really but packer gets around it)
  • the __proto__ bug for Mozilla browsers (this only affected the online version of packer)
  • a minor parsing bug affecting the detection of regular expressions
• simplified the user interface

Update:

The problems I outline below are fixed. Thanks Dean!

Unfortunately, I ran one of our libraries through it and found two issues that we'll need to address before we can use it (luckly, I have a local copy of the previous version of the Packer...):

• 'http://...' breaks. Your packer wants this to be double quotes ("http://...").
• /*comment*//*followed by another comment*/ breaks. This happens in our code because we concatenate several files together and each file starts with comments and ends with comments.

I emailed Dean. Maybe he'll have a fix. If not, we'll have to figure something out or use the old one.

Another topic we've been discussing lately is unit testing. This is especially tricky when you're writing code that requires a specific context, but even if we had an automated test for all our common libraries - which assume no such context - I think it would help dramatically. Here's a recent post on Ajaxian about Squish, but, as noted in the post, Selenium seems to be the current favorite for this kind of task...

Squish for Web is a GUI testing tool aiming to be well suited for testing Ajax GUIs (and has special
support for many frameworks such as Backbase, dojo, ICEFaces, qooxdoo, JackBe, etc.)

The Squish for Web edition enables testing HTML-based Web and Web 2.0 (Ajax) applications in different web browsers running on different platforms.

Squish for Web is, unlike many available web testing tools, not restricted to a single web browser or platform. Squish for Web supports running and recording tests for web applications in Microsoft Internet Explorer, Mozilla, Firefox, Apple's Safari and KDE's Konqueror on Windows, Linux, Unix and Mac OS X.

Demos

• Introduction to Squish
• Testing a backbase application

Selenium seems to be the de facto standard these days, but we can always do with new tools to help us test. What do you use?

Just today I was asked over in the Mootools forums why we don't create a dependency map like the one in Mootools. My answer there was, basically, that the common code we publish here on clientside is but a small portion of our library. Our javascript spans numerous teams, sites, and applications, and keeping a map like this by hand is probably not practical.

Then today on Ajaxian there's this post about T.J. VanSlyke's alterations to Dean Edward's Base.js to allow him to generate a dependency map of all the classes he writes. This isn't quite the same as mapping out file-by-file dependencies, but it's a start. Considering that Mootools is largely based on Base.js, this shouldn't be too hard to incorporate over there. | Read the rest »

Part of writing clean code that doesn't cause you grief in esoteric browsers is doing the best you can to ensure that your code is completely syntactically valid. My pal Valerio (principle author of Mootools) pointed out how to turn on strict warnings, which I couldn't get to show up in Firebug, even though I enabled them there.

The problem turned out to be the excellent Web Developer Toolbar which, if you haven't installed, you should.

The issue is that the default setting in Disable > Javascript > Strict Warnings is to suppress these errors, so even if you enable them in Firebug, you won't see them. You have to enable them in both places. | Read the rest »

via Ajaxian and pertinent to some of our security efforts:

Shreeraj Shah has published a paper on Crawling Ajax-driven Web 2.0 Applications.

Crawling web applications is one of the key phases of automated web application scanning. The objective of crawling is to collect all possible resources from the server in order to automate vulnerability detection on each of these resources. A resource that is overlooked during this discovery phase can mean a failure to detect some vulnerabilities.

The introduction of Ajax throws up new challenges for the crawling engine. New ways of handling the crawling process are required as a result of these challenges. The objective of this paper is to use a practical approach to address this issue using rbNarcissus, Watir and Ruby .

It really shows how powerful tools like Watir are.

Today on Ajaxian there's a post about Joe Hewitt's recent presentation where he demonstrates the nice new features in Firebug 1.0 (note that the ajaxian post actually includes a video of Joe presenting Firebug from last may, which I think is an error as the post refers to this most recent presentation). If you haven't had time to fool around with Firebug, or feel like you're not getting everything out of it that you can, you really should watch this presentation.

What are you waiting for? Get Firebug now.

One year and twelve days later I am happy to announce that the leopard’s growl has been quieted to a purr, clearing the path for the final Firebug 1.0 to make its way in the world.

If you read this blog, that won’t mean much to you personally since you’re probably already using 1.0 beta. However, there are still tens, maybe even hundreds of thousands of people who are still using 0.4.1 and are going to get a very nice present the next time they restart Firefox.

Thanks to all the people who have supported Firebug during its infancy, especially those who have contributed new ideas and donations to the project. We’re just getting started here! If nothing else, I hope Firebug inspires the makers of other browsers to invest more time in development tools. The web development paradigm wants to evolve, but we can’t build the future with yesterday’s hammer.