Libraries, Frameworks and Applications

We’re getting ever-closer to the final release of jQuery 1.3! In a follow-up to the recent 1.3 Beta 1 we have another test version for everyone to try. As with before, it’s not ready for production use yet but we definitely need help in hunting down any bugs that we may have missed.

Please don’t test 1.3 Beta 1 anymore - all testing should move on to beta 2. The final release of jQuery 1.3 will be on the 14th of January with a final release candidate available a few days before.

Download

A copy of jQuery 1.3b2 can be found here:

• http://code.jquery.com/jquery-1.3b2.js

Please don’t use minified or packed versions of jQuery when testing - it makes locating bugs difficult.

Changes

So far two changes in 1.3 have been the most likely to cause problems:

1. Old, XPath, style attribute selectors: [@attr=value]. These have been deprecated for quite some time - and we’re finally removing them. To fix it just remove the @!
2. Bubbling triggered events. Triggered events now bubble up the DOM - some plugins haven’t expected this and have had to adapt. Its pretty easy to fix your code to “protect” against bubbling - add the following statement to your bound handler: if ( this === event.target ) { … }

Tests

The test suite is holding up quite well. We currently have 1370 tests covering all aspects of the library and passing in all the major browsers:

How to provide feedback:

• Submit a bug to the jQuery bug tracker (you will need to create an account, first).
• Be sure to include a simple test case for any problem that you’re experiencing (either attach the test case or provide a link).
• Mention that you’re testing “jQuery 1.3 Beta 2″ (otherwise your ticket will get confused with another release).
• Email a link to your test case and bug report to the jQuery Dev list so that the dev team will be notified about your issue.

Thanks to everyone, in advance, for all your help in testing this release. We’re really excited about this release and can’t wait to get it into your hands.

One of the biggest under-the-radar movements in JavaScript development during 2008 was the reemergence of an interest in unit testing. YUI Test, YUI’s unit testing framework, reached GA status in February and other libraries either introduced their own unit testing frameworks or started publicizing existing ones. As a result, there’s a lot more documentation regarding the creation of unit tests for JavaScript. Simply having JavaScript unit tests isn’t enough, though; if your tests are written improperly, they can lead to a lot of lost time. Learning to write effective JavaScript unit tests will save you time and headaches in the future.

The key to writing effective unit tests is to understand the word "unit." In testing terms, a unit is an isolated part of code that can be tested independent of other pieces of code. In an object-oriented language like JavaScript, each method is considered to be a unit. Proper OO design typically entails nicely encapsulated methods that serve a single purpose and are therefore easy to test.

Traditional unit testing is designed to test the implementation of an interface, so private methods don’t get tested explicitly. This is called black box testing. The idea is that you can swap out the implementation of an interface and the unit tests will all still pass because they are completely agnostic to the underlying implementation. All the tests know is a set of constraints that must be met; they don’t care how those constraints are met.

As I said in my talk, unit tests should test inputs and outputs. Inputs can be named method arguments or changes in globally accessible variables that the method depends upon to function correctly. Outputs can be return values, changes in the state of variables, and even thrown errors. For each input-output set, there should be a single unit test. Each test should explicitly state, "given these inputs, I expect these outputs." Any deviation from that statement is a failed test.

Each test should be as simple as possible and test only one input-output set; combining sets into a single test minimizes the effectiveness of the unit test. For example, consider the following test of a function called trim():

Here, the testTrim() method of the test case is actually testing two different input-output sets:

1. Input string has leading white space; return value has no leading white space.
2. Input string has trailing white space; return value has no trailing white space.

The problem is that these two sets have literally no relation to one another, yet if the first input-output set fails to produce the correct result, the second set will never be tested. This is a situation where one failure masks another. It is more effective to separate out these input-output sets into two tests:

This code now properly tests the trim() function’s input-output sets, keeping them separate.

Unit tests are always written as if the code being tested works correctly. Good software design involves mapping out these input-output sets ahead of time so that you know exactly what the result should be in each case. In this way, unit tests become a type of technical requirement document in addition to actual code.

One of the most important parts of writing unit tests is proper assertion definition. Each assertion specifies a condition that, if not met, indicates that the functionality isn’t behaving appropriately. It’s important to use only as many assertions as necessary to properly test the code output. Too many assertions can lead to false failures while too few can lead to false passes.

In the previous example, each test contains a single assertion because that is all that’s needed. I know exactly the value that to be returned and so I test specifically for that. The tests may both look very simple, but they get the job done. Again, there’s no rule about the number of assertions that make a good test, just make sure you’re testing every expected output of the code for the given input.

To make test failures more coherent, you should include a failure message with each assertion. In YUI Test, this is always the last argument of any assertion method. A failure message should tell you what should have happened, not what did happen. Some examples:

Note the difference between the bad and good failure messages: the bad tells you what happened and the good tells you what was expected. When running your tests, a failure already indicates that something unanticipated happened, so there’s no need to simply repeat that something unanticipated happened. It’s more helpful to know what should have happened because it is an exact representation of your requirement. By taking this approach, failures end up being a list of unfulfilled requirements that you can go back over and evaluate.

JavaScript is unique to other languages in that it frequently has ties to the environment, the DOM. Methods that interact heavily with the DOM are difficult to unit test because the entire environment must be setup in order for the method to execute completely. Further complicating matters is the tendency of JavaScript to be triggered by a user action such as a mouse click. YUI Test provides event simulation to aid in creating tests for methods that are reliant on DOM interaction, however, this starts to cross over into the area of functional testing.

Functional testing, as opposed to unit testing, is designed to test the user’s experience with the product rather than input-output sets for code. If you find yourself wanting to test that the user interface responds in a specific way due to user interaction, then you really want to write some functional tests rather than unit tests. YUI Test can be used to write some basic functional tests, but the most popular (and quite good) tool for such testing is Selenium.

