So here’s the deal: write a todo list application and a blogging application (the two Hello Worlds of the web) that don’t require me, as the developer, to maintain servers to support the users.

But I want to keep the stuff that makes users love webapps:

• Easy to install
• Seamless updates
• Available from any web accessible computer

We’re going to need some infrastructure to exist if this is going to work. But it’s only necessary to imagine two online services:

• OpenDB. This is a REST accessible database service, with authorization that restricts access with a username and password. It has a user friendly registration system.
• OpenServer. This is a REST accessible file system service, that serves the contents of a specified directory up to the web. It supports domain names and has a user-friendly management panel.

And that’s it. Here’s how the webapps work:

The Server-free Todo List Application

I write my application: The Untethered Todo. It’s just JavaScript and HTML. I deploy it by making those static files available on my web server.

My user arrives, and loads up the application from my server. The application is now running in the user’s browser. The app hasn’t got any persistance configuration, so the first thing it does is ask the user for the details of a database provider. The user - who is an early adopter, and quite tech savvy - types in the url and password of his OpenDB account.

The very first thing the application does is offer the user a single url, that he can bookmark and use to load the application up with the same database in future. The OpenDB url is encoded in the query string parameters, so next time the user will only need to type their password.

Then the app sets up the schema and any other initial database configuration. In this case it creates an example project and todo item. Now the app is ‘installed’ and ready to go.

Whenever the user loads the app from now on, the app will connect to the OpenDB database from the connection information in the query string and work from there.

From now on the application stores all its information in the OpenDB instance. If the user creates a new todo, the app (which is running solely inside the user’s browser) will post the required information to the database. Lists of projects are loaded up over that connection too, through a JavaScript ORM layer wrapping the HTTP calls.

At no point will the application need to talk to the developer’s servers. So I won’t need any. But since the user is loading up the app every day from my domain, I get to release updates straight to the user.

And that’s how I’m going to write a todo list web application that doesn’t require any hosting.

The Server-free Blogging Software

It’s a little bit more complicated to imagine blogging software that doesn’t need the developer or the user to run a server, because there are third parties involved now too. There’s me, the developer, there’s the blog author, and there are the blog visitors.

So in this case, when the application loads, it asks for OpenServer information. It then creates the blog as static files in a directory on OpenServer. Whenever the author writes a new post, the app creates the necessary files on OpenServer.

The author goes to OpenServer and specifies that she wants this domain attached to that directory, and any visitor to the domain name will see the blog served from OpenServer.

I imagine that the blog software wants to set up an OpenDB database as well. If the OpenDB provider supports ‘users’ (perhaps they are running MySQL), then there is a ‘commenter’ user that has insert-only access to the ‘unmoderated-comments’ table. Then when the author logs back in, the application - still running from her browser - loads the unmoderated comments and let’s her approve or delete them, before they are written to OpenServer as part of the blog.

Random Thoughts

• Server costs are zero.
• There’s no such thing as downtime - from my point of view.
• I don’t have control over the user’s database - so schema migration must be done very carefully.
• I don’t get to see usage information about my software.
• Every web application written in this fashion has an automatic data API.
• If there are going to be multiple OpenDB and OpenServer services, what do the common API standardS look like?
• Does anything like OpenDB or OpenServer exist already?
• Why does the MySQL multiple user access model suddenly seem so attractive again?
• When do I get to write these apps? :)

The lists feature of Redis meant that it was not necessary anywhere in the application to serialize a datastructure into a stored value. This is a tremendous win. I don’t have much experience of writing applications against key-value databases, but I worry that serialization would cause headaches.

I didn’t find a use for the Set structure, simply because I couldn’t see a set of data that I wouldn’t at some point want to page over. The list of a user’s followers was the closest I came. The downside of using a set is that in order to paginate the followers the entire set would have to be sorted first. The downside of using a list is that membership checking (is User A following User B?) requires list traversal by Redis.

There is a SORT command, so sorting sets can be done in the database layer, but I have no desire to sort this data (which could be massive) just to iterate over it in a consistent order. I went with a list for now, but you could use a set and a list to support both types of usage, at the cost of maybe twice the memory usage. I’d like to have an ordered Set structure available, if it could be done in a fast way.

I wonder if a Set and List is all we’ll get, or if Salvatore is planning more structures. Could you implement Trees in any kind of sensible way? Arrays? Would they be useful?

Anyway, I encourage you to try Redis out soon.

http://github.com/danlucraft/gutkumber/tree/master

I’ve been using Gutkumber on the Redcar editor project for a while now, and it seems to work well. Here is an example of the kind of features you can write with Gutkumber:

  Scenario: Kill line
    When I type "def foo"
    And I press "Left" then "Left"
    And I press "Ctrl+K"
    ... some Redcar specific assertions

  Scenario: Open a file
    When I press "Ctrl+O"
    And I set the "Open" dialog's filename to "plugins/edit_tab/features/fixtures/file1.rb"
    And I click the button "Open" in the dialog "Open"
    ... some Redcar specific assertions

This is still in early development (it’s probably the most rough and ready software I’ve ever released!). But I’m finding it useful and I thought it would be good to demonstrate that it is possible to thoroughly integration test your Ruby-GNOME2 applications.

I’m writing new steps and helpers as I go along, but they are quite specific to my application, so you will probably find you need to write more. It’d be great if we could build the set of helpers and steps to the point where it contains everything needed to test new Ruby-GNOME2 apps.

