What Mislav exploited was the fact that Working With Rails didn’t require a POST request to create recommendations, so just by visiting his blog you’d inadvertadly recommend him (if you were logged into WWR).
In less than 24 hours Mislav got enough recommendations to boost his raking by 10 places.

WWR fixed that particular hack, they disallowed GET requests to the create action, only allowing POST ones.

However, they certainly haven’t solved the problem. It’s possible to make cross site POST requests without the user actively submitting a form. This script I made creates an iframe with a form inside, and submits the form. So, without a user realizing it, they’ve recommended me on WWR (I haven’t used it in this site btw).

It just shows that it’s fundamentally important to use a form authentication token (which Rails 2 now does by default) to prevent CSRF.

And, it’s worth bearing in mind that an open crossdomain.xml file would make any CSRF protections absolutely worthless, since you could go and grab that form authentication token with Flash.

The other day someone sent me a Powerpoint file containing some screenshots, wrong on so many levels, but perhaps some good will come out of it since it motivated me to write this simple Air app.

Airdoc is a very simple Air application that registers itself to open those Office documents. It’ll then proceed to upload them to Google Docs - and open them right in your browser.

You’ll need to install Adobe Air first.

Download Airdoc.

Rack is an abstraction between Webservers and Ruby web frameworks. Thin, for example, uses this to great effect - by using Rack, Thin automatically supports tons of Ruby web frameworks out of the box:

• Camping
• Coset
• Halcyon
• Maveric
• Merb
• Ramaze
• Sinatra
• Vintage

There is also a Rails adapter to Rack (in the Thin repo)

So, wouldn’t it make more sense for the mod_rails team to work on mod_rack? Then you could upload a simple Ruby script like this to your webserver, and it would just work:

rack_app = Proc.new do |env|
[200, {”Content-Type”=>”text/html”}, “hello world!”]
end
run rack_app

After Paul’s neat hack to allow downloading of IPlayer programs, I thought I’d also improve the IPlayer’s pink experience by providing an RSS feed.

The Big British Castle, in their infinite wisdom, don’t provide a feed to the IPlayer, but instead email you updates - how antiquated is that!

So, I’ve made a simple script that scrapes their website (with Hpricot), and constructs a RSS feed. And I have a cron job that runs it daily.
For example:
./iplayer-feed /path/to/apache/public/dir/iplayer-feed.rss
Or in the crontab:
20 4 * * * /path/to/iplayer-feed /path/to/apache/public/dir/iplayer-feed.rss >/dev/null

Originally I subscribed to the daily updates (as you can see from the code). However - I underestimated how much unwatchable content they make, so I had to cut back to a few categories. Since everyone’s taste is different, I’d thought I’d post the code, rather than host the feed, so people can customise it to suit themselves.

So, just browse the IPlayer site, choose a few categories, and paste the urls into the code. Or, take the full plunge, and subscribe to the daily updates (don’t say I didn’t warn you).

Anyway, here’s the code.

Disclaimer: I’m fairly new to Python and Twisted - so there may be a way of speeding them up which I’m not aware of - perhaps by compiling to byte code or using a stackless interpreter.

Rather than test performance at a TCP level, I thought I’d do more of a real world example - and test HTTP servers. Thin (combined with Rack) is a HTTP layer to EventMachine. Twisted has its own HTTP parser built in.

Results (recorded with ab)

Concurrency: 20
Requests: 2000

EventMachine: Requests per second: 3327.79/sec (mean)
Twisted: Requests per second: 3194.76/sec (mean)

Concurrency: 200
Requests: 20000

EventMachine: Requests per second: 4401.80/sec (mean)
Twisted: Requests per second: 4761.90/sec (mean)

Conclusion

Take these tests with a pinch of salt, as the old saying goes something along the lines of ‘There are lies, damned lies, and then there are statistics’.

The results are remarkably similar - with EM beating Twisted at some concurrency levels, and vica versa. There doesn’t seem to be an obvious difference in requests per second - even with an extremely large volume of requests.

To be honest, I’m a bit surprised. Ruby isn’t know for it’s speed, and we’re already using 2 more gems, Thin and Rack which, although they are as light as possible, still add overhead.

When it comes down to virtual memory Ruby uses a hefty 47 mb, but Python isn’t much better at 39 mb. I don’t suppose that would be a deal breaker for most people though.

I call it a draw ;)

You can see the code I used here.

Aireo is an digital asset solution, letting you simply upload your files to the internet, keeping them backed up safety, and providing a intuitive interface to access them anywhere.
On top of this, Aireo’s sharing capabilities allow you to email files and create links to them (shown in the last screenshot).

I’m also working on a client side part of Aireo which will be released next.

My experience with queues in general suggests that most of the time you don’t need anything complicated at all and the biggest concern is performance and stability.

I’ve used SQS, but I think even that goes too far with message ids and explicit message deletion.

All you really need is ’set’ and ‘get’, basically just the memcached protocol.
Twitter seem to have produced their own messaging queue, called Starling, that works on this principle; but, as far as know, it hasn’t been open sourced.

So, last night, I wrote my own, called Sparrow. It’s in early stages at the moment, but you can grab the code from the Google project.

The advantage of using a simple protocol like memcached is that there are lots of other client libraries out there that will support it already.

