I’ve just released Mnemosine, which is a key/value store written in Ruby. I wrote it for a CodeBrawl challenge, the details of which can be found here: http://codebrawl.com/contests/key-value-stores. Mnemosine is essentially an incomplete knockoff of Redis. It’s got some of the same data types, and many of the same functions.

Mnemosine could be a good app to study if you’re curious about TDD, client/server apps, using raw TCP sockets, or event driven programming. The tests are extensive, and the code is quite modular.

The contest may be over, but the project was a lot of fun, and I’d like to add some more functionality. For instance, Mnemosine has basic map functionality, but doesn’t support a reduce stage. I’d also like to implement sharding/replication sets, and maybe even indexed search.

Obviously a database written in Ruby is probably not going to be very performant. On the other hand, it’s easy to implement high-level functionality with Ruby, which makes Mnemosine a great testbed for features that would be more time-consuming to write in C/C++.

I’ve just finished putting together another screencast for Rocket. This one is a walkthrough of building a simple project. Unlike the last tutorial, this one is all live coding.

It’s based on the text documentation on this page: http://actsasbuffoon.com/rocket-io/Transmission_API.html

In addition, I’ve created a channel on Vimeo for my Rocket screencasts. The channel is here: http://vimeo.com/channels/236065

The documentation for Rocket.io is live, though there’s still some work to be done. Hopefully it’s enough to get you started.

I’ve got annotated Ruby source and JS source thanks to Docco.

Check it out at: http://actsasbuffoon.com/rocket-io

I’ve just finished a screencast for Rocket.io and made it available on Vimeo. Let me know what you think.

Rocket.io from Michael Tomer on Vimeo.

Rocket.io is a realtime web application framework built with Ruby. This is the presentation I gave at RailsCamp New England 2011 when the project was officially released to the public. Read more on my blog at http://actsasbuffoon.com or on my Github account at http://github.com/actsasbuffoon/rocket-io

I must confess, putting together a screencast is far more difficult than I’d imagined. The video quality isn’t quite what I’d hoped, but it gets the point across.

I got back from RailsCamp New England 2011 on Monday morning, and I had an awesome time. Brian Cardarella did a great job organizing the event, and the house was gorgeous.

We had people from ThoughtBot, Intridea, RailsMachine, and more. A great time was had by all, and a great deal of alcohol was had by most. Due to the smaller, more intimate nature of the meeting, I feel like I learned a lot more than I normally do at confs.

I’d like to see RailsCamp get bigger, but I think that would ruin the atmosphere. Maybe we just need them more often. I’d happily attend RailsCamp a few times a year.

I’ve done a fair amount of work with different forms of server push over the years, and I find that a lot of developers are curious about the topic. As such, I’d like to create a series of posts on the different ways one can send data to the client without the client initiating a request.

The Anatomy of a Web Request

Before we get into how push works, let’s quickly go over the way HTTP normally works.

The internet is built on TCP/IP (Transmission Control Protocol and Internet Protocol, respectively). TCP is a method of transferring data from one endpoint to another in a reliable fashion. Those endpoints can be different applications running on separate computers, though they can also be used to “loopback” to the same computer, and even the same application. Error detection and correction are built in at a low level. Unlike UDP, TCP ensures that each packet gets through in the intended order before allowing the next packet to be sent. That adds a bit of overhead, but alleviates a lot of headaches for most applications.

Internet Protocol on the other hand, is how the computer routes the data to its intended recipient. We’re all familiar with IP addresses, which are indeed a part of the Internet Protocol.

Many applications use raw TCP sockets to communicate. For instance, when you connect an application server to a database server, they may very well be communicating over a raw TCP socket.

HTTP (Hypertext Transfer Protocol) is a request/response protocol that runs on top of TCP/IP. Simply put, a client makes a request to a server (consisting of a request line, headers, and possibly a body). The server handles the request in whatever way is deemed appropriate and sends a response consisting of headers and possibly a body.

Here’s a slightly more in depth look at what happens when a user types a URL in their browser and hits enter:

• The client turns that URL into an IP address. If the address is cached then that is used, if not, it requests the information from a domain name server.
• The client initiates a TCP connection with the server.
• The client sends the request data, including a request line (i.e, GET /index.html HTTP/1.1), headers, and perhaps a body.
• The server processes the request.
• The server sends the response data, including headers, and possibly a body.
• The TCP connection is ended.

