#!/usr/bin/ruby

require 'rubygems'
require 'httpclient'
require 'json'

class Angular
  def initialize(username, password, library)
    @http = HTTPClient.new
    @library = library
    post("/login", :email => username, :password => password)
  end

  def libraries
    get("/data")
  end

  def store(database, document, data)
    post("/data/#{database}/#{document}", data.to_json)
  end

  private

  def post(path, params)
    request(:post, path, params)
  end

  def get(path, params=nil)
    request(:get, path, params)
  end

  def request(method, path, params)
    uri = (path.index("http") == 0) ? path : ("http://#{@library}.getangular.com" + path)
    response = @http.send(method, uri, params)
    if response.code == 302
      get(response.header["Location"][0])
    elsif response.code == 200
      parsed = parse(response)
      status_code = parsed['$status_code']
      raise "#{uri.to_s} responded with #{status_code}" if status_code && status_code != 200
      parsed
    else
      raise "#{uri.to_s} responded with #{response.code}"
    end
  end

  def parse(response)
    begin
      JSON.parse(response.body.content)
    rescue
      {}
    end
  end
end

Also available on GitHub for your forking pleasure.

Maybe in the future I’ll write up a blog post about how I’m using Angular.

Jasmine is a new Javascript testing framework from my pals at Pivotal Labs.

Jaxer is an Apache module that wraps Firefox’s Javascript and rendering engine, providing a server-side Javascript environment that’s fast and compatible with any JS that works in Firefox (including all kinds of DOM manipulation and libraries like Prototype, jQuery, etc.).

Running Jasmine Tests Through Jaxer

Part of an app I’m writing uses Jaxer and I wanted to write my tests in Jasmine, so I wrote a test runner and reporter to bridge the two, and then I wrote a rake task to run the tests.

So now I can run “rake spec” and my JS tests will run, in Firefox, but without having to actually have Firefox open up (or be installed).

So:

rake spec

returns:

.    foo should do something.
.    foo should do something else.
.    foo should do yet another thing.

3 of 3 specs passed

And the whole thing takes 0.37 seconds. It should be noted that those are trivial tests, but running a JS test suite with only 0.37 seconds of overhead is pretty neat.

My rake task looks like:

task :spec do
  results = `curl -s http://127.0.0.1:8081/jaxer-service/jasmine-jaxer`
  print results
  fail "spec failures" if results.match(/FAILURES!/)
end

Download

The JS code that hooks Jasmine to Jaxer is here: jasmine-jaxer.js.

So I wrote a bookmarklet to reload the files. Here it is:

reload CSS

(Just drag that into your bookmarks bar. Tested in Safari and Firefox.)

It works by appending the letter “x” after a “?” at the end of each stylesheet reference. That causes the browser to reload the stylesheet. Here’s the code:

var links = document.getElementsByTagName("link");
for (var i = 0; i < links.length; i++) {
  if (links[i].rel === "stylesheet") {
    if (links[i].href.indexOf("?") === -1) {
      links[i].href += "?";
    }
    links[i].href += "x";
  }
}

I created a site called JS Dev Tools (jsdevtools.com) to keep track of useful Javascript development tools and libraries.

Check out the site, subscribe to the feed, and suggest your favorite tools and libraries.

Background

wshlst uses a lot of Javascript. When developing, I want to have all of my JS files listed in my index.html page. But in production mode, I want a single JS file. So I wrote a script to read in my index.html file, find all the references to my Javascript files, and write out a new HTML file that contains a reference to a single JS file that was created by concatenating and compressing all the JS files.

As an example, have a look at what my index.html page looks like in development mode and in production mode.

Ruby Script → Rake

When a server move prompted me to upgrade to Subversion and Capistrano, I decided to turn my Ruby script into a Rake task that I could trigger from my Capistrano deploy: minify.rake

Capistrano

I added a line to my Capistrano deploy.rb file to run rake minify on the server after updating from Subversion:

run "cd #{release_path} && rake minify RAILS_ENV=#{rails_env}"

Apache

I also added a few lines to my httpd.conf file to support this. First, since the Rake task combines all the JS files into a single JS file but Capistrano deploys the entire app, I wanted to restrict access to everything in the javascripts directory:

# Don't allow access to the javascripts directory (all JS should be in minified js file)
RewriteRule ^/javascripts/ - [F]

Then, because the Rake task reads index.html and outputs a file called index-mini.html, I wanted to send all requests for / and /index.html to /index-mini.html:

# Rewrite index.html to index-mini.html
RewriteRule ^/index.html$ /index-mini.html [QSA]

# Rewrite index to check for static
RewriteRule ^/$ /index-mini.html [QSA]

Why Not Use AssetPackager?

