Avand.

Write Less JavaScript

2014-12-15T00:00:00+00:00

How many lines of JavaScript code were used to create the following interface?

At Mystery Science, we recently released this feature to capture feedback after a teacher has taught a lesson. There are four possible screens or states:

Prompt (did you teach?)
Rating (stars)
Comments (open-ended feedback)
Done

Each state (except the last one) prompts and subsequently saves user input. The server knows I taught a lesson as soon as I click “yes.” The star rating and comments work the same way — all responses are submitted via XHR. How little JS code can we write to get this feature working?

The first trick to writing less JS is to find the right abstractions. Let’s explore the two key abstractions here. When a teacher submits a response, JS is advancing the interface’s state. This can be accomplished in any number of ways but at the end of the day some elements are being shown (display: inherit¹) and others are being hidden (display: none). JS also has to send the response to the server, which in jQuery-terms eventually means a call to $.ajax().

Let’s wire this up:

// Let's assume this feature lives inside <div class="lesson-feedback">.
var container = $('.lesson-feedback');

// First, let's wire up the UI:
container.find('.yes-control').click(enterRatingState);
container.find('.rating-control').click(enterCommentsState);
container.find('.no-control, .submit-comments-control, .skip-comments-control')
  .click(enterDoneState);

// Now, let's wire up the response submissions:
container.find('form').submit(submitViaXHR);

This is a great start! This code is readable and there’s not much of it. But we’ve introduced some event handlers like enterRatingState() that are not defined. Presumably, these functions will reach into the container and show and hide their respective elements. But given that each state has many elements, how can we do this without introducing a bunch of JS? Let’s introduce some CSS to do the heavy-lifting. This is the second trick to writing less JS: defer view logic to CSS whenever possible.

.lesson-feedback.state-rating .rating,
.lesson-feedback.state-rating .visible-during-rating {
  display: inherit;
}
.lesson-feedback.state-rating .prompt,
.lesson-feedback.state-rating .comments,
.lesson-feedback.state-rating .done,
.lesson-feedback.state-rating .hidden-during-rating {
  display: none;
}

Let’s unpack this. Obviously, .lesson-feedback is the container. We’ll modify the container with .state-* classes to enter and exit the four states. This means there will also be .state-prompt, .state-comments, and .state-done. Each state needs blocks like the ones above. I’ve also included .visible-during-* and .hidden-during-* helper classes to control elements that span states (like the header and image). It may seem like a lot of CSS but once it’s there you shouldn’t need to change it unless you add or remove a state. Some of the repetition can also be reduced with a preprocessor like LESS or SASS.

Now, enterRatingState() and the other state-related functions are really lightweight:

// You'll need a function like this for each state:
function enterRatingState() {
  enterState('rating');
}

function enterState(state) {
  container.removeClass('state-prompt state-rating state-comments state-done');
  container.addClass('state-' + state);
}

That’s all we need to drive the interface; looking good! Now, let’s look at data submission. In the first code example, I introduced submitViaXHR(). Let’s define that now.