The best way to determine if something is a unit test is to ask if it can be written before the code that it’s designed to test actually exists. Unit tests, as part of test-driven development, are actually supposed to be written ahead of the actual code as a way to guide development efforts. Functional tests, on the other hand, cannot exist ahead of time because they are so tied to the user interface and how it changes in response to user interaction.

YUI Test, just like other unit testing frameworks, supports a hierarchy of test cases and test suites. Each test suite can contain other test suites as well as test cases; only test cases can contain actual tests (methods beginning with the word "test"). The best way to organize your test hierarchy is to follow a very simple pattern:

• Create one test suite for every object you’re going to test.
• Create one test case for every method of an object you’re going to test and add it to the object’s test suite.
• Create one test in each test case for each input-output set.

In this way, your test hierarchy mirrors the code you’re testing and it’s easier to figure out where new tests should be created.

Perhaps the most important part of unit testing is to run your tests frequently. Testing is only effective when done on a regular basis. At a minimum, you should be running your unit tests before checking in changes to source control. Optimally, you’d also run the tests automatically on a regular basis to validate any changes after they’ve been committed to source control. This is how you’ll get the biggest benefit of unit testing: quick discernment, and hopefully prevention, of regressions.

• YUI Test
• YUI Theater: Test Driven Development with YUI Test, by Nicholas C. Zakas
• FireUnit
• FireUnit extension for YUI Test
• JavaScript is Code Too: Test It!
• JavaScript Unit Test Isolation

Tags: yuitest, unittesting, javascript, webdevelopment, qa, yui, fireunit

Bringing Rails and Merb together is about more than just merging the respective code. We’re also picking up the best ideas from both communities beyond the code. Following on Merb’s success in offering a strong evangelism effort, we’re pleased to announce the creation of the Rails activists:

At launch, we’ve identified seven areas where the Rails activists can contribute to the Rails ecosystem:

• Public Relations with media of all sizes
• Ombudsman work to ensure good user-to-user support
• Community Leadership at events and conferences
• Media Organization to help create good promotional opportunities
• Website maintenance
• Documentation efforts
• Developer support

The initial members of the Rails activists are Gregg Pollack, Matt Aimonetti, Ryan Bates, and Mike Gunderloy. But we can’t do all this alone, nor do we want to! Our vision includes a large and vibrant Rails network composed of other activists, bloggers, event hosts, authors, and developers. Our intent is to provide connections, resources, and support to help the entire ecosystem to grow. To start things off, we’re bringing in a lot of our own projects, including videos, screencasts, case studies, Rails documentation, and more – we’re a working group, and we hope you’ll work with us.

If you have ideas about improving the Rails community, projects you want to participate in, or are just looking for ways to get involved, get in touch with us! There are a lot of ways to do that:

• Through the new Rails activism Google group.
• Through the Rails feedback site, where you can vote on which projects you’d like to see us devote resources to in the Rails 3 timeframe and beyond.
• Through our Twitter accounts (linked above)
• Through IRC to Matt (mattetti) or Mike (mikeg1a)
• Through email to Mike Gunderloy, Matt Aimonetti, Gregg Pollack, or Ryan Bates.

We look forward to hearing from you!

For additional perspectives from the activists, see the posts by Gregg Pollack, Matt Aimonetti, and Mike Gunderloy.

Photo by Flickr user caravinagre

Happy New Year! Apparently the Rails core team was not doing too much partying to end the old year: we had 35 commits hit the edge tree, and some of them involved very substantial work. Here’s my weekly overview of some of the most visible and significant changes.

In some of the first fruits of the Rails-Merb team merger, Yehuda Katz took a look at the respond_to method, which is of course heavily used in many Rails applications to allow your controller to format results differently based on the MIME type of the incoming request. After eliminating a call to method_missing and some profiling and tweaking, he reports an 8% improvement in the number of requests per second served with a simple respond_to that switches between three formats. The best part? No change at all required to the code of your application to take advantage of this speedup. commit commit

If you want a preview of what else to expect from Rails 3, you might want to dip into Yehuda’s own fork of the Rails tree I’ll be covering these changes as they make their way back into the master copy of edge Rails.

You know about dynamic finders in Rails (which allow you to concoct methods like find_by_color_and_flavor on the fly) and named scopes (which allow you to encapsulate reusable query conditions into friendly names like currently_active). Well, now you can have dynamic scope methods. The idea is to put together syntax that allows filtering on the fly and method chaining. For example:

There’s some further discussion of this over on Ryan Daigle’s blog. commit

There were a few changes going on in Active Record this week. A trio of commits cleaned up some behavior of associations when the :primary_key option is specified. commit commit commit

On another front, ActiveRecord::Base#new_record? now returns false rather than nil when confronted with an existing record. While there was some discussion of the wisdom of this change, the consensus seems to be that it can’t hurt and might make things less surprising for some developers. commit

Rails now has built-in support for HTTP digest authentication. To use it, you call authenticate_or_request_with_http_digest with a block that returns the user’s password (which is then hashed and compared against the transmitted credentials):

commit

When using Active Record callbacks, you can now combine :if and :unless options on the same callback, and supply multiple conditions as an array:

commit

A little flurry of activity cleaned up some loose ends in our testing strategy for Rails itself. This included not running symlink tests on Windows, adding test coverage to Rails::TemplateRunner, removing some assumptions in various tests, and getting the FCGI and sqlite2 tests working again. This is all part of a longer-term effort to make the Rails continuous integration server more useful moving forward. As you’ll see if you peek at the current build status, we’re not quite there yet, but we’re getting close.

By the way, if you want to set up your own CI server for Rails, there are instructions right in the source code.

One side effect of the changes to respond_to is that people really liked the inline comments that make the intent of the class_eval code clear. As a result, we now have similar comments throughout the Rails source code. For example:

