I know, I know, it’s been tooooo long. But whatever!

At Shermans we have begun a large project to rebuild the architecture around the travel deals system. And guess what? we chose to do it all in Ruby! Yay!

The deals server (as we are calling the entire system) will consist of a few separate apps, mostly Rails. A few of these apps will be REST based web API’s, allowing our partners and publishers to fetch deals. Surprisingly, there are very few Ruby Gems available to help with creating an API. But that probably has more to do with the great support for exposing resources built in to Rails using respond_with and co.

But based on my experience building the Codaset API, I knew I wanted a better way to expose the “views” for the API. For example, I don’t want all attributes of my model to be exposed, and Rails doesn’t provide a simple way to do that. Enter RABL!

… and that wasn’t even part time!

I’ve been using Twitter for quite a while now, and I have quickly found that every time I come across a site or web page of interest - I will tweet it. And quite often, I have found myself either forgetting to add these links to my bookmarks in Firefox, or just not bothering. But that’s not good, as also quite often, I remember I tweeted a link that I need to refer back to, but just can’t remember the damn thing.

Twitter has become my primary means of bookmarking. But there is a problem with that - Twitter doesn’t give me an easy way to see all those bookmarks. It is for that reason that I promptly set about building a web app that will make it easy for me to find all my tweeted links and organise them by hashtags.

Rails 3 is awesome! BUT…

For some unknown reason, the powers that be decided to remove the error_message_on and error_messages_for form helpers. I’m not sure about every one else, but I use these in pretty much every single form that I create, so I just have no idea why it was removed.

Fortunately, all is not lost. The code for these helpers was extracted out into a plugin called dynamic_form. But unfortunately it doesn’t seem to have been kept up to date, as the last commit was back on June 12th. Running the tests failed all over the place, simply because the HTML returned has changed slightly in the release candidate. So I took it upon myself to fork the code and managed to get the tests passing with Rails 3 RC. I then also packaged it up into a Gem which you can grab now and install in your Rails 3 app.

My next task was to get the custom-err-msg plugin working with Rails 3. But rather than fix and refactor that as it is, I decided to simply integrate it into the dynamic_form plugin, as it’s functionality is closely related.

So the dynamic_form plugin has been enhanced a little, so please install and let me know what you think. I’ve put in a pull request to the official dynamic_form repo, so hopefully they will accept that soon. But in the meantime, you can still use my version by simply running gem install dynamic_form or adding to your Gemfile (if you are using Bundler) gem "dynamic_form".

I’ve been using MongoDB quite a bit recently in several different projects, and it kicks ass. But the hardest thing to learn and to get used to with Mongo, is it’s schemaless structure. With SQL databases like MySQL, you always have a defined and very rigid structure, which is of course the schema for each table you create. You create a table with a few columns; each column has a set type, a length, and a whole host of other variables.

It’s this rigid structure that most of us have gotten used to for years, and that is the hardest thing to shake off when using NoSQL databases such as MongoDB.

But that is not to say that Mongo has no defined structure. In fact, that is far from the truth. Mongo and all schemaless databases have defined structure, but the difference is that that structure is defined by you. And that is what makes Mongo so cool. No need to actually create any tables and define each column - Just insert some data in your own defined way.

But there is a side effect of this schemaless idea. Even though you no longer have to define a schema in the traditional sense, you still have to think about the structure of each collection, and how that will look. In fact, there is a lot more to think about, as there are a lot more ways to structure your data with Mongo and other schemaless databases.

It’s somewhat of a steep learning curve, but well worth sticking with. I’m still leaning the best ways to structure certain data types, and dates is one that I think I’ve nailed.

So I use Ajax quite a bit in many of my projects. And why not? It kicks ass! I have one project which dynamically updates specific elements of an HTML page via Ajax. Something like this:

1
2
3

$.get('/travel_guide/Paris', function(data){
  $('#advice').text(data);
});

The problem I have, is that sometimes that data can include HTML entities like & and >, and for reasons I don’t want to bore you with, I cannot do anything about it on the server side. When inserting a block of text that contain HTML entities into the DOM, those entities are not parsed as such, and get printed exactly as they are.

I’ve never managed to find a really good jQuery based autocomplete plugins, especially one that is flexible and easily extensible. So when the jQuery UI team released 1.8 back in March, I was intrigued to find that they included - amongst other new widgets - an autocomplete widget. And it turns out to be pretty damn good, and flexible to boot.

So when I had a need to add the ability for a local data source for the autocomplete plugin that we use on ShermansTravel QuickSearch, I gave the new jQuery UI widget a go.