function submitViaXHR(event) {
  event.preventDefault()

  var form = $(event.target);

  $.ajax(form.attr('action'), {
    type: form.attr('method'),
    data: form.serialize()
  }
}

Remember, all the forms have submitViaXHR() bound as an event handler on submit. Instead of submitting to the server with a traditional page refresh, jQuery steps in and submits the data via XHR instead — this is nothing new. The real elegance here is that they all submit the same way. There are not three different handlers for the prompt, rating, and comments forms. The third trick to writing less JS is to keep data in HTML. Here’s an example of the HTML for the first state, prompt:

<div class="lesson-feedback state-prompt">
  <div class="prompt">
    <div class="answer">
      <form action="/viewings" method="PUT" style="display: inline;">
        <input type="hidden" name="viewing[actually_taught]" value="true">
        <input type="submit" value="Yes" class="yes-control button button-green">
      </form>

      <form action="/viewings" method="PUT" style="display: inline;">
        <input type="hidden" name="viewing[actually_taught]" value="false">
        <input type="submit" value="No" class="no-control button button-red">
      </div>
    </div>
  </div>

  <!-- And so on for the other states... -->
</div>

There are two really lightweight forms with hidden values that submit to the server. That’s all we need. The destination of the request (/viewings), the HTTP verb (PUT), and the request data ({ viewing: { actually_taught: true} }) are all stored in the markup and that’s a good thing.

So let’s recap. To write less JavaScript:

Find the right abstractions.
Defer view logic to CSS whenever possible.
Keep data in the HTML.

1: inherit is a better choice than block for visible elements. This approach will allow inline elements to preserve their inline display type.

Calculated Attribute Pattern for Ruby Models

2014-11-26T00:00:00+00:00

Sometimes in a Rails application a model has attributes whose values need to be computed. For example, at Mystery Science, we have a Viewing model that is created when a lesson has been viewed. This model is associated with actions that a teacher took with a lesson (e.g., playing a video, entering full screen mode, etc.). If we want to know how much time the teacher spent watching the videos, we need to calculate the value:

class Viewing

  def seconds_spent_watching_videos
    @seconds_spent_watching_videos ||= videos_played.sum do |play|
      play.duration
    end
  end

end

It’s advisable to at least memoize this attribute so it doesn’t have to be recalculated more than once for the same instance. But, when dealing with a collection of viewings, the calculation has to be performed on each one. That means querying is very expensive and can’t be done in SQL. Let’s store the value in the table instead:

class AddSecondsSpentWatchingVideosToViewings < ActiveRecord::Migration

  def change
    add_column :viewings, :seconds_spent_watching_videos, :float
  end

end

Now, you need a method to update that value. You might be inclined to write a calculate_seconds_spent_watching_videos method that you call before_validation. That approach works just fine but it clutters up your model; consider that there may be more other attributes like this one. Here’s a pattern that I’ve used that works really well in these cases:

class Viewing

  def seconds_spent_watching_videos(options = {})
    if options[:reload]
      @seconds_spent_watching_videos ||= videos_played.sum do |play|
        play.duration
      end
    else
      read_attribute :seconds_spent_watching_videos
    end
  end

end

Here, I’m overwritting the attribute’s accessor method to take options. If you call it normally, viewing.seconds_spent_watching_videos, you’ll get the value from the database. But if you call it with the reload option, viewing.seconds_spent_watching_videos(reload: true), you’ll get the calculated value. You still need to write_attribute at some point — a callback may still be the right place for that — but I’m of the opinion that your “getter” shouldn’t double as a “setter.”

I’ve used this pattern throughout my Rails applications and it’s been really useful. Hopefully, it’s useful for you as well.

CSS Spinners

2014-08-21T00:00:00+00:00

Spinners are really easy to implement with animated GIFs. However, they don’t look great when overlayed on top of another image because GIFs only support index transparency. If they’re on a solid background, you can match colors and they’ll look fine. Services like ajaxload.info make it easy to generate the appropriate image.

To implement a spinner as an overlay requires another approach. SpiffyGif turned me onto the idea of using a translucent PNG sprite spinner. This technique involves a PNG sprite with every frame drawn out. Some JavaScript code updates the background-position of the sprite on an interval, which makes it appear to be spinning. Here’s the example they provide:

See the Pen The Sprite Spinner by Avand (@avand) on CodePen.

Initially, I was enamored with the idea but as I started to wire it up, I realized it was heavy-handed. There had to be a way to achieve the same affect without JS. I knew if I animated the transform: rotate(360deg) declaration, I knew I could get the PNG to spin around but it looks awkward when the spokes of the graphic actually move. Then I remembered that the timing-function could be given as a number of steps (e.g, [steps(n)]). Instead of drawing each frame of the animation, steps(n) breaks up the animation into n states. steps(2), for example, would draw the animation when it’s 50% complete and then again at 100% ignoring the steps in between. If you set n to match the number of spokes in your graphic, you’ll rotate the PNG in as many steps, just like a second hand might tick around a clock. Here’s a demo:

You could take this idea further and actually generate the graphic with CSS too but personally I think the PNG works just fine.

Here and Now

2014-05-29T00:00:00+00:00

The here and the now are compelling destinations. People want to feel like they’re part of what’s happening now. They want to feel like now is happening where they are.

Stripe Checkout features animations to communicate what the product is doing. They’re subtle but the product feels incomplete without them. These animations pull you into the present moment. You don’t have to wait for you text message to arrive, the product is waiting with you. It puts you here and now rather than disconnecting from you.

Music is the sound of here and now. The harder you listen, the more there is to hear. Great artists don’t stop if they play the wrong note or sing the wrong word. They lead into the charge into the present moment. In turn, the audience idolizes the artist, putting them on a stage under all the lights. Sometimes it feels like you could follow them forever.

Surfers ride on the crest of a wave, an incredibly fleeting moment where the past meets the future. Often it’s a perilous place. Disconnect for even a split second and you’re buried under a mountain of water. The practice of the present requires tremendous focus.

We relax in places where here and now appear to slow down. By removing indicators that time is elapsing, it can feel like a moment lasts forever. On the beach, the sun appears to be hung high in the sky. The constant crash of the waves act like a metronome setting the pace. Even here, just an empty cocktail on the beach nudge our attention out of the now and onto what’s next.

Of course, the ultimate irony is that the present tense is always available. Many people put it in front of them. Others claim it’s behind them. There’s always a here and now to tap into. In fact, that may be all there is.

Momentum

2013-11-20T00:00:00+00:00

Startups move fast. They’re young, loud, and disruptive—a room full of excited twenty-somethings willing to burn the midnight oil to get a release out the door. Startups are enticing playgrounds with more Apple hardware and beer on tap than you can handle. When you’re tired, don’t go home. Stay. There’s still more work to be done, the Backlog says so. The blind lead the blind in this “up and to the left” landgrab.

“Speed comes from precision,” says Rob Robbins, an engineer at TaskRabbit and a seasoned musician. You don’t get fast by going faster, you get fast through precise repetition. With each iteration, you discover, then eliminate, imperfections that held you back. Though it’s said that “practice makes perfect,” not all practice yields the same results.

Psychologist K. Anders Ericsson has been a pioneer in the field of “deliberate practice.” “The differences between expert performers and normal adults reflect a life-long period of deliberate effort to improve performance in a specific domain,” Ericsson says. Going through the motions is not enough. In his book The Talent Code, Daniel Coyle says that to practice well is to “look at the task as a whole…divide it into its smallest possible chunks…[and then] play with time, slowing the action down, then speeding it up.”

When you practice something, you eliminate the frictions that impede you. Practice is an accelerant. And the better you practice the more you accelerate. Better practice can be achieved through “chunking,” like Coyle suggests. It can also be improved simply through focus—obviously, you’ll practice better when you’re not distracted.

But deliberate practice isn’t the only way to improve. You can also just practice more. I see this evidenced each week at General Assembly, where I teach front-end web development. Some students stay moderately but consistently focused for the duration of the 10-week course. And they match up with students that practice more intensely but spend less time overall. The highest performers practice both frequently and intensely. And perhaps unsurprisingly, physical objects obey the same rules.

To determine an object’s velocity, that is its speed in a given direction, we can use the equation v = u + at, where u is its initial velocity, a is its acceleration, and t is time. If you accelerate at 10 meters/second/second for 10 seconds, you’ll be moving at 100 meters/second. To double your speed, double your acceleration, or double the time. But double both and velocity grows by a factor of two.

But velocity is only part of the equation. You can vigorously work on a triviality for a lifetime only to be left with a triviality. To make a “dent in the universe” (Steve Jobs) requires work of substance, matters of importance and mass. Impact happens when velocity and substance meet.

In physical terms, impact is momentum, “the product of the mass and velocity of an object.” Momentum, p, is calculated by multiplying mass, m, by velocity, v (p = mv). A big idea with little action or execution doesn’t have a significant impact. Similarly, considerable effort put towards a weak idea also lacks impact. As Derek Sivers puts it, “ideas are just a multiplier of execution.” And startups cluster at the fringes of this spectrum, either working vigorously on trivial ideas or apathetically on big ones.

It’s hard to make big things move fast—that’s just inertia. After 10 years of classical piano, I’m able to play “Träumerei” or “Dreaming” by Robert Schumann.

This one page of music represents years of practice. It’s not where I started. Practice and time gave me velocity. And as my repertoire gained mass, I gained momentum as a pianist.

Now, I think to the future. Of course, I want my work to be meaningful. But dreaming of the impact my work may have is just inspiration. Their impact will come from years of practice. The things I work on today will collide into the things on work on tomorrow, and one day, years from now, I’ll have the velocity and mass to make a difference.

Canary

2013-08-01T00:00:00+00:00

The last product I built, Sqoot, had a lot of moving parts. We had three databases, a search server, an API, website, and a deal importing system. It’s a marvel that it worked at all! The truth is that it went down pretty frequently. Sadly, our customers were often the first to find out even though we went to great lengths to monitor our apps.

After Sqoot, I briefly worked at TaskRabbit. Because we had an operations team I didn’t have to think about whether or not our code was running. But I did still have to worry about the code itself: thousands of lines scattered across a bunch of apps. We wrote lots of tests to prevent bugs. The slowest tests were our integration tests. These tests actually boot up a server and clicked around the site in a browser like a customer would. These tests were so frustratingly slow that Rob Robbins and I dreamt up Specford. And still anytime someone on my team wanted to push a change, we’d wait 15-20 minutes for the tests to run. Our test suite was the biggest adversary to our speed.

Paradoxically, our code still broke in production. If you want to know with 100% confidence that things are “up,” you just need to check production. There are a few services that will do this kind of monitoring for you but they’re either hard to use, expensive, or both. I want a service that’s affordable and well designed. So I’m building it.

Canary is an uptime monitoring service. Canary tells you when things go wrong before anyone else does. Currently Canary will monitor a URL and send an alert if the URL doesn’t respond or responds unsuccessfully. There are no usage limits or tiered subscriptions; $5/mo gets you everything.

I’ve teamed up with my friend and previous co-founder, Brandon. We’ve built great things in the past and are really excited to build out all the ideas we have for Canary.

Try out Canary free for 14 days. I’d love hear your early feedback.

Getting Close to Your Customers

2013-04-26T00:00:00+00:00

Play Strength, a Rdio Feature Concept

2012-11-29T00:00:00+00:00

Music can make or break a party. And picking good music to play is hard. I think it should be easy.

Here, I take a closer look at creating a great setlist with Rdio. I start with some back story about why I started thinking about this problem and why I think it’s important. Then I explore 10 potential design concepts, three of which have mockups. Finally, I’ll dive deep into one concept I’m calling Play Strength.

Above all else, this is a design exercise to showcase how I think about problems and approach solving them. It should take about 10 minutes to read.

Back Story

Daft Punk Is Playing At My House was stuck in my head as soon as the bartender told me she had seen LCD Soundsystem at The Orpheum in Boston. It must have woken the dormant DJ inside me because as soon as the party came home, it was queued up. And the jams didn’t stop there. Three hours of hitting Play Later left us with an eclectic ambient mix. My favorites soon became my friends’ favorites, and the next day I used History to build a playlist, which I shared to our guests and on Facebook.

Playing DJ for a night got me thinking. The mechanics of the Queue worked out fantastically. I would go searching for a few songs in Collection, rearrange the order, let the songs play out, and repeat. Rdio got out of my way and allowed me to focus on the music. But finding good music to play was still hard. I’d only find two or three new songs for every song that played. I was having a blast, so I wasn’t watching the clock, but I must have spent about a third of the night at my computer.

Is there an easier way to build a great setlist?

Ten Different Perspectives

Apple follows a 10-3-1 design process, where designers rigorously explore three options from 10 concepts before settling on one strong decision. I fall in love easily, especially with my own ideas, so I force myself to follow this process.

Here are 10 different ways to think about creating better setlists.

1. Radio Station

Perhaps hand-selecting music is entirely unnecessary. I played music from Collection, so a station made up of that music is a great start. For more variety, the Heavy Rotation station would have introduced new music to the mix. But I was actually looking to keep to a theme. For example, deadmau5 is in my library but was a bad fit that night. With a radio station, the only control you have is to skip to the next track. And you can’t skip a song without breaking the groove.

2. Radio Station with Smoother Cuts

Introducing smoother transitions between track cuts might cut down on interruptions. But doing it well is difficult and seems beyond the scope of Rdio; better suited for Serato maybe. A simple cross-fade might help but, no matter what, skipping a track is still an auditory interruption.

3. Radio Station with Better Suggestions

Identify a theme by choosing a song, genre, or artist, and a Pandora-like radio station might be able to keep that vibe going. Each song is a gamble and “channel surfing” is still an interruption. But training the station with likes and dislikes does give users some control beyond just skipping the track.

4. Radio Station with More Control

Manipulate a generated playlist based on your Collection or Heavy Rotation. When it gets close to the end, Rdio could add a handful of new tracks automatically.

Now the DJ has more variety, can reorder tracks, and remove unwanted music before it plays. But it’s a subtractive process, which means less satisfaction for hand-selecting the next great track.

This auto-generated-never-ending playlist could exist as a new section under Browse and/or Your Music in the left-column navigation. It shares some similarities to an iTunes Smart Playlist.

5. Remote Control

I enjoyed the selection process but had to get off the couch to keep the tunes flowing. With better synchronization between devices, I could have added and rearranged music right from my phone. Great for convenience, terrible for social etiquette.

Take this one step further and friends could add music to the queue from their phones.

For what it’s worth, I started this exercise before version 2.0.0 of the Rdio iPhone app had been released.

6. Play Indicators

When you hear a song, you’re less likely to want to hear it again, especially at a party. The interface could indicate when a song has been played. I attempted unsuccessfully to achieve this with icons. Hourglasses were much too hard to read when scaled down and any other simple indicator, like a read/unread dot, lacked sufficient context. I used an opacity reduction instead. To avoid visual clutter, songs that are played together as part of a set would also fade in together. Because songs are tightly grouped by album, this opacity change could bubble up to the album level too. It’s a clever implementation but the opacity change still lacks context. Manipulating opacity is always a nuanced design choice and I don’t think it works well here.

7. Last Played

Most music libraries on the market today have a column for when a song was last played. But when sorting thousands of songs, the signal-to-noise ratio is low. For example, it’s hard to know why a song hasn’t been played in a while. Or you may play a song on your ride to work and want to hear it again at happy hour.

8. Popularity

While I was browsing more unfamiliar albums, it was hard to know which song to pick. I knew, for example, that I wanted to hear something off Shrines by Purity Ring, but I didn’t know which track. In this case, I’d be happy to default to the most popular option. Spotify does this in some places (screenshot) but it’s less useful outside the context of an album.

9. Stars

Starring serves the same utility as popularity but gives me more control. For example, I just re-listened to The 2nd Law by Muse and Unsustainable stood out as a token dubstep track. I’ll definitely be hunting it down again soon. It would be nice to call it out from the other songs on that album. On the other hand, stars add clutter and in other applications, like Gmail, they’re predominantly underutilized.

10. Play Strength

Perhaps the solution is more holistic. A great setlist takes into account when a song was played last, its popularity, how it relates to friends’ musical tastes, and similarity to music that’s currently playing. Rdio could compute a compound index, Play Strength, and expose it in the interface to help suggest the next tracks. You don’t have to explain how you computed the index, but the mechanics are interesting. Pandora does this when they explain why you’re hearing a particular song and it adds to the experience.

Play Strength Deep Dive

Play Strength is a compound index computed for each song for each user based on:

Number of times the user has played the song
When the user last played the song
Number of friends that have recently listened to the song
Popularity of the song in the community
Similarity of the song to other songs in the current setlist

Play Count & Last Played

In every music library, plays are distributed over time organically based on the owner’s tastes. Every song’s play count and last played will fall within some standard deviation of the library’s average. You may be able to tell if a song is being over or under played based on the standard deviation for these two values.

In my mockup, I simply print last played and play count but it might be more interesting to actually tell the user, “you over/underplay this song” or “you have (not) played this song recently.”

It’s also important to note that an overplayed song may actually be a great addition to a setlist. Songs with abnormally high play counts are probably the songs you like the most. In these cases, the Play Strength should get a big boost. But if the song was already included in the current set, the Play Strength should drop dramatically.

Friends

Rdio already does an awesome job of leveraging my friends’ musical tastes to help me discover new music. But once music is in my library, it’s up to me to rediscover it. The more friends I have that are listening to a song, the higher its Play Strength should be. This is especially useful when my friends are listening to particular songs on an album more than others. And if you knew which Rdio users were listening to the current mix, Play Strength could be taken to a whole new level.

Popularity & Similarity

While building my setlist Saturday night, there were a few times where I knew what album or artist I wanted to hear but I had no idea which song to play. Albums can have a huge variance in tempo and mood so it’s easy to choose… poorly.

Knowing which songs are popular across the entire music community is really helpful. Next Big Sound has done some really interesting work in this area but it centers around artists. I imagine Rdio already has the data required to know which songs are being played more than others by album or artist across the ecosystem.

A setlist is also bound to share acoustic themes. Songs that sound like what you’re currently playing should have a higher Play Strength. But knowing which songs sound like other songs programmatically is hard. The Echo Nest out of Boston has some API’s that could help but song similarity is part of a much larger music discovery problem.

Songs within a genre share similar sounds, especially when they’re released around the same time. Rdio could boost the Play Strength for any song in a genre currently represented by the setlist.

Closing Remarks

Play Strength is a hard technical problem but is a simple solution for the end user. I think the last radio variant concept, i.e. the auto-generated-never-ending playlist, is also really interesting but it’s a specialized feature. Play Strength stays out of your way and consistently adds to the experience of browsing music.

I also like Play Strength because it lends itself to iteration. The bar-style strength indicator, inspired by AngelList, is not an invasive addition. At first, the callout that explains how Play Strength is computed could be left out. As the rules for computing Play Strength change, the callout evolves organically. This gives the feature a lot of room to grow.

Finally, I like Play Strength because it’s comprehensive. It’s the type of feature I might grow to love and is hard to copy.

Looking forward to your feedback in the comments.

Create Great Technical Interviews

2012-11-26T00:00:00+00:00

A technical interview or screening is a crucial part of reviewing a candidate for an engineering position. It’s usually the second step in the review process and is a prerequisite to an in-person interview. Here are some lessons I’ve learned in the last few years of taking and giving a dozen or so interviews.

You learn bits and pieces about the personality of a candidate throughout the entire interview process. The technical interview is a chance for them to highlight their expertise, aptitude, and style, not their charm, wit, or lack thereof. I set aside an hour for technical interviews: 10 minutes for introductions, 40 minutes to code, and 10 minutes at the end for Q&A.

I start with a three to five minute summary of who I am and what I do. Humans naturally mirror each other’s behavior. In an interview, I find this to be amplified so I make sure to stick to the facts and ask the candidate to do the same.

If you’ve got a “Chatty Cathy,” keep your eye on the clock. Make sure chit-chat doesn’t eat into their time to code. Interrupt your candidate politely by saying, “I want to make sure you have enough time to get through the code so let’s come back to this during Q&A.” Inversely, if the candidate is taciturn, have some questions ready to open them up. What projects are they working on? What type of role are they looking for? How do they stay current with technology?

When it comes time to code, there are thousands of interview questions to choose from. I look for a single problem that flexes several computer science muscles like recursion, object-oriented programming, queues, or data structures. The more ways there are to solve the problem, the better chance you’ll have to see how the candidate thinks. I also prefer problems that start simply, build in complexity and lend themselves to test-driven development (TDD).

Practice explaining the problem clearly to avoid wasting time and encourage candidates to think out loud. Most technical interview problems have a really elegant and non-intuitive solution. Candidates often know this and can spin their wheels trying to figure it out on the first pass. TDD helps alleviate these symptoms. Remind candidates that you’re looking for thoughtfulness over correctness to help them feel more comfortable.

It’s crucial to see every keystroke. An engineer’s cursor is an extension of her thought process. In the past, I’ve used Skype or Messages (formerly iChat) to screen share. Besides being a little invasive, screen sharing can lead to “rabbit holes,” especially during setup. For example, I’ve seen confused candidates create entirely new Rails projects or bundle a gem when a single Ruby file would have sufficed. The less wiggle-room the better. Google Docs works but you really want an editor designed for code. I recommend Stypi.

Run the code. Engineers iterate on solutions by executing the code they’ve written. I think it’s unfair to make anyone think through a whole problem in their head. If you’re using a web-based editor, you may be able to pipe the code directly to a local interpreter. The folks at Stypi made this easy:

# Just replace the URL (don't forget "/raw")
$> curl --silent https://www.stypi.com/raw/avand/interviews/reverse_polish_notation.rb | ruby
Loaded suite -
Started
.
Finished in 0.000427 seconds.

1 tests, 4 assertions, 0 failures, 0 errors, 0 skips

Be helpful, engaged, and bail candidates out of sticky situations. It’s easy to go into “spectator mode.” By actively following a candidate’s thought process you’ll better understand how they think and keep the interview on track. To stay engaged, introduce a big problem one small piece at a time, give examples of input and output, and point out potential bugs or edge cases as they come up.

Cut candidates off at the time limit, even if their work is unfinished. If you made it clear up front that you’re not necessarily looking for the correct answer, this should be easy. Change gears quickly to Q&A by asking them if they have any questions for you and wrap up the call from there. Great candidates have great questions that open up really interesting conversation. I like to indulge in good conversation, especially if the coding exercise went well. It helps me understand if the candidate would be a good mental and cultural fit.

Pull the plug if a candidate is bombing. Like going on a blind date, you may know within minutes that the candidate isn’t a good fit. I prefer to pull the cord immediately when this happens. I’ll say, “this isn’t going as I expected” and then site a reason (e.g., “we’re looking for folks that understand a language, not framework” or “a solid understanding of these data structures is really important to us”).

Finally, If the candidate is a no-go, give a good reason why. “We don’t think there’s a good technical fit” isn’t a real reason. Describing why a candidate is or is not a fit is hard but it’s worth doing. It forces you to objectively distill your thoughts, which will make it easier to discern other candidates. And it’s great feedback for the candidates too as they, no doubt, will learn from this experience.

Creating great technical interviews is a key piece of growing an engineering team. Doing it well means objectively screening candidates without tying up a lot of resources. Having sat on both sides of the interview table, I’ve found this approach to be a really good baseline. I look forward to reading your thoughts in the comments.

Snappy Dashboards with Redis

2012-10-15T00:00:00+00:00

It seems that almost every application I’ve worked on has some sort of dashboard component. It’s not usually the first feature but it often becomes the most useful.

But dashboards are hard to build.

They break resource-oriented design patterns and often rely on complicated one-off SQL queries. Dashboards also usually feature graphs and activity streams, both of which are not trivial to implement well.

At Sqoot, a local deal API, we have a simple dashboard for our customers. Given a time frame, it tells developers how many deals they’ve served (impressions), how many clicks they’ve driven, and how much affiliate revenue they’ve earned (earnings). It might also be interesting to know how many API calls they’ve made.

All of these stats follow a pretty standard query pattern:

SELECT COUNT(*) FROM collection WHERE USER = ? AND TIME > ? AND TIME < ?

This works great for small collections or well-indexed relational tables. For example, earnings are reported exactly like this. But enormous collections, especially when stored in document-centric databases, become slow to query. This is especially true if you have to join disparate data sources.

So we developed another way to store the counts we need. It’s a thin Ruby wrapper around Redis and we call it The Count (ah ah ah ah ah!). Here’s how it works.

For every stat we’re interested in, we set a few keys:

{stat}/year:{YYYY}
{stat}/year:{YYYY}/month:{MM}
{stat}/year:{YYYY}/month:{MM}/day:{DD}
{stat}/user:{id}/year:{YYYY}
{stat}/user:{id}/year:{YYYY}/month:{MM}
{stat}/user:{id}/year:{YYYY}/month:{MM}/day:{DD}

The first three keys tell us totals for all users by year, month, and day. The last three scope the same totals to one user. For example, if you want to know how many clicks user 5 drove in September:

REDIS.get("clicks/user:5/year:2012/month:09").to_i

You can also query across date ranges with the help of some Ruby:

REDIS.mget([
  "clicks/user:5/year:2012/month:06",
  "clicks/user:5/year:2012/month:07",
  "clicks/user:5/year:2012/month:08"
]).inject { |sum, i| sum + i.to_i }

Every time an API call, impression, or click happens, we update all the relevant keys at once:

REDIS.multi { keys.each { |key| REDIS.incr key } }

If Redis isn’t available, for whatever reason, we could rebuild the gaps from the canonical data in Mongo. We’ve never had to do this.

Now, when our customers load their dashboard, we don’t need to go slogging through millions of records. This makes our dashboards snappy. It’s also worth noting that this approach takes up very little space. If we segment by day, each year for each stat only uses 375 keys per user and another 375 for the aggregate data. The values are almost inconsequential since their just numbers. All our dashboard data is stored in this way with our friends at Redis To Go in a 20 MB instance.

Track Expenses in Google Docs via SMS

2012-05-14T00:00:00+00:00

Tracking expenses is a pain in the butt. At Sqoot, we use Google Docs for almost everything, including expenses, but entering anything on the go is cumbersome. Today, I got frusted and decided to take an hour and hack something together.

I wanted to be able to text something like this:

“35 Burgers with the team”
“420.15 Hosting costs”

Those text should become entries in a spreadsheet like this:

Description	Date	Amount
Burgers with the team	5/14/2012	$35.00
Hosting costs	5/12/2012	$420.15

Twilio

I had never worked with Twilio before but it was a cinch.

I set up a new account and funded it. For $1.00/mo, I got myself a phone number that I could start texting. Twilio will POST to whatever URL you specify when a text comes into that number. So getting texts into my app was basically done.

Eventually, I would also need to send back a confirmation text. Turns out that’s pretty trivial as well with the Twilio Ruby gem:

TWILIO = Twilio::REST::Client.new "twilio-account-sid", "twilio-auth-token"

TWILIO.account.sms.messages.create({
  to:   "from-phone-number",
  from: "to-phone-number",
  body: "Success!"
})

Google Drive Gem

After a little sleuthing, I found a Google Drive gem that would let me interact with our expense spreadsheet with just a few lines of Ruby:

require "google_drive"

session     = GoogleDrive.login("avand@sqoot.com", "would-you-like-to-know")
spreadsheet = session.spreadsheet_by_key("...")
worksheet   = spreadsheet.worksheets[1]
row         = worksheet.num_rows + 1

worksheet[row, 1] = "Burgers with the team"
worksheet[row, 2] = "5/14/2012"
worksheet[row, 3] = "35.00"

worksheet.save

This simply grabs the spreadsheet, opens up the worksheet, and adds a row with three columns to end.

Brioche

Finally, I wrapped up all this code into a very simple Sinatra app called Brioche. It responds to a POST to /expenses and expects the parameters Twilio sends over. Brioche then parses the body of the text, connects to Google Docs, and adds a row to a worksheet. Finally, it composes a confirmation message and sends it back via the Twilio API.

It doesn’t handle errors and you’ll need to set your Google password as an environmental variable on Heroku (shudder), but for an hour’s worth of work, it works pretty well!

Cheers!

Five Ways to Evaluate New Ideas

2012-02-18T00:00:00+00:00

It took six years for the novelty of building stuff to wear off. I’ve worked on huge failing corporate projects, cool weekend hacks, and successful startups. At a certain point, you’ve proved to yourself that you can build it. Now, what you’re building matters. So how do you become selective about the products you work on?

Real Fucking Problems

I have some friends from the management consulting world. You’ve probably sat next to one on a plane. They have IBM ThinkPads and crunch Excel workbooks for a project that is invariably behind and over budget. They travel a lot. They’re paid well. And, it seems that all of them want to start something. Bright-eyed and bushy-tailed, they ogle at Facebook, Twitter, FourSquare, Pintrest, Path–whatever’s hot and on the first page of TechCrunch. They’ll attend a StartupWeekend wearing the obligatory “idea guy”-colored T-shirt and pitch their idea: “I want to build a disruptive, mobile, social goal setting app”. Puke.

Wake up and smell the dehydrated single-serving crap you call coffee! If you’re serious about building something, tackle a real fucking problem. Delve into your vast reservoir of corporate experience and drum up every complaint, grievance, and suggestion you can remember. Bribe HR for access to the comment box if you have to! Those are problems people deal with every day. They pay money for solutions. Real problems are well-defined; a constraint you need to build a good solution.

Elegant

“Good design is as little design as possible.”

Dieter Rams, Braun

Real problems often have complex solutions but complexity isn’t something to be afraid of. Almost any time I’ve tried to explain how the web works, I’m stunned that it works at all. Sometimes to get this to go over there in that much time involves some wizardry. Don’t sweat it.

But at 30,000 feet, an idea should be elegant. Twilio: wrap up all the madness involved in sending texts and making calls behind a developer-friendly API. Heroku: make deploying a standard Rails app as simple as checking in your code. Uber: hail and pay for a black-car service from your phone. In mechanics, it’s possible to determine the motion of two bodies but the three-body problem cannot be solved. Reduce the number of variables and keep your product ridiculously simple and straightforward upfront.

Dough from Day One

“You have customers, they pay you money… you get profit!”

David Heinemeier Hanson, 37Signals, at Startup School in 2008.

If you haven’t thought about how your product will make money, your days are numbered. If “targeted advertising” or “freemium” are your biggest potential revenue streams, go back to the drawing board. It’s not that it can’t be done, but to succeed you need massive adpotion and engagement. Easier said than done. The glitz and glamor of bootstrapping wears off fast. When it does, have real money coming in the door.

What about raising capital? Without a jaw-dropping team or massive traction, you’re too early for most investors you’d actually want to take money from. Accelerators don’t present much more favorably odds either. Over 1,500 folks applied to the last round of TechStars in New York. They accepted 15. We haven’t even factored in YC or all the other teams that didn’t apply. Even though a ton of capital is being dumped into startups, you and your idea are up against a shit load of competition. If you have to draw a line that goes up and to the right, make it revenue.

Scratch Your Own Itch

Leverage yourself by solving a problem you have. When you really understand a domain you can spend more time building and less time gathering requirements. “When it’s all in [your] brain, it’s a perfect feedback loop,” says Jason Seats, co-founder of SliceHost. If you don’t use your own product, you’re completely reliant on feedback. “You have to construct artificial ways to get information.” You’re likely flying blind or moving too slowly.

Unfair Advantage

The expression “life isn’t fair,” isn’t totally accurate. Life is only unfair fair if you’ve got the short end of the stick. When I was at DreamIt Ventures in 2010, Josh Kopleman of First Round Capital gave us some tips on being better entrepreneurs. This was one of them. If you’re working on a big opportunity, so are others. Why you and not them? It may be someone you know, a patent you filed, or an exclusive contract you signed. You may simply have a killer team that can get shit done. Know your unfair advantages take full advantage of them.

That’s it! These are the five rules I screen all new ideas with:

Pick real fucking problems,
Find an elegant solution,
Make dough from day one,
Scratch your own itch, and
Take advantage of being advantaged.

As my good friend Michael Dwan, co-founder of SnapJoy, once told me, “ideas are like the bus… you miss one, there’s another right behind it.” Don’t take it personally if your idea doesn’t make the cut. You’ll make it to your destination faster by being selective about how you get there.

Serving Different Robots.txt Using Rack

2011-10-11T00:00:00+00:00

While doing an SEO audit for the daily deal API I’m working on, the subject of the robots.txt came up. In addition to our production environment (what you and everyone else see), we also use an “edge” environment. It’s a place we can push the latest and greatest changes and test them before they go live. Edge is an exact copy of production just running on a different domain. Since we didn’t want to get dinged with content duplication we had to disallow spiders from crawling our edge environment. Here’s how we serve different robots.txt files based on environment using Rack within Rails.

Move public/robots.txt to config/robots.txt. This is now your production robots.txt. Any other environment will disallow everything for all user-agents.
Create a RobotsGenerator in lib
Point /robots.txt to the generator in your routes

lib/robots_generator.rb:

class RobotsGenerator
  # Use the config/robots.txt in production.
  # Disallow everything for all other environments.
  def self.call(env)
    body = if Rails.env.production?
      File.read Rails.root.join('config', 'robots.txt')
    else
      "User-agent: *\nDisallow: /"
    end

    # Heroku can cache content for free using Varnish
    headers = {
      'Content-Type'  => 'text/plain',
      'Cache-Control' => "public, max-age=#{1.year.seconds.to_i}"
    }

    [200, headers, [body]]
  rescue Errno::ENOENT
    headers = { 'Content-Type' => 'text/plain' }
    body    = '# A robots.txt is not configured'

    [404, headers, [body]]
  end
end

config/routes.rb

require 'robots_generator'

YourApplication::Application.routes.draw do
  # ...

  match '/robots.txt' => RobotsGenerator

  # ...
end

Update (Sept. 23, 2013): Thanks to @michaelbaudino for pointing out that routes.rb needs the require 'robots_generator' since Rails 3 does not autoload files in lib. Additionally, the request headers should always include Content-Type to avoid a Rack::Lint::LintError error.

Make a 60 Sec Video Pitch in 500 Photos, $2 and 1 Day

2011-10-09T00:00:00+00:00

Often the hardest part of building a product is explaining it to people. If it seems complicated, most people just move along. A popular way to grab people’s attention is with a short video. They come in a bunch of flavors but the popular ones include 2D & 3D animations, screencasts and live action.

If you have the budget, getting one of these videos made is easy. Just plunk down about $5k, create a script or storyboard and out comes a video. But the rest of us have to come up with something on our own. Here’s how I created this 60 second video explaining Zippr in about 6 hours with a laptop, markers, paper, $2.00 and the Tron Legacy Reconfigured album.

</embed>

Ingredients

Markers: Simple Crayola will do.
Paper: 8.5” x 11”. The thicker the better. Loose leaf.
MacBook with iSight: Photo Booth is about to become your friend.
iMovie
Patience: Can be replaced with a great 3 hour playlist
External monitor, keyboard, & mouse: Optional but highly recommended for your sanity
Tape

Directions

Before you dive into the video production:

Write a script: You don’t have time to get into detail, so keep it short and sweet. Make sure you answer these questions for your customers: what’s in it for me, how does it work and what do I do next? Time yourself reading it outloud.
Create a storyboard: Divide a 8.5’ x 11’ piece of paper into 9 quadrants and sketch each “scene.” Get a rough idea of how long each scene will take to narrate. Each scene will end up what you draw on one piece of paper.

Now the fun part:

Set up your computer so the webcam is about 10 inches from a plain white wall. Plugin an external monitor and hook up a mouse and keyboard do you can see what’s going on while your computer is in timeout.
Adjust the angle and position of the webcam such that when you hold a piece of paper against the wall it fills up the entire shot. Mark the wall at the corners of the paper with a pencil.
Ideally, you’re in a well lit room. Set up lamps around your computer to provide a nice bright shot. More importantly don’t change the lighting once you start.
Start drawing. You’re going to draw a little bit (2-3 lines) then tape the picture up against the wall where you marked it earlier.
Take a picture.
Repeat steps 4 and 5 ~300 times. It sounds tedious because it is. Jamming out to a good playlist helps. This should take about 3 hours and I’d recommend doing it in one shot because ambient lighting can change. Verify your work after each scene to make sure you’re on track. Remember, you can’t go back and redo a scene without redrawing the entire page so take more pictures than you need.
Dump the photos into iMovie. Set all the clips to be ~0.1s. You should find that you have way more photos then you need.
Edit to your heart’s content. Delete clips, make certain clips longer, etc. Get it down to roughly the timeframe you set for your script.
Record the narrative. You can do this right from iMovie.
Spice it up with some music. My friend Darby pointed me towards Friendly Music. I searched for “whistle” and listened to about 20 songs before finding the Quirky by Benny Hawes. $2 later, I dragged the song into iMovie.

Nutritional Information

That’s basically it. You can export from iMovie to whatever file format you’d like. Then upload it to YouTube, Vimeo, or whatever.

Remember, your product will likely change (especially if you don’t have a budget for a “real” video). Stick to sketches and drawings instead of screenshots. Talk about benefits instead of features because features change. This way in 3 months when you’re doing something different, you don’t have to go create a whole new video.

Building an App to Monitor Your App

2011-04-28T00:00:00+00:00

Keeping a web application up and running usually requires lots of moving parts. Since these parts are all codependent, when the whole app goes down, the immediate question is: what broke?

I want to share with you the solution we came up with at Sqoot. Let’s dive right into the code and then talk about how we got here.

Diving Right In

We start with a simple Sinatra web app:

require 'erb'
require 'sinatra'
require 'active_support'

PROCESSES = [:solr, :memcached, :mongo] # ...can be anything

get '/' do
  # Ask each process what its status is (e.g., { :solr => true, ... })
  @process_statuses = PROCESSES.inject({}) do |memo, process|
    memo[process] = self.send("#{process}_up?")
    memo
  end

  # Set the response code to 200 if all the statuses are up
  status @process_statuses.all? { |k, v| v } ? 200 : 503

  erb :index
end

Then we just need a bunch of _up? methods to do the checking, like this:

require 'httparty'

def solr_up?
  solr_host = '...' # replace with your Solr server
  HTTParty.get("http://#{solr_host}/admin/ping").success?
end

In addition to Solr, we also make sure that Mongo and Memcached are running.

Finally, we need a couple endpoints for Pingdom to hit (e.g, /solr) so that we can check each service independently:

PROCESSES.each do |process|
  get "/#{process}" do
    @process = process
    @status  = self.send("#{process}_up?")

    status @status ? 200 : 503

    erb :process
  end
end

Add a couple trivial views, some CSS3 awesome, and voilà, you’ve got health.sqoot.com!

Taking a Step Back

The first thing we did to monitor uptime was point Pingdom at Sqoot’s homepage. We would perform some trivial check and when the site went down we dealt with a deluge of errors we couldn’t do anything about (e.g., Timeout::Error). Since we use Hoptoad to stay on top of application exceptions all these errors got really noisy. We also still didn’t know which dependency had gone down. We just knew the site was hosed.

We had to be able to monitor each service independently. So we created a StatusesController in the app that had an action for every service we wanted to monitor. The good thing was that we could now really introspect the process (like above) to make sure it was OK. For example, we might want to know that search is running and there are a certain number of documents indexed too. Unfortunately, if the status of one service changed, they usually all changed (due to requests queuing up, etc.). So we still didn’t have great insight as to what broke.

By creating a separate application that performed the checks, we were able to get detailed insight as to what services were running (or not). We can use Ruby to make each check meaningful and since it lives outside our app, it reports on each service exclusively.

Boom!

Tests Pass. You Fail.

2011-03-29T00:00:00+00:00

Shit breaks. It’d be so much cooler if things just worked the way we expected, but they don’t. For better or worse, we live in a world where everything eventually fails. And software is definitely not an exception.

So we write tests. If 1 + 1 should be 2, we make assertions that that’s always the case. Seems like an all-upside no-brainer.

But could your tests being doing more harm than good?

You Stop Looking Forward

Just because your tests look back doesn’t mean you should. In fact the exact opposite is true. As a developer you have to keep your head up, scanning the horizon for opportunities. Ideally, you’re looking for opportunities to make your product better. But even if you’re not responsible for the decisions that create happier customers, babysitting your test suite is still probably not the best use of your time.

If you’re interested in actually moving the needle, perhaps the better benchmark is not how often your tests pass, but how often they fail.

You Lose Sight of Your Customer

Passing tests are quite a high. Engineers are always looking for cold hard facts. Passing tests take the edge off: “I wrote code to solve a problem, and now this test I wrote proves that I really solved the problem!”

It can be a good thing. If the problem matters and the tests actually test the right things then it’s a great thing. But it’s easy to chase that high by writing tests that don’t test the right thing, test something that’s already tested or, worse, pass despite a feature that still doesn’t work correctly.

Don’t lose sight of your customers in spite of your test coverage.

You Fear Failure

The tolerance for failure is probably a lot higher than you imagine; your customer is probably much more forgiving than you (or your boss) think, especially if you handle it the right way.

OK, that’s not always true. If you’re engineering the rules for credit card approval, the launch sequence for a missle, or the internals of a pacemaker, most of this post is irrelevant. But if you’re like me, trying to break through to meaty part of the adoption curve, then isn’t the ultimate test simply feedback from your users?

If you think about your product from that perspective code coverage suddenly becomes less important. Are users signing up? Are they coming back? Are they raving fans? Is your product a vitamin or a pain-killer? Make those tests pass.

90% of coding is debugging. The other 10% is writing bugs

– @bramcohen

Show-stopping bugs are easy to prevent. At Sqoot we use a few tools that I consider just as important as rake test. Squawk, a gem I wrote that let’s our app tweet, gives us live feedback (good, bad and ugly). Pingdom hits our endpoints every minute to ensure uptime. Hoptoad is invaluable to trap and report on errors.

So I say release some bugs! The benefit of being 10-20% more nimble over the lifetime of a project totally outweighs the cost of breaking things from time to time.

You Slow Down

No matter how lean and mean you think you are tests are a process and process can slow you down:

Chasing 100% coverage: Once you start testing, you don’t want to stop. Untested code becomes a second-class citizen. But that’s fine! Not all code is created equal.
Calcification: Deleting code is awesome, but when it’s tested, you think twice. This is especially true when you’re new to a project.
You become the customer: Tests are one part of your app where the customers are other developers. It’s easy to get lost in a world of tools and process. Unless you’re GitHub, your product is probably not other developers.

“New process is reluctantly introduced only right before the point where things tip into chaos”

– Yishan Wong on Facebook

Now, Before You Roast Me on HN…

By this point, I’ve probably ruffled some feathers. So let me be clear that testing isn’t all downside. There are several critical reasons you have to test:

Implementation first thinking: When you write tests you end up thinking about how other parts of your application will use that code. This means less refactoring down the line.
Free regression suite: Rarely do engineers go back to test untested code, so it’s good to know that the feature you built works now and will forever. This is especially true for teams.
Framing the problem: Originally for PiggyBack.it, I built some code that balanced debts between a bunch of people. To think about that problem conceptually would have taken me forever to solve. By laying out the expectations first, the solution came naturally.

See, even I write tests!

Loaded suite /Users/avand/.rvm/gems/ruby-1.9.2-p0/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
..................................................................................................................................................................................................
Finished in 5.778192 seconds.

194 tests, 290 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 50633
Loaded suite /Users/avand/.rvm/gems/ruby-1.9.2-p0/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
..............................................
Finished in 13.691397 seconds.

46 tests, 56 assertions, 0 failures, 0 errors, 0 skips

If you’re saying to yourself “13 seconds to run 46 tests is slow,” you may want to re-read this post or double-down and check out riot.

Happy Customers are All That Matters

I don’t enjoy writing code for code’s sake. It’s ironic to think you might even evaluate a software engineer by the code he doesn’t write. Coding is fun, it’s addictive and it’s a bit hypnotic. So you have to be really careful that the code you’re writing actually matters!

Are you making your customer happier?

If the line of code you’re working on doesn’t answer that question with a huge “yes” then you’re probably wasting your time.

Managing Styles with Sass on Heroku

2010-09-15T00:00:00+00:00

I’ve generally found stylesheets to be the messiest part of any website. And I’m not surprised:

Cross browser support means kludgy code
Functionality usually takes the drivers seat to well thought out styles
It’s someone else’s job

But organizing styles doesn’t have to be a mess and here’s one strategy that may make your life easier.

But First…

Since REST became the de facto way to design Rails apps, I’ve focused on organizing stylesheets by the same patterns. It just seemed natural that if you had a folder /views/users/new.html.erb you should have a similiar folder /stylesheets/users/new.css. Back in 2008, I wrote a two part post on how to do this nicely with Rails. Three years later, I’m not the only one who thinks that this is a decent idea.

But CSS has grown old and weary and is in desperate need of an update. Sass is clearly a more expressive way to define styles.

So, it seemed like a great time to refresh the way I manage styles in my Rails apps.

Why Start from Scratch?

Simply put, this was a pain in the ass. Why was it harder than it should have been?

I’m masochistic: I wanted it to work a certain way. I didn’t want to wrangle with a bloated framework or sacrifice on simplicity.
Heroku: Heroku has a (mostly) read-only filesystem. Waaa, waaa!. Since Sass needs to be compiled, this poses a bit of a problem. There are a few workarounds that involve serving CSS from /tmp, but I didn’t want a hack.
Organization: I resisted Sass for a long time. I think by just organizing your selectors you can get a lot of the same benefits. My new setup had to have the same clarity.
Packages: Everyone should know by now that the HTTP overhead of requesting multiple CSS files degrades client performance. But you can’t just pile them all into one file because you need to separate styles for print, screen, IE, or mobile. This problem had a solution, but not with Git based deployments on Heroku and the Amazon S3 workaround sounded like trouble.
Javascript: Javascript and CSS are very very different. I wanted my solution to organizing styles to inspire the way I manage Javascript, not muddle it up.

Seriously, it shouldn’t be this god damn complicated.

FTW!

Sass: I was commited to porting to Sass, specifically because you don’t have to rewrite all your CSS to get started. Scss plays nice. It’s part of Haml, so throw it in your Gemfile:

gem 'haml', '3.0.18'

Migrate your CSS to Scss: Using the command line tool sass-convert I migrated all my CSS to Scss. I know it needs a lot of refactoring to take advantage of Sass, but I’ll do that later.

$> sass-convert source.css destination.scss

Organize: I wanted stylesheet packages to be derived by how styles were organized - not by a configuration file. So while it made sense to have the Sass files live next to my erb (remember, I have a one-to-one mapping of styles to my templates), Chris Powers noted that it was cleaner to store them in /app/stylesheets/:package/. For me, :package was just “desktop.” Later, I can easily create packages called “mobile,” “print,” or “ie” if I need to. See?

Use Rack to do all the heavy lifting: Compiling Scss isn’t hard. Concatinating all the stylesheets isn’t hard either. Ryan Bates’ 222nd Railscast helped me write a Rack application that does the work:

class AssetsApp < ActionController::Metal
  include ActionController::Rendering

  def stylesheets
    @output = ''

    Dir.glob("#{Rails.root}/app/stylesheets/#{params[:package]}/**/*.css*") do |filename|
      sass_options = { :syntax => :scss }
      sass_options[:style] = :compressed unless Rails.env.development?

      @output += Sass::Engine.new(File.open(filename, 'r').read, sass_options).render
    end

    response.headers['Cache-Control'] = "public, max-age=#{1.year.seconds.to_i}" unless Rails.env.development?
    response.content_type = 'text/css'

    render :text => @output
  end
end

Add the route and reference it: With Rack doing all the hard work, I just point to it:

Sqoot::Application.routes.draw do |map|
  match "/stylesheets/:package.css" => AssetsApp.action(:stylesheets), :as => 'stylesheets'
end

<%= stylesheet_link_tag stylesheets_path(:package => :desktop) %>

All together now!

Instead of 15-some stylesheets being downloaded at ~50 KB, now I send the client one 8 KB file.
No writing to disk! So Heroku’s happy.
Varnish leverages HTTP to cache the compiled CSS.
I can sleep again because all my styles are now served in one tight bundle.
You get a nice free gist of the code to try for yourself.

UPDATE: I presented on the topics of this post at Chicago Ruby and Refresh. The video and slides are now available online. (May 1st, 2011)

The Four Hour Sprint

2010-09-08T00:00:00+00:00

If you want to talk about themes that have dominated the last year of my life, “agile” has got to be one of the most popular. It seems that everyone wants to be agile, and there’s a lot of debate about what that means, if anything. Agile software development is a group of software development methodologies that are based on iterative and incremental development. It comes in a variety of flavors, the most popular being Scrum.

If you’re familiar with Scrum you know the common traits:

Release often: Success if based on shipping working product.
Don’t release crap: Trim back the features and release something that works well, both for you and your customer.
Iterate: This week you’ll do X, next week you’ll do Y, even if that means undoing X.

The mechanics of a successful agile team vary, commonly differentiated by the length of a sprint or iteration. After much tweaking I’ve found that the shorter the sprint the better. I’m currently working in four-hour sprints and here’s why you should too.

Incedental Reasons

Four hours is about the amount of time you can spend in Starbucks without your ass going numb.
Four hours is about the amount of time you can actually focus. Hunger is usually my biggest distraction.
Four hours is about the amount of time your laptop battery will last without re-charging.

For Realzy Reasons

You have to manage scope: When you measure your sprints in hours - not days - you have no choice but to seriously question the scope of what you’re doing. You have to ship something! So, get your shit together.
You can’t write garbage code: Let’s face it, how much damage can you do to a codebase in four hours? If tests have to pass and a deployment has to happen you just don’t have time to fuck around.
You’ll get realistic: Constraints breed creativity. You’ll come up with incredible solutions to deliver on your deadline.

I know, this won’t work for everyone. I’ve worked on projects where simply deploying was a four hour task in and of itself! That’s garbage. If this is you, put “make deployments easy” at the top of your to-do list. Maybe your part of a bigger team, where coordinating deployments can get tricky. Work towards building a team of branching ninjas that can compartmentalize features and releases.

We’re very simple creatures. Most projects, probably the one you’re working on right now, go over budget and over time. That’s because, as humans, we grossly overestimate what we’re capable of actually accomplishing. Don’t fight it! Break things down into chunks you can actually handle.

School's Out Forever

2010-02-17T00:00:00+00:00

Growing up, I was told that the most important ingredient for my future was an education. Do your homework, study hard and the road ahead will lead to a satisfying career and financial security. That was the promise, anyway. But as it turns out, in the kitchen of education, I cooked up concoction that would make even Andrew Zimmern cringe.

I went to high school at Boston University Academy, a prep-school that essentially guaranteed a fast track through college if you just played by the book. I didn’t play by the book. In tenth grade I was held back and junior year wasn’t any more promising. My teachers begged me to study, explaining to my parents that I just wasn’t applying myself. On the night of my last and deciding final of 11th grade, I sealed my fate watching a Seinfeld marathon. Clearly, getting through high school was going to be more trouble than it was worth.

When I came back from camp that summer, I was shipped to Chicago and the very next morning, in slacks, shirt and tie, reported for an internship at a financial company in the Loop. It was a complete correction of my downward spiral and the beginning of my career as a software engineer. I completed my GED and started taking night classes at DePaul. By my sophomore year, I was in the top of my class.

Everything seemed copacetic until I dropped out.

When School Works

It was an issue of motivation. When I’m told to do something, I ask why. If I don’t like the answer, I push back, and, depending on my conviction, will eventually just refuse. Turns out that up until college you don’t have much say in what you learn. Ask why and eventually the answer boils down: you don’t have choice.

I think that’s bullshit. A lot of what I was told to learn was, in retrospect, totally practical. Study a language and you’re given the power of self-expression. The sciences teach you how to manipulate the world around you. History explores human behavior, geography and politics. These are the types of answers that may have satiated my interrogation of academia and could have motivated my intellectual curiosity.

But reflecting on all the classes I’ve ever taken, there were many that were just arbitrarily required. Especially at $190/credit, it makes sense to keep you in class. School works when a student is motivated and motivation is fueled by purpose.

When It Doesn’t

When I started working, the paradigm completely changed. Now, I was motivated by a paycheck, a career, and my peers. I enjoyed what I was doing and was solving real world problems. Everything I did became practical (although often equally pointless).

It made sense to start taking classes again with this new found motivation and focus. I would spend two nights a week at DePaul, hacking away at a Computer Science degree. I was learning a lot but at a price.

In the age of information, where a good (free) search can yield more about a topic than you can learn in an entire academic career, that becomes a steep sacrifice. Then there’s opportunity cost. My classes ate into precious time I would otherwise spend learning on my own projects. With no other obligations and boundless energy, these years are quite arguably the most valuable of my life.

By the time my peers graduated, I had 4 years of work experience and was cashing in on it. I had come out ahead. I’ve never had a career opportunity jeopardized by an incomplete degree and I’m humbly optimistic that it never will.

Get Real

Ask ten people in your office what their degree is in and I bet at least half of them admit to something completely irrelevant to their job. Now ask them if they’re really passionate about what they do.

What if they had spent their four college years doing internships, traveling and searching the world for a calling that really fires them up? What if they had taken the fifty grand (or more) it took to graduate and had instead started a business, or two, or three? What if high school was an accelerated 3-year program followed by a 1 year intensive “real-life lessons” program covering topics like real estate, incorporation, financial management, insurance and law?

Of the four-man engineer team I was last a part of, only one had a degree and was, fittingly, the weakest member of the team. That’s how it works in the world of software. It should work for other fields, too.

There’s a lot of great things out there to learn, but theory is one thing and practice is another.

What About You?

Fill out my Wufoo form!

Update (August 1st, 2010)

Since writing, I’ve found several articles regarding the flaws in the academic system. Marty Nemko of U.S. News describes one’s undergraduate education as America’s most overrated product. I thought it was worth highlighting some of my favorite points:

“What percent of students would you guess graduate from college within six years? Forty percent. Six out of ten never graduate.”
On the social value of attending university: “Fact: 27% of all undergraduate students binge drink regularly”
“We need to capitalize on students’ desire to learn what they’re excited about and motivated to learn at that point in time. When kids are at eighteen or twenty, they’re at their most idealistic. It’s a great time to teach them about things that are going to foment that idealism. It’s a great time to teach them about relationships. It’s a great time to teach them about careers.”
“Colleges produce a shoddy, overpriced product and it’s time we held them accountable.”

Getting It: What Makes a Great Software Engineer

2010-02-08T00:00:00+00:00

Introduction

I’ve been writing code for a while now and for about the last 2 years there’s been a nagging question in the back of my head:

What makes a great software engineer?

Call them “rockstars”, “ninjas”, “submarine pilots” or any other catchy title you’d like. They exist, and they’re dangerously good at what they do. Let’s emphasize dangerous there, because right next to them is a second bucket. You’ve probably hired them, or worked with them - there might be one sitting right behind you. These guys know what they’re doing but seem to be lacking something; somehow, everything they work on seems incomplete.

For lack of better semantics, my friend Michael Dwan and I have always said that the ninjas just “get it.” In suit, I think it makes sense to refer to them, collectively, as the “get-its” and the latter as the “get-nots.”

Wait, Why Engineer?

engineer |ˌenjəˈni(ə)r|, noun: a person who designs, builds, or maintains engines, machines, or public works.

After reviewing the attributes I identified that make up a great software engineer, I realized that they are in many ways common to all engineers. And although software is my trade, I thought that abstraction warranted exploring.

Code for Codes Sake

Car analogies work really well to conversationally describe software applications, but I’m going to use the metaphor of a carpenter to describe our quintessential developer.

Initially, you have your newbie, who barely knows how to hold a hammer properly. If you told him to build a house, he’d have no choice but to defer. But an experienced carpenter, someone whose built a few houses in his day, would be comfortable taking up a spot behind the table saw and getting right to it.

But there’s a third category - let’s call him “qualified.” He’s just as comfortable as the expert behind the table saw. But he doesn’t quite get it. He lacks the mastery of the expert and as a result mis-measures, recuts, rebuilds, and so on until he’s got his shoddy house standing.

Software is exactly the same - only worse. It’s way easier to type rails superfluous-app than to fire up the saw and cut a piece of wood. And there’s a lot of get-not’s in the workshop, just keystrokes away from leaving 100’s of lines of scraps strewn about the floor.

The master knows that the best cut is no cut.

Drawing a Line Between Done and Done Right

</param> </param> </embed>

Now you’ve got your house built. Maybe it looks a bit like Ned’s after the Simpson’s neighborhood chips in and rebuilds it, but hey, at least it’s standing.

As with the carpenter, a software engineer can fall anywhere on the skill ladder. Just go to your local Borders and spend a minute walking down the “Computers” aisle. There’s no shortage of well written, opinionated instructions on how to write code.

This is where many of the get-nots thrive. They’ve got a site up, but instead improving the experience, they migrate databases. They boast that their application has 100% test coverage, but it’s not live. Their server clusters are capable of handling gagillions of requests per second, yet actually respond a few times per day.

The get-its, in contrast, focus on the finished product. A get-it will systematically and holistically tackle each problem in the way of that goal, tactfully embracing the constraints and imperfections along the way.

Changing the Future

Think about the last time you saw a master at work. Someone that’s just qualified goes through often obvious and intuitive steps to get the end goal. But the masters ways are much more enigmatic, maybe skipping steps or starting with something that seems like it logically belongs at the end.

That’s how the get-its work. They’ll read a simple feature request and think through the ramifications it has on the whole project. A get-it will think through a problem and solve it quickly with an eye for what else is going on and what might be soon to come. I read somewhere that the most successful people don’t manage their time, but their priorities. A get-it can always answer the question: what is the next most important thing?

Get-its don’t just challenge the products their working on. They also challenge their tools. If it sucks, they build a new one. If they don’t like the way so-and-so library handles bla-bla-bla, they make it better and then share it with their peers. They’ve got their heads up, listening to other get-its, and are always a little uncomfortable because they understand that the only definite is that something’s about to change. The best of them are the catalyst for that change.

Integrating Twitter Authentication with Rails

2010-01-13T00:00:00+00:00

I’m working on a project called Piggy Back, a simple service where friends can keep track of debts between one another. To encourage user registration, I’m lowering the barriers, allowing users to sign up their Twitter and Facebook accounts. I’d like share with you how I got this functionality into this Rails app. A shout out to Chris Powers and Jeff Talbot for their feedback along the way.

Eliminating Plugin Magic

I needed to get my hands into the authentication code if I was going to allow Twitter and Facebook integration. I was using Authlogic and could have extended it with other plugins to give me this support, but I wanted the process for my users to be as seamless as possible. I knew this would probably involve some Piggy Back specific customizations.

Furthermore, I was actually only using about 20% of the functionality Authlogic provides. I had “magic columns” (last_logged_in_at, failed_login_count, etc.) because they were free, but I didn’t actually need them.

Finally, making it possible for users to sign up with their Twitter accounts meant a user record with no email or password, fields Authlogic required. There were likely workarounds available, but that meant hacking Authlogic, not working on my app.

Hand Rolling Authentication

Authentication isn’t complicated. I liberated the heavy lifting cryptography algorithms from Authlogic. Obviously, it was important for me to use the exact same algorithm in my own system. Then I got inspired with Jamis Buck’s Bucketwise project and prepped my user to be authenticated.

See the code!

Authlogic encourages you to use a UserSession model which lends itself to restful design, but I found it much easier to just create two actions on my SiteController that simply responded to GET requests. Originally, I had used require_authentication as a before_filter, so I ported those over to the new system as well. Check it all out in the gist.

Now, Let’s Get Twitter Up in There!

Twitter supports OAuth authentication. It’s a little trickier to implement than basic HTTP authentication, but isn’t terribly complicated. Your application, the consumer, gets a couple tokens, which you exchange for request tokens. Then you use the request tokens to do what you will with Twitter, including obtaining access tokens to, well, access users accounts.

There’s a lot that OAuth does and I wasn’t prepared to start from scratch, so I installed the oauth Ruby gem and included it into my application. I also added 4 columns to my users table to store the Twitter information, twitter_id, twitter_handle, twitter_token, and twitter_secret. My user validation rules adapted to this change to, permitting users without emails or passwords in favor of these attributes.

You need two actions to support Twitter OAuth. One to start the request and the other, known as the callback, to finish it. In examples, these actions are nestled in among other controllers, but I decided for clarity to create a standalone TwitterController.

It’s a bit too large to embed here, but you can still take a look at the TwitterController.

The trickiest part was actually making the workflow seamless for all the users. I’m referencing comments in the TwitterController:

A new users comes to Piggy Back and creates an account by logging in to Twitter. (C)
An existing user comes back to Piggy Back and logs in via Twitter, but:
Piggy Back doesn’t now about their Twitter account and the two must be linked (B) or
Piggy Back knows about their Twitter account and logs them in (A).

To get this split behavior, I simply altered the callback URL that Twitter uses to return flow back to the application. This was simple enough with two named routes:

map.with_options({ :user_action => 'create' }) do |twitter_map|
  twitter_map.twitter_oauth '/twitter/oath/:user_action', { :controller => :twitter, :action => :oauth }
  twitter_map.twitter_callback '/twitter/callback/:user_action', { :controller => :twitter, :action => :callback }
end

To handle the case where accounts may be linked, I store the users Twitter attributes in session for a moment, while I redirect to my SiteController#login action. Here, the user is asked to login specifically to link their account to Twitter. Jeff Talbot offered great feedback about this workflow, suggesting that anywhere there’s a “Sign in with Twitter” link, it should just seamless create a users account. This creates a problem for existing users, however, where they could easily end up with two accounts. To solve this, I’m adding a big button to this login page, “Don’t Have an Account, Create One Instantly.”

Conclusion

So many web apps need to do exactly what I spent Monday doing, so hopefully you can reuse some of the strategies I implemented here.

Chris Powers asked if I thought this could be pulled out into a plugin, and I’m sure the answer is yes. However, it’s not a lot of code and there’s a lot of customizations your app will need within the areas I commented out. I’m not a control freak (I did, after all, convert from C# and ASP.net), but I do believe there is value in controlling your apps code.

References

Instantly Losing a Customer

2010-01-11T00:00:00+00:00

A while ago, I wrote a post about great customer service, where it’s coming from and where to find more of it. Today, I’d like to take a look in the other direction and talk about the biggest mistake a business can make: losing a customer.

I’ve used 1-800-flowers.com for several orders over the past few years. Although the majority of the orders were unfulfilled or late, I sympathized with the company’s position. They’re stuck as the liaison between me, the over expecting customer, and any number of questionable florists. Every time there was an error, I was able to get my money back, although I often had to fight for it. I would never expect them to get every order right, but as you’ve probably experienced, it’s so easy to win back a customer whose had a bad experience with stellar customer service. 1-800-flowers.com certainly left something to be desired.

I wasn’t planning on using them again. I’m single now, so I have no immediate floral emergencies. But today, I’m vowing to never again use their service, no matter how long I’m in the dog house. Today, marks the decisive end of my business with 1-800-flowers.com. Today, they crossed the line between business and consumer that I once thought was far less demarcated. Today, I received this in the mail:

At first, I thought, interesting, perhaps they caught an error in the last transaction I had with them and were sending me, much to my surprise and satisfaction, a check to correct the error. I opened it, still skeptical that it was likely a scam, yet was lured even further into believing they were in fact sending me cash. For all intents and purposes it looked exactly like a real check. And it was. Except that when you deposit this check you’re actually purchasing a membership. To make matters worse, it’s a membership in a 1-800-flowers.com affiliate.

I was appalled. I don’t expect stellar customer service from every company, but this absolutely crosses an ethical boundary. My mother often calls me to ask how she can claim her prize for being the 1,000,000 visitor to a website. If she had received this piece of mail, she would have cashed that check. There’s no way she would have caught the fine print, or would have even been able to read it.

The poor service and lack of customer care I can tolerate - maybe even expect - but this is the first customer interaction I’ve ever witnessed that proactively lost a customer.

Often the line is not so clear. Take, for instance, the placement of ads on a website. Most consumers have come to tolerate a moderate amount of advertising in their lives. Ads often do pay for the subsistence of many sites on the web. But it’s crucial to constantly ask: does what I’m doing make the life of my customer better. Forget about how much you can get away with. Certainly dismiss any idea that could possibly drive a customer away!

It’s a honor that your existing customers even work with you! Appreciate their contribution to your business and rather than kill the golden goose, focus on getting the next one.

The Big Bang Rewrite (Part 3): Authentication, Authorization, and Tests

2009-12-20T00:00:00+00:00

One of the biggest deficiencies in the old application was being able to lock down access to the site based on users. Originally, there were two special users, Admin and Guest. The former had complete control, the later had none. Anyone else was a normal user and had the same level of access.

Since we have an opportunity to build this right from the ground up, we explored 3 levels of access control:

Authentication: Actions behind this layer of protection, first, require a user to be authenticated.
Authorization: These actions assume a user has been authenticated but determine whether they have access to perform the requested actions.
Permissions: Assuming the first two layers pass, does the current user have permission to perform that action to that object?

I’ll go into the details of each section, then describe our testing strategy.

Authentication

Step one: plug in Authlogic. This did a huge majority of the heavy lifting for us to ensure that a user session was persisted request to request.

Let’s take a look at some of the helpers in our base controller, ApplicationController:

protected

  def require_authentication
    raise Exceptions::Security::AuthenticationRequired unless authenticated?
  end

private

  def authenticated?
    !current_user.nil?
  end

Our custom exception Exceptions::Security::AuthenticationRequired is systematically caught and returns a HTTP 401. Piece of cake. To lock down a controller now, we simply add a before_filter to the actions we’d like restricted to users that are logged in.

Authorization

Authentication was easy, but now that we know we have a user, should they be able to hit that action? To the end user, or a business analyst these may seem like the same question, but as a developer I think it makes sense to separate the concerns.

Because we followed REST conventions in this application, the abstraction for authorization was self apparent: restrict access on a controller/action basis. So we created roles which stored sets of controller action pairs. Then add another before_filter just like only a bit different than our authentication layer.

protected

  def require_authorization
    raise Exceptions::Security::AuthorizationRequired unless authorized?
  end

private

  def authorized?
    # authorized_for just checks to see if that key value pair exists for that user based on their role
    current_user.authorized_for?(self.controller_name, self.action_name)
  end

Just like authentication, we add a before_filter and catch the AuthorizationRequired exception, returning a HTTP 403 response to the client.

Permissions

Our entire authorization system now covers us up to the controller action. But there’s still one more step. Does that user have permission to do that action on a particular object. In our case, can a user edit a specific business?

What we have actually looks a lot like Ryan Bate’s CanCan plugin.

Testing

My feelings on testing are a subject for another discussion, but in a nutshell, I believe it’s crucially important to test permissions. I think the reasons are obvious. But testing permissions can be a real pain in the neck.

We use Shoulda to assist our testing process for two reasons. Firstly, we enjoy the dry-ness and organization of contexts. Beyond organization, however, the macros allow your tests to be very expressive while staying super clean - this is especially true of controllers. As you can see in the samples below, however, we avoid the stresses surrounding assertion readability with breadcrumbs (e.g. a User unit test might read, “validations > first_name”).

As discussed above, each user belongs to a role. To satisfy our authorization layer, a role then specifies which controllers and actions may be accessed. So we need to be able to systematically hit all the controllers and actions that require authorization with each role and assert the appropriate behavior.

This could easily get out of hand:

class UsersControllerTest < ActionController::TestCase
  context 'GET to show >'
    context 'as an admin >' do
      setup do
        login_as :admin
        get :show
      end
      
      should_do_all_sorts_of_great_stuff
    end
    
    context 'as a business owner >' do
      setup do
        login_as :business_owner
        get :show
      end
      
      should_do_all_sorts_of_great_stuff
    end
  end
end

There’s a few issues here. First of all, there’s a lot of duplication. More importantly, we duplicate the get, which is really a common procedure to all these tests. Secondly, we’re retesting that this action should_do_all_sorts_of_great_stuff and binding those assertions to the setup of the test. Gross.

Shoulda controller macros encourage you to avoid duplicating the setup block over and over again, so I dove into creating a custom macro, designing it by implementation first:

class UsersControllerTest < ActionController::TestCase
  context 'GET to show >'
    setup do
      login
      get :show
    end
    
    should_authenticate
    should_authorize :admin, :business_owner
    should_do_all_sorts_of_great_stuff
  end
end

So, much better! But how to make that work?

class ActionController::TestCase
  def self.should_authenticate
    should 'authenticate', :before => lambda { logout } do
      assert_response :unauthorized
    end
  end
  
  def self.should_authorize(*role_names)
    role_names.each do |role_name|
      should "authorize #{role_name}", :before => lambda { login(role_name) } do
        assert @response.response_code != :forbidden
      end
    end
  end
end

Very cool, but if you’ve been paying close attention there’s one more method I haven’t touched on yet, login. Let’s take a look at the test_helper.

def login(arg = nil)
  if arg.nil?
    unless @skip_next_login
      @controller.expects(:require_authentication).returns(true)
      @controller.expects(:require_authorization).returns(true)
    end
  elsif arg.is_a?(String) || arg.is_a?(Symbol)
    @controller.stubs(:current_user).returns(Factory(:user, :role_name => arg.to_s))
    @skip_next_login = true
  end
end

This helper is probably the most robust part of the entire test. If you pass nothing in, as we do in the setup block, it will simply fake it. This is great because the assertions become oblivious to the authorization mechanism. Sweet. But the authentication and authorization assertions do care, so we give ourselves the option to login as a specified role. Our should blocks utilize the :before option to perform the login before anything else happens. Importantly, though, it sets a flag so the second login call (the one in the original setup block) doesn’t then screw things up.

Go back to part one or two.

The Big Bang Rewrite (Part 2): API First

2009-12-13T00:00:00+00:00

As I discussed in my previous post, rebuilding Fave was motivated entirely by the desire for better data. The core focus was not rapid front facing development, but almost entirely back end work. In essence, we started with our API.

One of the features Rails boasts as an application framework is that out of the box, it lends itself to API support. Every controller/action that is generated includes responses for XML based requests. I would challenge most applications to try and publicize an API using the default Rails setup. It’s likely not even close to the end result you’d expect. But that’s OK - no application framework should satisfy that expectation.

At first, our API, was script/console. But, of course, that only got us so far. With our new data model, objects that used to be represented as one were now two three or four different objects. We had normalized our data - aware of the penalties and overhead that would haunt us along the way.

As a result of this normalization, we make heavy use of virtual attributes. It had to be possible to create a Business with one HTTP POST. Phone numbers on businesses, for example, work like so:

class Business < ActiveRecord::Base
  attr_writer :phone_numbers_attributes # [{ :area_code => 312, :exchange => 123, :suffix => 3333 }, ...]
  
  before_validation :set_phone_numbers_from_virtual_attribute
  
  private
    
    def set_phone_numbers_from_virtual_attribute
      @phone_numbers_attributes.each do |phone_number_attributes|
        self.phone_numbers << PhoneNumber.new(phone_number_attributes)
      end if @phone_numbers_attributes
    end
end

In some places take advantage of accepts_nested_attributes_for, however, we found it wouldn’t play nicely with polymorphic associations and were uncomfortable with unknowns it introduced. We’ve found it’s best to write it yourself first, then find abstractions and helpers on a need by need basis.

The controllers, all the meanwhile, have remained “skinny” in spite of complexity. We’ve rigorously moved logic down into the model layer so that the various security components would be the only core responsibility for the controllers. I will go into detail with our approach to security in the next post.

We needed to get data into the application as quickly as possible. As a result, we spent time on an application to simply wrap up the HTTP side of things. It enabled us to create a hash on one end that represented the structure we desired, make the post to the server, and end up with a usable object on the other end. In some ways it is a lot like ActiveResource, and in fact we made enormous progress simply using ActiveResource. But again, our needs grew.

For the longest time, the views of the new site were simply a wrapper to the API. The majority of the teams effort was building the API and other scripts/applications that consumed it. This made for quite a refreshing approach to views, which I’ll discuss in more detail in a later post. The API had forced us to think about what data inputs and outputs were core to the application. It satisfied all the application’s needs first. We no longer had to include messy scripts into our application that relied on directly interfacing with our models to import data. Everything consumed the API. Even the views simply consumed that core data.

All things considered, the API first approach is not one I would recommend to everyone. At Fave, our data is completely core to our business and as a result it seemed appropriate and has paid us in dividends. A site like Piggy Back has far simpler data structures with the user interface demanding much more focus. In this case an “API first” approach would likely be the wrong choice. Although even there I will note that through the process of making the interface more accessible, for example from an iPhone or mobile device, I was forced to clean up my controller and think harder about what data they should and should not be passing in and out. It’s an exercise that every developer should practice and one that has become our regiment at Fave.

Go back to part one or read part three.

The Big Bang Rewrite (Part 1): First Ask Why

2009-12-07T00:00:00+00:00

When it comes to building something, be it a building, a car, or software, there are always imperfections. The first iteration is usually something simple, but eventually as features are added and requirements made more complex, the system starts to become bloated. Even with great agility and the most stubborn resistance to scope creep, technology changes so rapidly that immediately, often even before its conception, a product is out of date. It’s a fact of product development; it’s a fact of life. Change is the only constant.

This frustrating realization means that a tabula rasa is a rare find indeed. Realistically, the majority of our time is spent just making sure that progress doesn’t break what already works. This curve is exponential, such that eventually the smallest of alterations is painful, time consuming, and dangerous. The alternative, a rebuild, does not offer a much better promise as it consumes massive amounts of resources, with little front facing change.

So, when do you know to start over?

At Fave, I was faced with this same question with the development of getfave.com. The product, architecture and design requirements are simple but, when handling massive amounts of data, represent unique technological challenges. The site has also seen an enormous growth in traffic, straining the application to its limits. However, the application was weakest in the face of the company’s own desire to innovate. We wanted to push the envelope farther than our competition and offer more value to the consumer. The current product just wasn’t good enough.

We had to ameliorate the situation and it came down to a tough call: start from scratch, or plow on with what we had? This decision hinged on how we defined “better.” If the current site was deficient, what was it missing and what did it need to be complete? Initially, these answers were elusive - amazingly, you can ride out “better” for a while. We continued with the old application, deploying changes iteratively in the pursuit of minor progress. Frustrations mounted and eventually we pushed against the stakeholders hard enough to solidify a tangible goal. We finally could sum up it with two words: better data.

Although Fave relies on outside vendors for the bulk of our data, we’ve come to realize that its integrity is of utmost priority. We wanted to open our arms to as much of it as possible, but know that it is the most accurate in our market. This meant a major refactor to our data model - every core structure had to drastically change. This also meant exposing the data model to outside vendors in the form of an API. With the greater exposure would also come the need for tighter security. Each action on the site had to be locked down to specific roles. We of course, had much of this support already, but it left much to be desired. If our data was going to be accurate, we would have to have fine control over who was changing it. Better data also meant we had to track changes to businesses over time with a versioning system and human review process. Finally, if we had great data we had to be able to find it - our search engine, too, fell in the cross hairs.

As we filled a whiteboard with requirements, it started to become apparent that we were standing in the shadow of an enormous endeavor. Everything hinged on many very invasive changes to the structure of the data which represented huge risks to the stability of the site. It was no longer a technical change, but a much more fundamental change in focus for the whole company. With a clear goal of superior data, we start shedding extraneous features. Soon the concept of starting from scratch became manageable.

Read part two or three.

Rebuilding a Brand. Avand.

2009-11-22T00:00:00+00:00

Once again, it’s been months since my last post. I’ve been taking some good and some bad classes at DePaul for the last 10 weeks and as a result haven’t really had much time to invest in myself. Even Piggy Back has taken the back burner. The one personal priority I did get around to was my new website avandamiri.com. I thought I would take a moment and reflect on the motivations, goals, and end results of the process.

Motivations

I’ve always wanted a web presence for myself. Unfortunately, I suffered from the same shortsightedness that many of the clients I’ve worked for have had in the past: simply wanting a website isn’t enough. From day one I broke my own rule to start with content first.

Back in the day, I had a Blogger account, “Simple Things.” The process of posting was frustrating and I never liked the look of the template I had. It worked for my posts but it said absolutely nothing about me. It also annoyed me that all my posts were out in some database somewhere. I didn’t feel like I had control of my content. So, I migrated to my own hosted Wordpress account. The writing process improved tremendously, but I hit another self-expression road block, biting my tongue for several months with a pretty cool, simple, clean template.

Then I finally caught myself. This entire time I was just shifting sand around. I was spending less time writing and more time reconfiguring the site and throughout the entire process had said absolutely nothing about myself. I made a promise to myself to build a site that accomplished exactly what I wanted.

Goals

Describing one’s self is possibly one of the most difficult challenges. I decided to approach the problem systematically:

Who am I?
What do I do the majority of my time?
What do I do with the rest?
What things I like most?
What values do I espouse?

It became instantly apparent that I wasn’t building a blog at all. I was building a brand: my brand. So I started answering some of those questions for myself.

My birth name is “Avand Amiri,” although I have gone all my life by “Andy.” I decided that I wanted to stay true to my heritage and make the switch. It’s been hard to get my friends to call me “Avand,” change my old accounts, and track down all the old references, but I think I’m mostly there. Because “Avand” is so unique, I decided to build my entire “brand name” off of it. It became the cornerstone of this site.

I’m fortunate to say that I love what I do. I spend my days building websites and I have for some time. Sometimes the line between “work and play” is a little ambiguous for me, but that’s OK. I decided that my work was a major focal point who I am and that my site had to reflect that.

With every iteration of the old site, I was frustrated that I never expressed myself. I didn’t want an “About Me” page. In fact, I didn’t want any text at all. I had to find something important about myself that could become part of the “Avand” brand. I finally realized that cycling was a huge part of my life and I felt comfortable sharing that part of me with the world.

Finally, I needed the site to subtly explain myself through the atheistic. This was the most fun part because the only question I had to answer is “what do I like?” Red, black and white are my favorite colors because they’re so pure. I embrace simplicity and minimalism in my life, and I integrated those concepts right into the design.

Getting There

I decided to completely ignore the implementation details at first. I forced myself to focus on content. I knew that I wanted my best work to be featured as well as explained through my resume. The site also had to host my blog, featuring my latest blog post on the first page. There had to be a way to get in touch with me as well as find me through the various social networks I’m a part of. Finally, it needed tell a little bit more about me: my love of bikes, design, fashion, and cars.

I had spent so much time self reflecting that the site actually came together quickly. I did all my drafting in Photoshop, with the exception of exploring some designs with pencil and paper.

Although I had no preference of where the site was hosted, I did know that I wanted full control of the content. Chris Vanpelt had once mentioned Jekyll to me and I decided it was perfect me. Instead of coming to the table with bulky features than simply distract (searching, comments, drafts, etc.) it gave me the perfect blank slate to build just what I wanted.

I migrated each post to a markdown based text file and wrote a basic script to copy the files up to a cheap HTML hosting account with GoDaddy. Wufoo allowed me to fulfill the “Talk to Me” component without the need for any server side scripting, although getting it to look just right has been a bit time consuming.

Finally, I embraced iterative development. I published the PSD for friends to explore so I could get feedback instantly. I deployed early, while major functionality was still pending, and often, to make sure I was always moving forward. Today, I migrated the remaining posts from my old Wordpress account and added syndication, celebrating this major milestone with a fresh post about the process.

Ultimately, I’m really satisfied with the end result. I feel like I actually accomplished what I set out to do a long time ago, and that’s really gratifying. At the same time, I’m prepared for the changes to come. I know that what I do, and who I am will develop over time. I look forward to reflecting on those developments here at avandamiri.com.

The Race to a Beta Launch: The Trials and Tribulations of Piggy Back

2009-07-16T00:00:00+00:00

I haven’t posted in a while, and here’s why: Piggy Back;. If you follow me on Twitter, or are friends with me on Facebook, you’ve probably seen the updates crawling by.

Piggy Back is a web site that helps users manage debts between each other. It was inspired while I was consulting at Echo Global Logistics, where Rob Freas, Bryan Dougherty, Antuan Kinnard and I were constantly going out for lunch. One of us invariably didn’t have cash, and to make things simpler one person would just always pay. We shared out a spreadsheet and whoever paid would update it.

The pain: with every new record we added we had to go through the mental anguish of actually figuring out who owed what to whom. Piggy Back was born from that concept. Initially code named “Balancr,” in true Web 2.0 style, Piggy Back takes debts between people and nets them out. If Rob owes Bryan and Bryan owes me, well then Rob just owes me. It really is “the shortest distance between two wallets.”

I whipped something together over a year ago, using it as more of a sandbox for Ruby on Rails wizardry than an actual product, then shelved it for quite some time as I pursued other endeavors. I finally decided to revisit the project about 3 weeks ago with a commitment to launching it, and here’s my story:

##Focusing on What Matters##

When I cracked open the source code again, there was a lot that had to change. Some were some obligatory upgrades, but in order to take this site from “no” to “pro” the amount of work was a bit overwhelming.

So I decided to focus on only what mattered and that was the balancing algorithm. At the core Piggy Back had to be able to net out debts and find the simplest way for money to exchange hands. I started work on this part of the project solely with tests. Using Shoulda I created a sea of nested contexts describing every possible debt situation I could think of, then I tweaked the algorithm, which was already pretty solid, to make the tests pass.

Then I started pounding it as a test user, building up more and more complicated scenarios. As was expected, but not hoped for, the algorithm buckled. Something was clearly wrong, so I went back to the drawing board.

I created more test cases and found the bug, but now, paranoid that there were other errors, I decided to map out every possible debt scenario I could think of… on paper:

There was so many more fun things to work on. I wanted to build the bells and whistles that make it fun to use, pretty, and more useful. But I kept catching myself: no one would use it if it didn’t crunch the numbers correctly, including me. Two more late nights, and I was ready to move on to the fun stuff, with my mind at ease that Piggy Back could do the math right, although I’m still keeping my fingers crossed.

##Racing to Production##

After that little problem was over and done with, it became a sprint to get it live. No marathons here. I got an account with Slicehost, and knocked out all the little annoying things that had to happen before going live: user registration workflow, invitations, error handling with Hoptoad, Google analytics, hosting, and ultimately deployment. Boom, it was live!

There was so much more that had to happen, but at least it was up and running and I was accountable to my users and immediately started getting feedback.

##Feedback is Deafening##

Just like holding a microphone up to a speaker, the feedback started pouring in: where’s the remember your password button, can I create private debts, why is this over here, etc., etc., etc. I guess it’s really easy to criticize something.

At times I got annoyed, sitting back and taking the attitude of, “well, if you want it to work that way, why don’t you build it!” Then I caught myself. These are my users. This is exactly what I had been working so hard to achieve. I can’t swear them off just yet!

##Build it to Use It##

Piggy Back was inspired by a pain that I felt. I was tired of curbing my own generosity because I was afraid I’d never get paid back. I want Piggy Back to have a mobile interface to make it easier to add debts, for me first and foremost. Having worked on a lot of different projects, it’s really refreshing to really feel the need of the user and be able to act on it.

##Build it to Use It, Again##

Apparently the way I use software, and the way others use software is totally different: make no assumptions about user behavior. Given a text box that says “Name” I type “Avand Amiri,” while others type “ben” or “G.” When I click a link and it takes a second to load, I look to the browser’s status bar to see if browser is loading something. Other’s just give up.

I’ve spent a few hours talking to people, and looking over people’s shoulders to see how they move their mouse, and ask them “why’d you do that?” Pay attention to how people phrase questions, and how many they’re asking.

##Testing##

For the technical people out there, how well is this application tested? Not really. The part that matters, Debt#balance, is heavily tested, but everything else really hasn’t been a priority. There’s 73 tests with 81 assertions, and absolutely zero controller testing.

How does that make me feel? Not great. But it’s been eye opening to test what actually matters. If I don’t test that user’s have many debts, I guess I don’t really care, because the application will disintegrate if that becomes the case. Seriously, when was the last time a developer on a whim said, “meh, this has_many declaration can’t be that important.” It doesn’t happen. At the end of the day, my tests are the product of necessity. Some new functionality I’m releasing, requires my user registration to be much more robust, and I’m a little scared of the edge cases, so I’ll test them.

So going back then, I guess I’d rather have a product that I use that has a few bugs, than a fully tested product that has yet to ship.

##Conclusion##

All things considered I’m having a lot of fun building Piggy Back and I think that’s because it directly impacts me. It’s fun to be user number 1, and it’s fun to see user number 10. Getting feedback has been huge, because it’s made me think about things I didn’t consider important or necessary. More than anything, it’s dynamic. Don’t get too comfortable with Piggy Back, just yet, there’s a lot more to come.

Outstanding Customer Service and Where It's Coming From

2009-06-08T00:00:00+00:00

For best results, read while on hold with your favorite ISP.

Is anyone else seeing what’s happening here? I’m not sure where it’s coming from, but companies are becoming obsessed with excellent customer service.

I witnessed it a little here and a little there at first, but then, after reading last month’s Inc. magazine’s article on Tony Hsieh and Zappos, I started to notice it everywhere.

First, I ordered shoes from Zappos. Got them next day with free shipping and returned two pairs with no issue. I haven’t had to call in yet, and don’t think I’ll ever have to because that company has their shit together. Did you know they can get an order into a box and ready to be shipped within 8 minutes of you pressing "buy?" That’s impressive for a 800,000 square foot warehouse. Hsieh isn’t trying to build a store where you buy shoes, though, as the article describes. He’s building a store where you buy happiness.

At first I thought it was just Zappos, but then I found Bonobos. Who would buy pants online? Well when you make it so easy, I think the question becomes who wouldn’t buy pants online. I have yet to use these guys, but my next pair is coming from that site.

A short aside: how long will it take for these apparel sites to build a “if you’re an 11.5 in Kangaroos, you’ll be an 11 Puma” feature.

So I started to notice a trend, although some people say it takes three occurrences of something to become a real pattern.

I manage a website for a summer camp up in New Hampshire that I went to as a kid. Great place, by the way. I get copied on all the form submissions from the site; usually it’s just spam or a parent curious about tuition. Then I read this:

Hello,

I work for Garmin GPS. I received a complaint from one of our customers on how our unit guided him to your camp. He said it took at least one unsuitable dirt road (almost a trail).

I am going to try to get this fixed. May I ask a question since you know the area and I do not? When routing to the camp from the south, should the route involved 109A and then Federal Corner up to the camp? Our units seem to want to approach from the other side (via HWY 171 from the northeast). I think that may be the problem–that Federal Court is awful between 171 and camp but is okay between camp and 109A? I may be guessing wrong. Any help appreciated.

It just so happens that I’ve been down that trail, and I was lost. Of course, that was back when MapQuest ruled the world (proof that you can take down the market leader with a better product… twice. Goin’ back though, how cool is it for a GPS company to take such ownership of their product?

So what’s the deal? If an online shoe company can figure it out, what’s Comcast’s problem? Or AT&T’s for that matter. It’s a good thing I asked, because I’ll tell you: constraints. When you’ve got your customers by the balls you don’t have to be nice. But when you’re selling a product that people have to try before they buy, you do.

An article from Popular Science a few months back talked about the work two desktop printer engineers are doing in the development of a nuclear fusion generator. They’re competing with the International Thermonuclear Experimental Reactor, a consortium of seven governments sinking billions of dollars into decades worth of research. And they’re doing it with 2 million bucks in an office park.

“It’s pretty basic, boring stuff,” he says. “Look in your car. There’s no superconducting magnet in there. There’s pipes and pistons and tubes. That’s what I want. I want to make a fusion machine at a sort of car level. And that’s why we can make it for $50 million and they” – government and university coalitions – “make it for $20 billion. That’s the difference.”

It’s survival of the fittest. So look for innovation, whether it be the cure for cancer, a solution to the world’s energy problems, how to get to space more cheaply, or just how to get a great pair of shoes, from the underdogs. Because when the only other option is straight up failure, it’s amazing what people are capable of.

The New York Subway System. Holy Crap.

2009-06-01T00:00:00+00:00

I was recently in New York to visit a friend. Flew into La Guardia and called him up to tell him I was taking public transportation into Manhattan. He sounded puzzled but I didn’t really feel like spending $60.00 getting to West Village. Plus, there’s something to be said for pulling out the machete and blazing through uncharted lands. And by machete, I mean iPhone; and by lands I mean tunnels.

After taking a few wrong turns, I made it over the bridge onto 125th street, but I was definitely lost, and decided, “you know what, it’s late - maybe a cab is the right move.” Nope - apparently New York has these “black” cabs competing against the trusty yellow ones. I think they’re just there to freak out tourists.

Back to public transportation - and this time I’m going underground.

Without the aid of my iPhone underground, I had to memorize some of the key stops for my journey. I got an MTA card from a touch screen kiosk (why those things are so complicated I have no idea - don’t even get me started on the ones in CA.) When I finally got on the platform and got my bearings I was blown away. The New York subway system is absolutely incredible.

When you decide below the streets, there’s not 1, or even two layers of trains, there’s sometimes 3. And each level contains up to 3 rails. May not seem like such a big deal, but then you remember that above you is one of the biggest cities in the world - behemoth towers of steel and concrete growing above these arteries. I was really blown away.

Then I got lost… again. And here’s why:

##Why I Got Lost##

Why is the word “Exit” on a red background? Does following the arrow mean you’re going to the exit? The red divides the routes on the right from the arrow. I was unsure whether following the arrow meant the exit, those lines, or both.
What does this mean: “Local to Bay Ridge-95 St. Late nights N to 36 St, Bklyn for R” ?
I actually like the alphanumeric dots of color, but why mix them into the language? At a glance it should be obvious what trains are coming to the platform your standing at.
Once you’re underground, which way is North? South? When you’re spun around, it can be very confusing. Don’t look to the signs; unless you know the city they won’t help you. I was amazed that even the transit maps (not pictured) while telling you “you’re here” failed to point out which way you were going. Unless you traced the route to the last stop - and even that wasn’t consistent.
Pay-to-turn bidirectional revolving steel doors? I for one find those things scary as hell. They remind me of one of those elaborate cave traps Indian Jones gets stuck in in the Temple of Doom. To make matters worse, they turn both ways on some ratcheting system. Not enjoyable.

##What I Found Comforting##

The students playing a concerto in the walkways. Really good stuff.
The electronic signageon some of the subways. They give a bright and clear indication of direction of travel, make it obvious which stop you’re at, and dynamically show only the pertinent information like what stops are coming, not those that have passed.

Lack of conventions, obscure abbreviations, and unclear signage made for a fairly confusing night ride. Might not seem bad reading it at your laptop, but three stories underground, with trains whizzing by and no access to the outside world makes it pretty daunting.

Compare that to Chicago, granted a much simpler subway system (I feel inadequate even linking to a picture of the subway map):

Lines have clear names, and the construction emphasizes the route (red line = red steal girders). While maybe redundant, the signs are explicit (“Board here”) bringing the commuting experience down to the lowest common denominator. Maybe that says something about a difference between East Coasters and Midwesterners.

But I think it says more about design: know your audience. A public transit system has to serve everyone from the battle hardened city warrior, to the foreign tourist. Just the dependence on full English sentences describing routes throughout the NY transit system seems like a huge design deficiency to me.

Compare their websites, too: Chicago vs New York.

But one can’t be too harsh, just take a close up look at their subway map and you’ll see it’s really incredible.

Adventures with Ad Delivery in Rails

2009-05-28T00:00:00+00:00

It’s always hard to find the line between buy vs. build - or as it’s known in the open-source world, buy vs. “borrow.” I find this to be more true in Rails than in any other application framework. You want authentication, you got it; you need paging, done. Before you know it you’ve got an application that does almost everything you need, almost everything you don’t and you’re stuck in the middle.

Now, it’s time to actually write code.

At GetFave.com, we had a problem on our hands. We needed to deliver ads from our own inventory - space on the site that our sales team sells to our clients. I immediately asked - how can we do this without writing anything. You can anticipate the complexity that comes from adding a feature like that: find ads contextually, figure out which one to show, show it, track that it was shown, all while not slowing down the page. We take performance very seriously at GetFave.com

So we tried on Google AdManager for size. It seemed to be the right fit. First off, it’s Google, so it’s gotta be good (debatable, I think). Secondly, it promised to do all the heavy lifting for us: tracking impressions, click-throughs, reporting, delivery, impression distribution, inventory management, and more. They even worked with us to open up an advanced custom attribute targeting system. The only known draw back was that it wasn’t going to work with other ad network APIs. Plus, it was a drop in replacement for AdSense - so we had nothing to loose.

A few weeks later, a day before one of our clients ads had been promised to be delivered, AdManager has yet to perform as we’ve expected. The interface is clunky and convoluted. I can’t blame them, they’ve built a behemoth catch-all advertising management system. But most importantly it wasn’t delivering the ads we needed to satisfy our customers (I later discovered that AdManager requires several weeks for custom targeting data to propagate and effectively deliver ads.)

With our lovely sales director popping her head in to make sure we on target for ads to be delivered, I found myself between a rock and a hard place. Then it occurred to me: “wait, I know how to write code!”

Queue Pandora. I started with a basic ActiveRecord model and stubbed out what I thought we’d need - borrowing heavily from my experience on the Google side of the wall. The biggest issue was performance and although I was reluctant to have ad delivery happen synchronously, I decided to go with it (we’d have some time to refactor before we had enough inventory to slow things down). I had already written a nifty tracking class to help me keep track of the context of the page such as keywords and geography. In an afternoon I had the whole thing done.

Pretty soon it was in production and getting feedback from sales people and customers. There were bugs, as was to be expected, but we’ve since worked them out in addition to adding several new features. Shameless plug: All you small business owners out there may be interested in our new geo-targeted ad product.

The moral of the story was that sometimes - I’ll say maybe even the majority of the time - it pays just to write it yourself. To borrow from my friend Michael Dwan, and then in turn DHH, “don’t use code you couldn’t write yourself.”

Next up, Google Analytics.

Data Driven Development (DDD)

2009-01-15T00:00:00+00:00

In the world of software, methodologies rule. It isn’t about the code, it’s all about the process. And when it comes to processes, there’s a lot to choose from; developers have a habit of over thinking this stuff. So as one, I figured I’d throw in my two cents, too.

Test Driven Development has been a buzz word in the Rails community for a some time. It certainly deserves the credit, too. The peace of mind that comes with a solid test framework is unparalleled. But there’s a component of testing that I think is ignored. To write a good test, you need good test data.

You have a couple options when it comes to data:

Fixtures: In Rails, you can use static YAML files to represent the data in your database. Once your migrated, just load the fixtures and you’ve got some data to work with. The downside here is that to get a lot of data, you have to do a lot of typing. Additionally, as your data becomes more and more complex, it becomes really tough to keep track of the dependencies and associations between objects.
SQL: Aa SQL dump from another machine or production is a great fast way to get tons of data, but is incredibly fragile. As your database changes, the migrations and schema may deviate machine to machine, and it only takes one change to invalidate an entire SQL dump. They’re a pain to work with as most text editors crash on such large files.

Recently, however, another option has become available: generate it! I was really inspired after watching the Populator Railscast by Ryan Bates, in which he demonstrates using Ruby to spin up a few hundred database rows in a few minutes. With simple models, it’s a totally painless process. So what happens when you outgrow the out of the box Rails application?

Well, I say you stay disciplined. When you embrace TDD, it becomes weird not to write the test cases first. Same thing here, for what I’m calling Data Driven Development. Write the tests, migration, model, and a data generator in one process. Change your model? Change the data, and change the test. Every model should have tests. Every model should have a data generator.

Using the populator and faker gems was a great way to get started. In a few places you have to do some work directly with ActiveRecord, when relationships become complicated, but it’s relatively painless. I wrote the following method that I call at the beginning of each generator to deal with dependency issues that helped me quite a bit:

# Given a set of class names, will require objects of those types to
# have been populated.
# Usage: depends_on(User, Post, Comment)
def depends_on(*args)
  if args.any? { |a| a.count.zero? }
    dependencies = args.map{ |a| a.name.pluralize }
    raise "Depends on #{dependencies.to_sentence.downcase} to populate data." 
  end

  args.each { |a| eval "@#{a.name.underscore.pluralize} = #{a}.all" }
end

This not only helped declaratively define my dependencies, but also sets up whatever instance variables (i.e. @users) to help you out with the generator.

As far as testing goes, factories come in really handy. It’s just like using a generator, but knowing that the output will be the same each time. For my tests I completely rely on factory_girl. Not only can they run much faster as many tests don’t even need to hit the database, they allow each test to declaratively set up exactly the conditions you need.

Ultimately, the approach gives you more peace of mind. Loose your database? No problem: migrate, then generate. Need more data? Generate millions of fake records while you grab a cup of coffee. Good deal.

In-n-Out Burger: Consistency, Animal Style

2008-12-23T00:00:00+00:00

I recently took a trip out to California and had my first dinning experience with In-n-Out Burger. I really reveled in the experience, because they’ve really nailed, what in my mind, makes a great product.

Immediately In-n-Out Burger’s menu jumped out at me. In my day to day operations I’m often tasked with conveying information quickly. The web is my domain, but regardless of medium, the most easy to convey information is also simple information. I’ve commented before on how Apple has been successful following this mantra. So when I walked into In-and-Out, expecting to become quickly stressed with an overload of options, sizes, and extras, I was pleasantly surprised to find this instead:

No tricks here. A simple set of options, listed by price. A whopping 34 possible menu options by my count. Which seems pretty easy when I compare it to any other fast food places - yeah, that’s right, no salads here. Even the option I found most delicious - “animal style”, is unlisted on the menu. Talk about restraint and compromise. So, we sit down to eat and I’m anxious. I’ve heard good things, and am happy thus far, but just because they have a simple menu, doesn’t say anything about the food. Fresh ingredients: crunchy lettuce, a thick tomato wedge you can actually sink your teeth into, tasty sauce, and real beef, all on a toasted buttery bun. French fries, cut from whole potatoes right before your eyes. Delicious.

First experience was a huge success. But what was really inspiring were the subsequent visits (I tallied 6 charges on my credit card statement after the trip). In-and-Out Burger, beyond making delicious burgers, wins because they’re consistent. The deliver the same experience every meal at every location. The menus, burgers, fries, outfits, tile, floor-plan, receipts, toilet paper - all, exactly the same from store to store. It’s like someone came through with a Chinook and just airdropped them into a lot. This serves the customers, while most not as detail obsessed as I, in making the experience more familiar and completely reliable. And it serves the franchise; just think how much money was saved not having to re-hash every detail.

I was really impressed, and will think back to my experiences there while working in my domain. But first… something to eat.

CSS Tricks (2 of 2): Using Rails to Manage Styles

2008-11-19T00:00:00+00:00

For the second half of my CSS “tips n’ tricks” tutorial, I’d like to take some time and discuss how Rails can help manage stylesheets. As you start out any Rails application, there are some huge conventions you follow within the ‘app’ folder. I think these conventions make it much easier for developers to find, maintain and create code. But when it comes to stylesheets I find there to be a notable absence of these conventions.

My web applications have, in the past, began as one stylesheet called “default.css” or “application.css” and placed in the stylesheets folder. I’d try and arrange similar styles in similar places, and use comments to help organize it. Pretty soon I had a 800 line CSS file on my hands and was hunting to find styles on various pages. I knew there had to be a better way, and thanks to Rails and some conventions I’ve started following, I think I’ve got a decent system. It involves 3 basic components: using controllers and actions as CSS selectors; many shorter CSS files; and Rails stylesheet caching.

##1. Controllers and actions as CSS selectors##

Depending on the application, you’ll be using some kind of layout in the views/layouts. I usually stick with something like views/layouts/application.html.erb early on in the game. The first thing I do is make whatever div I have wrapping my main content area adopt the current controller and action names as CSS classes:

<html>
  <head>...</head>
  <body>
    <div id="wrapper" class="<%= "#{@controller.controller_name} #{@controller.action_name}" -%>">
      <%= yield %>
    </div>
  </body>
</html>

This means that now in any stylesheet I have full control over what gets rendered and no style can step on the feet of another. For example:

div#wrapper {
  /* insert styles common to all controllers here */
}
div#wrapper div.users {
  /* insert common styles for all user actions here */
}
div#wrapper div.users.index {
  /* insert users#index specific styles here */
}

