The app uses various algorithms to calculate your friend’s most interesting tweets, providing a daily Atom feed with the top 50. The idea is that you potentially miss out on a lot of interesting Tweets during the day – there’s just too many tweets to read. MissTweets solves this by showing you your friend’s top tweets once a day.

Check out the site.

CSS has advanced so far recently, that I believe it can go some way to replacing Photoshop in the design process. With that in mind, I present YMockup – UI mockups using HTML and CSS.

With YMockup, you can code up a general theme for your site – and then drag/edit/resize elements to your hearts content! It’s really flexible, and you can create any kind of element that your site needs.

The best part of it, is that you can reuse all the CSS and HTML in your actual site – no need to cut up the designs in Photoshop.

Try out the demo here (only supports WebKit based browsers, such as Chrome or Safari).

YMockup Features:

• Customisable for any HTML/CSS
• Edit elements in place
• Drag and drop
• Snap to grid dragging
• z-index control
• Move elements with the arrow keys (hold ctrl)

If you want to use your own themes/elements, clone the repository and follow the README – it’s designed to be used locally, so you can edit the HTML and CSS in your preferred editor.

As you can see, I’ve include the aristo theme – since I’m primarily using this to build Bowline applications.

Of course this won’t be everybody’s cup of tea, and does require a good knowledge of HTML/CSS. However, I believe it’s perfect for design minded hackers, like myself.

• New desktop app framework using wxWidgets, WebKit and Ruby 1.9.
• Improved and faster binding API
• New API for asynchronous Ruby/JS callbacks
• Bundler support
• Background updating
• Loads of fixes and optimizations

There’s also a new JavaScript framework for Bowline which will be released soon. It’s designed to be fairly de-coupled from Bowline – so you can use it for web applications. The idea is that you can share a lot of code between your desktop apps and your web applications.

Additionally I’ve been working on a project for in-memory models called SuperModel.
SuperModel works particularly well inside Bowline apps. Here are the main features:

• Serialisation
• Validations
• Callbacks
• Observers
• Dirty (Changes)
• Ruby Marshaling to disk
• Redis support

I’ve also re-written SuperModel in JavaScript – it’ll be integral to the next Bowline release.

Syncro is another recent project – it’s like Juggernaut on steroids! Syncro let’s you easily synchronise Ruby classes and state between remote clients. It’s also has some fancy features like offline support. You can now make Bowline apps, that function fully offline, and then can synchronize up to your servers (and any other clients) when they come back online.

All that work has made Taskforce possible. Taskforce is a collaborative work manager. Think of it as a cross between Things.app and Google Wave. Here’s a recent screenshot of Taskforce working on top of Bowline on OSX.

If you’re interested, sign up.

There is another way though. Remail is a project I’ve just released that brings REST to email.

Remail proxies emails through Google App Engine:

• To send an email – just send a POST request to your Remail Google App Engine.
• To receive an email – Remail will send a POST request to a callback URL.

It’s that simple. App Engine gives you 2000 free emails a day, and if you need more – the prices are very reasonable.
It’s worth mentioning, that at the moment, Remail only works with Rails 3.

Step 1 – App Engine

So, firstly create a App Engine project:

Next, install the Python developer SDK.

Clone the remail-engine git repository:

git clone git://github.com/maccman/remail-engine.git

Configure the remail-engine application.yaml file, by adding the name of your App Engine project (the yaml key is called application).
Then, you’ll need to configure the settings.yaml file. Specify the public url of your site as outbound_url, and a random string as api_key (you can generate one using uuidgen).

Add the remail-engine to the App Engine SDK and deploy.

Step 2 – ActionMailer

Install the remail gem:

sudo gem install remail

Add add it to your Gemfile:

gem "remail"

Now configure Remail, either in application.rb, or in the environment files:

  config.action_mailer.delivery_method = :remail
  config.action_mailer.remail_settings = {
    :app_id  => "remit-yourappname",
    :api_key => "changeme"
  }

Right, so now we can send email. How about receiving them? We need to specify a callback controller like this:

class EmailsController < ApplicationController
  skip_before_filter :verify_authenticity_token

  def create
    if request.headers["Authorization"] != "yourapikey"
      return head(:unauthorized)
    end
    UserMailer.receive(params[:email][:raw])
    head :ok
  end
end

