Interesting Things

• Shotgun is an automatic reloading version of the rackup command that's shipped with Rack.

Interesting Things

• The Golden Gate Ruby Conference is now accepting proposals for talks.

• Rails by default stores its session in a browser cookie as an encrypted string. If you want to get the contents of that cookie from within Rails, you can call "session.dbman.send :marshal, session.data". If you want to get that value from tests, you'll have to use an integration test, as functional tests mock out too much of the session store.

Regular Selenium tests (in Java) might look like:

selenium.open("/login");
selenium.type("id=username", "bob");
selenium.type("id=password", "password");
selenium.click("Login");
selenium.waitForPageToLoad();
selenium.click("My Account");
selenium.waitForPageToLoad();
assertEquals("bob", selenium.getText("//table[2]/tr[3]/td[2]/");

After a few tests, this kind of thing becomes painful to manage. The typical solution is to create a bunch of constants for IDs and Xpaths, but that doesn't help too much.

Fellow Pivot Mike Grafton came up with a cool pattern for improving on this. The idea is to create a class representing each page of your web app. Each class contains two types of methods: a bunch of action methods (clickMyAccountLink(), typeUsername()), and a bunch of inspection commands (isLoginButtonEnabled(), getLoggedInUsername()).

When an action takes you to a new page, the corresponding action method returns a new class representing that page. When it stays on the same page, the method just returns "this". This allows methods to be chained to make the tests more readable.

Here's how that test would look using this new pattern:

MyAccountPage myAccountPage = new LoginPage(selenium)
  .typeUsername("bob")
  .typePassword("password")
  .clickLoginButton()
  .clickMyAccountLink();

assertEquals("bob", myAccountPage.getLoggedInUsername());

The constructor of each page class should validate that it's on the correct page (waiting if necessary, and perhaps asserting on the page title).

Ask for Help

• "Can anyone recommend a tool to help find cross-site scripting (XSS) vulnerabilities?" One suggestion was Wikto.

Interesting Things

• Adobe has opened the spec for Flash and FLV (more or less).
• IE 6 and 7 handle z-index much differently than other browsers. If you are doing anything with z-index, it's probably safer to do your development in IE that day.

Ask for Help

• "Is it really safe to set allow_concurrency in ActiveRecord if it's going to be called from a script and not from Rails or Mongrel?"

Interesting Things

• Tip: acts_as_solr will revert to using Rexml if it can't find the much faster libxml-ruby. So if your solr processes start to take forever, make sure libxml-ruby is being used.

Interesting Things

• Erector is nearing its initial beta release.

  Erector is a Builder-like view framework, inspired by Markaby but overcoming some of its flaws. In Erector all views are objects, not template files, which allows the full power of object-oriented programming (inheritance, modular decomposition, encapsulation) in views.

• The latest Rails Podcast features Pivotal's Nathan Sobo talking about Treetop.

  Treetop is a language for describing languages. Combining the elegance of Ruby with cutting-edge parsing expression grammars, it helps you analyze syntax with revolutionarily ease.

Ask for Help

• "Can anyone suggest any solutions, or point to a web site that seems to have solved the following problem: an iframe that's showing content from one domain wants to communicate with its parent document that's showing content from another domain, without modifying the parent document's URL or refreshing the parent document's page? Adding Javascript to the parent document is okay, but installing a proxy on the server of the parent document's domain isn't possible."

Interesting Things

• Today is Earth Day
• There are lots of parties around town due to the Web 2.0 Expo

Ask for Help

• "Can anyone recommend a website monitoring service?" Some suggestions were Montastic, Site 24x7 and Scout.

http://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx

Interesting Things

• We've started to run across this in one of our projects: Javascript DOM methods can be a nice way to create a DOM tree (with some practice, you can write clear, reusable JS UI components), but it's slow. You probably won't notice it if you're only creating a few DOM nodes, but if you're drawing thousands of them then it can turn into a performance bottleneck. The generally-accepted solution is to push a bunch of strings into an array, use Array#join("") to create a single string, then stick it in an element's innerHTML. Quirksmode has some numbers and Joseph Smarr has a related presentation.