I recently stumbled across mailcheck.js, a little jQuery plugin from Kicksend that suggests domains based on common typos in email forms. For example, 'user@gnail.co' will generate a suggestion for 'user@gmail.com'. It's perfect for preventing errors in user signups, and the authors claim its reduced their email bounces by 50%. After playing around with it, I've decided to bundle it into production for most, if not all of my projects, and this is just a brief demo of what can be done with it.

Getting Set Up

Our goal is to create a simple display that shows email suggestions to the user and offers a way to automatically fill in the field with the suggestion. The plugin is used in two steps - first, it has to be attached to a text field, and then you have to actually do something with its suggestions. Let's get the basic JavaScript structure set up (make sure you include the actual plugin on your page as well!)

<!-- The HTML -->
<input id="email" type="text" placeholder="Email">
<div id="hint"></div>


// The JavaScript
var $email = $('#email'); // Cache jQuery objects into variables
var $hint = $("#hint");

$email.on('blur', function() {
  $(this).mailcheck({
    suggested: function(element, suggestion) {

    }
  });
});

The setup is only a few lines, although it's important to understand what's going on. Our HTML is fairly straightforward - we start with a generic input that we'll be using the plugin on. The <div id="hint"> is an initially hidden div that will contain our suggestions to the user. In our JavaScript, we're first sticking jQuery objects into variables for convenience. Then we're attaching the mailcheck() function to our email field on its blur event, which is called whenever the element loses focus (i.e., the user moves on to the next field). Mailcheck takes two callbacks, suggested() and empty(). suggested() is called whenever a suggestion is available for the field, and empty() whenever the field is left blank. We'll only be using suggested() in this demo, although depending on how you use the plugin it's generally a good idea to use both.

I'm happy to unveil a much needed makeover for andrewberls.com! I've learned a huge amount since I first started this site what seems like forever ago, and I figured it was time to update the site to reflect that.

The process began with a much needed migration to Heroku's Cedar stack. Cedar is the successor to the previous Bamboo runtime stack on which my old site was deployed, and the migration was actually surprisingly easy with the help of this Dev Center article. Theoretically, Cedar offers all sorts of cool things such as a process model and 'Twelve-factor methodology', but the most important thing for me is support for Rails' 3.1 asset pipeline. This means that I can take full advantage of Sass and CoffeeScript, and easily serve up concatenated/compressed assets in production.

My favorite part is that the new site is fully responsive, thanks to a tiny grid framework I wrote called Cheeky.css. Syntactically, Cheeky is very similar to other grid frameworks in that you contain content in rows, with 16 columns available for positioning. Once you've defined spans and offsets, Cheeky uses responsive media queries to automatically scale the page as the browser resizes. I'll write more about Cheeky later, but in the meantime you can read more about it here. Check it out - try resizing your browser on this page!

Take a look at that picture for a second or two. If you can tell me at a glance what absolutely any of that does, that you are a much smarter person than I. (Or a producer. One of the two). That's a screenshot from the popular Reason audio software, and in my opinion it's an absolutely terrible design. At a glance, it's cluttered and non-intuitive, and non-functional elements waste space on the screen. Its design is governed by something called a skeuomorph, an extremely prevalent concept in digital interfaces.

I interact with two computers on a daily basis. I have a desktop and a laptop, both running Windows. My desktop is a stock Vostro 430 - I haven't done much in the way of customizing the hardware, so it's no powerhouse, but it's capable. The selling point is the monitors, two 24-inch beauties I've acquired over the course of a year or two. On the other hand, my laptop is a wee Vostro V13 (notice a trend?). The hardware is minimal, and the screen is only 13 inches. I bought it primarily for taking notes once I got to college- I didn't expect to use it for much else than notes or the occasional trip, which is why I was surprised when I realized I was doing most of my coding and development on my laptop. After all, I'm a sucker for screen real estate, and here I had the ideal work desktop setup! Big monitors, a nice keyboard, and a great mouse. So why was I doing all my work on my laptop?

As promised last week, today is dedicated to delicious Rails! This post is the first of several in which I'll talk about how the various feature implementations in Sutro, the blog engine that runs this site. In particular, today will focus on what it means to add tags to articles, and how to associate the models underneath.

Models and Associations

Rails associations are a set of methods that enable us to tie conceptually related models together and describe their relationships. For example, a Car belongs to a Person, and a Customer has many Orders. The association keywords "belongs to" and "has many" are several of the built in associations that Rails provides. We'll see that by specifying the relationships between two models (posts and tags here), we gain access to high-level helper methods that make our lives infinitely easier.

Our first step is the most important - determing the right relationship to use between posts and tags. The complete list of Rails model associations, as well as an explanation of their purpose and usage can be found at the RailsGuide here. So which ones are right for our needs? Well, clearly a post can have many tags. But remember, the relationship must be defined both ways. In that case, a post has_many :tags and a tag belongs_to :post relationship seems like the obvious choice. After some thought though, you'll realize that's not right. A post can have many tags, but a tag can also belong to many posts. For example, if a post is tagged with "ruby", the "ruby" tag is not locked to that post. Many posts can be tagged with the same name. So the association we're looking for is has_and_belongs_to_many. A post has and belongs to many tags, and a tag has and belongs to many posts. This is a mouthful, and gets a bit complicated to put in place, but ultimately, it allows us to call the methods @post.tags and @tag.posts, which will be enormously useful. Let's move on to generating our models and migrations!