Here we are, a couple years since Ajax was coined, JavaScript has become a language that people actually respect. The code being written now is better than ever before. Object-orientation, name-spacing, object detection, and correct scoping are prevalent now. The libraries available (prototype, jquery, yui, dojo) are very well written. What is the next step to improve code quality? If you want my opinion, it's Testing. Otherwise, here's the door. :)

Many experts that advocate testing bring up selenium. While I think selenium is great, it is a functional test tool. All you are really testing is that you scripts aren't generating errors and working at a basic level. Unit testing ensures that your code is correct, i.e. it does what you think it should.

So, how do you unit test JavaScript? I've had good luck with crosscheck. Here's a synopsis from thefrontside.net...

Crosscheck is an open source testing framework for verifying your in-browser javascript. It helps you ensure that your code will run in many different browsers such as Internet Explorer and Firefox, but without needing installations of those browsers. The only thing you need is a Java Virtual Machine.

Crosscheck tests look like this: crosscheck.onSetup(function(){ crosscheck.load("prototype.js") crosscheck.load("myScripts.js") }); crosscheck.addTest({ test_function: function () { ... } });

Now we need a js code coverage tool to show how badly we are doing in respect to JavaScript testing. JavaScript Coverage Validator is something that I'll have to try.

Starting a backup routine is hard. I wanted a backup solution that did the following:

• Runs automatically every night
• Backup OS X resource forks correctly
• Maintain creation/modification times for backup files
• Make checkpointed-incremental backups

The key for me is incremental checkpoint backups, and by than I mean that every time the backup runs it creates a folder that only contains the changes since the last backup. See image on right, and how the file shares an inode. We can do one better using unix hard links to show all files, while still not using any more space. Read about hard links on wikipedia.

The unix utility rsync that comes with OS X 10.4 solves bullets 2-4 according to the man page. But, in practice, I could never get the checkpoints working correctly with "rsync --link-dest". Apparently that parameter doesn't always work. I tested it by running some test backups and checking the inode of the files using "ls -li". If a file doesn't change across backups it should share an inode number.

After more digging on the net I ran across rsnapshot, which is a perl front-end to rsync. It can make incremental checkpoints without link-dest. This blog shows some steps to getting rsnapshot installed on OS X. I'm going to augment those steps because I didn't want to install darwinports or fink, and I wanted to use launchd instead of cron.

Download and Installation

First, go to rsnapshot.org and download the "Generic UNIX" gzip, rsnapshot-1.3.0.tar.gz. Now, open terminal and type the following: tar -xzvf rsnapshot-1.3.0.tar.gz cd rsnapshot-1.3.0 ./configure --sysconfdir=/etc sudo make install [enter password] sudo cp /etc/rsnapshot.conf.default /etc/rsnapshot.conf sudo open /etc/rsnapshot.conf # This should open the configuration in your text editor

Configuration

See this blog and the rsnapshot docs for the options to specify in the config file. The file is very well documented. You can download my configuration files here. At the minimum, you need to change the snapshot root and the backup points.

Automation

The blog uses crontab, but Mac OS X 10.4 deprecated cron for launchd. For information on launchd, see Apple's documentation. My configuration is included in the resources zip below. It goes in /Library/LaunchDaemons. If you want other intervals besides daily, make sure they are uncommented in the rsnapshot.conf and create new launchd plist's for them. Once the launch configuration is complete, load the configuration with the launchctl command or just restart: sudo launchctl load /Library/LaunchDaemons/com.nearinfinity.backup.plist

Testing

For initial testing you might want to change your backup points to be smaller, otherwise this could take a while. When your ready, run a backup by typing: sudo rsnapshot daily [enter password]

This will create a daily.0 folder in your snapshot root directory. If you run the command again, the daily.0 will be renamed to daily.1 and daily.0 will represent the new backup. You can verify that inodes of files haven't changed using this command in your snapshots directory: ls -li daily.0/localhost/[someFile] daily.1/localhost/[someFile]

That's it, now I just need to get these offsite, for a solid backup solution. Rsnapshot supports using ssh to backup to a remote server. See the rsnapshot documentation for more information.

Resources

Download my launchd and rsnapshot configuration files.

It seems that Encytemedia was successful in their "Call for Prototype Documentation" blog posted in the old year.

The site lives at prototypejs.org and should help new and experienced users alike master the popular JavaScript library.

Features

• API of all extended and new objects with examples
• Tips/Tutorials section that includes how prototype works
• Easy method for users to contribute

Good work guys!

Looks like Joe Hewitt has been busy.

Firebug now has it's own site at getfirebug.com. The new site shows the features for Firebug 1.0 which seem like a giant leap in functionality from the current 0.4.1. My favorites look to be the new profiler and the network activity view (shown right).

The catch? According to Hewitt's blog, it might not be free. I know I would pay $15-$25, what about you?

Javascript particle Engine

I was at the No Fluff Just Stuff Software Symposium in Reston, VA this past weekend and had some time in between sessions to work on something. As most of the people I work with know, I rarely code things that might actually be useful to someone in my spare time. So, I had no reason to attempt to rationalize the use for a particle engine in Javascript.

