Helicoid Insider

Agile Deployment

Alex Young — Mon, 13 Jul 2009 16:17:39 BST

I’m working on a series of articles about deploying Rails apps. It’s based on things I’ve learned at Helicoid, and it’s called Agile Deployment. Read it over at my personal blog.

Open Source: JsChat

Alex Young — Wed, 1 Jul 2009 12:38:15 BST

As well as Loom, I’ve been working on a few other open source projects funded by Helicoid. The biggest so far is JsChat which is an MIT-licensed JSON-based chat system with a nifty web interface:

People have called it an “open source Campfire”, but it’s not really meant to be a Campfire competitor. It’s actually a response to these questions:

Can we make a chat system like IRC without the legacy and bloated protocol?
Can it work naturally on the web, desktop and console?

The “Js” in JsChat refers to JSON rather than JavaScript. It’s very easy to build bots and clients. For more information, see the JsChat site and JsChat blog.

Loom: Open Source Edition

Alex Young — Fri, 26 Jun 2009 13:09:10 BST

Loom is our issue tracking system. It evolved from Bugtagger, which I created for internal use in 2006. Loom has a few nifty features: the bug report form automatically snoops browser and OS details (to help designers), and it has exception tracking for developers. You can sign up to try it for free right now.

But the future of Loom is open source. I’ve set up a private GitHub repo to prepare it for release. It will be MIT licensed, and easy to set up for use within your company. I’ll continue to develop the server-based “closed” version, but features will be pushed back into the open source edition. The only major difference will be that Loomapp.com will be integrated into Helicoid’s single sign-on system that Helipad and Deadline use.

If you’re interested in helping prepare Loom for the public, contact us and I’ll add you to the private GitHub repo. The repository will become public once we’ve verified it installs and runs on enough systems—we initially had Ruby 1.8.6 issues (it was my fault), which Ric Roberts helped me fix.

Loom is built with Ruby on Rails, but help from designers and writers would be awesome too! You’ll get fully credited of course!

Secure Trading Rails Plugin

Alex Young — Wed, 15 Apr 2009 12:06:22 BST

We use Secure Trading for Helicoid’s payment processing. I wrote a payment processor plugin for our apps about two years ago, and it’s been in production since then. A few people have asked me to open source the code, so here it is: securetrading-rails.

I’d like to integrate it with ActiveMerchant because I like their API, but I haven’t had time so far.

Out of all the payment processing companies I’ve dealt with, which is a lot, Secure Trading have been the most reliable with the best customer service. Their XML API is relatively straightforward too.

Loom exception logging for your apps

Alex Young — Fri, 20 Feb 2009 20:14:47 GMT

We’ve recently added exception logging to Loom. There’s an open source rails plugin which you can use to integrate Loom with your Rails apps. The API is simple so we’ll probably collect plugins and libraries for other platforms (I’ll look into iPhone support for iPhone apps).

If you haven’t seen it before, Loom is a tiny app we built to track bugs in our apps. It also works well as a customer support tool. It originally started off as Bugtagger in 2006, and it had some work towards remote exception logging but this was never finished. Bugtagger was a quick app I built to support Tiktrac customer support in the early days.

So now remote exception logging is almost ready for the public. You can check out the plugin and integrate it with your apps by adding your Loom account details to a controller. The README on Github has more details. The code looks like this:


  enable_loom :email => 'alex@example.com',
              :password => 'test',
              :url => 'http://yoursubdomain.loomapp.com',
              :project_id => 1

There’s a lot of work to do to make this a truly useful tool, but I have a feeling closely integrating bug reports with support requests and logged exceptions could lead to something incredibly useful.

Add ShareThis buttons to Tumblr

Alex Young — Sat, 14 Feb 2009 11:51:06 GMT

Tumblr can be extended heavily by editing the templates and by adding services through JavaScript. I just wrote this ShareThis JavaScript that will automatically add ShareThis buttons to your Tumblr posts. This will:

Add Digg/Delicious/etc buttons in a menu so people can easily Digg your articles
Add the correct link and title to pages on your Tumblr index page, as well as on the article pages themselves

Here’s the code:

To use it follow these steps:

Sign up to ShareThis
Create JavaScript for “Other Blog” (ShareThis JS)
Login to Tumblr, and go to Customize, Theme
Get my JavaScript: tumblr_sharethis.js
Replace the first script line with your ShareThis JavaScript (ShareThis JS)
Paste your edited tumblr_sharethis.js into the header of your Tumblr Template
Change the template where it says {Block:regular} to include <div class="ShareThis"></div> after {Body}

I’ve been quite explicit with these instructions but it’s actually very easy to do. Just remember that you need to edit my JavaScript with your ShareThis code, because ShareThis uses your publisher ID for its API.

You can see this JavaScript in use on QuiteUseful.

Awesome Helipad ruby gem

Alex Young — Wed, 28 Jan 2009 12:46:18 GMT

If you want to write software that works with Helipad, there’s now an awesome Helipad gem written by Lonnon Foster. I’ve checked over the code, and it’s clean and well-written.

You could build a lot of cool stuff with this. How about a Shoes Helipad app? Or maybe something with RubyCocoa? Let us know what you build and we’ll give you mad props (and possibly riches).

Here’s some example code from Lonnon’s library:

Unified Single Site Browser (SSB) support

Alex Young — Wed, 14 Jan 2009 16:04:00 GMT

In Rapid Fluid support I talked about adapting web applications for Fluid. Since Bubbles for Windows has a similar API I decided to write a wrapper around Fluid and Bubbles so you can support both SSBs in your web applications.

This wrapper is called ssbx, and is used like this:


if (SSBX.isAvailable()) {
  SSBX.log('hello');
  SSBX.notify({ message: 'This is a message', title: 'Title' });
  SSBX.notifyOnce({ message: 'This is a message', title: 'Title', unique_id: 5});
  SSBX.setDockBadge(5);
  SSBX.log(SSBX.availableDriver);
}

You can also only run when there’s a compatible SSB available like this:


SSBX.run(function() {
  SSBX.log('hello');
}

It’s still evolving, so add it to your watch list on GitHub if you’d like to stay up to date.

Tips on sending SMS from web applications

Alex Young — Sat, 3 Jan 2009 15:56:49 GMT

We recently added SMS support to Deadline. Finding a bulk SMS provider that we liked was actually more work than supporting the technical requirements in our software.

There used to be several free web and email to SMS gateways. Certain mobile operators in the US make still make this possible (also Orange in France have a developer programme that provides free SMS for France). However: generally SMS is expensive.

Most bulk SMS providers allow you to buy credits. The cost of sending a message to a phone on in each country (and for each operator) varies. For example, Clickatell charge you 1 credit for the whole of the US, but operators in the UK vary between 1 and 2 credits.

We tested both free and commercial bulk SMS services, with the following criteria:

Transparent international support
Clean API
Affordable pricing

Technically supporting SMS is incredibly easy. Our code basically does the following:

Tracks the number of messages sent per-user each day to prevent abuse
Records message send status to catch phone numbers the bulk SMS provider has issues with
Abstracts the bulk SMS provider’s API in case we need to switch

Pitfalls to watch out for

There’s actually a few pitfalls to be aware of when sending messages:

Be sure to check your provider’s API documentation for acceptable telephone number formats (most expect integers with full international dialing code and no + at the start)
Even though some providers allow you to set an alphanumeric from address, some mobile operators have equipment that can’t cope with UTF-8 or spaces
Check that the bulk SMS provider you’re looking at can provide message receipts so you can track users who are having problems receiving messages

Services

We found Wadja and Clickatell to be the best services in our roundup.

wadja.com has an easy to use API and allows you to send a fixed number of free messages per day. Your registered name is sent as the “from” name for the SMS, and they add adverts to support their service. They support international messaging and also allow you to pay for messages to remove ads.

Clickatell is purely focused on SMS. As such their documentation makes the pitfalls of sending SMS very clear. Their XML APIs are a little bit overcomplicated for what they do, but their HTTP API does almost everything and is as easy as sending a HTTP GET.

Conclusion

We got Deadline working with both Wadja and Clickatell—the live site is currently using Clickatell. We ended up purchasing SMS credits because of the restrictions of Wadja’s free service.

It’s frustrating when larger businesses can absorb the cost of SMS and make them free, but this is impossible for a small business like ours. That means our supporting business model was one of the most important considerations when adding SMS to our app.

Rapid Fluid support

Alex Young — Fri, 26 Dec 2008 15:59:49 GMT

Fluid is a Site Specific Browser (SSB) for Mac OS. It allows web applications to run in their own window with a dock icon, dock badge and supports Growl notifications. You can support Fluid in your web app without any server-side code changes.

I recently added Fluid support to Deadline. Deadline basically a calendar/reminder system, so it works particularly well with Growl notifications. It was a rewarding development experience: Fluid’s API is clean and delivers excellent results with minimal effort.

Browser support detection

It’s important to check if Fluid is available before trying to call its API.

The easiest way to do this is:


  if (!Object.isUndefined(window.fluid)) {
    return new FluidAppMode
  }

This stops browsers from trying to load Fluid functionality when its not available.

Auto-refresh

Deadline displays a list of events with no automatic browser refresh. When adding Fluid support I decided to automatically update the displayed items using PeriodicalExecuter (from Prototype). This makes it feel a little bit more application-like. Deadline shows inline editors, so it’s trivial to check if any inline editors are visible to hold off PeriodicalExecuter to prevent it from updating while the user is editing.

As time goes by each deadline’s event date is reached and a notification is displayed. To track which ones have been displayed I use a cookie that stores a list of deadline IDs.

Dock badge

Deadline reminders that are ready are counted and displayed in the dock icon:

Changing the dock icon is easy: window.fluid.dockBadge = count. To avoid changing server-side code, I derive the dock badge count by counting the number of deadlines marked with “Now”.

Growl Notifications

Growl notifications can be displayed with this Fluid API call:


    window.fluid.showGrowlNotification({
        title: "Deadline Reminder", 
        description: message, 
        priority: 1, 
        sticky: false,
        identifier: message_id
    })

You can’t just display notifications blindly, however. For Deadline I decided to record the displayed deadline IDs using a cookie. We have an internal JavaScript library called Azuki which abstracts cookie management, but you should be able to follow this code without it:


  showNotifierMessage: function(message, message_id) {
    if (this.displayedMessage(message_id)) {
      return
    }

    window.fluid.showGrowlNotification({
        title: "Deadline Reminder", 
        description: message, 
        priority: 1, 
        sticky: false,
        identifier: message_id
    })

    this.logMessageDisplay(message_id)
  },

  logMessageDisplay: function(message_id) {
    // Log message to cookie
    var deadline_notifier_messages = Azuki.Storage.Cookie.find('deadline_notifier_messages')

    if (Object.isUndefined(deadline_notifier_messages)) {
      deadline_notifier_messages = message_id
    } else {
      deadline_notifier_messages = deadline_notifier_messages + ',' + message_id
    }

    Azuki.Storage.Cookie.create('deadline_notifier_messages', deadline_notifier_messages, 365)

    this.log(deadline_notifier_messages)
  },

  displayedMessage: function(message_id) {
    var deadline_notifier_messages = Azuki.Storage.Cookie.find('deadline_notifier_messages')
    message_id = parseInt(message_id)

    if (Object.isUndefined(deadline_notifier_messages)) {
      return false
    }

    var message_ids = $A(deadline_notifier_messages.split(','))

    return message_ids.find(function(logged_id) {
      if (parseInt(logged_id) == message_id) {
        return true
      }
    })
  }

As you can see I store each displayed deadline ID separated by commas in a cookie. This then allows Deadline to only notify new deadlines.

Supporting multiple SSBs

There’s a few SSBs available. I’ve chosen to support Bubbles for Windows.

To support multiple SSBs you could either use inheritance or delegation to manage shared code. In Deadline’s case I’ve shared the notification cookie management code and the use of PeriodicalExecuter between Fluid and Bubbles using inheritance. Remember that Prototype’s inheritance mechanism is now specified through Class.create


var FluidAppMode = Class.create(WebAppMode, {
  initialize: function() {

I’ve detected the availability of Bubbles as follows:


  if (typeof(SSB) != 'undefined') {
    return new BubblesAppMode
  }

Bubbles’ API is accessed through the SSB singleton object.

Share your SSB support

Have you supported an SSB with your web app? Why not share your links and experiences in the comments?