This happens for every single piece of data that needs to be requested. You’ll make one request for the HTML page, another for the CSS, a few for however many Javascript files are included, and one for every single image, etc. You could easily make several dozen requests for a single page, each of which goes through the entire list of steps given above.

When you think about it, it makes perfect sense that a server can’t normally push data to a client without a request; after responding to a client, the TCP connection is terminated and the server doesn’t even know if the client is still available.

Despite that, there are many means for getting realtime or semi-realtime data to users. Many years ago polling was the only option, followed by Java, Flash, ActiveX and other browser plugins. Eventually Web Sockets and Event Source were created, which allow for realtime data push without plugins. That said, all of the aforementioned techniques are quite different. I’ll cover some of those options in later posts including example applications.

So in summary:

• IP is how computers locate and route data to one another on the internet.
• TCP is how the individual packets of data are transferred in an orderly and fault resistant fashion.
• HTTP is how clients and servers speak to one another. It involves an unbreakable request response cycle.
• Polling, plugins, Web Sockets, and Event Source allow us to send realtime (or mostly realtime) data to clients, but each has a unique set of pros and cons.

I’m moving my blog over to Github with Octopress. Bear with me while the DNS changes propigate and I import my old content.

I intend to create some posts about my new framework, tentatively named Rocket. It’s a realtime web application framework made with Ruby. I’m also going to create some posts about Web Sockets, polling, Event Source, Web Socket fallbacks, and probably Faye as well. I’d also like to talk about EventMachine a bit, as I’ve found that a lot of developers like to pick my brain on these topics.

Sometimes I’ll likely post screencasts on these topics. Watch this space.

I recently created an interesting animation with Raphael.js. This looks better on the original page, but here’s a preview:

I’ve just released Typekit In Situ, which aims to help you see more realistic Typekit font previews. Check it out on Github.

On the project I mentioned yesterday, I created some really nice CSS “buttons”. The buttons were actually just links with some nice styling, but they’d become a distinctive feature of the UI. Unfortunately, your only options for submit buttons are a regular button or an image, which wouldn’t mesh well with the rest of my UI. You can submit a form via Javascript, but I’m not sure if you can send a commit message that way, and I happened to need the message.

The buttons look like this:

It’s just a link with a CSS3 gradient, border, and CSS3 drop shadow. Inside is an img tag, and some text.

Fortunately, I was able to come up with an unobtrusive JS solution that should degrade gracefully. The following code uses jQuery and Coffeescript.

Notice

This isn’t intended to be a plugin or a piece of code you can use without modification, but with a little tweaking it could be handy.

1
2
3
4
5
6
7
8
9
10
11

$('input[type=submit]').each (i, eo) ->
  elem = $(eo)
  text = elem.attr 'value'
  cls = elem.attr('class')
  if /icon_(.+)/i.test(cls)
    icon = cls.replace(/^icon_/, '')
    elem.after "<a href='javascript:void(0)' class='button'><img alt='icon' class='icon' src='/images/icons/#{icon}.png' />#{text}</a>"
    btn = elem.next()
    btn.click (b) ->
      elem.click()
    elem.hide()

For example, say you have the following submit element:

The script iterates over all submit buttons, and checks to see if they have a class starting with ‘icon_’. If true, the script hides the submit button (but doesn’t delete it), and inserts a link after it. The script reads the class name (discarding the ‘icon_’ part) and uses that to attach an icon from my /public/images/icons/ directory. The script also uses the value of the original submit button as the text to insert in the new “button”.

When the user clicks the link/button, it triggers a click() event on the original submit button. This means that you still get the commit message. Additionally, if your user doesn’t have JS, they should just get the original button.

For the heathens among you who aren’t using Coffeescript, here’s the same code in plain Javascript:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$('input[type=submit]').each(function(i, eo) {
  var btn, cls, elem, icon, text;
  elem = $(eo);
  text = elem.attr('value');
  cls = elem.attr('class');
  if (/icon_(.+)/i.test(cls)) {
    icon = cls.replace(/^icon_/, '');
    elem.after(("<a href='javascript:void(0)' class='button'><img alt='icon' class='icon' src='/images/icons/" + (icon) + ".png' />" + (text) + "</a>"));
    btn = elem.next();
    btn.click(function(b) {
    return elem.click();
  });
  return elem.hide();
}