I think I've written a particle engine in almost every language I've used for an extended period of time. This includes python, java, objective-c, and c. What's surprising is that it has taken me this long to write a particle engine in the language I probably spend the most time coding in -- Javascript.

By the way, this is probably the worst particle engine ever created (TM), but it is written in Javascript, so give me a break. It doesn't support colors yet as I couldn't think of an efficient way to change the color of a png. I've only tested it in Firefox and Safari because I'm on a Powerbook. It's also pretty slow, in that it can handle only a dozen or so particles.

Let me know what you think!

features

• Create multiple particle emitters per page
• Emitters have individual configurations
  • Velocity Range
  • Life Decrement Range (opacity)
  • Maximum particles to use
  • Particle re-spawn number
  • Event type to trigger particles
  • Individual X, Y forces applied to particles
  • Size of particles

demo

html configuration

1. import prototype, scriptaculous, and particle.js
2. add emitter class to element
3. add options to configure emitter

download

Here's an interesting bug in Internet Explorer I ran across today:

When using window.location to go to a named anchor inside of an iframe, using a String object versus a string primitive produces different results.

main.html

iframe.html

When main.html is opened in Internet Explorer 6 (try it), the iframe doesn't move to the anchor, instead it refreshes itself with the contents of it's containing html page -- main.html. Huh? If we change set window.location to "#here" instead of instantiating a new String object, it works as expected (try it). What is going on here? Let us try to break down the line in question.

Javascript's string primitives and String Objects

Javascript provides both string primitives and String objects¹. A string object is created by new String(""), whereas a primitive is declared by quotes. The object contains methods like charAt and properties like length and is automatically instantiated anonymously if you write something like: "hello world!".length.

window.location

The location object is special. Isn't it? You can set it to a string, or any of it's properties. Could IE be confused when objects are being passed in? Maybe confusing a string object with a location object?

Anyone have any other ideas?

Of, course, the better way to go to an anchor on the current page is setting the hash property of the location object. Using a string primitive versus a String object both work equally well. Here's an example.

¹Mozilla's page on Strings

the waiting game

No matter what apple says about Java development on the Mac, I always hated the waiting game before I could use some new Java API. First, it was Java 5 Tiger, which because apple ports it themselves to the platform, lagged considerably behind the Sun release. Then, it was Java3D and the JAI API. Even now, the Java3D API on OSX is at 1.3. I'm just glad that the JOGL and Java3d folks found a way to bypass Apple's porting process this time with Java3D 1.5.

Java3D is currently at 1.4.0 stable and has a 1.5 dev version out. The key to all of this is that the 1.5 branch includes the ability to use JOGL to bind the Java3D API to the native OpenGL implementation. What does this provide? Well, since JOGL is already ported to OSX, we can install Java3D 1.5 and JOGL and upgrade our outdated Java3D!

how to do it

Prerequisites

• Java 1.5
• Mac OS 10.4

Procedure

1. Download the windows binary of Java3D 1.5 from the Java 3D site
2. Replace the three jars (j3dcore.jar, j3dutils.jar, vecmath.jar) located in /System/Library/Java/Extensions with the ones in the java3d download. You can back up your old jars to easily revert.
3. Download JOGL (now called Java Bindings for the OpenGL API). They have a PPC and universal download, as it's a JNI library
4. Extract the jogl-natives-macosx-[ppc|universal].jar and copy libjogl.jnilib, libjogl_awt.jnilib, and libjogl_cg.jnilib to /System/Library/Java/Extensions. Make sure to copy jogl.jar here also.
5. Optional: Test out your install by downloading the j3d-examples

Have fun with all the new features!

Posted by jharwig Jun 28 2006, 08:19:45 PM EDT
Permalink Comments [5]

The problem..

If I had been allocated one Firefox extension to use, without hesitation it would be Joe Hewitt's Firebug. But, eventually, I have to test my code in IE (and Safari¹), and need to debug some DOM or css scripting. Many times I would use the url field to execute Javascript in the page using this method...

javascript:function(){ /* some code */ }()

Wrapping the code in a function will prevent variable name collisions. The problem is that this method can get messy and time consuming when trying to inspect elements nested deep within the DOM.

An answer?

I created a bookmarklet that allows you to inspect DOM elements, just like Firebug². Using a bookmarklet allows it to run in any javascript browser, including Firefox. After inspection, a console can be used to modify and query the object. How does it work? The bookmarklet is just a stub that loads the external javascript file³. It adds a click and mouseover handler to the document body object. The mouseover handler adds a window status message with the highlighted DOM tree, and the click attribute opens the inspector.

The inspector has a console with the variable clicked_element pointing to the element. Common attributes like id, class and innerHTML can be edited live. All other attributes can be viewed (or changed using the console) and the computed style is also available.

Download

Save the bookmarklet archive, or try it out on this page. (You can also bookmark this link directly)

Screenshots

• DOM tree
• Editing Attributes
• Console

Todo

• Allow inspecting of active elements - buttons, links
• Improve inspector look
• Editing innerHTML containing ' breaks

³IE 6 has huge limitation in that the url is only parsed to 512 characters. The external javascript is also much easier to maintain.