If you’re just using Rails, you’ll never see these comments – but if you’re helping to maintain and improve the framework, you’ll appreciate them. commit

Happy New Year! Apparently the Rails core team was not doing too much partying to end the old year: we had 35 commits hit the edge tree, and some of them involved very substantial work. Here’s my weekly overview of some of the most visible and significant changes.

In some of the first fruits of the Rails-Merb team merger, Yehuda Katz took a look at the respond_to method, which is of course heavily used in many Rails applications to allow your controller to format results differently based on the MIME type of the incoming request. After eliminating a call to method_missing and some profiling and tweaking, he reports an 8% improvement in the number of requests per second served with a simple respond_to that switches between three formats. The best part? No change at all required to the code of your application to take advantage of this speedup. commit commit

If you want a preview of what else to expect from Rails 3, you might want to dip into Yehuda’s own fork of the Rails tree I’ll be covering these changes as they make their way back into the master copy of edge Rails.

You know about dynamic finders in Rails (which allow you to concoct methods like find_by_color_and_flavor on the fly) and named scopes (which allow you to encapsulate reusable query conditions into friendly names like currently_active). Well, now you can have dynamic scope methods. The idea is to put together syntax that allows filtering on the fly and method chaining. For example:

There’s some further discussion of this over on Ryan Daigle’s blog. commit

There were a few changes going on in Active Record this week. A trio of commits cleaned up some behavior of associations when the :primary_key option is specified. commit commit commit

On another front, ActiveRecord::Base#new_record? now returns false rather than nil when confronted with an existing record. While there was some discussion of the wisdom of this change, the consensus seems to be that it can’t hurt and might make things less surprising for some developers. commit

Rails now has built-in support for HTTP digest authentication. To use it, you call authenticate_or_request_with_http_digest with a block that returns the user’s password (which is then hashed and compared against the transmitted credentials):

commit

When using Active Record callbacks, you can now combine :if and :unless options on the same callback, and supply multiple conditions as an array:

commit

A little flurry of activity cleaned up some loose ends in our testing strategy for Rails itself. This included not running symlink tests on Windows, adding test coverage to Rails::TemplateRunner, removing some assumptions in various tests, and getting the FCGI and sqlite2 tests working again. This is all part of a longer-term effort to make the Rails continuous integration server more useful moving forward. As you’ll see if you peek at the current build status, we’re not quite there yet, but we’re getting close.

By the way, if you want to set up your own CI server for Rails, there are instructions right in the source code.

One side effect of the changes to respond_to is that people really liked the inline comments that make the intent of the class_eval code clear. As a result, we now have similar comments throughout the Rails source code. For example:

If you’re just using Rails, you’ll never see these comments – but if you’re helping to maintain and improve the framework, you’ll appreciate them. commit

Attention: We found a regression in the rc3 release that breaks datepicker in Internet Explorer. The issue has now been resolved with the rc4 release - please do not download the rc3 release anymore. We apologize for the inconvenience.

I’m absolutely thrilled to announce the latest release candidate for the long awaited jQuery UI version 1.6. It has been a busy couple of months, and not only our team but also our processes, specifications, and codebase has been updated. This means that rc4 isn’t simply a bugfix release on top of rc2, but really a whole different level of code. Using a our new interaction design processes, we build up the foundation of many widgets from the ground up, and refactored widgets multiple times until we finally reached the look and feel we were confident with. So, let me show you quickly what has changed especially in this release!

In order to make room for the new theming, we needed to unclutter the datepicker a bit. A couple of options have been removed, changeMonth and changeYear have been changed to be disabled by default and showButtonPanel was introduced as new method. More on that soon, detailed information can also be found in the related ticket.

The slider also went through a refactor. The ‘axis’ option was changed to ‘orientation’, the ‘handle’ and ‘handles’ options were removed, ’steps’ and ’stepping’ were removed in favor of ’step’, ’startValue’ and ‘moveTo’ have been removed in favor of ‘value’ (option and method), and much more. For more detail, see the slider specification page.

We will provide detailed compatibility information and upgrade solutions with the final release, so stay tuned.

The positioning and intersection logic of drag and drop and sortables has been completely redone, along with more than 200 automated tests to test all different environments, i.e. scroll offsets and position values. As positive effect, at least 30 conditions where the positioning was failing (i.e. scroll not included, helper stick at top) had been fixed.

jQuery UI 1.6rc4 features an entirely new look and feel, designed by our new Interaction Design team and powered by the new jQuery UI CSS Framework. Each widget’s markup and CSS has been re-approached to provide our cleanest and most flexible solution yet.

jQuery UI 1.6rc4 is built upon a brand new powerful CSS framework. The new jQuery UI CSS framework is built to support not only jQuery UI’s own plugins, but also custom plugin development. It is a special kind of CSS framework that is aimed specifically at user interface development as opposed to overall page layout. The framework provides classes for commonly used UI utilities, states, containers and icons and is manipulated by jQuery UI ThemeRoller. Read more about the
framework API here: http://jqueryui.pbwiki.com/jQuery-UI-CSS-Framework

The website is currently going through some major updates, and in the first block of changes we’re happy to announce that the demos section has been completely redone from scratch. We removed the demo carousel (which was nice but not really usable), and introduced a page that both includes real world and functional demos for all widgets and interactions. The demos are directly pulled from the actual demos/ directory in our code repository, and then ajaxified. They are bookmarkable, and if you download the development bundle, you’ll see they even come as standalone!
This is only the first step of where we want to go for the final 1.6 release. If you’re interested in how it might look in the end, have a peek at our design wiki!

ThemeRoller has been completely redesigned to compliment the new CSS framework and widget designs. ThemeRoller now resides in a vertical sidebar and has loads of new features added, such as:

Toggle-able panels with previews

ThemeRoller’s levers are now grouped into collapsible panes for ease of use. Each pane shows a preview of that state’s current styles so you can still view its settings while collapsed.

New Levers! Round corners! Drop shadows!

We’ve added new levers to the application for highlight, error, corner radius, overlays, and overlay shadows. Try em out!

Icon sprites

The jQuery UI CSS Framework comes with loads of icons for custom widget development. Icons are now packed into sprites and classes for each icon can be found in the docs.

New themes

We’ve added a bunch of cool new themes to the new gallery which can beviewed and customized in the gallery tab of ThemeRoller.

History/back button support

Every action you take in TR is now undoable/redoable through your browser’s history.

Legacy theme support

Themes designed using the older version of ThemeRoller will load just fine in ThemeRoller v2, but keep in mind that there are a number of new settings that your old theme will not have yet. This version of ThemeRoller allows you to still download any ThemeRoller theme for jQuery UI 1.5.

Coming soon…

• PNG 8 Support in ThemeRoller
• New ThemeRoller developer tool: Pull ThemeRoller into any page on the web and design themes for custom components built using the jQuery UI CSS Framework.
• New ThemeSwitcher bookmarklet: A quick script that will allow you to bring a miniaturized Theme Gallery into your web pages to allow visitors to quickly change themes for custom components built using the jQuery UI CSS Framework.

Now go ahead and download from our download page, then help us test and report anything odd that looks like a bug in our bugtracker. Also note: jQuery UI 1.6 final will ship with and require jQuery 1.3, so please let us know if you find any issues when combining this release with jQuery 1.3b1.

Cheers!

When developing using the WAI-ARIA Roles and States, you need to test your code in a screen reader to ensure everything is working as you expect. As a follow up to my presentation on Developing Accessible Widgets with ARIA and in the interest of helping other developers test their code, I thought I would provide some tips on how to configure your development environment for screen reader testing.

Before I install and configure screen readers I start by installing a virtual machine. (This is mostly out of necessity because I use a Mac and the most-popular screen readers run on Windows.) Using a virtual machine provides a couple of benefits when testing with a screen reader: To start, a virtual machine provides a sandboxed environment, so I am protected if anything goes awry when I am installing and configuring each screen reader. (So as not to give the impression that screen readers are unstable pieces of software, this is definitely the exception more than the rule.)

The second benefit to using a virtual machine is that they allow you to save and restore state. This is an especially helpful feature for efficiently testing and re-testing specific pieces or states of complex web applications. So, using a virtual machine can help save you time when testing.

Which virtual machine to use? If you use Windows, you can download and install Microsoft Virtual PC for free. As a Mac user, I have found both VMware Fusion and Parallels Desktop work well.

It is important to remember that to work, ARIA requires a team effort between the browser and the screen reader. To test ARIA you’ll need to install browsers that both support ARIA and are supported by screen readers that also support ARIA. For example, Opera has support for ARIA, but is not supported by screen readers. Currently only Internet Explorer 8 and Firefox 3 have support for ARIA, and are supported by several screen readers for Windows that also offer support for ARIA.

After installing each browser, be sure to save the state of the virtual machine. That way you’ll be able to quickly revert back to a clean, working state should anything go wrong during the screen reader installation.

With the browsers installed the next step is to install and configure each screen reader. The two most-popular screen readers for Windows, JAWS and Window-Eyes support ARIA and work with both Internet Explorer 8 and Firefox 3. Free, trial versions of both products are available for download from Freedom Scientific’s and GW Micro’s websites. The open-source screen reader NVDA also has excellent ARIA support and currently works with Firefox 3. Knowing that most visually impaired users use more than one screen reader, I recommend installing all three for testing.

As a sighted person I disable a couple of features of each screen reader and change some configurations so that I can test more efficiently. For example, most screen readers are configured to startup automatically when you start your computer. This is obviously not desirable when you have multiple screen readers installed, so I turn off that feature. Additionally, every screen reader uses a different keyboard shortcut for toggling the virtual buffer on and off. To avoid having to remember the keyboard shortcut for each screen reader, I configure them all to be the same: Ctrl + Shift + Space. (For more on the virtual buffer, read Making Ajax Work with Screen Readers.)

The following sections provide step-by-step instructions for configuring JAWS, Window-Eyes and NVDA.

1. Open the “Keyboard Manager” dialog by selecting “Utilities” -> “Keyboard Manager” in the JAWS application menubar.
2. Select the “default” profile in the left, “Profile” pane.
3. In the right pane, sort by the “Script Name” column, then find and select the item named “VirtualPCCursorToggle”.
4. Open the “Change Keystroke” dialog by either right clicking on the “VirtualPCCursorToggle” item, or by pressing Ctrl + H.
5. In the “Change Keystroke” dialog, choose the new keystroke by pressing the desired keys. (I use Ctrl + Shift + Space.) JAWS will warn you if the keystroke you choose in already in use.
6. Press the “OK” button to close the dialog.

1. Open the “Basic Settings” dialog by selecting “Options” -> “Basics” in the JAWS application menubar.
2. In the “Basic Settings” dialog, make sure the checkbox labeled “Automatically start JAWS” in not checked.

1. Open the “Browse Mode Hot Key Definitions” dialog by selecting “Hotkeys” -> “Browse Mode…” in the Window-Eyes application menubar.
2. In the “Browse Mode Hot Key Definitions” dialog, scroll down to the item named “Browse Mode” in the scrollable “Keys” list.
3. Select the “Browse Mode” item and then press the “Capture Key” button.
4. Press the keyboard combination you want to use. (I use Ctrl + Shift + Space.)
5. Press the “OK” button to close the dialog.
6. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar.