But getting Cucumber up and running to test Ruby-GNOME2 has been a joy. I think this is because unlike the other two, Cucumber doesn’t use Ruby’s at_exit to determine when to run its tests, giving you more control over the environment.

So here’s how. The problem with testing Ruby-GNOME2 - and indeed any gui - is that they are event based. Once you decide to use Ruby-GNOME2, you hand over control of your application to the gui main-loop. But test frameworks rely on keeping that control so they can dispatch tests.

For instance, you could decide to have a button in your application that reads “Run Tests”. And that button, when pressed, would fire a gui event that sends off to Test::Unit or whatever to say ‘run all tests’, and Test::Unit would march through its test suite, and then the original event would return control to the gui.

But all your tests have been processed within the same gui event handler. So by definition, no other events can have been processed during that time. That means no keypresses or menu clicks or TreeView updates will work in your tests.

What we want is for the gui to process events as needed, but still keep the control with our tests. We do that by replacing the GTK main-loop with a loop that we control.

First you have to write your application to not start the main-loop if features are running, as we will process our events manually. So your code will need to contain a guard like:

  unless $running_features
    Gtk.main
  end

Now in a Test::Unit testcase, you would need to write code like:

  def test_click
    click_button
    process_all_gui_events
    check_dialog_visible
  end

But in Cucumber, we can write something more natural. Our feature will look like this:

Feature: User clicks on something

Scenario: Single click
  When I click on the button
  Then the dialog should be visible

Run this feature using this Gtk Cucumber formatter (requires Cucumber 0.2):

module Cucumber
  module Formatter
    class GtkFormatter < Pretty

      def visit_step(step)
        super
        while Gtk.events_pending?
          Gtk.main_iteration
        end
      end
    end
  end
end

And gui events will automatically be processed between each Cucumber step. Of course this means steps can’t rely upon events being processed within the body of the step, but steps are supposed to be short and atomic anyway, so it should not be a problem.

I have just started using this technique in Redcar, and it has been working very well (example). It’s much more comfortable than the RSpec version that I was using before. I’ll now use RSpec for unit testing in my application, with no gui interaction at all. This seems right because a test that requires the gui like this is an integration test, and Cucumber is our integration test framework!

(Picture: Gideon Bullock)

So use features_report to unlock those specs and turn them into a lovely PDF. Here’s a sample of the output. Install and use like this:

sudo gem install features_report
features_report features/*.feature

Features:

• Uses Prawn to generate the PDF.
• Has a table of contents of all your features
• Option to add a logo to the front page.
• If you use git, it can add a ‘last changed date’ to the table of contents, along with the name of the committer that last touched it. (Requires the gem ‘mojombo-grit‘ to be installed from Github).

Issues:

• The contents page is at the back. I don’t think Prawn has the capability to go back and add the contents page after the document has been generated, if I’m wrong please enlighten me.
• FIT tables are not handled correctly. The Cucumber project is rewriting the parser at the moment, and it looks like adding this will be lots easier afterwards so we decided to wait.

The source is available at Github and features_report was written by Daniel Lucraft and Niko Felger. Features_report was sponsored by Songkick.com. Thanks to Bryan Helmkamp for some cribbed Cucumber parsing code from features2cards.

Confreaks have put the RubyConf 2008 videos online here. To convert the larger 960×468 videos to a format playable on your Ipod using ffmpeg:

ffmpeg -i ruby-19-what-to-expect-large.mp4 -cropleft 480  \
-vcodec h264 -b 150k -bufsize 244 -maxrate 768k \
-s 480x368 -bf 0 -level 13 -f mp4 -acodec aac -ar 48000 \
-ab 64 ruby19.mp4 

Confreaks videos have two halves: the slides and the presenter. The cropleft option removes the left hand half of the video, in this case the presenter, leaving just the slides.

If you want to test out your options you can tell ffmpeg to only process a few frames:

-vframes 2000

Connection

Choose your IRC chat client. I used to use Pidgin, but now I use Irssi. A terminal based client was my choice because it means I can leave it open on my server and connect to it from wherever I am, work or home. That means the client is never closed, so logging can happen continuously and I do not need to disconnect and reconnect periodically. Disconnecting and reconnecting is accomplished using GNU Screen. This is a good tutorial on using Screen and Irssi together.

You do not need to use Irssi, or to have a permanently open connection to run an IRC chat. Having said that, ChanServ has some impenetrable help text about channel successors or somesuch, so may want to test this stuff out.

Register your nickname

Before you can register a channel, you have to have a registered nickname. Send a message to the NickServ bot to register the nickname you are currently using. You can send the message from any channel (though be careful with your typing otherwise you will be broadcasting your password).

/msg nickserv identify mypassword

Create your channel

You create a channel by joining it. So type:

/join #mychannel

Register your channel

Registering a channel secures it from being taken over by unscrupulous types. Freenode runs the ChanServ bot for this purpose. To register your channel send a message to ChanServ

/msg chanserv register #mychannel

You can now use ChanServ to grant yourself admin privileges when you need them, and to make sure that no one else has admin rights. To give yourself admin rights to your channel (called ‘ops’) type:

/msg chanserv op #mychannel

To remove admin rights type this:

/msg chanserv deop #mychannel

According to my sources, admin rights are like sudo, you should grant them to yourself when you need them but otherwise have them turned off.

You can get help about all of ChanServ’s commands:

/msg chanserv help

• Stripes: check.
• Reflection: check.
• Beta: check.
• Rounded corners: check.
• Gradients: check.

Gosh. If only there was a new design in the pipeline I could look forward to.