Web Info & Tutorials

We went through Google Code and did a lot of work to get it running faster.

The team used a lot of the principles from Steve Souders book: High Performance Web Sites and ended up with a nice gain:

According to our latency measurement stats, the user-perceived latency on Google Code dropped quite a bit, anywhere between 30% and 70% depending on the page. This is a huge return for relatively small investments we’ve made along the way, and we hope you’ll find these techniques useful for your own web development as well.

The changes were low hanging fruit that most of the sites could also implement:

• Combined and minimized JavaScript and CSS files used throughout the site
• Implemented CSS sprites for frequently-used images
• Implemented lazy loading of Google AJAX APIs loader module (google.load)

Asciify is a new library that draws ASCII art for you, so it had "Friday" written all over it:

There are trends on the web (as in real world) that last days or weeks and there are things that became a classic form of expression of the geek culture and are still interesting to explore after 20+ years.

Ascii Art is one of these things. If you don’t know what ascii art is you’re probably reading the wrong blog, however for the one or two that doesn’t know about it, here you can learn more about it: Ascii art on wikipedia.

I always had in mind the idea to create an actionscript class to render ascii art from pictures and now with as3 this is going to be possible at decent speed.

My class is called Asciify and it can actually “ascii-fy” every DisplayObject instance on the display list.

It is simple to use too:

Takes me back to my insanely cheesy .sig files from many years ago:

         \\|//
         (o o)
+----oOOo-(_)-oOOo--------------------------------------------------+
|   dionXalmaer.com   |               FREE TIBET *                  |
| www.almaer.com/dion | * with any tibet of equal or greater value  |
+-------------------------------------------------------------------+

Dustin Machi has written about his dojox.analytics package:

dojox.analytics is a small project, both in aspirations and in size. It has a simple goal of logging browser and application data to the server for review. This data can be used to monitor application performance, effectiveness, and quality, or it can be used for custom data collection to identify or monitor a business-specific use case.

The software is a tiny little logger that has a very loosely defined plugin system. It is a collection of objects that monitor some specific aspect of an application or its environment and then pushes the data it collects to the main logger, which in turn pushes this data to a server at a configurable rate. Currently there are plugins for the console, window info, Dojo Toolkit info, mouse position sampling, and mouse click events. Not too complicated, not too difficult, but it opens up a world of utility.

None of this, of course, is a new idea; we build on what exists and what we can see as other uses for a utility. In this case there are a number of different products that do something similar, Google Analytics not least among them. There are also other products such as Firebug for iPhone that essentially do the same thing, but for an entirely different purpose. dojox.analytics is meant only to provide client side code that can enable these other projects, and do so in a way that is simple and will not get in the way of the loading or performance of an application.

You can use the tool with or without the Dojo Toolkit itself. If you using another JavaScript framework, you can simply do this instead of the dojo.require():

Then you can sprinkle code like this throughout your application:

I like small, useful utilities, like this.

ASIDE: I also noticed a blog post from Dylan talking about the new Dojo, DWR, and Cometd support offerings.

John Resig started a detailed spreadsheet to track the progress of ECMAScript 4 implementations. There is also a set of columns to track the thoughts of various companies (Mozilla, Google, Apple, Microsoft, Adobe, etc) on various parts and pieces of the spec, which is enlightening. You get to see a layer of transparency in the ECMA process. Imagine if this was more open?

Francis Cheng of Adobe has written a brief description of the implementations:

• ES4 RI: This is the ECMAScript 4th Edition reference implementation that the ES4 working group is developing. It is written in Standard ML '97, except for the library of core classes, which is written in ES4 itself.
• Tamarin: This began life as the AVM2 (ActionScript Virtual Machine 2), but morphed into Tamarin when the AVM2 was released as open source and handed over to Mozilla for hosting and coordination. Tamarin will serve as the VM for future versions of Flash Player as well as future versions of the FireFox web browser.
• Spidermonkey: This is a JavaScript engine hosted by Mozilla. It provides scripting support in many applications, some of which are Mozilla FireFox, Yahoo! Widgets, Adobe Acrobat, and Adobe Flash CS3 (allows scripting control of the Flash authoring tool with JSFL).
• Rhino: This is another Mozilla JavaScript engine, but this one is written entirely in Java and is intended for use in applications rather than in browsers.
• Futhark: This is a JavaScript engine developed by Opera Software for use in Opera's browser versions 9.5 and 10.0.
• Mbedthis: Mbedthis specializes in embedded web server solutions and is developing EJScript 3.0, which is based on ES4.
• JSCore: This is short for JavaScriptCore, which is the JavaScript engine in WebKit.