By default Window-Eyes will speak in response to some mouse gestures. For example, when you press the left mouse button, Window-Eyes will say “left”. As a sighted person I find this feature unnecessary, so I disable this feature.

1. Open the “Mouse Voice” dialog by selecting “Mouse” -> “Voice” in the Window-Eyes application menubar.
2. Select the “Off” item.
3. Press the “OK” button to close the dialog.
4. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar.

1. Open the “Startup Options” dialog by selecting “File” -> “Starup Options…” in the Window-Eyes application menubar.
2. In the “Startup Options” dialog:
   • Uncheck the checkbox labeled “Run Window-Eyes at the Login Screen”.
   • Uncheck the checkbox labeled “Run Window-Eyes after login for all users”.
   • Select the radio button labeled “Never” under “After login for Current User, Run Window-Eyes”.

3. Press the “OK” button to close the dialog.
4. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar.

1. Uncheck the checkbox labeled “Show this dialog when NVDA starts” that pops up the first time NVDA starts
2. Disable the confirmation dialog that pops up when you exit the application:
   1. Open the “General settings” dialog by right clicking on the NVDA system tray icon and selecting to “Preferences” -> “General settings” in the context menu.
   2. In the “General settings” dialog, uncheck the checkbox labeled “Warn before exiting NVDA”.
   3. Right click on the NVDA icon in the system tray and select the “Save configuration” menu item in the context menu.

Like Window-Eyes, by default NVDA will speak in response to some mouse gestures. For example, when you move the mouse NVDA will play tones to help the user track the position of the mouse. As a sighted person I find this feature unnecessary, so I disable this feature.

1. Open the “Mouse settings” dialog by right clicking on the NVDA icon in the system tray and selecting “Preferences” -> “Mouse settings” from the context menu.
2. In the “Mouse settings” dialog, uncheck both “Report text under the mouse” and “play audio coordinates when the mouse moves”.
3. Right click on the NVDA icon in the system tray and select the “Save configuration” menu item in the context menu.

1. Shut down NVDA - right click on the system track icon and choose “Exit” from the context menu.
2. Navigate to the path “C:\Program Files\NVDA\appModules”.
3. Open the file named “_default_desktop.kbd”.
4. Find the line: “NVDA+space=toggleVirtualBufferPassThrough”.
5. Change to: “Control+Shift+space=toggleVirtualBufferPassThrough”.
6. Save the file.
7. Restart NVDA.

With all of the screen readers installed and configured, restart Windows. Once Windows is restarted, take another snapshot of the virtual machine’s state. If you are using the free, trial versions of JAWS and Window-Eyes they will require you to restart Windows after using either product for ~30 minutes. Using the virtual machine, you can revert back to using JAWS and Window-Eyes more quickly than you would if you had to restart Windows.

That’s it. The steps for configuring your development environment for testing using a screen reader can be summarized as follows:

1. Install virtualization software
2. Install browsers & take a snapshot of that state
3. Install and configure screen readers
4. Restart the virtual machine & take a snapshot of that state

• Developing Accessible Widgets with ARIA
• An Introduction to Screen Readers
• Roles for Accessible Rich Internet Applications (WAI-ARIA Roles) Version 1.0
• States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties) Version 1.0

The biggest change in Rails in recent memory isn’t reflected in edge Rails yet: I’m speaking, of course, about the merger of Merb into Rails 3 . There is a 3-0-unstable branch in the repository, but it hasn’t yet started to diverge from the main line of development. I’ll continue to focus on the master branch, which will be released as Rails 2.3, for the time being.

And Rails 2.3 is still cooking along. The team managed 39 commits this week, despite people taking holiday time off. Many of those were minor bug fixes, but here are a few things you might want to track in the new development.

commit commit commit commit

A couple of fixes to ActiveRecord get rid of failing cases for associations. One handles quoting table names in some has_many :through associations – if the table name contains a SQL keyword, then you can’t use it in such an association in Rails 2.2. commit

The other fix allows you to once again use a hash in conditions for a has_many relationship:

That worked in Rails 2.1, fails in Rails 2.2, and will now work again in Rails 2.3 (if you’re dealing with this issue in Rails 2.2, you can use a string rather than a hash to specify conditions). commit

Some side effects of calling Model#last (it would change the order for other finders within the same scope) have been removed. commit

With this patch, you can supply custom prompts for the various date select helpers (date_select, time_select, and datetime_select), the same way you can with collection select helpers. You can supply a prompt string or a hash of individual prompt strings for the various components. You can also just set :prompt to true to use the custom generic prompt:

commit

The dbconsole script now lets you use an all-numeric password without crashing. commit

You can now use symbols for the :type option of send_file and send_data, like this: send_file("fabulous.png", :type => :png). commit

If you’re using Active Support delegates, the new :allow_nil option lets you return nil instead of raising an exception when the target object is nil. commit

You can now specify a particular timestamp for updated_at timestamps: cust = Customer.create(:name => "ABC Industries", :updated_at => 1.day.ago) commit

The biggest change in Rails in recent memory isn’t reflected in edge Rails yet: I’m speaking, of course, about the merger of Merb into Rails 3 . There is a 3-0-unstable branch in the repository, but it hasn’t yet started to diverge from the main line of development. I’ll continue to focus on the master branch, which will be released as Rails 2.3, for the time being.

And Rails 2.3 is still cooking along. The team managed 39 commits this week, despite people taking holiday time off. Many of those were minor bug fixes, but here are a few things you might want to track in the new development.

commit commit commit commit

A couple of fixes to ActiveRecord get rid of failing cases for associations. One handles quoting table names in some has_many :through associations – if the table name contains a SQL keyword, then you can’t use it in such an association in Rails 2.2. commit

The other fix allows you to once again use a hash in conditions for a has_many relationship:

That worked in Rails 2.1, fails in Rails 2.2, and will now work again in Rails 2.3 (if you’re dealing with this issue in Rails 2.2, you can use a string rather than a hash to specify conditions). commit

Some side effects of calling Model#last (it would change the order for other finders within the same scope) have been removed. commit

With this patch, you can supply custom prompts for the various date select helpers (date_select, time_select, and datetime_select), the same way you can with collection select helpers. You can supply a prompt string or a hash of individual prompt strings for the various components. You can also just set :prompt to true to use the custom generic prompt:

commit

The dbconsole script now lets you use an all-numeric password without crashing. commit

You can now use symbols for the :type option of send_file and send_data, like this: send_file("fabulous.png", :type => :png). commit

If you’re using Active Support delegates, the new :allow_nil option lets you return nil instead of raising an exception when the target object is nil. commit

You can now specify a particular timestamp for updated_at timestamps: cust = Customer.create(:name => "ABC Industries", :updated_at => 1.day.ago) commit

It’s christmas, baby, and do we have a present for you. We’re ending the bickering between Merb and Rails with a this bombshell: Merb is being merged into Rails 3!

We all realized that working together for a common good would be much more productive than duplicating things on each side of the fence. Merb and Rails already share so much in terms of design and sensibility that joining forces seemed like the obvious way to go. All we needed was to sit down for a chat and hash it out, so we did just that.

What this will mean in practice is that the Merb team is putting their efforts into bringing all of the key Merb ideas into Rails 3. Yehuda Katz will outright join the Rails core team, Matt Aimonetti will work on a new evangelism team, and Carl Lerche and Daniel Neighman (hassox) will be co-starring the effort to bring all this over. We’ve immortalized the merge with plaque page at rubyonrails.org/merb.

What’s being brought over?
Some of the key ideas that they’ll be taking with them from Merb into Rails 3 are:

• Rails core: Yes, Rails is a full-stack framework and will remain so, but there’s no reason we shouldn’t also make it possible to run with less than the full monty. Rails 3 will make it easy to run just a bare minimum and then allow you to opt in just the stuff you want, if that’s necessary for your particular situation. Think “rails myapp—core” (and “rails myapp—flat”).

• Performance optimizations: Merb has a lot of Rails pieces rewritten to be faster. We’ll be bringing all that good stuff over. We’ll also bend the architecture in the places where that’s necessary for a big yield. In short, Rails 3 will get all the performance attention that the Merb guys are known for.

• Framework agnosticism: Rails will always have a default answer to every question within the stack. If you don’t care about testing frameworks, you’ll get test/unit. If you don’t care about which ORM, you’ll get Active Record. But some people do care and want something else. Some people want RSpec for testing, others want to use Sequel or Data Mapper for ORM, others again prefer Haml for templating, and some might prefer jQuery for Ajax. All these people should feel like Rails is welcoming them with open arms. Yes, we’ll have a default, but we shouldn’t have any form of discrimination against alternatives.

• Rigorous API: Too many plugins break when Rails is updated because it’s not clear where they can safely hook into the internals and when they’re monkeypatching and should expect things to break. The Merb guys committed to a public API with tests to ensure that it wouldn’t break. They’ll bring over that line of thinking and give Rails 3 a tested and documented API for extensions that won’t break willy-nilly with upgrades.

This is not a big bang rewrite
It’s important to understand, however, that this is not a “big bang” rewrite of Rails. We’re far beyond the time when we could just throw out everything and start over. This is going to be a progressive improvement of Rails that’ll carefully judge new initiatives on their impact on backwards compatibility as well as their general utility.

I’m sure there’ll be some parts of Rails 3 that are incompatible, but we’ll try to keep them to a minimum and make it really easy to convert a Rails 2.x application to Rails 3. The Merb guys will also be working hard on giving existing Merb users a manageable upgrade path to Rails 3. We’re working with lots of ideas including allowing existing Merb controllers to be mounted alongside new Rails 3 ones. We’ll see how it all plays out, but play out it will.

Also, the Merb guys aren’t just abandoning the existing Merb user base and their applications. They’ll still be doing bug fixes, security fixes, and work on easing the upgrade path to Rails 3. This will all progress in a nice, orderly fashion.

The timeline
Rails 2.3 is just around the corner. We hope to wrap up and release in January. It’s a blockbuster release packed with goodies to the tilt. But as soon as that’s done, all eyes will be on Rails 3.

The probably-overly-optimistic goal is to have at least a beta version ready for RailsConf 2009 in Las Vegas. Who knows if we’ll make it, but we’ll certainly have made tons of progress on it by then.

So all of these changes are pretty much effective immediately. We’ve already started the collaboration and we’ll be rolling out a bunch of public initiatives announcing the concrete elements of the work under the Rails 3 milestone very shortly.

No hard feelings, just kumbaja
This is quite a dramatic turn of events. We went from testy relations to coming together in not very long at all. But I’ve been incredibly positively surprised at how well everyone on both sides have been gelling behind the scenes. The more we talk, the more we realize that we want the same things. And in the few cases were we do care about something different, it’s usually complimentary.

I really hope that everyone within both communities will deal with this news as gracefully as the key contributors from both camps. Let’s just wipe the slate clean on anything that has gone before and cherish that we can now move forward in unity instead of as fractions of the same ideas.

Rails 3 is going to kick ass.

Also read what Yehuda wrote about this and Carl Lerche and Ezra and Matt.

It’s christmas, baby, and do we have a present for you. We’re ending the bickering between Merb and Rails with a this bombshell: Merb is being merged into Rails 3!

We all realized that working together for a common good would be much more productive than duplicating things on each side of the fence. Merb and Rails already share so much in terms of design and sensibility that joining forces seemed like the obvious way to go. All we needed was to sit down for a chat and hash it out, so we did just that.

