Best practices: 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 ;).

I just did a little clean up and released Fx.SmoothMove. This functionality used to be a part of Element.setPosition but now it’s an extension to Fx.Styles.

Mootools has a convention that I was breaking here (the same reason prompted me moving Fx.SmoothShow into Fx and out of Element). Basically, it is a general rule in the Mootools dev team never to create one-off instance of classes, especially in Native object extensions (Element in particular). Element.setPosition had an option (smoothMove: true) that would transition the position of the element to the new location smoothly (i.e. using Fx.Styles). But it didn’t return this to you, so every time you used it you created a new instance of Fx.Styles. Aside from this being wasteful, it also means that if you attempt to do this behavior while another is still in process, instead of canceling the previous one and starting a new one, both would run, causing your element to jump around until they both finished.

This is bad form and I should be given three lashes or something. I figured all this out after I’d written a lot of it and have just now gotten around to cleaning it up. But hey, as long as we all learned something… right?

See Fx.SmoothMove in action.

Update: I keep switching out Fx.SmoothShow and Fx.SmoothMove; this note as about the latter… Fixed the typos…

There is a new “Facebook” application that utilizes CNETs great API system. This app that was developed is called “My Tech”.
Apart from the great technology use, it is a fun way to show off your latest tech gear to your friends. The best part is you can show your disdain for certain tech products if you absolutely hate it… Good times

“Tag line from app profile”
This application allows you to let everyone know about the latest tech gadgets available using MyTech powered by the CNET API. Facebook users can find it at: http://mytech.cnet.com

CNET Report on CNET MYtech

Here’s a step-by-step and line-by-line example of how to write a Mootools Class. I wrote this example for a javascript class I taught here at CNET for our developers and figured I’d share with everyone else.

Jonathan Snook has a nice write-up about using private methods in javascript.

With JavaScript, you can create private methods and properties using what Yahoo describes as the module pattern. Here's the basic construct, including a private method:

PLAIN TEXT

JavaScript:

MyObject = function(){

  var privateMethod = function(){ /* do stuff */ };
 
  var obj = {
    publicProperty:5,
    publicMethod:function(){ /* do stuff */ };
  };
 
  return obj;
}(); // run it right away

If you're not familiar with this pattern, it's really quite cool. It takes advantage of closures, allowing the public methods to access the private methods. I've been using this approach in my recent work and it feels nice and works well.

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>

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 »