Avand.

Serving Different Robots.txt Using Rack

2011-10-11T00:00:00-07: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 = { 'Cache-Control' => "public, max-age=#{1.year.seconds.to_i}" }

    [200, headers, [body]]
  rescue Errno::ENOENT
    [404, {}, ['# A robots.txt is not configured']]
  end
end

config/routes.rb

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

  match "/robots.txt" => RobotsGenerator

  # ...
end

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

2011-10-09T00:00:00-07: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.

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-07: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 status.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-07: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-07:00

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)

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.

The Four Hour Sprint

2010-09-08T00:00:00-07: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-08: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.

After that summer, I was brought out 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 maintaining a solid A grade-average.

Everything seemed copasetic 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. 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 learned a lot, but at a price: $1,688.00 per class. Each class was running me about $150.00 bucks.

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 quite literally come out ahead. No opportunity had been 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-08: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

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.

Update: The Results Are In

When this post when up, I asked people whether they “got it” or didn’t. Here are the results:

	Percentage	Count
	Total	122
I don't get it.	`54.10%`	66
I get it!	`45.90%`	56

Integrating Twitter Authentication with Rails

2010-01-13T00:00:00-08: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 before_filters, 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:
1. Piggy Back doesn’t now about their Twitter account and the two must be linked (B) or
2. 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-08: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.

Rebuilding a Brand. Avand.

2009-11-22T00:00:00-08: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-07: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-07:00

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-07: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.

Data Driven Development (DDD)

2009-01-15T00:00:00-08: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)
  raise "Depends on #{args.map{ |a| a.name.pluralize }.to_sentence.downcase} to populate data." if args.any? { |a| a.count.zero? }
  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-08: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-08: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-07: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-07: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-07: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-07: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-07: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 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-07: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 domain’s the target should be in a new window. Just because someone want’s 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-07:00

I launched a site today for Northpoint Horizons (http://www.northpointhorizons.com), 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-07: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 => 
  
  # 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, it’s 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-07: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-07: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.

Stephen D. Levitt in Freakonomics 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 Visual Studio 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 the 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?</div>

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. </div>

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-08: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-08: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 site, 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 IMAPing 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-07: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 Saturday’s at the Museum of Fine Arts in Boston. However, along the way, I also feel in love with technology. I love computers, gadgets, iPhone’s, 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 doesn’t have a coat racks? Why the latest OS’s have a wonderful animation library of fades and shadows but then abruptly blink to life after the screen turns off. 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