What this will mean in practice is that the Merb team is putting their efforts into bringing all of the key Merb ideas into Rails 3. Yehuda Katz will outright join the Rails core team, Matt Aimonetti will work on a new evangelism team, and Carl Lerche and Daniel Neighman (hassox) will be co-starring the effort to bring all this over. We’ve immortalized the merge with plaque page at rubyonrails.org/merb.

What’s being brought over?
Some of the key ideas that they’ll be taking with them from Merb into Rails 3 are:

• Rails core: Yes, Rails is a full-stack framework and will remain so, but there’s no reason we shouldn’t also make it possible to run with less than the full monty. Rails 3 will make it easy to run just a bare minimum and then allow you to opt in just the stuff you want, if that’s necessary for your particular situation. Think “rails myapp—core” (and “rails myapp—flat”).

• Performance optimizations: Merb has a lot of Rails pieces rewritten to be faster. We’ll be bringing all that good stuff over. We’ll also bend the architecture in the places where that’s necessary for a big yield. In short, Rails 3 will get all the performance attention that the Merb guys are known for.

• Framework agnosticism: Rails will always have a default answer to every question within the stack. If you don’t care about testing frameworks, you’ll get test/unit. If you don’t care about which ORM, you’ll get Active Record. But some people do care and want something else. Some people want RSpec for testing, others want to use Sequel or Data Mapper for ORM, others again prefer Haml for templating, and some might prefer jQuery for Ajax. All these people should feel like Rails is welcoming them with open arms. Yes, we’ll have a default, but we shouldn’t have any form of discrimination against alternatives.

• Rigorous API: Too many plugins break when Rails is updated because it’s not clear where they can safely hook into the internals and when they’re monkeypatching and should expect things to break. The Merb guys committed to a public API with tests to ensure that it wouldn’t break. They’ll bring over that line of thinking and give Rails 3 a tested and documented API for extensions that won’t break willy-nilly with upgrades.

This is not a big bang rewrite
It’s important to understand, however, that this is not a “big bang” rewrite of Rails. We’re far beyond the time when we could just throw out everything and start over. This is going to be a progressive improvement of Rails that’ll carefully judge new initiatives on their impact on backwards compatibility as well as their general utility.

I’m sure there’ll be some parts of Rails 3 that are incompatible, but we’ll try to keep them to a minimum and make it really easy to convert a Rails 2.x application to Rails 3. The Merb guys will also be working hard on giving existing Merb users a manageable upgrade path to Rails 3. We’re working with lots of ideas including allowing existing Merb controllers to be mounted alongside new Rails 3 ones. We’ll see how it all plays out, but play out it will.

Also, the Merb guys aren’t just abandoning the existing Merb user base and their applications. They’ll still be doing bug fixes, security fixes, and work on easing the upgrade path to Rails 3. This will all progress in a nice, orderly fashion.

The timeline
Rails 2.3 is just around the corner. We hope to wrap up and release in January. It’s a blockbuster release packed with goodies to the tilt. But as soon as that’s done, all eyes will be on Rails 3.

The probably-overly-optimistic goal is to have at least a beta version ready for RailsConf 2009 in Las Vegas. Who knows if we’ll make it, but we’ll certainly have made tons of progress on it by then.

So all of these changes are pretty much effective immediately. We’ve already started the collaboration and we’ll be rolling out a bunch of public initiatives announcing the concrete elements of the work under the Rails 3 milestone very shortly.

No hard feelings, just kumbaja
This is quite a dramatic turn of events. We went from testy relations to coming together in not very long at all. But I’ve been incredibly positively surprised at how well everyone on both sides have been gelling behind the scenes. The more we talk, the more we realize that we want the same things. And in the few cases were we do care about something different, it’s usually complimentary.

I really hope that everyone within both communities will deal with this news as gracefully as the key contributors from both camps. Let’s just wipe the slate clean on anything that has gone before and cherish that we can now move forward in unity instead of as fractions of the same ideas.

Rails 3 is going to kick ass.

Also read what Yehuda wrote about this and Carl Lerche and Ezra and Matt.

Douglas Crockford returns to YUI Theater with another chapter in his evolving lecture series. This session, “Ajax Performance,” debunks common misconceptions about the relationship between JavaScript and performance and gives engineers a core focus for improving the performance of web apps: Reduce the value of n. Because DOM interactions are generally slow, leveraging Ajax to reduce the number of DOM operations, Douglas argues, is often the most important optmization you can make. In fact, it usually dwarfs other techniques in terms of its impact on the actual experience of using a website.

This talk joins an extensive library of Douglas’s lectures now available on YUI Theater, including his popular series on JavaScript.

• Slides (zipped PPT)
• Full text transcript of this talk

Douglas Crockford: "Ajax Performance" @ Yahoo! Video

download (m4v)

Some other recent videos from the YUI Theater series:

• Nicole Sullivan: "Design Fast Websites (Don’t Blame the Rounded Corners)" (Yahoo! Video | .m4v download)
• Todd Kloots: “Developing Accessible Widgets Using ARIA” (Yahoo! Video | .m4v download)
• Nicholas C. Zakas: "Test-Driven Development with YUI Test" (Yahoo! Video | .m4v download)
• Douglas Crockford: "Web Forward" (Yahoo! Video | .m4v download)

• YUI Theater RSS feed
• YUI Theater on iTunes

Nicole Sullivan is a website performance specialist and a former member of Yahoo’s Exceptional Performance Team. She is currently writing a book for O’Reilly with Stoyan Stefanov on performance optimization and she and Stoyan are the creators of Smushit, an engine for crushing images.

Nicole visited Yahoo last week to do an encore of her "Design Fast Websites" talk in which she outlines a set of practical guidelines for building websites that are supremely fast and visually rich. Her advice is to know your craft, to engage your designers, and to make sure that your collaboration with designers works intelligently in the service of users. She was kind enough to let us record the talk and share it with you here on YUI Theater.