For a normal Rails application, AssetPackager is probably the right solution to this problem. However, wshlst doesn’t use Rails to generate the UI (it’s all done in Javascript), so AssetPackager wouldn’t work.

Sending mouse events such as click and mouseover in JsUnit tests can be really hard.

More Bad News

Prototype doesn’t make it any easier. Sam Stephenson says:

We would very much like to support it in the future. It’s fairly complicated to implement native event firing across all supported browsers, so in 1.6.0, fire works with custom events only.

YUI To The Rescue

YAHOO.util.UserActions can simulate some user actions. Unfortunately, calls to YUI can look a bit clunky in a Prototype-heavy codebase:

var element = new Element("div").insert("Hi");
var offset = element.cumulativeOffset();
YAHOO.util.UserAction.click(element, { shiftKey: true });

YUI + Prototype FTW

A little mixin magic:

Element.addMethods({
  simulateClick: YAHOO.util.UserAction.click.bind(YAHOO.util.UserAction),
  simulateDblClick: YAHOO.util.UserAction.dblclick.bind(YAHOO.util.UserAction),
  simulateMousedown: YAHOO.util.UserAction.mousedown.bind(YAHOO.util.UserAction),
  simulateMouseup: YAHOO.util.UserAction.mouseup.bind(YAHOO.util.UserAction),
  simulateMouseover: YAHOO.util.UserAction.mouseover.bind(YAHOO.util.UserAction),
  simulateMouseout: YAHOO.util.UserAction.mouseout.bind(YAHOO.util.UserAction),
  simulateMousemove: YAHOO.util.UserAction.mousemove.bind(YAHOO.util.UserAction)
});

and now our test code looks nicer:

var element = new Element("div").insert("Hi");
var offset = element.cumulativeOffset();
myElement.simulateClick({ shiftKey: true });

I contemplated having a per-user time zone setting, but that seemed complicated. So I decided to just show how old the item is. For that, I needed to write two things. I’m posting them here in case anyone else finds them useful.

RelativeDate.js

First, I needed a simple relative date formatter, so I wrote a simple one. Given two dates, it returns a string like

4 days ago

or

26 hours ago

Here’s the code and the JsUnit test:

RelativeDate.js
RelativeDateTest.html

ServerTime.js

The timestamps of the items I’m displaying are stored in the database, so they are based on the clock of my database server. The relative dates are calculated in Javascript, so they are based on the clock of the user, which might be hours or just minutes off from the database server time.

The first thing my app does when it loads is checks to see if the user is logged in, so I decided to piggyback the current server time along with the response. Since the client and server talk using JSON, it’s simple to add another property to the response:

def current
  ...
  render_json({
    :success => true,
    :user => user,
    :servertime => dbtime()
  }.to_json)
end

...

def dbtime
  ActiveRecord::Base
    .connection
    .select_all("select unix_timestamp(now()) as now")[0]["now"]
    .to_i
end

I wrote a ServerTime class on the client side and I initialize it when the app receives the current user response from the server:

this.serverTime = new ServerTime(json.servertime);

Here’s the code (it’s very simple):

ServerTime.js

Putting It Together…

And now to display the relative time, my app only has to do this:

var updated = new Date(item.updated_at * 1000);
element.insert(new RelativeDate(updated, app.serverTime.get()).toString());

It’s been a lot of fun to write, and one reason is that the entire UI is written in Javascript. No HTML, no CSS. There’s no HTML generation on the server-side either; it’s all client-side Javascript. I’d really like to write more apps like this.

The Server

There is of course a server-side component. I decided to write the server in Rails because I had just finished working on a Rails project at Pivotal Labs and had Rails on the brain. Plus, my web host, DreamHost, supports Rails and doesn’t support Java, which is the language I’ve written all my other web apps in.

DreamHost’s support of Rails is a bit limited though: they kill any long-running processes, which means that a response from your Rails app could take 10 seconds if no other requests have been made lately. It’s good enough for a little project like Wshlst with only a few users and for initial development, but not much beyond that. (If I were to do it over again, I’d probably just use Ruby CGI, or maybe even PHP. Or use a VPS from Rimu, but that costs money.)

Because all of the UI is in Javascript, the Rails side of things doesn’t have to generate any HTML. Instead, it takes standard Rails requests and returns JSON using JSON for Ruby. For example, the client sends the following AJAX request:

GET http://wshlst.com/user/list

and the server uses ActiveRecord magic to find all the users that are “friends” with the current user and uses JSON for Ruby to convert that list to JSON, which it returns back to the client like this:

[{name: "Andy Acorn", id: 12, email: "andy@example.com"},
{name: "Betty Beets", id: 13, email: "betty@example.com"},
{name: "Chad Carrot", id: 14, email: "chad@example.com"},
{name: "Donna Donut", id: 15, email: "donna@example.com"}]

which Prototype automatically converts to Javascript objects.

