Andrew Berls

Ruby tips: Procs vs lambdas

2013-05-14T20:58:50Z

I recently ran into a Ruby subtlety that I had heard of but never encountered before, regarding the use of the return keyword within blocks. Let's jump right into an example. Let's say you have an array of numbers and you want to select all the even ones. What will the following output?

def evensWithReturn(items)
  items.select do |item|
    if item.even?
      return true
    else
      return false
    end
  end
end

> evensWithReturn([1,2,3,4,5,6])
# => false

Wait, what? We're expecting to see [2, 4, 6], not false. What's going on here? Let's try it again, this time removing the return keyword from the select block.

def evensWithoutReturn(items)
  items.select do |item|
    if item.even?
      true
    else
      false
    end
  end
end

> evensWithoutReturn([1,2,3,4,5,6])
# => [2, 4, 6]

Much better. Although why was the return keyword messing things up? It turns out that this is a result of the subtle differences between Procs and lambdas in Ruby, both of which represent chunks of reusable code. For the most part, the two are identical, although one of the differences is that a Proc returns from its enclosing block/method, while a lamba simply returns from the lambda. Let's see some more examples. First, using Procs:

def procWithReturn(items)
  myProc = Proc.new do |item|
    if item.even?
      return true
    else
      return false
    end
  end

  items.select(&myProc)
end

> procWithReturn([1,2,3,4,5,6])
# => false

This is the same result as we saw with the block. Still not the result we wanted, but at least we know why. As soon as the proc gets the first item (1), it will call .even? on it and return false, and consequently return false from the entire procWithReturn method. However, it we try the same example using a lambda instead of a proc:

def lambdaWithReturn(items)
  myLambda = lambda do |item|
    if item.even?
      return true
    else
      return false
    end
  end

  items.select(&myLambda)
end

> lambdaWithReturn([1,2,3,4,5,6])
# => [2, 4, 6]

Success! Here, the lambda returns values to the select block, but doesn't exit the enclosing method. For completeness, the other difference between Procs and lambdas is that lambdas enforce arity, meaning it will throw an ArgumentError if you don't pass the number of arguments it specifies.

For the record, this example is fairly contrived for illustrative purposes - before you jump down my throat, I know that you can do

[1,2,3,4,5,6].select(&:even?)

I hope this clarifies some of the subtleties between procs and lambdas. For interested readers, I recommend this excellent blog post which goes into further detail.

Faking keyword arguments in Ruby

2013-05-09T17:56:21Z

With the official release of Ruby 2.0, there have been a myriad of posts about all of its shiny new features. Of those, my personal favorite is the addition of keyword arguments. This is essentially built-in support for what's been traditionally accomplished in Ruby using options hashes. For example, it's not uncommon to see method calls like foo(bar: "one", baz: "two"). However, under the hood this might be implemented as:

def foo(options={})
  bar = options.delete(:bar)
  baz = options.delete(:baz)
  puts "#{bar} #{baz}"
end

foo(bar: "one", baz: "two") # => "one two"

In fact ActiveSupport in Rails 3.2.13 defines a method called extract_options! that deals with exactly this. However, if we're stuck on Ruby < 2.0, defining every method to use an options hash is often more work than necessary, especially when a method only takes one or two parameters. We can get around this with a clever trick. If we change our method slightly from the previous example to work without an options hash:

def foo(bar, baz)
  puts "#{bar} #{baz}"
end

We can then fake keyword arguments by calling it like this:

foo(bar = "one", baz = "two")
# => "one two"

This trick exploits the fact that the returned value from the assignments in the call to foo() will be the value that's assigned, so at the end of the day "one" and "two" will still be passed in! This saves us having to work with options hashes and still looks pretty, although it's important to note that unlike hashes and Ruby 2 keyword arguments, order matters here. If you change up the order you pass in baz and bar, things won't work as expected.

Personally, I can't wait to switch my projects to use Ruby 2.0 and use keywords arguments for real, but in the mean time this is a neat trick I hadn't seen before to emulate them!

Git tricks: Unstaging files

2013-05-06T01:36:08Z

This post dives a bit into the git reset command. If you want to jump straight to the good stuff, click here.

I wanted to share a handy alias I use for removing files from the staging area in git. Often I'll be working and adding files to the staging area with git add, and then decide (for example), that I don't want to commit some files with the others and get them out of the staging area (but keep my work intact). Let's look at an example case - running git status after staging a file might look like this:

$ git add example.txt
$ git status
# On branch test
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   modified:   example.txt
#

Hey, that's neat - it tells us right there how to unstage files! This is accomplished using the git reset command. From the docs:

git reset [-q] [<commit>] [--] <paths>…
This form resets the index entries for all <paths> to their state at <commit>. 
(It does not affect the working tree, nor the current branch.)

This means that git reset <paths> is the opposite of git add <paths>.

git reset can be used for several things -it can point the current HEAD at a specified state, and we'll be using it to copy entries from HEAD to the index, or staging area, thus removing our file from the staging area and leaving our working tree unchanged. Also important is that <commit> defaults to HEAD, so we can leave that bit out. Let's give it a shot!

$ git reset -- example.txt
Unstaged changes after reset:
M   example.txt
$ git status
# On branch test
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   example.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

And our changes are left intact but removed from the staging area! Mission accomplished! However, you might be wondering about the strange -- that shows up in the command. Those are referred to as the 'bare double dashes', and they prevent ambiguity by ensuring that we're resetting a file and not specifying a branch. For example, if you have a branch and a file both named example and you run git reset example, you might see the following:

fatal: ambiguous argument 'example': both revision and filename
Use '--' to separate filenames from revisions

Git can't tell if you're talking about the branch or the file (each of which has very different consequences), so the -- makes it clear we're not talking about a branch and that we want to reset our file.

So we've seen that we can use git reset to unstage our files. However, it'd be nice to be able to say git unstage <paths>, so let's define that using a git alias:

git config --global alias.unstage 'reset --'

And there you have it! Now we can run git unstage example.txt to our heart's content.

Naked asterisk parameters in Ruby

2013-04-10T18:14:47Z

I came across a Ruby idiom I hadn't seen before browing through some of the Rails source the other day. Specifically, the method in question looked like this:

def save(*)
    create_or_update
rescue ActiveRecord::RecordInvalid
    false
 end

I've never seen the asterisk as a parameter by itself, and to explain it a brief review of the splat operator is in order. The splat operator allows methods in Ruby to accept a variable number of arguments. For example:

def say_hello(*people)
  people.each { |person| puts "Hello #{person}!" }
end
 
say_hello("Alice", "Bob", "John")
# "Hello Alice!"
# "Hello Bob!"
# "Hello John!"

The splat can be used with named arguments as well - it will just gather up all of the unnamed arguments into an array. It can also be used for a couple other really neat tricks, which are explained in detail in this post. However,when using the splat, it's much more common to see a definition like

def some_method(*args)
  # do something with args
end

So what's the deal with the unnamed asterisk? Well, this is still the same splat operator at work, the difference being that it does not name the argument array. This may not seem useful, but it actually comes into play when you're not referring to the arguments inside the function, and instead calling super. To experiment, I put together this quick snippet:

class Bar
  def save(*args)
    puts "Args passed to superclass Bar#save: #{args.inspect}"
  end
end
 
class Foo < Bar
  def save(*)
    puts "Entered Foo#save"
    super
  end
end
 
Foo.new.save("one", "two")

which will print out the following:

Entered Foo#save
Args passed to superclass Bar#save: ["one", "two"]

The globbed arguments are automatically passed up to the superclass method. Some might be of the opinion that it's better to be explicit and define methods with def method(*args), but in any case it's a neat trick worth knowing!

A gem for managing your code notes

2013-01-14T21:47:11Z

I just released my first gem to the world, a little command line tool for managing source code annotations. I found myself constantly scattering little notes such as TODO, OPTIMIZE, etc into my code comments, and I wanted a way to quickly view all such notes in my project directories. The result, the Notes-CLI gem, packages an executable for recursively searching through source files for common annotations with the flexibility to add your own search terms. If you've ever worked with Rails, this is very similar to the rake notes command, extracted to work with any project.

The gem installs the notes executable, which can be run with -h for some more information. For an example, if I run the notes command in one of my project directories (a Rails app), I get something similar to the following:

$ notes app/    # Only search in the app/ directory

app/models/user.rb:
  ln 32: # OPTIMIZE: this method can be cleaner
  ln 34: # TODO: this parameter is a hack

app/views/expenses/_net_total.html.erb:
  ln 1: <%# TODO: condense this eventually  %>

The options for adding custom search terms or excluding directories from search are documented on the project's Github page. If you want to jump right in, just run gem install notes-cli.

This project started as a tiny script with a bash alias. Converting it into a gem for distribution turned out to be a trivial process, thanks to this article. I've found it to be super useful, and I hope someone else is able to get some value out of it. Give it a shot and let me know what you think!

Winter Break - A Reading List

2012-12-10T17:31:03Z

Winter break is coming up fast, meaning I have a few weeks of rare free time. I want to use the time to learn as much as possible about topics I don't consider myself strong in. I've put together a list of things I've been wanting to learn, but it's incomplete. I welcome suggestions and additions, and I'll add them to the list - I'd love to foster a discussion on some interesting topics!

Scala

This is the big one for me - Scala is a statically typed language that brings functional programming concepts to the JVM. It's very fast (sorry Ruby), and gaining popularity, notably at Twitter. I have a feeling it will become one of the next big things.

Backbone.js

Client-side MVC (MV*) applications and frameworks are becoming more and more popular. I've never spent too much time working with Backbone, so I want to learn more about how apps with it are structured and built.

Graphs