The key is to religiously obey these prefixes. In Part 1 of this CSS series I talked about being as specific as possible with CSS selectors, and this is why. If you’re not, you’ll spend hours trying to figure out why something is rendering a certain way only to find that it’s inheriting something entirely irrelevant. So once you have that sorted you can then make…

##2. Many shorter CSS files##

So if you have a controller like UsersController, you’ll have a folder, views/users. Within that you’ll have files that respond to each action. Do the same thing for your styles. Create a folder public/stylesheets/users and create a stylesheet for each view that warrants its own styles. To follow the example above, you can now take any CSS that starts with div#wrapper div.users.index, and place it in public/stylesheets/users/index.css. Same thing for every other action, and partials too… hell, I even prefix those files with an underscore. I try and make the files stylesheets folder mirror the views.

You have to get a little more creative when it comes to common styles (those that span multiple controllers or actions). For styles spanning multiple actions, simply create a common.css inside the controllers folder. For styles that span multiple controllers, chances are that a layout exists for that part of the application. For example, navigation that may be common to administration would go in public/stylesheets/admin.css to correspond to app/views/layouts/admin.html.erb.

This process, actually works really well with javascripts too. It may seem ridiculous to include so many stylesheets into the final HTML that gets rendered, but fortunately you can send it all down as one.