The server is of course also responsible for sending static files, but those are all handled by DreamHost’s Apache servers.

The Client

Here’s where it gets interesting. The app consists of an HTML file that does little more than include the Javascript files. (In development mode, there are multiple Javascript files, but when I deploy to production, there’s just one file. Read this blog post on concatenating and compressing Javascript files with Ruby.)

The app relies heavily on Prototype, and also uses Animator.js for a few visual effects. Everything else I wrote from scratch. I like to write a lot of code from scratch when I’m working on a personal project so I can get a good understanding of what’s really going on and be able to better evaluate pre-written libraries when I’m programming for money.

The app’s main class is called Application and acts as a controller. There are many view classes which are combined to form the app’s UI. For example, the “Change Password” box is implemented by a ChangePasswordForm class and consists of a ModalBox with a FormPanel inside. The FormPanel contains instances of Buttons and Fields. Writing a Field class of course takes more time than putting <input type="text"> in some template file somewhere, but it allows for easy reuse and the ability to add a feature to all fields in just one place. (I hope to post some of the code from Wshlst on this blog in the future.)

Responding to user actions is just a matter of one Javascript method directly calling another method. No parsing of parameters, no layers of actions and filters, no guessing client state on the server side. It’s very liberating.

Lessons Learned

Test early and often in lots of browsers. This is obviously important when doing any web development, but when it’s 100% Javascript, there’s even more chance of incompatibilities. My JsUnit tests caught some issues (Date.now turns out to be Firefox-only), but most issues I had were visual.

MVC is good. Again, I already knew this, but I didn’t do nearly a good enough job with it in this app, probably because it was the first time I wrote an entire UI in Javascript. Next time, I’ll have multiple controllers and keep app logic out of the views as much as possible.

Events are probably the way to go. Wshlst suffers from some tight coupling of objects because they directly notify each other of actions. Next time, I’ll try having all my objects send custom events to and receive custom events from some global event source (perhaps document.body), like I did back in the days when I wrote Mac software.

UI is hard. I’m glad I did all the UI myself, but next time I’d like to build on the work of others. I’m still looking for a good Javascript widget library. Some of the widget libraries I’ve seen are trying to make web apps look application-y, and I’d prefer my web app to look web-y. Also, some libraries don’t have great support for calling everything from Javascript. I think I’ll look into Dojo again now that version 1.0 has been released, and more importantly, now that there’s more documentation.

Try It Out

There’s no way yet to sign up for Wshlst (if there’s enough interest I’ll do it), but the front page of the site lists some demo users you can use to play around: www.wshlst.com.

Read more articles about wshlst.com

The standard solution is to concatenate all the Javascript files into one big file and then compress it. I wanted it to be automated of course, and I wanted to do it at deploy-time, not at run-time.

So I wrote a little script that figures out what Javascript files are being included in the HTML page, compresses them with the YUI Compressor, concatenates them into a file named after the newly-compressed and -concatenated Javascript’s MD5 hash, and creates a copy of the original HTML page that references the new Javascript file instead of the old ones.

It’s pretty specific to my app’s needs, but with some minor tweaking, it should be useable on other projects. Check it out: minify.rb

$("foo").stylize({
  color: red,
  background-color: green,
  text-decoration: underline
});

Implementing stylize is easy with Prototype‘s Element.addMethods() method:

var ElementExtensions = {
  stylize: function(element, styles) {
    for (var s in styles) {
      element.style[s] = styles[s];
    }
    return element;
  }
}
Element.addMethods(ElementExtensions);

Update: Prototype 1.6 added a similar setStyle method which works similarly but also allows CSS string-type style declaration (e.g., myElement.setStyle("color: blue; border: 3px")). Still, the above is a nice example of Element.addMethods().

Easier said than done

Here’s the error I got:

It was looking for header files in /usr/lib/ruby/1.8/powerpc-darwin8.0, but they weren’t there; they were in /usr/lib/ruby/1.8/universal-darwin8.0.

The Solution

The solution was simple enough: create symlinks to the header files:

$sudo ln -s ../universal-darwin8.0/*.h ./
$sudo gem install termios

There’s even a Monstatic Widget for Yahoo Widgets.

I only wish it had Jabber notification in addition to email notification.

I also read about dwatch but I figured a service would be easier.

Update: I got an email from Arun who works for Site24x7.com. It seems to have more features than Montastic, such as being able to look for a particular keyword in the response (or not in the response), and nice looking reports. I’ll be trying them out alongside Montastic. (Unrelatedly, the makers of Site24x7 also make Zoho, a suite of productivty apps like a word processor, spreadsheet, etc. Somehow I’d never heard of them.)

Update 2: My pals at Pivotal Labs have released Monitwitter, which uses Twitter to show you the status of your servers. Brilliant!