Graphs play a central role in most large companies today (think Facebook's social graph), and I have a feeling it's something I'll absolutely need to know very soon. Goal: understand the basics of graph theory and their various uses.

SQL

I spend most of my time working with SQL databases through an ORM. I've been putting off learning the basics of raw SQL.

NoSQL

NoSQL is everybody's favorite buzzword nowadays. The term is rather poorly defined, but I want to understand the implications and advantages of using a 'NoSQL' database such as MongoDB or Redis over a relational one.

Google

Google has built some amazing technologies to power a business of their size - MapReduce is an extremely popular paradigm that inspired the Hadoop project, and Spanner is a revolutionary globally distributed database. Their papers are essential reading.

Ruby

I consider myself fairly strong at Ruby, so this is the 'fun' stuff. It's always interesting to look at the internals.

Data Warehousing

This is a topic I know very little about and will likely run into later. Key questions: why do companies do it? How is it accomplished - what is a dimension? What is a fact?

D3.js

D3 is a library for manipulating and displaying documents based on data. The possibilities here are endless - I want to see if I can make something out of it. Idea: mash up open source datasets.

http://d3js.org/

Misc

This is an aggregation of stuff that doesn't really fit into any of the previous categories.

What Every Programmer Needs To Know About Encoding

Intuitive Design

2012-10-24T02:51:52Z

I'm not sure when this happened, but the new (ish?) bit.ly homepage is not at all one that I would expect from a URL shortening service. The box to actually shorten a link is small and tucked to the side, instead of front and center like you might expect, and the user's eye is now instead drawn to links to sign up and log in.

Click for larger image

I would be willing to bet that a large percentage of their traffic is from users who are not registered on the site. While I understand that they're expanding the platform functionality and trying to reverse that trend, the new design still strikes me as straying from the core offering and not focusing on what most of their users are looking for.

Adding SFTP support to cURL

2012-10-15T04:49:17Z

I was surprised today to find out that cURL does not have SFTP support built in. I ran into the issue trying to get set up with René Moser's awesome git-ftp script, which is exactly what I needed to manage deployments for one of my sites running in a restricted server environment. I'll write more about git-ftp later, but in short, it gives you all the deployment goodness and capabilities of git when you only have FTP access to a server. In particular, I need to use it with SFTP, but kept running into the error Protocol sftp not supported or disabled in libcurl.

As it turns out, there's no easy way to add SFTP support to cURL. In the end, I had to rebuild the library from source with some special tweaks. I got frustrated from poring over archaic mailing list posts and jumbled documentation, so I wanted to share the steps I took to get it to work.

What you'll need

You'll need to be comfortable doing things at the command line. You'll also need a C compiler of some sort. If you're on a Mac, the XCode Command Line Tools package everything together nicely, otherwise I assume you have an equivalent installed. I did all of this on a Mac, but it should work on Linux as well.

1. Install libssh2

libssh2 is a client-side C library that implements the SSH2 protocol - we need to configure cURL to use this to get SFTP support. Download the tarball from this page, unpack it, and cd into the directory. Then run:

./configure
make
make install

It will output a ton of noise to your console, but that's all you have to do here.

2. Install/configure/build cURL using libssh2

Here we're building cURL from source, and linking to libssh2 in the configuration. Same process as before - download the latest release from here, unpack it, and cd in.

./configure --with-libssh2=/usr/local
make
make install

To check that it worked, run curl -V and ensure that sftp appears somewhere in the Protocols list. If it doesn't, see the note below or make sure that something didn't fail unnoticed during the config/build steps (you may need to run some commands with sudo).

In my case, I found that the executable /usr/bin/curl was outdated and taking precedence over my custom build, which installs to /usr/local/bin/. I chose to just move the one in /usr/bin/ to /usr/bin/curl_backup - if you like, you could copy the one from /usr/local/ into /usr/bin/. Your call. Edit: The reason for this was that /usr/bin came before /usr/local/bin in my path. You can fix this if you like using export PATH=/usr/local/bin:$PATH.

I hope this can be of some use to someone! Feel free to leave a comment if you run into any trouble with any of the steps.

A Rakefile to build CoffeeScript projects

2012-07-15T22:18:46Z

Update: I've since overhauled this project to be an npm package called Arabica. You should check it out.

I recently started a new project in CoffeeScript, and began by looking for a good build system. When developing a JavaScript-heavy application, concatenating and minifying scripts is crucial in order to reduce the number of HTTP requests and download size, making your app nice and snappy. Unfortunately order can matter when concatenating files, so randomly lumping together everything in the source directory isn't enough. I set out to find a solution that allowed me to specify files in the order to compile, with the ability to watch a directory for convenience. This is what I threw together - a Ruby Rakefile that makes use of the uglifier and listen gems, inspired by a script by Clay.io.

Usage

Using the script is very simple, but there are a few dependencies that must be resolved beforehand. An installation of Ruby and RubyGems is required. The Gemfile is only present for convenience - the script should work just fine if happen to already have the gems installed or want to install them manually, but you'll want the Rakefile in your project's root. If you're installing using the Gemfile, grab bundler if necessary with gem install bundler and finally bundle install to install the uglifier and listen gems. Once you've set up all dependencies, put your project filenames (in the desired order) in the FILENAMES array, and customize the SRC_PATH, BUILD_PATH, and DIST_PATH variables to your needs. You can call rake build manually to build the application, or just watch the source files with rake watch which will compile automatically anytime you save a change.

Notes

I tend to keep my editor and terminal on separate workspaces, so I added a Growl notification that alerts you if a compile attempt failed - this is totally optional and can be removed if you prefer. Finally, the rake clean task removes all compiled files (including distribution files) if you ever need to clean up your directory.

I've already run into the issue trying to include non-CoffeeScript files (such as vendor JS libraries), but it's entirely possible with a small hack and I can update to post that if anyone would like. As always, I welcome ideas or suggestions for improvement!

Suggesting URL aliases with CoffeeScript

2012-05-28T23:29:49Z

If you're familiar with any blogging platform or content management system, you've likely heard the term 'URL alias'. But what exactly does this refer to, and what problem does it solve? Let's start by looking at some common examples. If you've ever used Drupal, something like the path node/369 might look familiar to you. Then consider some example post on this site, accessible through the path andrewberls.com/blog/post/1234. What's happening in both of these schemes is that we're accessing a piece of content based on its ID in a database. However, these URLs are not particularly revealing - the difference between node/369 and node/254 is a mystery as far as we're concerned. Instead, we'd like to define URLs with a human-readable structure that describes a page's content. This is what a URL alias is - a readable path that allows us to access a resource. We'd like to create aliases for our content so that instead of using database IDs, we can using something more descriptive, perhaps using the content title to get something of the form andrewberls.com/blog/post/my-awesome-post. Implementing an aliasing scheme is beyond the scope of this article - instead, this is a small feature I wrote for my blog which automatically suggests paths based on a post's title.

Suggesting a path

The algorithm here is relatively straightforward. Let's say that when we're writing a new post, we're given input fields for the title, body, and URL alias. We're given the option to fill in the alias manually if we'd like, but the task is sort of a pain so we'd like to cover it automatically. When the user enters a title, we have to slice it up and make it 'safe' for a URL, and fill the alias field with the URL. Let's get our setup out of the way:

<!-- HTML -->
<form>
 <input type="text" id="title" placeholder="Title">
 <textarea placeholder="Body"></textarea>
 <input type="text" id="url_alias">
</form>

# CoffeeScript
$ ->
  $("#title").bind "propertychange keyup input paste", ->
    url = $(@).val()
    $("#url_alias").val urlsafe(url)

What are we accomplishing here? We're binding some anonymous function to a mess of events on the title field. When I first starting writing this, I just used the change() event on the title field, which was only called when the field lost focus (i.e., you enter a title and move on the body). This still worked, but we can do better than that. It would be cool if we filled in the URL alias as the user types the title. By binding our function to all these events, we're monitoring the title field in real time. But what does this anonymous function do? It starts by grabbing the value of the title field. The $(@) bit looks a bit strange though. In CoffeeScript, @ is a shortcut for this. As a result, you can use @property as a shorthand for this.property, and $(@) is the same as $(this). Once we have the title, it gets passed into some method called urlsafe() before filling in the alias field. This isn't a built-in method though - we're going to have to define it ourselves!

The urlsafe() method

We need to define a method called urlsafe that takes in a string and makes it safe for use as a URL. I'll start with another code dump, and then walk through what's going on.

urlsafe = (url) ->
  url = $.trim url
  url = url.replace(/\s+/g, ' ')
  url = url.replace(/[\.,-\/#!$@%\^\*;&:\[\]{}=\-_`~()]/g, '')
  url.split(' ').join('-').toLowerCase()

This method looks confusing at first, but we'll see that its nothing to be afraid of. We need to think about our goal - what exactly constitutes 'safe' for a URL? For starters, we're going to want to get rid of any whitespace such as spaces or tabs. We start by removing any whitespace at the beginning or end using jQuery.trim(). The first call to replace() after trim() covers the edge case of repeated spaces inside the url, and compacts them down to a single space. This is unlikely to occur and not entirely necessary, but we might as well be on the safe side. The next call to replace() involves an ugly-looking regex that's simple in purpose - we're just removing any punctuation. The chained call to split(' ').join('-') replaces spaces with hyphens by first splitting the url into an array, separating tokens by spaces, and then just joining it back into a string with hyphens between tokens. Finally, we lowercase the entire thing and return the now-safe URL!

The result

Everything works as expected - the alias field updates in real time, and if you are compelled for reason to name title your post this is@%!*#& the TITLE, the suggestion comes out to the friendly this-is-the-title. I've set up a demo page where you can play with the result more here. If you find any issues, hassle me on GitHub, and if you use it in any of your projects be sure to let me know on Twitter!

Introducing Cheeky: The responsive grid with Sass

2012-05-19T01:11:22Z

Mobile development doesn't have to be hard. That's why I created my latest project - Cheeky.css, a grid system that makes building responsive sites a breeze. It's more important than ever to create mobile-friendly sites, but defining a separate version or stylesheet just for handhelds is a pain. With Cheeky, you only have to style your page once, and your content will automatically scale to fit the browser width.

Using Cheeky

If you've used any grid before, the syntax will be very familiar. Cheeky is based off an 1100px grid with 16 columns contained in rows. 16 is an arbitrary number, but combined with familiar column offsets, you have the freedom to structure your content exactly how you like. To get started, everything is unsurprisingly contained in a <div class="container">. From there, you lay out your columns inside a <div class="row">, 16 to a row. Columns are defined using the syntax <div class="span-#">, where # is any number between 1 and 16. Offsets are almost identical - just toss on a class="offset-#", except that you can only offset up to 15. Let's take a look at the bare minimum example:

<div class="container">
  <div class="row">
    <div class="span-8">This is 8 columns</div>
    <div class="span-4 offset-4">This is 4 columns, offset by 4!</div>
  </div>
</div>

That's all there is to it! Once you get used to working with spans and offsets, structuring your content is easy and Cheeky does all the work for you. Nested columns are totally possible as well - just stick in another row and structure nested content the same way. You can find more usage information and downloads here!

Details

As mentioned before, Cheeky's base is an 1100px grid for desktop screens. Once the browser is resized, CSS media queries are used to progressively scale the grid down to 790px and 630px (In the code, these two states are listed as 'small' and 'tiny' grids). Past that point (portrait phones and below), Cheeky reverts to displaying columns stacked on top of each other. Cheeky is built with Sass (hence the tagline. Don't be misled; it's actually very friendly), so the entire grid system can be customized and tweaked just by changing a few variables.

Tips and Tricks

I learned a great deal about grid-based design and CSS media queries writing Cheeky, and I wanted to pass on a neat Sass trick I just discovered. For example, I use a mixin called width when defining spans, which takes in an integer and uses it to calculate the correct width. I had written a bunch of code that looked like this:

.span-1  { @include width(1); }
.span-2  { @include width(2); }
.span-3  { @include width(3); }
.span-4  { @include width(4); }
.span-5  { @include width(5); }
/*...on and on, up to 16 */

This went on and on for spans and offsets in all of the various media queries, creating a ton of repetitive code. Then I discovered that it's a perfect candidate for refactoring using a Sass loop, which reduces the example above to something like this:

@for $i from 1 to 17 {
  .span-#{$i} { @include width($i); }
}

That by itself generates the code for 16 classes (it doesn't include the endpoint) including the proper mixin! Turns out that for is only one of the Sass control directives; if, each, and while are also included. I don't have too much experience with them yet, but you can read more about them here.

Why?

With a large number of grid systems already available, one might ask why bother writing another one. Cheeky was created entirely as a learning exercise to practice responsive design techniques, and derives much inspiration from the excellent Twitter Bootstrap project. I'm using Cheeky in production on this site (resize this window!) and several other projects, and it's held up to the task. If you'd like to read more about Cheeky, I've set up a more extensive info page here, and the project is hosted on GitHub here. Finally, if you use Cheeky in any of your projects be sure to let me know on Twitter!

Update 5/22: As pointed out in the comments, some of the media queries were causing a horizontal scrollbar at certain dimensions. The framework has since been updated to fix this issue.

Reducing bad signup emails with mailcheck.js

2012-05-12T23:13:03Z

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. If you want to play with the end result before we dive into the details, I have a simple demo set up here. 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.

Using the suggestion object

Mailcheck automatically generates our field suggestions for us, but how do we use them? Note that the suggested() method from before is passed in two parameters - element, which is the field that we're checking, and something called suggestion. If you enter user@gnail.co and use your favorite tool to inspect it, you'll notice it's an object with three fields:

We have access to the address (what comes before the @), the suggested domain, and the entire suggested text. We can use these fields to populate and show a hint to the user using the previously mentioned <div id="hint">. Here's how you could go about filling the hint element:

var $email = $('#email');
var $hint = $("#hint");

$email.on('blur',function() {
  $hint.css('display', 'none'); // Hide the hint
  $(this).mailcheck({
    suggested: function(element, suggestion) {
      if(!$hint.html()) {
        // First error - fill in/show entire hint element
        var suggestion = "Yikes! Did you mean <span class='suggestion'>" +
                          "<span class='address'>" + suggestion.address + "</span>"
                          + "@<a href='#' class='domain'>" + suggestion.domain + 
                          "</a></span>?";
                          
        $hint.html(suggestion).fadeIn(150);
      } else {
        // Subsequent errors
        $(".address").html(suggestion.address);
        $(".domain").html(suggestion.domain);
      }
    }
  });
});

Before we do anything with the suggestion, we're making sure to hide the hint element. If there's a suggestion, we'll be repopulating it with the suggested domain, but this handles the case that a valid email is entered after we've already suggested a hint. At the beginning of the suggested() callback, we're checking to see if the hint element is empty (if (!$hint.html()) {...}). If so, then we can assume it's the user's first error. The suggestion variable is a rather nasty string of HTML that we'll be inserting into the hint element. There are other ways of doing this such as template systems or DOM libraries, but this is a quick and dirty solution. On the first error, we first fill in the hint with our suggestion ($hint.html(suggestion)) and fade it in by chaining it to jQuery's fadeIn method. On subsequent errors, instead of fading in the hint, all we have to do is modify its contents to reflect the new contents of the field. At this point, we should have a working hint!

At this point, we're missing the last piece of the puzzle - I've styled the domain to look like an inviting link, but clicking it doesn't actually do anything. It should be a link automatically fill in the suggestion for you - let's implement it!

// After our other code:
$hint.on('click', '.domain', function() {
  // On click, fill in the field with the suggestion and remove the hint
  $email.val($(".suggestion").text());
  $hint.fadeOut(200, function() {
    $(this).empty();
  });
  return false;
});

The code is much shorter for this bit - we're using jQuery's on() method to attach a click handler to the .domain link. All we're doing is filling in the field with the suggestion text, and fading out the hint, emptying it when it's complete. And that's it! We have a fully functional hint element that displays suggestions to the user and provides a link to automatically fill the suggestion into the field. Be sure to check out the working example here and grab the plugin here!

A fresh coat of paint

2012-05-02T23:28:00Z

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!

Tips and Tricks

I'm currently using Eric Martin's Simple Modal jQuery plugin for the modals on the front page. I've only played around with it a little bit, but it's been super easy to use and I recommend it.

I also made a new discovery - I'm convinced that box-sizing: border-box; is the best thing to ever happen to CSS. In the traditional box model, padding adds to the rendered width of an element. This can be confusing sometimes, as elements are wider than their declared widths. This is especially an issue if you want to add padding to an element of width: 100%. In the normal, or content-box box model, the element will actually break outside of the parent. Enter box-sizing: border-box! Elements with this property declared will render with their declared width, and padding/borders will cut inside the box. Now you can add padding to elements without breaking a grid layout, or have 100% width form inputs with padding but without ugly hacks!

Let's take a look at a very basic form example:

<!-- The HTML -->
<form class="contact-form">
  <input type="text" placeholder="Name">
  <textarea placeholder="Enter your message"></textarea>
</form>

/* The CSS */
.contact-form { padding: 20px; }

input[type="text"], textarea {
  /* The magic bit! */
  -webkit-box-sizing: border-box;
     -moz-box-sizing: border-box;
          box-sizing: border-box;

  margin-top: 15px; /* Space things out a bit */
  padding: 5px;
  width: 100%;
}

And now you'll have beautiful inputs with padding that fill the content area! Hooray! We're using the [type="text"] selector here in order to exclude [type="submit"]. Note that this is also using the placeholder attribute, a neat HTML5 feature.

To wrap things up, border-box is a property that can make the box-model a lot more intuitive. However, I'm still wary of using a rule like * { box-sizing: border-box; } as described by Paul Irish, and one has to keep in mind that browser prefixes are still necessary, so this should be reserved for projects supporting IE8 and up.

What's next

Now that things are nice and pretty on the front end, I plan to dive in and rewrite the blog engine that powers this site. I wrote it when I was first learning Rails, and there's much to be done in the way of refactoring and cleaning up my first attempt. I'll likely be taking a lot of inspiration from Nate Wienert's Obtvse project. As always, all the code is open source over at GitHub. I'd love to hear any ideas or criticisms!

The Trouble with Skeuomorphic Design

2012-03-03T00:43:47Z

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 green. Its design is governed by something called a skeuomorph, an extremely prevalent concept in digital interfaces.

What is a skeuomorph?

According to Wikipedia, a skeuomorph is "a derivative object that retains ornamental design cues to a structure that was necessary in the original". More simply, a skeuomorph is a design that retains elements of a predecessor or previous design, purely for visual purposes. Even that may be a little tricky to grasp, so I think the best way to become familiar with skeuomorphs is by example. They're just about everywhere we look - I'll focus on skeuomorphs in digital designs, although there are plenty to be found in the physical world as well.

Skeuomorphs in the wild

Digital skeuomorphs are absolutely everywhere. The floppy disk icon for Save, or the scissors to Cut have become ubiquitous, and the paint bucket is classic in illustration programs. And what about the fact that we sort files on our computers into 'folders'? On the web, retailers hold your items in a shopping cart, and buttons seemingly depress when you click them. One that's always annoyed me is the artificial shutter sound on cell phone cameras; regardless, someone thought it was important enough to make a default setting. Many of the digital interfaces we interact with on a daily basis are governed by skeuomorphs without us even thinking about it. But why such a focus on potentially outdated design elements?

Why do we use skeuomorphs?

Most technology has a learning curve associated with it. Skeuomorphs are used to make the transition easier, and to make a new design or concept feel more comfortable and familiar to us. Certain skeuomorphs are universally recognizable, and enable consistency across applications. Others drastically improve usability - Amazon's Kindle is a great device, and it's incredible easy to use because it mirrors the experience of paging through a real book. These are elements that we've come to expect, and they certainly have their place. But I'm writing this post because I think an over-reliance on familar elements can be harmful. The screenshot I posted from Reason is a particularly extreme example that characterizes what happens when too much focus is on emulating a predecessor. At its core, the modular component idea is nice. But the dangling wires clutter and complicate the screen, and extraneous elements such as power cables or cooling fans are gross wastes of space. Alternatively, think about calendar software. Let's say it's late in the week, and you're looking at your weekly view. It's common to see previous days, maybe grayed out, but still present and taking up space. This is a skeuomorphic relic of physical calendars, but digital calendars give us the power to do better. A rolling display containing the week ahead of the current day is a much more efficient display. Simply shifting our focus away from skeuomorphs can allow for much more efficient and elegant interfaces.

It's too late to change

It's hard to argue against the use of skeuomorphs completely. We've come to depend on our familiar interfaces, and even the slightest change would throw people off. Imagine what would happen if a developer decided to use something besides the iconic floppy disk for the Save action in their program. It certainly doesn't seem like a monumental change. But clicking on the floppy disk is a mindless action at this point, and changing it to something else requires thought from the user. Even if it's just a second, people will notice and get annoyed. These skeuomorphs are so ingrained in our everyday experiences that the slighest change throws us off, and so it's difficult to sit here and argue against their merits. It's too late to change the interface elements that we've become so accustomed to. Or is it?

Defining a new generation of experiences

Admittedly, that's a bold title. I try to avoid such grandiose statements, but recent technology has presented us with unique opportunities to define and create new standards of interaction. Think about the common elements of the current generation. My kids will have little context to grasp the idea of a floppy disk - sure, it means 'save', but what on earth is a floppy disk anyways? These things aren't even present in my generation, and yet they live on in our software. The skeuomorphs that are considered perfectly valid (and even expected) in current interfaces are quickly becoming outdated. Computing is rapidly shifting away from the traditional desktop model, and instead enabling an ever more mobile world. iPads and smartphones present an entirely new and more tactile way to interact with our devices, and I fear that too much of a focus on skeuomorphic designs of old spoils the opportunity to create new experiences and interfaces.

Why one monitor is better than two

2012-02-21T17:42:11Z

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?

Focus

Admittedly, it took me a while to realize why I was doing all my work on my dinky laptop and not my desktop. After all, why would I do such a thing? Multiple screens allow me to keep an editor and a browser (or multiple browsers) all open and visible on one desktop. There's infinitely more room for API references, Stack Overflow searches, you name it. I'm not particularly a fan of alt-tabbing all over the place, so the ability to keep everything open at once was like a godsend to me. And yet, most of this website was written on my laptop, along with most of my other web development and school projects of late. I've realized it all boils down to one thing: focus. After all, on a desktop there is indeed more room for browsers/API stuff, etc. But I found it was also enabling distractions. For example, my most common setup was an editor on screen and a testing browser on the other. But being the distractable person I am, I would often find myself pulling up reddit or Hacker News on a peripheral monitor the instant I got bored or temporarily lost focus. It was trivial to pop open a window or tab for something inane or distracting and stop working on my productive enterprises.

Although I find I tend to be able to focus more while I'm working on my laptop, there are still the tradeoffs I mentioned before. Small screens suck, and alt-tabbing is worse. There's not much that can be done about the screen itself, but there are workarounds that can make life more manageable. After some experimenting with virtual desktop programs, I came across VirtuaWin, which provides a fairly unobtrusive and functional interface for Windows. I found I could now emulate the advantages of multiple monitors - one for an editor, one for testing, etc. The experience is virtually the same - with some configuration, you can zip back and forth between workspaces in a heartbeat, but without the instant access to distraction. The portability aspect presents a pretty significant advantage as well - as an intern at RingRevenue this summer, I expect to be shuttling a computer back and forth, and the rumored MacBook Pro redesign is looking pretty tempting. I'm not a particularly disciplined person, and so I find that the 'confines' of a laptop allow me to sit back and just work, something I wasn't accomplishing as often as I'd like on my desktop.

Disclaimer

What I'm describing here doesn't necessarily apply to everybody - many people work perfectly fine with desktops and dual monitors. However, I've learned that I'm extremely prone to distraction and find myself not getting in the "zone" while trying to work at my desk because I'm constantly opening up tabs on another screen. By no means do I plan to get rid of my desktop - it still has its place. But when it comes time for getting work done, I'll take my laptop any day.

How It's Made: Sutro Post/Tag Associations

2012-02-11T01:23:03Z

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!

Fortunately, our tag model is extremely simple. All we care about is the tag name. Let's generate a model to represent our tags - run rails generate model tags to create the tag model, as well a migration to initialize the corresponding table.

# db/migrate/(timestamp)_create_tags.rb
def change
  create_table :tags do |t|
    t.string "name"
    t.timestamps
  end
end

That's all we have to do in our migration. Make sure to run a rake db:migrate afterwards. Now let's write the actual associations between our two models!

# app/models/tag.rb
class Tag < ActiveRecord::Base
  has_and_belongs_to_many :posts
end

# app/models/post.rb
class Post < ActiveRecord::Base
  has_and_belongs_to_many :tags
end

We're not quite done yet. If you were paying attention, you'll notice we haven't placed any foreign keys anywhere - nothing in either table references the other. For example, let's look at a customer/order relationship. A customer has many orders, and an order belongs to a single customer. The traditional approach would be to place a customer_id field in the Order table, so that an order now references a Customer by foreign key lookup. But a many-to-many relationship is more complicated. Since we defined that a post has and belongs to many tags, and that a tag has and belongs to many posts, we need an intermediate table to keep track of the associations called a join table. This is a table with two columns only - post_id and tag_id. The join table holds no data about either model - purely association data for lookups.

Creating the join table

While join tables may be a tricky concept to master in your head, the implementation is fortunately fairly simple and Rails handles most of the heavy lifting for us. For example, it's Rails convention to define the table name in terms of the two model names in alphabetical order. So, our table joining Posts and Tags will be called posts_tags. To implement it, all we have to do is generate the appropriate migration using rails generate migration CreatePostTagJoinTable.

# db/migrate/(timestamp)_create_post_tag_join_table.rb
def change
  create_table :posts_tags, :id => false do |t|
    t.integer :post_id
    t.integer :tag_id
  end
end

Note that we're specifying :id => false here. Rails automatically adds an id primary key to tables, but since this a pure join table we don't need it. Be sure to run a rake db:migrate again!

That's all we need to worry about in terms of migrations. Now we have to create an interface for our tags, and the ability to actually add a tag to a post.

has_and_belongs_to_many or has_many :through?

Before I continue, I want to explain a design decision here. If you have experience with Rails, you'll know that we had the option of doing has_many :through instead of has_and_belongs_to_many. For those unfamiliar with the association, has_many :through creates an intermediary model for the relationship. For example, consider a system that tracks appointments for physicians and patients. A physician has many patients, and a patient (potentially) has many physicians, but we need information about the relationship itself as well, such as the appointment time. In this case, we'd want to create the intermediary model Appointments and change our associations so that a physician has_many :patients, :through => :appointments and a patient has_many :physicians, :through => :appointments. Again, Appointments acts as a join table tracking the relationship, but now we have access to other information about the relationship itself. Other tutorials I've seen have implemented the post-tag association using has_many :through and created an intermediary model called Taggings. This doesn't appeal to me - a direct relationship seems to make more sense, so I've chosen to implement it using has_and_belongs_to_many. For more information, I highly recommend the RailsGuide on Associations or the ActiveRecord Associations ClassMethods Documentation.

Adding tags to posts

Before writing out any code, it's critical to sit back and imagine how you want the end result to work. I think of it in terms of a story - here, "when writing a post, I want to input the tags as a comma-separated list and have Rails do the rest of the work". This is possible, but takes a little bit of extra work on our part since we're no longer doing direct input as in a post title, for example. Let's write the corresponding code in our view first.

# app/views/admin/posts/new.html.erb
<%= form_for(:post, :url=>{:action => 'create'}) do |f| %>  
  <%= f.label :title %>
  <%= f.text_field :title %>

  <%= f.label :body, "Post" %>
  <%= f.text_area :body %>

  <%= f.label :tag_list, "Tags (optional)" %>
  <%= f.text_field :tag_list %>   

  <%= f.submit "Publish" %>           
  <%= link_to "Cancel", dashboard_path %>
<% end %>

At this point, you're like to run into an error if you go to the page - after all, our Post model has no attribute tag_list. We have to define methods to accept this tag list and transform it into a list of Tags associated with this post. Let's go into post.rb and define the appropriate methods.

# app/models/post.rb
def tag_list
  self.tags.map {|t| t.name }.join(", ")
end

With that defined, our new view displays fine, and our edit view displays the tags in a nicely comma separated list. But this doesn't actually associate any tags with a post yet. To do that, we have to define the special tag_list= method back in post.rb.

# app/models/post.rb
def tag_list=(tag_list)
  self.tags.clear # For the update method, just in case we're changing tags
  
  # Split the tags into an array, strip whitespace , and convert to lowercase
  tags = tag_list.split(",").collect{|s| s.strip.downcase}
 
  # For each tag, find or create by name, and associate with the post
  tags.each do |tag_name|
    tag = Tag.find_or_create_by_name(tag_name)
    tag.name = tag_name      
    self.tags << tag # Append the tag to the post
  end
end

We're making progress! We can now create posts with associated tags in a successful many to many relationship. Of course, we can't stop here. Tags aren't useful unless you have the ability to filter posts by their tags.

Filtering posts by tag

While it might seem like a good idea to generate a separate controller to handle our tags, I'm going to forgo that step. For now, it's somewhat of a lazy design decision, but we don't need that level of functionality and instead can just build our filtering into our post controller's list action. Let's do routes first.

# config/routes.rb
match "blog/tag/:tag"  => "posts#list", :as => "tag"

That gives us a simple named path that matches any tag string, such as /blog/tag/ruby and dispatches it to the list action on the posts controller. In the post controller itself, all we have to do is add a little bit of logic to determine whether or not we're filtering by a tag or just looking at the main blog index.

# app/controllers/posts_controller.rb
def list
    
  if !params[:tag].nil? # Are we looking at a tag?
    @tag = Tag.find_by_name(params[:tag])
    if @tag.nil?
      # Redirect if user is trying to look at a non-existent tag
      redirect_to blog_path
    else           
      @posts = @tag.posts.order("id DESC")
    end
  else
    # No tag - display posts as normal      
    @posts = Post.all.order("id DESC")
  end
                     
end

The actual Sutro implementation is slightly different (I check for status and do some pagination), but I've left those off for brevity. The full controller source is available on GitHub here.

Since we're lumping this in with the existing action, let's add a notice in the view so there's some indication that you're viewing by tag. My solution, although simple, was this:

# app/views/posts/list.html.erb
<% unless @tag.nil? %>
  <h1>Tagged: <%= @tag.name %></h1>
<% end %>

This creates an h1 at the top of the page displaying the current tag (if it exists)

Finishing touches

At this point, we've done all the real work for our tag implementation and now we're just working on presentational stuff. To close, this is how the tag 'pills' are displayed at the bottom of each post. A method called render_tags is defined in a helper that takes an array of Tag objects (as outputted by @post.tags or similar), and outputs a raw HTML string containing formatted links to each tag's respective path.

# app/helpers/post_helper.rb
def render_tags(tag_list)
  raw tags.map { |t| link_to(t.name, tag_path(t.name), :class=> "tag") }
    .join("")
end

Note that the Sutro implementation differs in that I use the same method for the public 'pill' display, and the backend dashboard which is a comma-separated listing. The full code is available here.

And we're done! We've succesfully created a many to many association between two models, the ability to enter tags with a post, and format them in a nice display. Rails provides powerful helpers to work with complex associations, and this is only a peek at what's possible. If you enjoyed what you read, or want to chide me on my lazy coding habits, make sure to inform me in the comments. Until next time!

Easily formatting dynamic HTML tags in PHP

2012-02-03T22:35:52Z

It's probably somewhat ironic that I'm writing my first code-oriented post about PHP. After all, I'm becoming more of a Rails fanboy the more I learn about it, and putting down PHP is one of my favorite pastimes. That being said, we're about to roll out a Drupal installation over at SexInfo Online, and so at least a cursory knowledge of PHP is required.

So what are we doing here?

I got sick of seeing code that looked like this:

<?php
  while($row = mysql_fetch_array($result)){
    echo "<div class=\"item\">" . $row['field']; . "</div>";
  }
?>

I decided that I needed a utility function similar to Rails' own content_tag method, which allows you to do something like this:

<%= content_tag(:p, "Hello World!", :class => "strong") %>

The function is taking 3 parameters in this case: the type of tag (as a Ruby symbol), the content itself, and optional HTML attributes such as classes or an ID. So let's model our PHP version on this, and write down some sample usage.

// Our end goal:
<?php
  $content = "Hello World!";
  echo content_tag("p", $content, array("class" => "strong"));
  // Should return <p class="strong">Hello World!</p>
?>

Let's go about actually implementing this!

Getting Started

Our first step is to think about the parameters that our content_tag() method will accept, but we've already covered that. We need to be able to specify the type of tag, the content, and optional attributes. Let's write our basic skeleton.

<?php
  function content_tag($tagName, $content, $attr=array()) {
    // Implementation later!
  }
?>

Nothing too complicated here. The $tagName and $content variables will be passed in as strings. Attributes are slightly more tricky; we're giving them a default value of a blank array, and will handle them as key-value pairs when used, e.g., "class" => "strong"

Before we move on and start writing code, let's think about what an HTML tag actually consists of. Take a look at this simple tag:

<p>Hello World!</p>

This is about as simple as it gets. It consists of a the opening tag (<p>), the content, and the closing tag(</p>). Already some helper methods are becoming apparent: one each for the opening and closing tag. The methods will be very similar: each one needs to take in a $tag parameter so that the appropriate tag can be output, but the opening tag also needs to account for possible HTML attributes. Let's start backwards and write the close_tag() method first.

The close_tag() method

This is simplest helper method we'll be writing. All we need to pass in is the type of tag to be closed!

<?php
  function close_tag($tag) {        
    return "</" . $tag . ">";
  }
?>

Not a whole lot to say there. Onwards!

The open_tag() method.

Our job gets a little bit trickier here. The tag itself is very simple, similar to close_tag(), except that we need to account for HTML attributes as a possible parameter. As I mentioned before, attributes will be handled as key-value pairs in an array. To translate this into HTML, we need to loop through all the pairs in our attribute array and output it as key="value". Let's put this in a helper method to prevent our open_tag() method from getting cluttered, and call it generate_attr_string(), a function which will take a single array parameter.

<?php
  // Example usage: generate_attr_string(array("id" => "nav", "class" => "item"));
  //=> id="nav" class="item"
  
  function generate_attr_string($attr) {
    $attr_string = null;
    if (!empty($attr)) {
      foreach ($attr as $key => $value) {
        // If we have attributes, loop through the key/value pairs passed in
        //and return result HTML as a string
        
        // Don't put a space after the last value
        if ($value == end($attr)) {
          $attr_string .= $key . "=" . '"' . $value . '"';
        } else {
          $attr_string .= $key . "=" . '"' . $value . '" ';
        }
      }
    }       
  return $attr_string;      
}
?>

That's a little ugly, but it makes our open_tag() method trivial to finish. Let's wrap that up.

<?php
  // Example usage: open_tag("p", array("id" => "nav", "class" => "item"));
  //=> <p id="nav" class="item">
  
  function open_tag() {
    $attr_string = generate_attr_string($attr);
    return "<" . $tag . " " . $attr_string . ">"; 
  }
?>

Starting to see how content_tag() is going to work? Stay tuned - we're almost there!

The Final Function

At this point we're really just stringing together our utility methods, using our parameter signature from before. Let's see how it looks!

<?php
  function content_tag($tagName, $content, $attr=array()) {
    return open_tag($tagName, $attr) . $content . close_tag($tagName);
  }
?>

It's almost a disappointing finish - all the fun was in the helper methods! You could put keep all of the code in the content_tag() method if you wanted to, but I generally try to keep everything separated out into functions. Your choice. Anyways, I hope that you find this function useful one day - the use case I described in the beginning of this post was trivial, but I find this comes in handy when looping through results returned by MySQL or similar.

Anyways, that's hopefully the last I'll speak of PHP for a while. I promise the next code post will be delicious Rails :)

Are there any questions?

2012-01-27T23:18:20Z

On Wednesday, I went to an information session hosted by the gentlemen over at RingRevenue. They were there to give a presentation about what call performance marketing is all about and share some cool details about their Rails setup on the backend. There was maybe 20 people in the room at most - it was an ideal environment, very laid back and personal. But that's not what I'm writing to talk about - I'm writing to talk about a strange phenomenon that I've seen again and again in that setting. After the end of the presentation, the PowerPoint was turned off and the presenter asked "so, are there any questions?"

Silence.

It's the weirdest thing. Here I am in a room with a bunch of presumably intelligent CS undergrads and some incredibly smart engineers at a neat startup that's working on some big things. And yet, they're met with this awkward air of silence that just kinds of hangs over the room. I've seen this happen before at countless information sessions. And I always wonder what it is that prevents people from asking questions. Is it because there's nothing to ask? Perhaps partially. These guys are here talking about a vastly complicated enterprise-class platform. I didn't even know what "high ROI call performance tracking" meant going into the session. But my guess is that this stunned silence stems from something greater - fear. It's the fear of being singled out, of asking a "dumb question", or just interacting with someone you perceive to be smarter than you are. I've been guilty of it myself; I usually don't like to speak up when I'm in a large group of people. But the result is that you have a room full of people wasting an opportunity that's very literally presenting itself to them.

Be Conversational

I broke the silence and asked a question or two about scability issues with their Rails deployment. An easy start - it gets somebody talking. All of these presenters have done this many times, and pretty clearly love to talk about what they do. And I think that showing interest and getting somebody talking is the key to getting value (and a job!) out of these sessions. When you think of it as a conversation as opposed to a stiff me-vs-them panel scenario, you can have a lot of fun. One of my favorite questions to ask in these settings is something along the lines of "given the size of your company, do you feel that your (personal) contributions are visible in the company or the product?". I'm actually interested in the answer, and I think it's a question that should be asked, but more importantly, it leads into twenty other related questions. At that point, a previous intern piped up and talked about what she had done in her time there, and how she really felt like her contributions made a difference. Cool. At that point, you can start asking about the workflow. How do you interact with the other employees? What's the daily routine like? Do you find that all employees working in the same room leads to more distractions? Etc, etc, etc. It's all about finding that one entry question that leads to all the others, and not being the person who shows up with nothing to contribute (or take away).

Be Exceptional

This post is about more than awkward silences at information sessions. It's about how even once the conversation gets going, there's still the percentage of people in the room who say nothing. After the Q&A ends, it's the people who silently leave the room without chatting with the presenters. It strikes me as a waste of effort - after all, you came out to the information session. Step one! But step two is the most important, and I've seen a lot of people pass up the opportunity to spend five or ten minutes to schmooze with smart people. I recently read a great article on so-called "master networker" Keith Ferrazzi. Now, I'm not saying everybody should strive to be at a point where they need two Palm Pilots to track all their contacts, or make a living out of knowing people. But networking is a critical skill in life, and information sessions like the one I went to are sort of a baby step into making contacts. There was one line from that article in particular that I will always remember. The author of the article, Tahl Raz, was attending a lunch with Ferrazzi and a TV executive, and at one point, Ferrazzi leaned over and said, "You're a fucking loser if you don't walk out of here with some reason for getting in touch with her again". Now, Mr. Ferrazzi's approach may be a little harsh, but the idea remains true. Find a reason to get in touch with people again. Get your face in their memory. It only takes a question or two.

It's about doing more.

Now, let's say you took that advice to heart and became a networker. People know your name. You know people in high places. Unfortunately, you only have half of the puzzle completed. If you know all the right people in all the right places but can't follow through then you're still no better off than before. What does it meant to follow through? Simply put, be the best at what you do. Be able to bring something to the table. I see many of my peers sort of 'coasting' through undergraduate computer science classes. If you ask them what their favorite programming language is, they respond with "C++, because it's the only thing we've learned in school". There's nothing wrong with C++ in itself (perhaps debatable - another time). It's the second half of that sentence that gets me every time. "It's the only thing we've learned in school". How can you possibly stand out to recruiters, employers, or anybody if you only do the bare minimum that's asked of you? There is by no means a shortage of CS undergrads. If you want to find yourself at the head of the pack, then you have to do more. And it doesn't take a slavish commitment to programming for 19 hours a day to stand out. You don't have to freak out and give up because you haven't written the next Facebook by now. It's the people who do things for the fun of it that will get ahead. It's the tinkerers, the hackers, the builders, the ones who take things apart and put them back together again. It's the people who write code and learn languages for kicks or try to write a program just to see if it's possible. These are the people who will become leaders and show up in the news one day. So don't be one of the people with a degree and no real direction to turn. There are thousands of resources out there to get started with, and people much smarter than you. Ask questions. Do more. Have fun.

Are there any questions?

Hello World!

2012-01-18T22:28:57Z

Even though this is the obligatory 'Hello World' post, it feels like it's been forever since I started work on planning and building this site. In early fall of last year, I was gifted the domain andrewberls.com. I had no particular use for it at the time, but it seemed like a handy thing to hold on to. I decided I wanted to build a portfolio site for myself, to show off a little of what I've done up until this point and shamelessly promote myself. After completing the first iteration while also frantically trying to juggle schoolwork, I decided that the site needed more to it. Everybody has a blog, and I wasn't going to be the exception. I pondered my options- I posted on tumblr for the time being and thought about throwing a Wordpal or Drupal installation onto my domain, but that seemed unexciting. Nobody cares if you can install Wordpress, and I wanted to focus on improving my technical knowledge and abilities rather than actual writing (god forbid) anyways. The result you see here is powered by Sutro, a blogging engine I wrote from scratch using Ruby on Rails.

Going into all of this, I had absolutely no clue what Rails was all about, and had never used most of the tools I needed in any significant application. I had started learning a few snippets of PHP towards the end of the summer, and so the initial application was written in PHP. I started on the portfolio section, and only needed some basic scripting for the Contact form, so it seemed like a good fit. When I decided to write the blogging software as well, it was pretty clear that I would need a better solution, and so I had a good excuse to go learn Rails.

In building this site, I've learned more than I could have possibly imagined. The various features I chose to initially implement forced me to finally learn Ruby and what Rails was all about, the model-view-controller architecture, databases, authentication algorithms, optimization techniques, and some sneaky JavaScript tricks with a healthy dose of jQuery. It's not to say that I didn't know anything about these beforehand, but I'm a firm believer in that the only way to truly learn something is to get your hands dirty and work with it. I decided fairly early on that I wanted to avoid third-party plugins and pre-written code as much as possible. It's not because I don't see their value- to the contrary, I'm an advocate of letting other people do the heavy lifting for you, and believe it to be a best practice - but I wanted to make this a learning experience as much as possible for myself and see what I could accomplish from scratch. Some of the resulting features - slideshows, contact forms, etc, are a little rough around the edges, but they work and I get to say that it's something I wrote.

Behind the Scenes

The front end of the site is fairly straightforward. I use the Zen Coding plugin with Aptana Studio as my primary editor environment. All of the CSS is processed through Sass, and most of the JavaScript is handled by jQuery. None of these particular tools are critical to the project or its structure, but they make life much easier, and save heaps of time. On the back end, I'm running Ruby on Rails with PostgreSQL deployed to Heroku (with Zerigo DNS to route back to BlueHost), which is a result of many, many hours of tearing my hair out over obscure bugs and errors. All of the source code is managed by Git and hosted on GitHub. I'm still new to using Git, and so the freely-available Pro Git has been invaluable in helping me get off the ground. As much as I wanted to avoid plugins, I had to cave on several things where it's simply too inconvenient to avoid. I use BCrypt for password hashing and salt generation, and will_paginate for pagination of the post display (which is awesome for simple applications). What you see here is only half of the end result - everything is supported by a custom-built backend providing administrative views and actions on posts, as well as primitive support for multiple users with permission levels.

Design

I've gone back and forth on the design of the site. From the beginning, I knew I wanted a single-page scrolling layout for the front page, and a strong focus on clean, minimalist design. As it turns out, I'm terrible at design and coming up with something attractive and professional-looking is difficult to do. I constantly wavered on color palettes and layouts, and ended up changing the look of the blog at the very last minute. The design is heavily influenced by Twitter's Bootstrap framework which is absolutely brilliant, and I'll definitely be using it on my next project. The two tools I can no longer live without are Color Scheme Designer and Eric Meyer's Color Blender.

Looking Back

This may seem like a fairly trivial application in the end. Blogging software is actually relatively simple conceptually to write: a couple of forms POST to controllers which save the data and essentially spit it back out to the views for display. That's a generalization of course: the tricky bits are all in the tiny details in getting the bigger concepts to work, and I consider it a personal accomplishment. This is one of the first significant "real" projects I've worked on, and something I completed of my own volition. It's been fascinating to watch the project evolve, even from my own viewpoint. Since everything is hosted on GitHub, I can go back in time through the commit history and look at day one, where it was a single page written in PHP, up through where I first migrated to Rails (and wrote some pretty nasty code), and finally up to where the project is now.

The Future

So what's next? The site is not finished it any sense of the word. I have the ability to write and administer posts, which was my initial goal, but I plan to continue to expand the project in my free time. I only just touched on multi-user CMS-style support, and I have no shortage of refactoring and cleaning up to do (past me is a real slob). I have plenty of other projects on my plate as well. I'll be rolling out a complete rewrite of SexInfo Online in the weeks to come. I'm also just starting to look more closely into JavaScript and the HTML5 canvas element as part of writing a scrolling browser game for a class. I'll be writing posts about all of these in the future, as well as more in-depth looks at some of the various Sutro feature implementations with tips and tricks.

Goodbye World (for now)

If you're interested, be sure to check out the nitty gritty implementation over on GitHub, or shoot me an email!

Oh, and the best part? This entire thing was developed on a Windows environment. How's that for a healthy dose of sadomasochism? ;)