The Twilight Sun

Programming

Using retry after a LoadError

by Jonathan on May.12, 2011, under Ruby

Someone in the Ruby IRC channel pastied this code today and complained about how ugly it is:

begin
  require 'vlad'
rescue LoadError
  require 'rubygems'
  begin
    require 'vlad'
  rescue LoadError
  end
end

It’s meant to account for differences between Ruby 1.8 and 1.9, where rubygems is automatically loaded. And this code is pretty ugly. I came up with a simplified version that takes advantage of require()’s return value, and the `retry` statement:

begin
  require 'vlad'
rescue LoadError
  retry if require('rubygems')
  # raise
end

The `retry` keyword jumps back to the start of the ‘begin’ block so you can try to load your libraries again. Used carelessly this would turn into an infinite loop (LoadError occurs, retry, LoadError occurs, retry, ad nauseum), but since require() returns false if the library was already loaded, you can skip the retry in that case.

This version eats the LoadError, which is useful for an optional dependency, but if you don’t want that you can comment out the `raise` above. If the retry ended up not doing any good, it’ll just re-raise the LoadError that was rescued.

Frankly, this probably isn’t very useful in practice. After all, if you cared about 1.8/1.9 compatibility, you could just require(“rubygems”) first and get rid of all of the exception handling. I think it’s a pretty good example of how `retry` works, though.

9 Comments more...

Cooking up Dishes

by Jonathan on Aug.08, 2010, under Aspect, Web programming

I’ve just begun building the messaging model for Aspect, and I’m developing it as a separate, reusable Rack-based framework. It’s called Dishes, which is an extraordinarily lame pun derived from “asynchronous” sounding like it has a “sink” in it. So far things are looking good, but there’s a lot of work still ahead!

As it happens, I read up a little on BOSH, and it uses exactly the same two-connection model I described in my last post. It’s interesting reading and I’m sure to take a lot of inspiration from it. I don’t really want to adopt BOSH in its entirety because I think it’s way more than I need; Dishes is probably going to be fairly small.

Something cool I’m trying in Dishes is putting each request in its own Fiber. Since Aspect is going to be extremely I/O bound, it makes sense to re-invert the evented model using fibers to make handlers feel more synchronous. That will make it easier to use Dishes.

Anyways, that’s enough late-night rambling for tonight. When I have a simple working Dishes example, I’ll post again and explain how everything works. Meanwhile, you can always take a look at the current code. I even have a basic goal application to aim for.

Comments always welcome!
~Jonathan

7 Comments :, , , more...

Aspect’s messaging model

by Jonathan on Jul.28, 2010, under Aspect, Computers, Programming

(Before I begin, I should warn you that I haven’t had much time to actively work on this yet.)

I found an article about Starbuck’s method of handling coffee orders on Hacker News today. I was surprised, because I had explained this exact concept to some friends already, but using Pat & Oscar’s instead! This kind of query-response architecture strikes me as the perfect model for Aspect, because everything you do constitutes a request, and everything Aspect tells you is some form of response.

The Pat & Oscar’s analogy is a little different from the Starbucks one, though, and it highlights a few key points. If you’ve never been to a Pat & Oscar’s, it works like this: You go to the counter, make your order, receive a number, sit down at a table, and place the number card in the little holder on the table so they can find you. When the order’s ready, they come to you with the food. Importantly, you can make multiple orders and receive multiple numbers, and the orders will be served whenever they’re ready.

Now, how do you apply this to web communication? The classic HTTP protocol has a strictly blocking request/response format, meaning that every request must wait until the response is sent before you can reuse the connection. Most browsers have a cap on how many active connections you can have, and the bare minimum is IE’s two connections. So we need to make this work by using only two connections.

The solution is to use one connection for making requests, and the other for receiving results! You keep the results connection open constantly, and use the other whenever you make a request. The request connection must be closed as quickly as possible, so you just return an “order number”, a job ID. When the job is done, it’s pushed down the response connection along with its job ID. Then you re-connect the response connection so it’s constantly open. The approach the response connection is using is called long polling. Instead of polling periodically, the server hangs on to the connection until it has something to send.

I believe that this is a powerful approach to Comet-like communication. Unlike pure long polling – where the server simply holds the connection instead of responding immediately, and the client doesn’t need to care – it does require some infrastructure on both sides of the network gap. But if it can be abstracted properly, it should really be very easy to use. It’s just a layer you can work on top of.

I’ll be working on this as time permits, and of course I’ll open-source my work on this (though probably not Aspect itself) after a certain point. I’m a firm believer in open-sourcing platforms so everyone can benefit. If anyone else is interested in helping though, I’d be glad to make it public sooner! I think this is a useful model that definitely has applications beyond Aspect.

~Jonathan Castello

1 Comment more...

Lots of projects, not enough time

by Jonathan on Jul.14, 2010, under Programming

I’ve got a lot of interesting projects I’m dealing with right now, but I just don’t have enough time in the day to give each one the attention it needs. And naturally, some projects take more priority than others. Some of them are pretty cool, though, so I figured I’d list them here.

Aspect – The big one. I’ve been tinkering a lot with the MUSHclient source in my spare time instead, because it doesn’t take as much focus as building a whole new client, so at least I’m getting more experience with MUD clients. But this guy deserves a lot more attention from me.

Unnamed Rails project – This one takes priority, because I’m building it for my father and I actually get paid. It’s getting closer to completion, but I’m no designer, so getting the CSS just right takes a lot of my time. Inexperience rules the day here (but I’m not a total kludge!).

MUSHclient plugins and libraries – I’ve had plenty of ideas here, and a good amount have actually been completed. My newest project is a highlighting library which makes it much simpler to “paint” parts of lines different colors and styles without manually creating a trigger for each change, or worse, gagging and re-echoing the line with your changes. It should be simple to implement if I can just sit down and get down to business.

Misc. jobs – I do a lot of odds and ends for my father, like setting up Webalizer for a website. I’m very new to the whole Linux scene, so I (get|have) to learn something new with almost every job. (With Webalizer it was cron jobs.)

And then I do things in Real Life™ and in online communities like the MUSHclient forums. Of course, most of this is self-inflicted, and I enjoy everything I do; I’m definitely not complaining. I just come up with too many projects for my own good. :(

…As a rather funny side-note, I remember learning C++ and having no idea what I should do for my next project, and just kind of muddling around. Now I find myself with an excess of them. Life is bittersweet.

2 Comments more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...