##3. Rails stylesheet caching##

This is where it all comes together. With one simple command we can get the web server to concatenate all these files into one sheet that gets sent to the client:

<html>
  <head>
    <%= stylesheet_link_tag 'application', 'users/index', 'users/new', 'users/common', cache => 'cached/users' %>
  </head>
  <body>
    ...
  </body>
</html>

In some cases I’ll just bundle every CSS file I create into one sheet, or if the application is a bit more stratified you can create sets of caches. Usually the structure of your layouts will determine how you set these up.

This set up means you as a developer don’t have to loose time trying to find the styles that correspond to their respective view HTML, can save time when debugging by eliminating accidental style inheritance, and still send one file to the client. Enjoy.

CSS Tricks (1 of 2): First, Get Down with the OOP

2008-09-18T00:00:00+00:00

##Introduction##

I recently stumbled upon an interesting web design blog that featured an article about some CSS “essentials” and commonly used CSS code snippets. I read it with a great amount of interest and found that I had a few tricks and tips up my sleeve that I’d like to contribute as well. So this is the first in a two part post about how to improve your CSS and make the design process more fun and less stressful.

I immediately found that a lot of my tricks don’t actually have anything to do with visual design or CSS at all, but more about structure and design patterns. Funny, how that sort of thing happens when you learn how to code first. I’ve found that you can bring a lot of the organization and philosophies that come from structuring application code right into the presentation layer. Here’s what I’ve learned…