Sparrow comes with built in support for daemonization and clustering. Also included are example libraries and clients. For example:

require 'memcached'
m = MemCache.new('127.0.0.1:11211', '127.0.0.1:11212', '127.0.0.1:11213')
m['queue_name'] = '1' # Publish to queue
m['queue_name']       #=> 1 Pull next msg from queue
m['queue_name']       #=> nil
m.delete('queue_name) # Delete queue

# or using the included client:

class MyQueue < MemCacheQueue
  def on_message
    logger.info "Received msg with args: #{args.inspect}"
  end
end

MemCacheQueue.connect('127.0.0.1:11211')
MyQueue.publish('test msg')
MyQueue.run(true)

I’ve yet to run any proper tests, but early indications suggest that Sparrow processes messages at a rate of 850-900 per second (per client) which obviously depends on any clustering you’re doing. You can even open up several streams to Sparrow, since it uses eventmachine and has a non-blocking io, so it may not be necessary to have more daemons running. In a cluster of three, I can get message processing up to the 3000 per second mark.

Ideally Sparrow would be ported to a faster language (perhaps just pure C) than Ruby.

Anyways, It would be good to have some feedback - especially on code optimizations. For example, I don’t think the way I find messages after they’ve been saved is particularly fast.

>> {:ruby_symbol => :sym}.to_xml
=> <?xml version="1.0" encoding="UTF-8"?><hash><ruby-symbol:sym/></hash>

What is ruby-symbol:sym I ask you! Rails obviously chokes on this xml and your post/put fails. However, serializing Active Record objects works fine:

>> User.find(:first).to_xml
=> <?xml version="1.0" encoding="UTF-8"?><user><ruby-symbol type="yaml">— :sym\n</ruby-symbol></user>

So the problem is that Active Support’s serialization has got a bit of catchup to do with Active Record’s.
The next two lines are a quick and dirty way of fixing it for symbols (which is the only serialization I use) for the meantime, but I hope this will be fixed by the time Rails 2 comes. You can obviously add copies for Arrays etc.

ActiveSupport::CoreExtensions::Hash::Conversions::XML_TYPE_NAMES[’Symbol’] = ‘yaml’
ActiveSupport::CoreExtensions::Hash::Conversions::XML_FORMATTING[’symbol’] = Proc.new {|symbol| symbol.to_yaml }

Update
That was quick. I’ve been keeping an eye on the Rails edge changesets and it’s been fixed. Thanks Assaf.

  Mq.run_all(5) # which would run 5 pollers per queue forked with Daemonize

Get it here

As far as I know, Ruby/Rails has only two major libs for interfacing with SQS. ActiveMessaging and SQS.

I wasn’t satisfied with either since using ActiveMessaging with SQS seems rather overkill (chain saw to a bunny rabbit) and the SQS lib is too simple for my needs.

So, naturally, I wrote my own (on top of SQS) and here it is. It’s targeted towards a Rails environment, but should work in just plain Ruby too.

I’m debating whether to move this into a plugin, or just a single file in the lib directory. I’m going with the latter, at the moment, as it doesn’t really seem big enough. Likewise, I’m thinking of creating a google code project - let me know if you want to contribute.

So, the main concept, is similar to ActiveMessaging. You define Queues (or Processors) which inherit from one central class. If you’re using Rails, it’s best to add another folder containing these to the load path in environment. Each processor has its own queue on SQS. The log naming defaults to the lowercase class name. You can define delays and retries in your processor, which will overwrite the defaults.
Like so:

class AnotherQueue < Mq
  def on_message
   logger.info('Log from Another Queue')
   logger.info(args)
  end

  def retry_attempts
    1
  end

  def delay
  end
end

You can then add messages to the queue with a simple YourQueue.publish(*args), and pull them off with a YourQueue.run, accessing all arguments passed to the publish method in a ‘args’ variable.

  Mq.connect({:access_key_id => 'foo', :secret_access_key => 'foo'}) # in environment.rb
  Mq.run_all # in script/console or you can do individual queues: AnotherQueue.run(true)
  AnotherQueue.publish('a message') # somewhere in your app...

Methods on queues inheriting from Mq

  AnotherQueue.count
  AnotherQueue.empty?
  AnotherQueue.queue # raw SQS queue object
  AnotherQueue.destroy # returns false if queue isn't empty
  AnotherQueue.destroy! # forces destroy
  AnotherQueue.queue_name # the name of the queue on SQS
  AnotherQueue.run # eternal loop that pick up messages for this queue. Pass 'true' to daemonize
  AnotherQueue.publish(*args) # publish message to queue (needs at least one arg)

And the ones you’ll need from Mq:

  Mq.count_all # counts every message in every queue
  Mq.run_all # runs every queue (daemonizes by default)

I’ve also added some neat daemonization (you’ll need Daemonize btw), so pollers have the option of working in the background.

There’s still a bit of testing to be done, especially with the multiple poller for the same queue scenario, but I just wanted to get it out there, so to speak.

So, to sum up, you’ll need the SQS gem, the Daemonize lib and, of course, a SQS account with Amazon.

Get it here.

I’m not sure what the next step will be. I suppose it depends on feedback. I may release another lib I’ve written, using the same interface and methods, but using the db to queue messages.