Remail will send a POST request to that controller when it receives any emails.
If your Rails app isn’t available – Remail will try again and again – backing off as time goes by.

Right, so those are the two steps to using Remail in your application. You can now generate mailers as usual – everything should just work.

There’s a good Railscast on using ActionMailer with Rails 3, and a good Rails Guide on the subject.

Amazon don’t provider customers with a fixed IP for a ELB, only a CNAME.
Since a CNAME can’t be the root of your domain (it must be an A record) – you can’t fully balance traffic to your domain.

At the moment, customers have to forward all traffic to a CNAME, from http://example.com to http://www.example.com, to load balance their domains. This introduces a single point of failure. If the server you allocate to serve traffic from the root of your domain goes down, nobody gets forwarded.

In addition, this root server isn’t load balanced, so it receives all the initial traffic to your site. This defeats ELB’s purpose somewhat.

There’s a post that’s been on Amazon’s ELB forums for about a year – with about 60 replies, this clearly is a popular ‘feature’ (or I would argue requirement). It’s a deal breaker for some.

Amazon’s response is this:

Thanks for all the feedback. We understand your concerns and supporting this feature is on our roadmap. Unfortunately, we do not have a specific timeline for its availability.

As one commentator puts it:

Serving HTTP traffic off your root domain out of your core stack is really a basic thing that any load balancing solution needs to support.

Amazon, when do you expect to launch this feature?

We recently launched Machsend, which enables people to send unlimited amounts of data from inside the browser. You literally drag a file onto the site, send the recipient a link, and they can download it straight away. Machsend uses TCP P2P connections to transfer data between clients.

Most of the packets on the internet are controlled by TCP which provides a reliable, ordered delivery of a stream of bytes between two endpoints. The alternative is UDP which is much lower level than TCP – information isn’t guaranteed to reach its destination. Most P2P implementations use UDP to communicate (for reasons we’ll come to later), but I’m going to show you how to get the flow control and reliability of TCP in P2P connections.

Routers (combined with firewalls) are both critical to the stability of the internet, and an enemy to P2P connections. Networks can have lots of computers behind a single IP using a router – and the router will make sure the right packets get to the right computers, AKA NAT. However,  I guess they just weren’t designed with P2P in mind – so most require a bit of coaxing/trickery to set up P2P connections.

With UDP it’s fairly straight forward – that’s why it’s so commonly used in P2P software.
Client A sends a packet to Client B, opening a hole in Client A’s firewall. That packet will be discarded by Client B’s firewall, but that doesn’t matter. Client B then does the reverse, sending a packet back Client A – now there’s a hole in both firewalls and a P2P connection. I’m glossing over some of the more technical details, such as STUN and port prediction, but that’s the general gist. Here’s a good article on how Skype uses UDP P2P techniques to traverse firewalls.

UDP is perfect for Skype, for example, since you don’t care that much about reliability when delivering audio & video – but rather responsiveness. The data is very time dependent and needs to get to its destination quickly. However, with most other data transfers we care that all the data reaches the destination properly. If you’re transferring a picture to someone, you want to be sure all of it reaches the recipient.

I have actually created a UDP protocol for data transfer that’s as reliable as TCP, yet is also faster. That, however, is the subject of another post.

While routers don’t meddle with UDP connections too much, that’s not the case for TCP ones. Routers will enforce TCP standards and prevent you from accepting random incoming TCP connections. On top of that, most operating systems require root access to create raw sockets, which you need to manipulate TCP streams at the packet level.

So, it’s a bit of a pickle – on hand you’ve got proper P2P connections with UDP, but you have to implement your own flow control and reliability algorithms. On the other hand, TCP P2P connections seem very tricky to setup and aren’t supported on many routers.

Most people presented with this problem, will either use UPnP, a protocol for programs to configure routers, or tell people to configure their routers manually.
Obviously, this is far from ideal, both approaches have major caveats, but unfortunately it’s going to be the status quo for a while.

I was in the aforementioned situation, until I found a paper titled Characterization and Measurement of TCP Traversal through NATs and Firewalls. The students tested about 7 methods of TCP P2P traversals, and advocated a fairly simple one that works with about 80% of the firewalls they tested.

To save you reading the paper, I’ll elaborate. The TCP protocol starts with a 3 way handshake of SYN and ACK packets. However, although it’s an unlikely combination, most routers will let through incoming SYN packets, if an outgoing SYN packet has been sent to exactly the same ip and port combination. So, to sum up:

• Client A sends a SYN packet to Client B
• Client A starts listening on exactly the same port the previous SYN packet was sent on
• Client B then creates a normal TCP connection to Client A, to exactly the same local port Client A used to send the SYN, binding locally to exactly the same port that Client A sent the SYN packet too.

And that’s all there is to TCP P2P – those three steps.

To send a SYN packet without using raw sockets you just open a socket to an address, and then immediately close it.

To open a socket on a particular local port, since it’s usually chosen for you, you just need to set some options. If you enable SO_REUSEADDR and SO_REUSEPORT the operating system shouldn’t complain.

The document for Ruby’s Socket class is fairly sparse, so here’s an abstraction over it:

To accept connections from Client B, Client A sends a SYN packet, and then listens:

Client B’s connection to Client A looks like this:

If the connection fails, try reversing Client A and B, so Client B makes the connection to Client A – this usually works.

So, you might be asking yourself – how does Client A know Client B’s IP & port, and vica versa? Who’s controlling it? Well, for that you need a third party server known to both endpoints – usually called a STUN server, or with TCP traversal, STUNT. For Machsend, we built a JSON RPC server using Event Machine .

At the moment we haven’t implemented any port  prediction since I’ve noticed most of the routers keep the same ports that the computers choose. However, to improve reliability, that could certainly be implemented.

As well as the previously linked paper, there’s a good article on the subject here.

Currently I’m working on getting Ruby Threads working, Bowline would be a bit useless if it locked up every time you called out to Ruby. This involves upgrading upgrading Titanium’s Ruby version to 1.9, and using a rather obscure API for blocking the threads when Titanium calls Ruby (since Ruby isn’t thread safe). You can find the ticket here – if you’ve any experience with C++ please feel free to weigh in and help. This is the one major bottleneck to Bowline development – once it’s resolved we can get on with more interesting things.

I’m also working on closing the tickets – most of them to do with Windows support. At the moment I don’t have a Windows environment, just Linux and OSX – so more testers are welcomed.

I’ll be writing more documentation, tutorials, and a website. You can also expect a “twitter client in 5 minutes” screencast.

I’ve started up a Google Group for Bowline development here. This is one of the best times to contribute since the project is fairly young and can accommodate API changes without  any issues.

In a nutshell, Bowline lets you build cross platform desktop applications with Ruby, HTML and JavaScript. The idea is to make building desktop apps as simple (and fun) as building Rails websites.

Bowline is built on top of Titanium, a desktop SDK which essentially provides a Webkit window (and loads of useful APIs). The fact that Titanium uses Webkit (and a fairly edge version at that) means that you can take advantage of all those nice CSS3 and HTML5 features, and you can design for one browser.

On top of Titanium, Bowline provides:

• A way of binding up Ruby and HTML
• MVC development
• Helpers, Models etc
• Gem packaging
• Generators, console & more

In a desktop app you don’t have the request/response cycle that web frameworks, like Rails, are built around. So, to replace that, Bowline has the idea of ‘Binders’ – Ruby classes that you can bind HTML to – so when the Ruby class changes, the HTML automatically updates.

Additionally I’ve ported the beautiful Aristo theme to CSS3, you can find it on Github here.

Using Titanium’s Developer tool, you can package your applications up for all three OSes, it’ll be sent up to the cloud and built.

The rule is show, don’t tell – so here’s a basic Twitter client I’ve written with Bowline. Download the app (OSX only at the moment) here.

Twitter clients are truly the new ‘Hello World’.

It’s early days for both Bowline and Titanium, but progress is quick and I hope we’ll have a fully fledged desktop framework soon.

Machsend lets you send files to people without any size restrictions. Files are sent in a P2P fashion, straight from one client to another – which means transfers are faster, and you don’t have to trust a third party with your data.

If you’re on the same LAN, files are sent directly. Otherwise a type of firewall traversal  allows the two clients connect (which works on about 80% of firewalls). There are few good papers that explain more here and here.

Machsend uses Yahoo! BrowserPlus to perform this TCP magic.

Data transfers are unlimited – I’ve sent gigabytes over the system without any trouble.

Machsend works on OSX and Windows. Unfortunately there isn’t a version of BrowserPlus for Linux yet, but one is being developed.

There are a few more details on the ‘about‘ page.