##Embrace a Convention Through and Through##

Seriously, if you’re not using some kind of structure when it comes to building an application, you should probably go read some other blog. I’m somewhat infatuated with the MVC pattern these days, but for the sake of what we’re doing here I don’t know that it matters.

The idea is that you have various objects or models throughout your code. You may have some Users, Products, or Messages. The problem is that by the time they get to the view part of your application, their meaning has been diluted. Distill it.

You have a fairly common set of tasks for any object: List (index), view (show), create (new), update (edit), and delete (destroy). Almost all of those require a presentation of some kind, with the exception of delete, usually. There’s an obvious Ruby slant in these snippets, but I think you can handle it:

Users#index

<div id="users"><!-- Derive this from the controller -->
  <% for user in @users -%>
  <div class="user">
    <p><%= user.name -%></p>
  </div>
  <% end -%>
</div>

Users#show

<div id="user">
  <h3><%= @user.name -%></h3>
</div>

Users#new

<div id="user">
  <form><!-- Key off this in the CSS (i.e. #user form input) -->
    <input type="text" value="<%= @user.name -%>" />
  </form>
</div>

With this kind of structure, your CSS stays organized and follows much of the meaning defined by the business objects themselves. I would encourage designers to try and think as much like this as possible.

Instead of reinventing names for classes and ID’s look to the structure of the application code first and let it drive the front end.

##Don’t Over Refactor CSS##

Just like with code, your CSS can become overly abstract. If you need to style a single element on a single page, start with inline styles. An ASP.NET developer once told me, “never use inline styles - everything needs to have corresponding class or ID.” That attitude is part of what’s contributed to my career switch to Ruby on Rails. Don’t create a class for it until you see commonalities start to evolve.

An example: You may find that you’re putting a paragraph that needs a particularly attention grabbing look. Start with a paragraph and set its style attribute. Make it look just the way you need to for that one instance. As you continue to work on the site you may find that you want a link to actually look similar to that paragraph, maybe they’re both a specific shade of red. Go back to that paragraph, remove the color property, and create a class called .red, which you can now apply to both. The growth is now organic and maintainable.

##Tame the CSS File##

Whether it be in a Controller, Stored Procedure, or CSS, it’s not OK for files to just grow to thousands of lines without taking a step back and saying, “woah”, what just happened here? To avoid this little conundrum I like to use the CSS @import function. Group common styles together and import them when the page renders to make the developers lives easier.

I know what you’re going to say. There’s a significant performance hit for this, and I hear you. It’s not OK to go to production using @import, because each file will require another HTTP request, which isn’t cool. But, if you’re doing anything serious, you’ll have a deployment process and you should let that piece of the puzzle take care of grabbing the CSS and compiling it all together into one file.

###Be #as .Specific .as:Possible##

It’s very easy to be lazy with CSS and end up with thousands of styles that conflict with one another. You also may not realize that there is common styling between elements that could be “refactored.”

Let your CSS selectors follow the DOM as closely as possible. If you look back to the index example above you could easily just style off of .user, but that’s exactly the type of laziness I’m talking about. Use #users .user instead. It will make life easier in the long run, and isn’t that what development is all about?

##Conclusion and What’s to Come…##

The approaches here are pretty high level, but in the next part of this post (Part 2, for those you playing at home), I’ll talk with about more concrete examples on a line-by-line basis.

People and Process

2008-09-07T00:00:00+00:00

Over the last couple of days I’ve come to an astounding realization. While I had always considered that the culture of a company - its people and practices - made a difference in its day-to-day operations, the scope had eluded me.

This month’s issue of Inc. magazine featured an article about a law firm that is changing the way they do business. After noticing depreciating morale, and low outcome they revolutionized the way their office was run by implementing a strategy known as ROWE, a results-only work environment. Standing up against the “tried and true” 8-5, more hours is better, work hard play hard, meeting frenzied corporate culture, this approach seems insane. Forget about classic work culture for a moment and think just about how to get work done effectively. It might actually make sense to work when it’s most convenient for you, balance your personal affairs the way you need to, and set your own deadlines. These are all practices that ROWE embodies, even down to the receptionists. It’s the results that matter, not the logistics. Of course, it requires some discipline, but wait a second, do you want to employee people that need a schedule to be productive? That doesn’t really jive with having “passionate” employees, does it?

37Signals, of course, has tooted this horn for quite some time now. 4 day weeks, they say, has boosted productivity, catapulted morale skyward, and absolutely energized their company. It’s all about working “fresh;” maximizing your personal time to explore new opportunities and expand the mind to bring to work your absolute best.

Of course, Google, is the ultimate example of this.

What is interesting to me is that none of these approaches is domain specific. A law firm, a software company, and a search engine, all practicing new approaches to corporate policy, all claiming increased productivity and performance. It doesn’t really matter what you do, but how you do it - the process behind it.

When I was working at William Lawrence Camp as a counselor, I remember being a part of the tradition of “Beach Day.”. It’s a pretty grueling process for the staff, but the kids really enjoy pilling into buses, driving an hour and a half to the beach, and pilling on sun screen. When we get back, we always close the day out with a barbecue. I’ve always enjoyed grilling, and when we got back from one such trip, I jumped at the opportunity to help out on the grill. The head counselor, who was keeping an eye on things walked over to me and said, very simply, “Andy, you’re doing a great job, and thanks a lot for your help.” Buried in a billow of smoke and charcoal, I thanked him and noticed that instantly I wanted to help out even more. The urge was overwhelming.

It’s the amazing power of positive reinforcement. I think the tendency is to think that these philosophies don’t really apply in the “real world.” After all, we’re all adults here, and we have to put on our work clothes and just “get the job done.” That’s what it’s called, right? “Work.” So many “work” cultures are just that: a place where it’s not about being a part of a team but just producing, however that needs to happen.

I’m very fortunate to be involved in the career of my choice, something that I am tremendously passionate about, and I can understand that a lot of people, from a lot of walks of life, don’t share similar circumstances, but I doubt that it would matter very much. My point is that what you do, is far less important to how you do it and who you do it with.

The image from Iwo Jima, for me, conjures up the emotion of the later. That tremendous feeling of camaraderie. It’s the root of patriotism, and could be, arguably, the root of U.S.A’s strength. Imagine a business running on that fuel.

And as for how, I think back to companies like the ones I mentioned above. It’s a common theme of bringing employees closer together, while renouncing micromanagement and promoting quality results. Within my field of software development, “agile” processes come to mind, and I’m sure each industry has its own parallel.

This is of course more a science than I may be suggesting, but can’t it be measured through emotion? Think again about the feeling that photo conjures. Do you feel like that at work and don’t you think you’d get a lot more done if you did?

Bravo 37Signals for Phasing out IE 6!

2008-09-02T00:00:00+00:00

It’s been a long time coming…

Too much time has gone by with developers forced to limit their imaginations, creativity and ability to support the rusty weight of IE 6. But most websites have been afraid to stick their neck out.

So, kudos to you, 37Signals, for doing your part to rid the world of IE6.

Enigmo: A Shower of Entropy

2008-08-01T00:00:00+00:00

Since I got my iPhone 3G, I’ve downloaded, that is paid, for exactly 3 games. The best - by a long shot - is Enigmo, from Pangea Software. For those of you who don’t know it, it’s basically a puzzle game where you have a certain set of tools on each level that you need to use to somehow route a bunch of droplets of liquid from point A to point B. Sounds lame, right? Maybe this will clear things up:

Not so lame anymore, huh? Yeah, that’s what I thought.

Anyway, this game, besides just blatantly robbing my time, has actually spoken to me on a deeper level (think wading pool). For those of you who may know me, I’m a bit of a perfectionist. I find myself constantly balancing my idealism against productivity and efficiency. Enigmo helps me practice this. You’re trying to get all of these little droplets over to one place, but soon realize that things are just a bit more chaotic than you accounted for. In almost all the levels, much to my dismay, you just can’t get every droplet into the pot. It’s all about getting “good enough.”

And that’s OK! Because there’s a countdown racing to zero, and the goal isn’t to get all the droplets into the pots, but rather to get as many points as possible by finishing quickly. And even then, you only need to fill fast enough for them not to evaporate. The best way to get big points: just do it. It doesn’t have to be beautiful or ideal; there’s no “grand scheme” to the game, and there’s definitely more than one solution

So if you, like me, suffer from “entrophobia”, pick up this game asap and start embracing the insanity.

Computer 1, Andy 0 and I Couldn't Be Happier

2008-07-25T00:00:00+00:00

In my own time, I’ve been dabbling with some pretty hardcore machine learning. Trying to answer the question of how a computer can create a relationship between two things, blocks of text in this case. Turns out with a few matrix transpositions, single value decompositions, cosine similiarities, latent semantic index, and a naive Baysian filter to boot, you can get pretty close. And I was just dabbling.

I was blown away by how accurately the computer, when told what kinds of things to look for, could create associations between data for itself. I had to force myself to avoid using my head to solve the problem, and pass the buck to the machines. But this is nothing new - Google has been doing it for a while - and it seems to be a trend, if not a revolution, according to WIRED.

The problem with this whole movement is that unless you’re a math Ph.D., it’s completely counterintuitive. You’ve spent 20-60 years training your brain, and here comes a computer (or a whole bunch of them it turns out) that knows more than you do in the span of a few minutes. How is this possible?

Well, isn’t in the end your brain doing pretty much the same thing, maybe with a dash of evolutionary preprogramming? If you subscribe to theory of tabula rasa, we’re not much further along than a blinking terminal window when we’re born. It’s just a little unnerving that a machine can go from infant to prophet in minutes where it takes humans years. But, hey, we’ve had other problems to deal with, too (balance, speech, survival, etc.) - take that Mr. Fancy Computer.

But this isn’t even about computers. It’s just raw math; the type of math I hope to someday wrap my head around, if only slightly. Humans are selfish, egotistical, and prideful - all things that math could not care less about. You don’t “solve for x” with empathy. And it’s that stark, cold, unforgiving nature of a white board filled head to toe with equations that makes us layman turn to each other and say “pish posh - I’m a human, I’ll always know better than an equation.” But, like I said, in my dabbling, I’ve found that nothing could be further to the truth, and if that means the computer wins, I’m OK with that.

target="_blank" Convention

2008-07-10T00:00:00+00:00

I’ve been building websites for a while now, and each time I do it, I run into a couple areas where I sit back in my chair for a second, scratch my head, and ponder conventions. One great thing about Ruby on Rails is the way it enforces convention in many areas, but yet there are still a number of things up for debate. The target="_blank" is one such convention that has yet to be settled it seems.

I guess it’s a two sided issue. When do you use target="_blank", and how do you indicate that behavior to the user?

I think the first one is fairly simple. One obvious rule I follow is whenever you’re changing domains the target should be in a new window. Just because someone wants to read a little background behind a hyperlink, shouldn’t mean their done reading the rest of the text on this page. And I usually extend that same principle to other areas, too. For example, I recently built a site that had an editing form, and you could just repeatedly save changes as you went on. I added a “View” link that targeted a new window so that if you wanted to see the changes you’ve made you could without being taken away from editing. So as far as I’m concerned this issue is pretty straight forward.

This one isn’t: giving the user feedback that the link is actually opening in a new window. I can’t seem to find anything that is blatantly obvious. I’ve tried appending “(opens in a new window)”, to the link, but that messes up the design. I thought about changing the color of the link, or using a dashed underline, instead of a solid one, but your basic web user isn’t going to pick up something that subtle. I was also suggested by a colleague to just put text in the title. But the chances of someone waiting that long before their finger slams the mouse is slim. And using JavaScript to load something more instantly, seems bloated.

The most obvious technique I’ve found I saw for the first time with Mantis, a bug tracking system, which was to append a “[^]” to the end of every link. The link, itself would always open in the same window, but if you clicked on that little character, it would open in a new window. But then, why not just right click and let your browser handle it (“Open in a New Window,” or “Open in a New Tab”, Ctrl + Click, etc.).

Ultimately, I think the best solution would be totally default settings that the browser could pick up. Just like a link default is by default blue and underlined. Even then, I suppose it’s a browser setting, but we’d be closer to a consistent solution. Or everyone could just agree to something, which I suppose I’d be OK with…

…as long as I’m part of the conversation.

Deploying a Site via DNS - "That was Easy!"

2008-06-05T00:00:00+00:00

I launched a site today for Northpoint Horizons, and it was seriously one of the simplest deployments I’ve ever experienced.

We’ve been working on the site for months on the future (now current) production server. We’ve used it for the client to review the site, to perform testing, everything you’d do with you traditional development environment. All the meanwhile, the DNS for northpointhorizons.com has been pointing at some sandbox with an “under construction” banner. So after rigorously reviewing the “staged” site with the client and completely approving it for launch, we just flicked a switch pointing the DNS right to our environment and everything just worked.

I can’t imagine deploying a website, at least v1.0, any other way.

AJAX Form Validation for Rails

2008-05-06T00:00:00+00:00

Last Saturday at the Chicago Ruby User Group I gave a short presentation on Rails and AJAX. For part of the presentation I decided to solve a problem that’s haunted me as a web developer for some time – form validation.

Here’s the dilemma:

You start with server side validation, then build your form. To validate the inputs, you have to make a round trip to the server, and re-render the entire page with the validation messages. Not the smoothest process, given the bar set by Web 2.0. But at the same time, if you try to engage the user more, you find yourself writing the same validation in JavaScript for the client – not fun.

Here’s the solution:

Again, start with server side validation and a form. Then use JavaScript not to validate the data, but to facilitate an AJAX request to the server, where you there validate the field and send simple feedback to the user.

I started by searching for solutions for this. As it appears, I’m not the only developer in the room who wants AJAX validation. Here’s what I found:

I opted, for the sake of practice, to use these as inspiration to my own solution, which goes something like this:

def error_message_for(model, field, options = {})
  tag_id = "#{model}_#{field}_validator"

  # generate javascript for AJAX request and field observation
  function = "new Ajax.Request('/users/validate?field=#{field}&value=' + value, {" +
    "method: 'get'," +
    "onSuccess: function(transport) {" +
      "element = document.getElementById('#{tag_id}');" +
      "var output = transport.responseText;" +
      "var css_class = '#{options[:error_css_class]}';" +
      "if (output.length == 0) {" +
        "output = '#{options[:success]}';" +
        "css_class = '#{options[:success_css_class]}';" +
      "}" +
      "element.innerHTML = output;" +
      "element.setAttribute('class', css_class)" +
    "}" +
  " });"

  js = observe_field "#{model}_#{field}", :function => function

  # generate html for placing error message
  tag = content_tag(options[:tag], options[:hint], {
    :id => tag_id, :class => options[:hint_css_class]
  })

  return tag + js
end

I wanted my solution to be equally elegant as Rails’ non-Ajax solution, so I created a method error_message_for, which takes the model, field name, and various options. First, it creates the JavaScript I’ll need with observe_field, wiring up the Ajax request to the field we’re monitoring. Then, using content_tag produces an empty tag which will serve as our feedback placeholder. It returns all that HTML/JS to the browser. But, we haven’t done any validation yet. For that we need a validate action that can be called on whatever model you’re working with (in this case I’m working with a User):

def validate
  field  = params[:field]
  user   = User.new(field => params[:value])
  output = "" user.valid? # trigger the errors hash to be filled

  if user.errors[field] != nil
    if user.errors[field].class == String
      output = "#{field.titleize} #{user.errors[field]}"
    else
      output = "#{field.titleize} #{user.errors[field].to_sentence}"
    end
  end

  render :text => output
end

Now, we’re cooking. As the user moves from field to field, the AJAX request we wrote is created, firing validate. Validate then uses the valid? method to populate the errors collection on our model which in turn allows us to return the same error messages Rails would if we were using error_message_on.

Now we just implement it. Call our new error_message_for method right after the input field like so and that’s a wrap. The HTML and JS is returned to the browser when the page renders the first time. When focus leaves a particular field, its value is sent down to the server for validation, and the server replies with whatever applicable error messages, which are displayed in the originally empty HTML generated to begin with.

form.text_field :email
error_message_for :user, :email, {
  :tag     => :span,
  :hint    => "Your email must be formatted properly.",
  :success => "Looking good!"
}

You may have noticed some code in there referring to :success and :hint. I figure, while we’re in there let’s add support for a hint to be displayed before any validation occurs, and a success message to display when validation is passed.

The best part of the whole thing, is it’s really DRY (Don’t Repeat Yourself), and therefore simple. Change your validation rules, and the UI updates dynamically. In addition the same approach can be used on any form that has an underlying model associated with it.

Download an example from GitHub.

Peeling Up

2008-04-15T00:00:00+00:00

I’m not sure when exactly it happened, but drop shadows and rounded corners struck the web with a vengeance. Then it was the reflections. It seems like those persnickety designers are looking for anyway to make our lives as developers harder. But they have a fairly noble goal, anyway - to give a 2D fairly boring web page depth. I’m a big fan.

But at the same time, I find it very frustrating. Both rounded corners and drop shadows make dynamic widths a nightmare. Then there’s the issue of a drop shadow spanning two background colors with full translucency support. Solving any of these problems elegantly is a challenge. So recently I’ve been looking for simple ways to evoke the same illusion of depth. I think I’ve found two, but I’ll talk about one here.

Every since I signed up for LinkedIn, I’ve been dying for them to do a redesign. After logging in I felt totally inundated with information, and found it very challenging to navigate. Aside from the fact that a few months back they totally overhauled the design, they added a really slick design paradigm I’ve never seen before and I was really impressed. I’m referring to this:

Do you see what I’m referring to? It’s the peeling up effect below the “Add Connections” button. It doesn’t solve all the problems, but it definitely makes it easier than extending a drop shadow all the way up one side of that floating box. They actually call the class on that div “sticky-box” which I think embodies that “peel up” perfectly. Bravo LinkedIn!

Skepticism Happens {Here}

2008-03-11T00:00:00+00:00

I attended Microsoft’s 2008 Product Launch Event, Heroes Happen {Here}, today and I think my suspicions have been officially confirmed.

My interest in Microsoft products has been waning as of late. Nevertheless, attending a Microsoft launch event is a good reason to get free schwag, and they do a decent job of highlighting what to look for in their new products.

Products? Let’s take a minute to dissect what that means.

In Freakonomics, Stephen D. Levitt talks about the simple law of incentives. Real estate brokers, he argues, don’t stand much to gain by selling your house for a few thousand dollars more. By the time they get their commission, that few grand is only a few hundred dollars. In fact, to that point, they could make far more, by selling another house with the time and effort it might take to “wait it out.” Understanding this incentive is the golden key for sifting through potential B.S.

What does that have to do with Microsoft?

Well, Microsoft is selling a product after all. They make money when you buy VisualStudio 2008, SQL Server 2008, and Windows Server 2008. And that’s really only the beginning. Once you’re hooked (I walked away with a free copy of each), then they really take you for a wild ride with production licensing.

Now, I’m not saying that is bad. To the contrary. Your business needs paper, staplers, and desks, too. It needs all kinds of tangibles that someone makes money by supplying. It’s an awesome system that pretty much drives commerce.

But at the same time, when I see the same UpdatePanel demo in the developer track that I saw last year at the Chicago .NET User Group, I become skeptical. When Split View, one of the most prominent features evangelized at the conference, brings my friend to say “uh, duh, Dreamweaver,” I become skeptical. And what about LINQ? Try on ActiveRecord for size - it’s free. Silverlight? Ever heard of Flash? And how about instead of banking on the drag and drop AJAX Toolkit, you actually learn JavaScript. You are after all a web developer, right?

But it wasn’t all bad. JavaScript debugging and JS IntelliSense are very cool. The load tests also seem cool.

I just want to keep it simple. In one of the presentations, a speaker referred to JavaScript as one of the “bane of a web developer’s existence;” and you might say an UpdatePanel is the definition of simple. But to who? A dilettante or a developer?

If you want to do anything there’s a learning curve. If you embrace that curve you’ll find that there are simple, cheap, even free tools that replace the Microsoft suite, backed by hundreds of smart people who did the same.

And knowing that, it’s hard for me to bank on the guy counting all his cash.

Best Tool for the Job

2008-03-05T00:00:00+00:00

The religious wars go on. Microsoft vs. the rest of the world, it seems. On and on, ad infinitum.

But does it ever really matter? Is there definitively a platform of choice? Or more to the point, is that question even valid? Can there be a definite? As Jeff Atwood points out, every technology flexes different strengths and exposes certain weaknesses. Knowing the pros and cons will help you determine the best tool for the job.

I recently started re-reading parts of Marshall Goldsmith’s What Got you Here, Won’t Get You There. Goldsmith, an organizational psychologist, describes a terribly negative characteristic common among successful people dubbed as the “need to win.” Developers have got a serious case of it.

Looking for a feeding frenzy better than Shark Week on the Discovery Channel? Go into a room of shark, oops, I mean sharp, developers and ask what’s the best way to refactor some classes to support an MVC architecture. Before you know it, you’ve got 100 ways to solve the same problem. How do you pick?

Keep it simple, stupid. You don’t need a sledgehammer to hang a picture (although it might be fun). You don’t perform brain surgery with a chainsaw (I’m looking at you, Tarantino).

Unfortunately for software developers, knowing which tools to keep in that tool belt can be daunting. Each platform presumably exists for some reason or another. They don’t just write 300 page, $50.00 software text books for fun. So it’s got something going for it (or at least it did), even if it might not be much. Some guy, just as smart as you, probably smarter, was on the other side of your criticism when he built the damn thing. Unlike other industries, where there may be a definitive right way to execute, technologists grapple with hundreds of choices and decisions. So to really be able to know which tool is best for the job takes years of exposure, education, and error.

So take it upon yourself to constantly challenge the risk/reward of a given platform - arm yourself with an arsenal of tools that suits the job you need to accomplish. Picking sides, after all, violates the whole spirit of software development. So let’s stop arguing already and build something spectacular.

A Look Back at Windows Mobile 6.0 and ActiveSync

2008-02-12T00:00:00+00:00

While I was walking home from work today, checking my email on my iPhone, something very strange occurred to me. Once upon a time, I was a Windows Mobile junkie. Not just a standard user but an all out fan boy. I would talk to whoever was willing to listen about how awesome my Treo 750 was and how awesome of a job ActiveSync did at keeping everything, well, synced. So I started to wonder what happened?

A little background might help here. I made the conversion to Apple (iPhone, iPod, MacBook Pro) about 7 months ago. Before that I was all Windows, all the way. The conversion was sparked by two things. My interest in Ruby on Rails, a very rapid web development framework, which works best on Mac OSX and, the topic of conversation here, my desire to separate work from play. I was blown away.

ActiveSync, which requires an Exchange Server, is awesome. Loose your phone? No problem, your calendar, contacts, email, it’s all synced. Out of sight, out of mind. It also syncs really fast, with almost no lag from the minute something happens in Outlook to when it hits your phone.

But I wanted to separate work from play and I couldn’t seem to do it. Microsoft sells products, and as a result, no matter how awesome the product is, it’s limitations are in MSFT’s hands. So I switched to a more “open source” solution.

Now I’ve got both work and personal email happily IMAP’ing to my phone, contacts syncing to my Mac, along with the gigs of video and audio I have as well. No, my calendar doesn’t sync over the air. No, I can’t accept meeting invitations but I think I’m OK with that. The things it does do well, it does amazingly let alone the interface of the iPhone. It’s stable, which is a lot more than any Windows Mobile device can say. Every time a call came through it was like my Treo was having an aneurism. It really tried to keep up, but always seemed a few steps behind. Meanwhile the iPhone “just works.” Incoming call during a song? Music fades out, call fades in. It’s beautiful.

So all in all, I’m happy I made the switch. More than anything, I’m glad that my personal stuff is out of my corporate account. But hey, the phone’s cool too.

Introduction to this Blog

2007-07-22T00:00:00+00:00

Throughout my life, I’ve always had a knack for design. As a kid, I grew up in a house surrounded by fine art and lots of art classes. In my teens, I spent my Saturdays at the Museum of Fine Arts in Boston. However, along the way, I also feel in love with technology. I love computers, gadgets, iPhones, the internet, and especially web design.

So throughout my day to day trials and tribulations, I come across things that pique my interest. Design and usability flaws that are so minor that most people steam right over them. Some might call them insignificant, but I believe it’s important to be picky. It’s what ultimately separates the wheat from the chafe.

Simple things like why a refrigerator ice dispenser doesn’t revert back to “Water” after a few minutes of inactivity? Why North Face stores don’t have a coat racks? Why a brand new OS might have a wonderful animation library of fades and shadows but then abruptly blink to life when waking up. Why certain applications are huge successes, and others fall to the curb?

These are all questions that interest me, and that I hope to explore with this blog. The theme has a long chain to roam on but will stay within the intersection of design and technology, with a few usability and user experience tangents along the way.

I hope you enjoy it,

Avand