• Slides (on Slideshare)

Nicole Sullivan: "Design Fast Websites" @ Yahoo! Video

download (m4v)

Some other recent videos from the YUI Theater series:

• Todd Kloots: “Developing Accessible Widgets Using ARIA” (Yahoo! Video | .m4v download)
• Nicholas C. Zakas: "Test-Driven Development with YUI Test" (Yahoo! Video | .m4v download)
• Douglas Crockford: "Web Forward" (Yahoo! Video | .m4v download)
• Eric Miraglia and Matt Sweeney: "YUI3 — A Look Ahead" (Yahoo! Video | .m4v download)

• YUI Theater RSS feed
• YUI Theater on iTunes

The jQuery team has been working hard on the new release of the jQuery library and it’s ready for some in-depth testing! jQuery 1.3 is not ready for production use yet but we need help to weed out any bugs that might’ve snuck through.

Download

A copy of jQuery 1.3b1 can be found here:

• http://code.jquery.com/jquery-1.3b1.js

Please don’t use minified or packed versions of jQuery when testing - it makes locating bugs difficult.

Major Areas of Change

Here are some of the areas that have seen major changes and are most likely to cause problems in your code:

• Selector Engine - The selector code has undergone a complete rewrite - it’s likely that some edge cases still exist here.
• DOM Manipulation (append/prepend/before/after) - This code has also undergone a large rewrite along with some of the logic for executing inline script elements.
• .offset() - Another method that has been completely rewritten.
• Event Namespaces - The logic for handling namespaced events has been completely rewritten.
• Event Triggering - When triggering an event the event now bubbles up the DOM - this is likely to cause some problems.

While we won’t get into the particulars of all the new features that are in jQuery 1.3 (we’ll do that later, when it’s ready for final release - scheduled for January 14th) we do appreciate any/all feedback that you can provide.

How to provide feedback:

• Submit a bug to the jQuery bug tracker (you will need to create an account, first).
• Be sure to include a simple test case for any problem that you’re experiencing (either attach the test case or provide a link).
• Mention that you’re testing “jQuery 1.3 Beta 1″ (otherwise your ticket will get confused with another release).
• Email a link to your test case and bug report to the jQuery Dev list so that the dev team will be notified about your issue.

Thanks to everyone, in advance, for all your help in testing this release. We’re really excited about this release and can’t wait to get it into your hands.

We’ve just launched a mild refresh of the rubyonrails.org site. It now runs on Radiant through Passenger at Slicehost and includes a nip and tuck in various places along with a couple of new pages. Read about how we prefer to deploy Rails applications, the ecosystem that has sprung up around Rails, and see the much expanded list of prolific Rails applications.

We’ve just launched a mild refresh of the rubyonrails.org site. It now runs on Radiant through Passenger at Slicehost and includes a nip and tuck in various places along with a couple of new pages. Read about how we prefer to deploy Rails applications, the ecosystem that has sprung up around Rails, and see the much expanded list of prolific Rails applications.

Josh recently added Rails Metal, which has been getting a fair bit of publicity. Metal is a great piece of functionality for those rare cases where the speed of your framework actually matters.

However, people have been reporting 25x speed increase over a regular Rails action, and that just doesn’t seem right. So I decided to do some benchmarking of ‘Hello World’ Rails action v/s Metal. Here are my results :

You can find more details about benchmark command/code at http://gist.github.com/38080

Of course, these are not very scientific benchmarks and your results may vary a little from what you see here. You should also make sure you run your benchmarks in production mode.

Now, if you compare these results, 3000 r/s against 800 r/s, you may think you’re seeing a 3x performance increase. However, that’d a wrong perception and throughput isn’t the best metric here.

Difference in Time per request is what you should looking at. In my benchmarks, speed increase I get when using Metal is about 1 millisecond. And that’s a constant speed increase I’ll get over a regular Rails action. It’s very important to understand that it’s a constant speed increase. It’ll always be 1 ms for me.

For example, if my Rails action takes 12ms, when I reimplement it all in Metal, it will take about 11 ms and not 4 ms.

To conclude, I’ll just quote DHH :

But for those few, specialized cases where you just need as much raw speed as possible, Metal can be exactly what the doctor ordered. It allows you to have the best of both worlds in one package. The lowest possible overhead for a Rack application when that matters and the full-featured goodness of Action Controller when it doesn???t.

Josh recently added Rails Metal, which has been getting a fair bit of publicity. Metal is a great piece of functionality for those rare cases where the speed of your framework actually matters.

However, people have been reporting 25x speed increase over a regular Rails action, and that just doesn’t seem right. So I decided to do some benchmarking of ‘Hello World’ Rails action v/s Metal. Here are my results :

You can find more details about benchmark command/code at http://gist.github.com/38080

Of course, these are not very scientific benchmarks and your results may vary a little from what you see here. You should also make sure you run your benchmarks in production mode.

Now, if you compare these results, 3000 r/s against 800 r/s, you may think you’re seeing a 3x performance increase. However, that’d a wrong perception and throughput isn’t the best metric here.

Difference in Time per request is what you should looking at. In my benchmarks, speed increase I get when using Metal is about 1 millisecond. And that’s a constant speed increase I’ll get over a regular Rails action. It’s very important to understand that it’s a constant speed increase. It’ll always be 1 ms for me.

For example, if my Rails action takes 12ms, when I reimplement it all in Metal, it will take about 11 ms and not 4 ms.

To conclude, I’ll just quote DHH :

But for those few, specialized cases where you just need as much raw speed as possible, Metal can be exactly what the doctor ordered. It allows you to have the best of both worlds in one package. The lowest possible overhead for a Rack application when that matters and the full-featured goodness of Action Controller when it doesn’t.