Warpspire

Knyle Style Sheets

2011-12-05T00:00:00-08:00

So I’ve been writing CSS for somewhere around 13 years now. Some might think I’ve learned the right way to write CSS in that time — but if you ask me all I’ve learned is the most efficient way to drive someone insane.

CSS is complicated. It’s not object oriented. It’s not hierarchical. It’s a specificity based cascade applied to a dynamic hierarchical data structure that few people truly comprehend. Trying to impart this knowledge on someone is a very difficult task with extremely minimal rewards. I used to think that imparting this knowledge was the path toward writing maintainable CSS within a team.

Maintainability comes from shared understanding

It’s hard to define maintainability. In my eyes it has to do with creating an shared understanding. Anyone who has owned an aircooled Volkswagen knows how to adjust valves on any other aircooled Volkswagen. This is because of one of the best technical books ever written: How to Keep Your Volkswagen Alive.

Everyone I know who owned a Bug, Bus, Ghia or Thing owns a copy of this book and understands how to work on their car. This book is in large part responsible for that shared understanding.

How can we create a shared understanding with CSS?

Documentation

For all of the talk of Object Oriented CSS, SMACSS and pre-processors like SASS/SCSS & LESS… no one is talking about documentation.

Documentation is the key to shared understanding.

Enter KSS

Inspired by TomDoc, KSS attempts to provide a methodology for writing maintainable, documented CSS within a team. Specifically, KSS is a documentation specification and styleguide format. It is not a preprocessor, CSS framework, naming convention, or specificity guideline. This means it works great with ideas like OOCSS, SMACSS, SASS, and LESS.

I’ve created a specification for KSS as well as a ruby gem to parse the documentation.

In a nutshell, KSS looks like this:

/*
A button suitable for giving stars to someone.

:hover             - Subtle hover highlight.
.stars-given       - A highlight indicating you've already given a star.
.stars-given:hover - Subtle hover highlight on top of stars-given styling.
.disabled          - Dims the button to indicate it cannot be used.

Styleguide 2.1.3.
*/
a.button.star{
  ...
}
a.button.star.stars-given{
  ...
}
a.button.star.disabled{
  ...
}

The idea is to write simple, yet machine parseable documentation such that you can automatically create a living styleguide like this one:

KSS aims to create a shared understanding

I’ve tried really hard to make sure that KSS is flexible enough to work with as many styles of CSS development as possible. It’s purpose is to create a shared understanding through code documentation and styleguides. Not to tell you how to write CSS.

And well. I think that’s an important idea. Hope you like it.

https://github.com/kneath/kss

Knyle style recruiting

2011-11-07T00:00:00-08:00

Otherwise known as Kyle Neath’s guide to hiring the best people in the world: an examination into why recruiters are useless piles of humanflesh hellbent on destroying the souls of good designers and developers across the world.

Too harsh? Most likely. But here’s the thing: recruiters do not give a fuck about doing good in the world. They do not care about making people happy. They do not care about building a good company. They do not care about treating email addresses as human beings. They only care about their percentage.

Employees are the best recruiters

At its core, the idea of a recruiter never made sense. Are they going to be working with their hire? Are they a designer, developer, copywriter or someone who knows what kind of skills and personality traits to look for?

No. They’re salespeople. And I bet they’re great at hiring other salespeople.

It just seems so obvious to me that employees make the best recruiters. Recruiters have nothing to gain from a good employee, but employees have everything to gain. If you consider yourself a manager, don’t you want to be responsible for building the team of people you’re going to manage? If you’re a developer, don’t you want to work with other great developers?

How I hire people

I happen to think I’ve become pretty good at recruiting over the years. We’ve built a pretty amazing team at GitHub, and I’d like to explain how I go about finding the next GitHubber.

Friendship

If you want to hire great designers and developers, you should be friends with them. Be interested in who they are and what they do. This is not rocket science. When you’re friends with someone you’ll notice when they’re frustrated with their job or know when they’re looking for something new. And even if they’re not looking for something new — maybe they have a (designer/developer) friend who is.

Research

Take time to look up potential hires online. If you’re hiring in the tech industry, they’re almost certain to have an internet presence. Look up their current job. See what they do. Take a look on dribbble, browse their code on GitHub — look at their work. More often than not, it’s completely unnecessary to interview for skills. You can find that out with a half hour online. Who knows, you might even find someone new to hire in the process.

Research is the proper tool to understand whether someone has the skills to work for you.

Grab a beer

It’s vitally important that you sit down face to face and grab a beer with every potential hire. Or sit down for dinner. Smoke a joint. I don’t care what it is — you need to sit down in a relaxed environment and figure out what kind of person they are.

Talk about their family, friends, hobbies, current job, dream job — anything you can think of. Some good things to figure out:

Is this person a good human?
Do they have a drive to build good things?
Do they want to work on the things you want them to?

Grabbing a beer will help you figure out if someone will fit in.

Job boards, Twitter, and advertising

I always try and use my personal connections to find potential hires first, but sometimes I come up empty handed. When that fails, you need to stretch out and get some new blood. There’s no shortage of Job boards out there: GitHub Jobs, Dribbble, 37Signals, Authentic Jobs — the list goes on. Pick a few and post some ads. Maybe sponsor a local meetup.

But remember you’re posting an advertisement. This isn’t a fact sheet. Make that shit sexy. Make potential hires read it and think I want that job. Explain specifically what they’ll be doing day to day, what they’ll be responsible for, and who they’ll be working with. Explain what your company is. Explain what it is your company wants to do.

And if you have anything listed under requirements, you better damn well mean it. Don’t ask for a college degree if you don’t actually require it. That’s just dumb.

Credit where credit is due

These ideas aren’t exactly unique, and in fact they’re really not even mine.

In 2004 I was working for an agency and we hired a full time recruiter. Props to that man for showing me just how incompetent recruiters can be. Never in my life did I think someone would create a MySpace account and contact every teenager in the city trolling for leads. He really redefined the phrase unqualified candidate.

In 2009 I started working with Chris, Tom and PJ. For every person that thinks GitHub’s success is due to luck — I want to remind you how important the people are in a successful company. And these guys spend a lot of time making sure we have the right people.

Spend time on recruiting: it’s important.

Mustache, ERB and the future of templating

2011-10-17T00:00:00-07:00

There are days that I feel like I’ve spent the better part of my life inside templating languages. I’ve rocked hundreds of different styles of templates over the past 8 years. Smarty, vBulletin templates, generations of Wordpress, J2EE, XSLT, CFML, ERB, HAML, Mustache and every form of in-house bastardized template language that exists.

So when I say that {{ mustache }} is my favorite templating language I’ve ever worked with, I mean it with a great deal of sincerity and experience. It’s syntactically elegant, focused on output (HTML), encourages documentation, and discourages unmaintainable magic. I want to use it everywhere.

I mustache you, why mustache?

Mustache is more than a syntax. It’s a different approach to traditional templating — mustache templates have no logic. The template files themselves are HTML and mustaches:

<table class="devlist">
  {{#developers}}
  <tr>
    <td class="name">
      <h4><a href="{{ show_url }}">{{ name }}</a> <em>({{ github_username }})</em></h4>
      <p class="languages">{{ languages }}</p>
    </td>
    <td class="location">{{ location }}</td>
  </tr>
  {{/developers}}
</table>

You cannot modify variables. You cannot apply filters. You can only output variables or a collection of variables. Everything else happens inside of a view. A view can be written in any language of your choosing: C, Objective-C, Ruby, Python, Javascript, etc. I’ll use Ruby since that’s what we use:

module Jobs
  module Views
    class Developers < Layout

      def developers
        @results.entries.map do |hit|
          name = hit["fullname"].empty? ? hit["username"].capitalize : hit["fullname"]
          {
            :name => name,
            :github_username => hit["username"],
            :location => hit["location"],
            :show_url => '/developers/' + hit["username"],
            :languages => hit["language"]
          }
        end
      end

      def developers_count
        @results.total_hits rescue 0
      end

    end
  end
end

It’s just a good old Ruby class. Oh the wonder you can do with a class! Include modules, extend classes (such as that Layout class), and define any method you so desire. With any documentation your heart desires (something that’s missing from every templating strategy I’ve ever used).

I thought I loved Mustache a year ago, but over time I’ve learned just how revolutionary separating templates from views is toward maintainability and collaboration. Anyone who knows HTML can edit Mustache templates. And all the magic that happens on the whole V side of MVC can be fully documented and separated into re-usable Ruby classes and modules.

You want me to switch templating languages on my legacy app?

For all this talk, the application I spend most of my time working on is still ERB. In fact, the rails app that powers GitHub has over 500 erb templates. We have dozens of people throwing hundreds of commits a day at the codebase in over 150 branches. Switching to Mustache would be a disaster requiring everyone to stop development, switch patterns, and introduce an unknown number of bugs to our customers. A shitty trade.

I don’t want to stop new feature development, but I do want better templates. And I know that Mustache is the direction I’d like to go. Luckily for me, I work with the smartest people in the world. A little while ago Simon introduced a new templating strategy that I really like.

Mustache-style ERB templates

We’ve started using the mustache style but completely within ERB — we haven’t modified the template rendering chain at all. Inside of a new helper, we’ll create a view class:

module NavigationHelper
  class RepositoryNavigationView
    include ActionView::Helpers::NumberHelper

    attr_reader :current_user, :current_repository

    def initialize(user, repo)
      @current_user = user
      @current_repository = repo
    end

    # What symbols should we trigger highlighting for various tabs?
    #
    # Returns an array of symbols.
    def highlights_for_code
      [:repo_source, :repo_downloads, :repo_commits, :repo_tags, :repo_branches]
    end

    def highlights_for_pulls
      [:repo_pulls]
    end

    def highlights_for_issues
      [:repo_issues]
    end

    # Should we show the wiki tab? We try and show it when it's useful to
    # someone using these rules:
    #
    # - Never show it if the wiki is disabled under the admin section.
    # - Show it if you have admin access to the repository
    # - Show it if there is content
    #
    # Returns true to show the tab.
    def show_wiki?
      return false unless current_repository.has_wiki?
      return true if logged_in? && current_repository.pushable_by?(current_user)
      current_repository.wiki.page_count > 0
    end

  end
end

Nicely documented, isolated from application-wide helpers and easy to find. Inside of the html.erb, create a new instance of this view object:

<% view = NavigationHelper::RepositoryNavigationView.new(current_user, current_repository) %>

<% unless @omit_repository_toolbar %>
  <ul class="tabs">
    <li><%= selected_link_to "Code", code_path, :highlight => view.highlights_for_code %></li>
    <li><%= selected_link_to "Network", network_path, :highlight => view.highlights_for_network %>
    <li><%= selected_link_to "Pull Requests", pull_requests_path, :highlight => view.highlights_for_pulls %></li>

    <% if view.show_issues? %>
      <li><%= selected_link_to "Issues", issues_path, :highlight => view.highlights_for_issues %></li>
    <% end %>

    <% if view.show_wiki? %>
      <li><%= selected_link_to "Wiki", wikis_path, :highlight => view.highlights_for_wiki %></li>
    <% end %>

    <li><%= selected_link_to "Stats &amp; Graphs", graphs_path, :highlight => view.highlights_for_graphs %></li>
  </ul>

  <%= render_subnav 'repositories/code',        view.highlights_for_code %>
  <%= render_subnav 'repositories/network',     view.highlights_for_network %>
  <%= render_subnav 'repositories/graphs',      view.highlights_for_graphs %>
  <%= render_subnav 'repositories/wiki',        view.highlights_for_wiki %>
<% end %>

If you’re used to regular ERB templates it’s immediately obvious where this data comes from — it’s right at the top of the file! Ack the project for RepositoryNavigationView and you’ve found your view class. No magic.

One huge advantage of this tactic is that you can still use all the same Rails/ERB shortcuts for quick prototyping. If someone doesn’t want to learn the new template strategy right away, they can use the same methods they’ve been using for years.

Graceful upgrade path

Switching templating languages is something that needs to be done gracefully when you’re working with others. Ripping out everyone’s foundation is a recipe for unhappy developers. Rails is all about patterns, and sticking to those patterns is really important.

This strategy allows us to slowly convert the codebase to a better documented, view/template separation that anyone who’s worked with ERB can understand. And if we choose to switch to true-and-blue Mustache some day, our code will be 80% there already.

Brew Methods

2011-09-20T00:00:00-07:00

A wonderfully simple site dedicated to the art and style of creating fine coffee. Learn how to use that Chemex properly!

Design Hacks for the Pragmatic Minded Video

2011-09-05T00:00:00-07:00

The Ruby on Ales folks got around to publishing the video of my Design Hacks talk. The audio is a little weird in the begining, but hang on — it clears up a few minutes in.

Relentless Quality

2011-08-25T00:00:00-07:00

If there’s one thing I’ll remember about Alex Mahernia, it’s footer spacing. Here we are at 10pm in the office and we’d be trying to launch a site. The only thing left is an A-OK from the creative director. And without fail, he’d yell at me to come into his office and point at his screen. “The footer spacing is too big on this page.” So I’d go back to battle the CSS until every single page on the site had consistent footer spacing in every browser.

Motherfucking footer spacing.

And what did it matter? Are our clients really going to lose customers because there’s an extra 10 pixels of footer spacing in IE6 on one of the pages? Is the client going to refuse payment because of these pixels? HOW MUCH BLOOD ARE THESE PIXELS WORTH?

But it was never about the footer spacing. It was about quality. It was about cultivating a culture of relentless quality in everything we produced.

Quality versus the Ego

Every time Alex called me into his office and showed me a page with an extra 7 pixels of spacing my blood pressure went through the roof. I took it as a personal insult. But he wasn’t insulting me. It was about producing a quality product.

Quality has no room for egos. Other people will have better solutions. You are going to miss things. You are going to break things. You are going to make mistakes. And people are going to point it out.

And I think it’s okay to get upset. Take that feeling and turn it inwards. Vow to make things better. Make sure you’re always producing the best quality product you can.

Move fast and break things

If you take a look at any of Facebook’s recruiting marketing, you’ll see a phrase repeated over and over:

Move fast and break things

And with good reason — the idea it embodies is fantastic. Unfortunately I see a lot of people interpreting this quote as something like this:

It reminds me of another misinterpretation that’s always bugged me:

Quality isn’t something to be sacrificed. Move fast and break things, then move fast and fix it. Ship early, ship often, sacrificing features, never quality.

Embrace change. Ship. Never cut corners.

Quality is contagious

Which reminds me of the broken windows theory:

Monitoring and maintaining urban environments in a well-ordered condition may prevent further vandalism as well as an escalation into more serious crime.

Broken windows are the reason most large software projects suck to work on. A little technical debt here, a few shortcuts there, and pretty soon you’ve got a codebase so full of broken windows that no one even cares if they throw another pile of broken glass on the heap.

But just as broken windows are contagious, so is a dedication to quality. Carve out a little piece of a messy codebase and clean it up. Sharpen the edges, polish the surface and make it shine.

The caveat here is that you can’t half-ass quality. Dedication to “semi-quality” isn’t dedication at all. High-end design coupled with mediocre engineering can only produce a mediocre result.

And I don’t know about you, but I don’t dream of building mediocre. I dream of building the best. So I’m thankful to Alex for instilling this idea of relentless quality in me, even if I still have footer spacing related nightmares from time to time.

Deploying: Then & Now

2011-08-02T00:00:00-07:00

A couple months ago I got up on stage during lightening talks at CodeConf 2011 to talk about our friendly robot, Hubot.

Inside of five minutes I logged into our Campfire room with spotty WiFi, asked Hubot a favor, and he deployed a major new feature to our site — Issues 2.0. A deploy spanning around 30 servers that changed a major feature for 800,000 users. It was pretty awesome and kind of a ridiculous thing to do.

Rewind the clock 7 years ago and I had just landed my first steady job in the tech industry — a front end developer for a big interactive agency.

I remember one of our clients had a static HTML website that I was in charge of maintaining. We had a 45 minute window occurring once a week where we could deploy their site.

Once a week, I generated a list of files I’d changed since the last week so a System Administrator could FTP the files over to production. Any changes to production I needed that occurred outside that 45 minute window required manager intervention.

Recap time.

2004

System Administrator time required to deploy every website.
Deploys scheduled by managers once a week.
Manually generating lists of changed files.
Simple deploys take 30+ minutes.

2011

Deploying on stage for the hell of it.
System Administrator probably drinking whiskey.

2011 is pretty fucking awesome.

Deployment is an art. And the style in which you deploy impacts your company culture more than you think. Deploy with style.

Designing GitHub for Mac

2011-06-28T00:00:00-07:00

A few days ago we lifted the curtains on a project I’ve been deep into for a long time now: GitHub for Mac. This is the first OS X app I’ve designed and thought it might be interesting to share some of the process and things I learned throughout development.

Why should we build it?

For a long time I assumed OS X developers would see the immense market for an awesome Git application. Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons.

Clients claiming to be “simple” choose to redefine “simple” as fewer supported Git commands rather than simplifying the interaction with Git.

It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial & Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home.

Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub. And since we all use Macs — we should start off with an OS X application. Build what you know/use, expand from there.

What are we building?

Personally, I had some big goals:

Death of the SSH key. People should be able to connect to GitHub with their GitHub username and password.
Make it obvious that there is a distinction between remote and local. Make it clear what commits need to be pushed before others can see them.
Simplify the git fetch, pull (--rebase), push interaction. Synchronize — don’t make the user figure out what they need to do to get their local commits remote and remote commits local.
Fix the local/remote branching problem. Get rid of this tracking idea — interact with local or remote branches as if they were no distinction between the two.

I didn’t want to replace the command line. I wanted to build an awesome version control client. As it happens, Git is the perfect backend to do that — and GitHub is the perfect central server to collaborate.

Sketches & early ideas

The first thing we did was to start populating an internal wiki full of ideas. Lots of words, lots of sketches.

Incomprehensible pages from my Moleskine

Scott created a bunch of mockups with Balsamiq

Let’s get some designers on this

I’d been using OS X for years, but I didn’t feel comfortable designing a native app. My previous attempts at OS X design weren’t too fantastic…

In the end, we hired Eddie Wilson to come up with some wireframes and some comps while Joe and Josh cranked away at the Cocoa backend. His first comps were a great start, and influenced the end product tremendously.

Unfortunately right about this time is when we learned how much we suck at working with contractors. We’re extremely opinionated, really bad at expressing our opinions, and change our minds all the time. We asked Eddie to hold off while we re-grouped and figured out what we wanted from the app.

We sat down and had a lot of discussions about how we wanted this thing to work. Brandon Walkin helped out quite a bit, and even sketched up some wireframes & notes for us.

Eventually we figured out what we wanted to design — but now we didn’t have anyone to design it. Eddie had since taken up other work and pretty much every Cocoa designer on the planet was inundated with work.

In the end, I decided that GitHub for Mac was the thing I wanted out of GitHub, and if I wanted it to happen I’d have to take the design reins. I picked up Eddie’s comps and ran with it.

A slow process

I tried my best to combine Eddie’s original comps with our internal feedback and match it up with a modern OS X look & feel. All in all I created 45 comps for 1.0 — each with about 5-10 unique states (with layer groups).

After the first round of comps, I started writing down how I imagined everything to work.

My plan was to fully flesh out this styleguide — but as it happened, Josh was able to implement my designs faster than I could explain them. Still, I think it was a good exercise to explain my thinking for the designs — if anything for my own personal benefit.

The aesthetic

Learning the OS X aesthetic wasn’t easy. And it probably didn’t help that I started to get serious about OS X design about the same time Lion screenshots started showing up. Like it or not, OS X app design is changing in drastic ways right now.

Scrollbars are a thing of the past. Titlebars full of clickable areas. Buttons shedding themselves of borders. Custom graphics / buttons for every app. And Helvetica everywhere!

I tried my best to weigh this new direction with a lot of my favorite designed apps — Twitter, Espresso, Sparrow, and Transmit to name a few.

Tweetie style side-tabs. No title in the window, instead a breadcrumb — always promoting a one-window experience.

We use a lot of popovers (borrowed from iOS / XCode) rather than modal windows throughout the app.

Subtle buttons in the title bar.

Lessons learned

Designing a native OS X app was definitely full of surprises. I’ve actually done quite a bit of native development before with WPF & Flex — but Cocoa is quite different.

Welcome to 2004 — everything is a sliced image

Remember web development in 2004? When you had to create pixel-perfect comps because every element on screen was an image? That’s what developing for Cocoa is. Drawing in code is slow and painful. Images are easier to work with and result in more performant code.

Remember these days?

This meant my Photoshop files had to be a lot more fleshed out than I’ve been accustomed to in recent years. I usually get about 80% complete in Photoshop (using tons of screenshotting & layer flattening), then jump into code and tweak to completion. But with Cocoa, I ended up fleshing out that last 20% in Photoshop.

Change is painful

Want to move an element from the bottom of the screen to the top? A lot of times with Cocoa this involves rewriting your entire view. There is no layout engine for Cocoa. If you want two elements to rest side to side, you’ll need to calculate the pixel size of the text, padding, borders, margins — then manually position the next element.

What about Interface Builder? Pretty useless. Everything is a blue box on complex projects.

Want to change the background color of a button? You’re probably going to have to rewrite all of the drawing code for the button. There is no styling engine in Cocoa.

This sucks. And it means that change is insanely painful in code. It’s much easier to prototype with HTML / CSS and see if the design is going to hold up.

This proposed changes redesign is a good example of what I mean. I spent a long time creating a “clickable” prototype with animations. In the end, we decided a lot of the core ideas were wrong and decided not to go down that path. Creating this HTML/CSS/JS prototype took a couple days. Doing the same in code would have taken a lot longer — and been much harder to throw away (due to the way project files work in Xcode, branching is not simple).

Objective-C is easy, Cocoa is hard

This was the first serious Cocoa project I’ve been involved with. I had dozens of little example projects, but never pushed through to ship anything. As I went on and talked to people about my frustrations, they inevitably came up with the same response:

Why don’t you just use MacRuby?

Why? Because Objective-C is really easy. The language was never a problem. You know what was? Cocoa. Learning the differences between layer-backed views, layer-hosted views — understanding that you have to subclass everything — balancing delegates, weak connections, strong connections, KVC, view controllers, and notifications — understanding little intricacies like how AppKit flips .xibs when it load them up or how hard it is to make one word in a sentence bold. I’m not going to lie: Cocoa (that is: AppKit, UIKit, Core Text, Core Animation, etc) is extremely difficult. The gap between simple example apps and a fully functional application is huge.

Projects like Chameleon that give you a purely layer-backed environment to work with using a modern API (UIKit) matter far more than the language you’re using. This isn’t to say MacRuby isn’t awesome — it just means that it doesn’t make AppKit development any easier; you still have to learn Cocoa.

Along those same lines, I think that Cocoa is dying for a framework. Something that weighs on the simple defaults side rather than complex code generation side.

Secrecy is overrated

GitHub for Mac was in development for just under a year and there was never any leaked screenshots or blog posts. In fact, there were dozens of public screenshots of the app on dribbble — but for the most part, people were surprised when we launched.

We didn’t have beta testers sign NDAs or demand first-borns to get access to the early builds. How on earth did we keep something under wraps for so long?

We asked people politely not to share it with the world. It’s really not that hard. Don’t send betas to douchebags. Politely ask people not to blog about it. Done.

Here’s to a bright future

I’m hoping that GitHub for Mac (and supporting projects, like libgit2) spurs a new round of creativity in source control clients. I’ve already seen some progress — like legit — but I’m hoping to see a new generation of source control clients in the future. Git is immensely powerful, and it’s up to us to leverage that power into something awesome.

Excellent embedding markup

2011-06-15T00:00:00-07:00

I was playing around with Twitter’s new Follow Button and I couldn’t help but notice that the embedding markup is some of the best I’ve ever seen.

<a href="http://twitter.com/kneath" class="twitter-follow-button" data-show-count="false">Follow @kneath</a>
<script src="http://platform.twitter.com/widgets.js" type="text/javascript"></script>

I love the idea of using regular HTML with feature-flags in data attributes combined with a common script. Can’t wait to play around with this style on Gist.

Build your business around an idea

2011-06-14T00:00:00-07:00

Living in San Francisco and working in tech right now is absolutely insane. Employers and recruiters battle for employees while VCs rain down millions of dollars without meeting founders or even knowing what kind of company they’re building. It’s a crazy world to live in and can feel like money is growing on trees and the only spending limit is your imagination. If you have just a little bit of initiative, you can take any idea and start a company with absolutely zero personal risk.

And that’s one of the biggest reasons San Francisco is so special to me. Everyone out here knows they can do anything. Spend a few weeks hanging out in bars and cafes asking what people do and you’ll hear some of the most idiotic business ideas in the world. A lot of journalists use this argument to call San Francisco an echo chamber whose sole purpose is burning money. And you know, they’re right.

This city does burn through money on terrible ideas. But that’s a tradeoff for fostering a city of people who believe they can do anything. And that spawns an incredible number of amazing companies — so it doesn’t bother me. What does bother me is the lack of imagination most startup founders have.

Build something incredible

Most founders I talk to are pretty complacent building something mediocre. They won’t admit if you flat out ask them — but try pressing them to describe what makes their company special. Most cop out and give you an answer like:

We’re building [technology x] because [company y] hasn’t built it and [people z] need it.

Want a more concrete example? How about something like:

We’re building a cloud sync solution for iOS because Apple hasn’t built it and almost every iOS application needs sync.

There are thousands of people building products like this. They’re filling holes. Filling holes is mediocre and boring. Dare to build something incredible – something unique, something lasting, something special.

Ideas are lasting, products are not

The easiest way to build something incredible is to base your business around an idea. Products are just the manifestation of the idea.

This is something I think about at GitHub a lot. We’ve built an amazing product (github.com) — but when you ask us what the company is about we say:

We make it easier to collaborate with others and share your projects with the universe.

There’s a lot of interesting things you don’t see it that description: Git, version control, issue tracking, wikis, or website. We know that our product (a website hosting git repositories with built-in issue tracking & wikis) is great — but if it doesn’t serve a higher purpose, it would be mediocre. So we focus on the idea.

That means looking at version control, wikis, and issue tracking as tools for collaboration. It means that as important as it is for our website to be easy to use — it’s equally important for Git to be easy to use. Or to create tools that let people use Git without even knowing they’re using Git.

If I look into the future, I know that the idea of collaboration is lasting — but Git? That’s a hard bet to make. I know that if we focus our business on collaboration we can build something lasting. If we focus our business on being a Git host we’re doomed.

Ideas are sexy

One of the more awesome things about building your business around an idea is how easy it is to pitch to others. Ideas are sexy and draw people in — they invite passion and commitment. And pitching people is all about displaying passion and commitment. It doesn’t matter if you’re pitching for VC funding, trying to land a new customer, or interviewing a prospective employee — having a good pitch is critical to any successful business.

People want to be part of ideas. Being part of a company who builds a successful product is cool… but being part of an idea is a lot more attractive. If you can build a business where both your employees and your customers think they’re part of an idea, you’ve created something special.

Evolving ideas from products

The trouble is that founding a company around an idea doesn’t actually work. Apple ~~Computer~~ is a great example. They take bleeding edge technology, marry it with exceptional design, and sell it at a premium price. But the company wasn’t always like that. It was founded around a product — the personal computer. Yet in 2011, Apple’s biggest business is mobile phones.

You have to ask… how did a company founded around building personal computers come to generate most of its revenue from mobile phones? They evolved. They found their strengths (design, technology), and evolved the company around those values. This manifested itself into new products — the iPod, iPhone, iPad, TV, MobileMe, Airport Expresses, Cinema Displays, etc. Some successes. Some failures.

The core component of all these products is that they are manifestations of an idea. When the iPod took off in popularity, Apple didn’t rearrange the company around portable music devices. They kept focusing on building exceptionally designed hi-tech gadgets with bleeding edge technology.

So it’s okay to focus on a product at first. But as soon as you find your strengths as a company, abstract it out into an idea and focus on that. Do that and you won’t have your entire business invalidated by a feature that Facebook or Apple rolled out at their last keynote. Because ideas will last, products won’t.

Infinite Scroll + HTML5 History API

2011-05-31T00:00:00-07:00

Something I’ve been meaning to do for a while — here’s a little experiment using the HTML5 History API and infinite scrolling to kill off “next page” links and still maintain real URLs that persist across page views.

In my perfect world, this is how Twitter, Facebook and Tumblr’s infinite scrolling would work.

Product design at GitHub

2011-03-30T00:00:00-07:00

Product design is easily the hardest aspect of building software today. Technology, hiring, funding, aesthetic design, and press are all minuscule in comparison. When I talk about product design I’m referring to the process by which you decide what your product does and does not do. I happen to think we do a pretty good job of this at GitHub, and I’d like to give you a bit of an insight into our process and hopefully shed some light on why it works so well.

I should warn you that I am not a “Product Designer.” We don’t have titles at GitHub — we let employees pick their own. I like to call myself ~designer since I mostly focus on the look & feel of our product. But then again, I spent the past weekend building an application to track & distribute binaries and updating some of our reducing functions to support a newer version of MongoDB. So, yeah. I’m ~designer. But maybe that leads me to my next point…

Everyone is a product designer

Every employee at GitHub is a product designer. We only hire smart people we trust to make our product better. We don’t have managers dictating what to work on. We don’t require executive signoff to ship features. Executives, system administrators, developers, and designers concieve, ship, and remove features alike.

Having the role of “Product Designer” or having a CEO who says they’re going to “focus on product design now” never made much sense to me. Aren’t you hiring smart people who use your product? Don’t you trust your employees? Doesn’t everyone at your company want to make your product better? Doesn’t that make everyone product designers all of the time?

Along these lines, my two favorite questions to ask in an interview (or to people who don’t know they’re interviewing) are:

What would you like to see in GitHub?
What feature do you think we messed up / should remove?

It brings out the passion in people and instantly highlights problems you might have with their decisions. Some people just don’t have the same vision for your product as you do, and that’s fine.

Write down ideas like crazy

Our internal wiki is filled with ideas. Old ideas. Bad ideas. Good ideas. Half-baked ideas. The point is that we have a place to share our crazy with each other. This wiki page discussing compare view eventually became Pull Requests 2.0 — arguably the best code review tool I’ve ever used.

Most of the time when someone adds an idea it’s nothing original. It’s something we’ve discussed in person, seen in another product, or maybe thought about ourselves. But that’s really half the point — seeing someone else write down the same idea you’ve had makes you twice as excited about the idea. As others chime in saying they’d love to see the feature, excitement about it grows and grows. Eventually you’ve got 4 developers hacking on something at 11:30pm because they want to see it happen so badly.

Constantly experiment and iterate

Right now our main repository has 65 branches. This doesn’t count the dozen or so other repositories that collectively represent what is https://github.com or the 139 repositories under our organization. Needless to say, there are a ton of features, anti-features and half ideas in these branches. Sometimes they’re really pretty features that aren’t functional and sometimes they’re really ugly features that are completely functional.

We’re always sending pull requests, shipping them to staging and asking others what they think. Talking about a feature in a meeting and crafting a spec is one thing, but coding up a working prototype is way more effective. We’re always running experimental features in production to staff only. No better way to see if a feature is going to fit than to actually use it.

Once a feature is out and ready for people to use there’s about a 100% chance that someone is going to want to change some aspect of it. So we iterate — tweak, deploy, discuss in a pull request — over and over until it’s good enough for public consumption.

On that note, our pull requests are generally pretty epic. It turns out that pull requests are perfect for experimenting with new features, discussing them with the team, and getting others to help you ship. Check out this pull request for shipping our org profiles. (Funny anectdote: this pull request was created before we shipped pull requests 2.0 — we constantly use experimental features)

Abandon features

You can’t run a product and pretend that every one of your ideas is perfect. You’re going to have bad ideas, ideas that don’t fit, and features that become abandoned. Don’t be afraid to abandon ideas. The amount of time you spend on something is meaningless. You’re not losing anything by throwing work away — you’re choosing not to make your product worse.

The first version of http://jobs.github.com that we built didn’t share a single piece of functionality with what shipped on day one. It wasn’t an iteration — we straight up threw away a few months of work because we realized it was a bad idea. We started using our creation and realized we couldn’t figure out how to make money without pissing off our customers. So we abandoned that idea and started anew — even though we could have shipped it and started making money immediately.

Shipping features because you spent time or money on them is a coward’s excuse. It takes balls to abandon features — grow some.

Argue all the time

We do not have a quiet workplace. We argue in bars, in Campfire and in email. New hires and CEOs alike. But it’s not personal — it’s about making our product better. If you’re not forced to rationalize your product choices, who’s to say you’re making good decisions?

Arguing with your co-workers isn’t a bad thing. It’s not creating a negative work environment — it’s a tool to help you make good decisions. Being an empty cheerleader and telling everyone that their idea is great is harmful and short-sighted. Argue and make good decisions.

Talk to your customers

I spend a good portion of my day reading through our support site, mailing lists, twitter feeds, and blog posts written about git and GitHub. Listening to your customers is supremely important — they’re full of great ideas. They’re also full of shockingly terrible ideas. As Tom puts it:

Don’t give your customers what they ask for; give them what they want.

We also spend a lot of physical time with our customers. We have monthly meetups here in San Francisco, and you can pretty much guarantee that anyone who’s traveling will host a meetup in whatever city they’re in. People can get crazy online. It’s a lot harder to spout out that crazy when you’re talking to someone face to face. It forces people to really think about what they’re going to say and reminds them that there’s a living, breathing human being behind the product.

Product design is in the eye of the beholder

We know that product design isn’t just adding and removing features. It’s how our customers perceive the features. Who cares if some analyst thinks your company is doing well if your customers don’t?

Having a great blog post explaining new features is absolutely killer. It allows us to frame features in a certain light and explain our thinking. It also shows a record of shipping — and we try hard to ship and tell people about it all of the time.

If you redesign your entire product once every two years like Twitter does, it’s a big deal. If your users don’t like 100% of it, they’re going to be pissed. But if you ship something every two months and they don’t like 10% of it — their overall perception is still positive.

We also know that what we don’t do is just as important as what we are doing. We don’t publish roadmaps or promise features within a timeframe — we under promise and over deliver. And really, I think that’s why our customers are so happy with our product design as a whole.

Don’t give your customers what they ask for, give them what they want. Under promise, over deliver.

Design hacks for the pragmatic minded

2011-03-24T00:00:00-07:00

Slides and references links from my presentation I gave at Ruby on Ales – Design hacks for the pragmatic minded.

Documentation is freaking awesome

2011-02-05T00:00:00-08:00

Slides and references links from my presentation I gave at Magic Ruby – Documentation is freaking awesome. Check it out if you’re curious.

Speaking at Magic Ruby

2011-01-04T00:00:00-08:00

I’ll be giving a talk about documentation (no, not just code comments and RDoc) at Magic Ruby February 4th-5th. Oh, did I mention it’s in Disneyworld? And it’s free?

URL Design

2010-12-28T00:00:00-08:00

You should take time to design your URL structure. If there’s one thing I hope you remember after reading this article it’s to take time to design your URL structure. Don’t leave it up to your framework. Don’t leave it up to chance. Think about it and craft an experience.

URL Design is a complex subject. I can’t say there are any “right” solutions — it’s much like the rest of design. There’s good URL design, there’s bad URL design, and there’s everything in between — it’s subjective.

But that doesn’t mean there aren’t best practices for creating great URLs. I hope to impress upon you some best practices in URL design I’ve learned over the years and explain why I think new HTML5 javascript history APIs are so exciting to work with.

Why you need to be designing your URLs

The URL bar has become a main attraction of modern browsers. And it’s not just a simple URL bar anymore — you can type partial URLs and browsers use dark magic to seemingly conjure up exactly the full URL you were looking for. When I type in resque issues into my URL bar, the first result is https://github.com/defunkt/resque/issues.

URLs are universal. They work in Firefox, Chrome, Safari, Internet Explorer, cURL, wget, your iPhone, Android and even written down on sticky notes. They are the one universal syntax of the web. Don’t take that for granted.

Any regular semi-technical user of your site should be able to navigate 90% of your app based off memory of the URL structure. In order to achieve this, your URLs will need to be pragmatic. Almost like they were a math equation — many simple rules combined in a strategic fashion to get to the page they want.

Top level sections are gold

The most valuable aspect of any URL is what lies at the top level section. In my opinion, it should be the first discussion of any startup directly after the idea is solidified. Long before any technology discussion. Long before any code is written. This is top-level section is going to change the fundamentals of how your site functions.

Do I seem dramatic? It may seem that way — but come 1,000,000 users later think about how big of an impact it will be. Think about how big of a deal Facebook’s rollout of usernames was. Available URLs are a lot like real estate and the top level section is the best property out there.

Another quick tip — whenever you’re building a new site, think about blacklisting a set of vanity URLs (and maybe learn a little bit about bad URL design from Quora’s URLs).

Namespacing is a great tool to expand URLs

Namespaces can be a great way to build up a pragmatic URL structure that’s easy to remember with continued usage. What do I mean by a namespace? I mean a portion of a URL that dictates unique content. An example:

https://github.com/defunkt/resque/issues

In the URL above, defunkt/resque is the namespace. Why is this useful? Because anything after that URL suddenly becomes a new top level section. So you can go to any <user>/<repo> and then tack on /issues or maybe /wiki and get the same page, but under a different namespace.

Keep that namespace clean. Don’t start throwing some content under /feature/<user>/<repo> and some under /<user>/<repo>/feature. For a namespace to be effective it has to be universal.

Querystrings are great for filters and sorts

The web has had a confused past with regards to querystrings. I’ve seen everything from every page of a site being served from one URL with different querystring parameters to sites who don’t use a single querystring parameter.

I like to think of querystrings as the knobs of URLs — something to tweak your current view and fine tune it to your liking. That’s why they work so great for sorting and filtering actions. Stick to a uniform pattern (sort=alpha&dir=desc for instance) and you’ll make sorting and filtering via the URL bar easy and rememberable.

One last thing regarding querystrings: The page should work without the querystrings attached. It may show a different page, but the URL without querystrings should render.

Non-ASCII URLs are terrible for english sites

The world is a complicated place filled with ¿ümlåts?, ¡êñyés! and all sorts of awesome characters ☄. These characters have no place in the URL of any english site. They’re complicated to type with english keyboards and often times expand into confusing characters in browsers (ever see xn--n3h in a url? That’s a ☃).

URLs are for humans — not for search engines

I grew up in this industry learning how to game search engines (well, Google) to make money off my affiliate sales, so I’m no stranger to the practice of keyword stuffing URLs. It was fairly common to end up with a URL like this:

http://guitars.example.com/best-guitars/cheap-guitars/popular-guitar

That kind of URL used to be great for SEO purposes. Fortunately Google’s hurricane updates of 2003 eliminated any ranking benefit of these URLs. Unfortunately the professional SEO industry is centered around extortion and still might advise you stuff your URLs with as many keywords as you can think of. They’re wrong — ignore them.

Some additional points to keep in mind:

Underscores are just bad. Stick to dashes.
Use short, full, and commonly known words. If a section has a dash or special character in it, the word is probably too long.

URLs are for humans. Design them for humans.

A URL is an agreement

A URL is an agreement to serve something from a predictable location for as long as possible. Once your first visitor hits a URL you’ve implicitly entered into an agreement that if they bookmark the page or hit refresh, they’ll see the same thing.

Don’t change your URLs after they’ve been publicly launched. If you absolutely must change your URLs, add redirects — it’s not that scary.

Everything should have a URL

In an ideal world, every single screen on your site should result in a URL that can be copy & pasted to reproduce the same screen in another tab/browser. In fairness, this wasn’t completely possible until very recently with some of the new HTML5 browser history Javascript APIs. Notably, there are two new methods:

onReplaceState — This method replaces the current URL in the browser history, leaving the back button unaffected.
onPushState – This method pushes a new URL onto the browser’s history, replacing the URL in the URL bar and adding it to the browser’s history stack (affecting the back button).

When to use `onReplaceState` and when to use `onPushState`

These new methods allow us to change the entire path in the URL bar, not just the anchor element. With this new power, comes a new design responsibility — we need to craft the back button experience.

To determine which to use, ask yourself this question: Does this action produce new content or is it a different display of the same content?

Produces new content — you should use onPushState (ex: pagination links)
Produces a different display of the same content — you should use onReplaceState (ex: sorting and filtering)

Use your own judgement, but these two rules should get you 80% there. Think about what you want to see when you click the back button and make it happen.

A link should behave like a link

There’s a lot of awesome functionality built into linking elements like <a> and <button>. If you middle click or command-click on them they’ll open in new windows. When you hover over an <a> your browser tells you the URL in the status bar. Don’t break this behavior when playing with onReplaceState and onPushState.

Embed the location of AJAX requests in the href attributes of anchor elements.
return true from Javascript click handlers when people middle or command click.

It’s fairly simple to do this with a quick conditional inside your click handlers. Here’s an example jQuery compatible snippet:

$('a.ajaxylink').click(function(e){
  // Fallback for browser that don't support the history API
  if (!('replaceState' in window.history)) return true

  // Ensure middle, control and command clicks act normally
  if (e.which == 2 || e.metaKey || e.ctrlKey){
    return true
  }

  // Do something awesome, then change the URL
  window.history.replaceState(null, "New Title", '/some/cool/url')
  return false
})

Post-specific URLs need to die

In the past, the development community loved to create URLs which could never be re-used. I like to call them POST-specific URLs — they’re the URLs you see in your address bar after you submit a form, but when you try to copy & pasting the url into a new tab you get an error.

There’s no excuse for these URLs at all. Post-specific URLs are for redirects and APIs — not end-users.

A great example

ASCII-only user generated URL parts (defunkt, resque).
“pull” is a short version of “pull request” — single word, easily associated to the origin word.
The pull request number is scoped to defunkt/resque (starts at one there).
Anchor points to a scrolling position, not hidden content.

Bonus points: This URL has many different formats as well — check out the patch and diff versions.

The beginning of an era

I hope that as usage of new Javascript APIs increases, designers and developers take time to design URLs. It’s an important part of any site’s usability and too often I see URLs ignored. While it’s easy to redesign the look & feel of a site, it’s much more difficult to redesign the URL structure.

But I’m excited. I’ve watched URLs change over the years. At times hard-linking was sacrificed at the altar of AJAX while other times performance was sacrificed to generate real URLs for users. We’re finally at a point in time where we can have the performance and usability benefits of partial page rendering while designing a coherent and refined URL experience at the same time.

My TextMate Snippets & Triggers

2010-08-26T00:00:00-07:00

A while ago I put up a collection of some of my handcrafted TextMate snippets. mostly focused on front-end stuff: HTML shortcuts, CSS gradients, jQuery plugin bases, commenting helpers, etc.

The Geek Talk Interview

2010-08-23T00:00:00-07:00

A quick interview I did over at The Geek Talk. Mostly covering my daily routine and whatnot.

RSS Feeds for Warpspire

2010-08-23T00:00:00-07:00

I was going to try and fix some bugs in GitHub Pages (that’s how this site is hosted) — but I think I’m going to give up that fight. If you’d like to subscribe to Warpspire, you can find the feeds at http://feeds.feedburner.com/warpspire

Rethinking Warpspire

2010-08-01T00:00:00-07:00

I think it’s always a good idea to take a step back and ask yourself why you’re doing something. So right now I’m taking a step back to rethink Warpspire.

Getting rid of cruft

The other day I followed a link to a blog post on Mint. I was presented with this screen:

I hate what most designers have done to the web. You’d think people would be taking cues from things like Readability and Safari Reader, but they’re not. People are throwing more and more crap onto each page and making things harder and harder to read.

Anyways, it got me to thinking about sites that I continue to enjoy reading in the browser. One site that immediately came to mind is Daring Fireball. The format and presentation has lasted for years without feeling tired or hard to read. So it should come as no suprise that this new layout mirrors DF in a great number of ways. (Alas, my logo features the same unicode character as DF — something which has now turned from a funny coincidence to a long boring story. I hate logos.)

This new layout is the simplest layout I’ve ever had on one of my sites. The goal was to create a focused place for my ideas.

Abandoning old baggage

There was a lot of crap on Warpspire. WordPress tells me the first post was published August 15, 2004. That’s six years ago. To say that the web is a different place now is an understatement. I remember debugging that initial site on IE5 for Mac. Six years ago, I was in my 2nd year of studying Civil Engineering at Cal Poly. I had no concept of the value of the web or how important it would be come. I was also twenty years old, angsty and wrong about many things.

So I deleted most of my posts.

What’s left? The most popular posts (traffic wise) along with a couple of ones that I particularly enjoyed and still felt relevant. I’ve also edited them all, and rewritten some.

Almost certainly a bad idea for my traffic, but probably a good idea for my readership. And I’ll value readers over pageviews any day.

On the subject of comments

The thing about comments is that commentors tend to be a bunch of crazies wandering the internet like it’s a zombie apocolypse. It’s a striking contrast to the rational human beings whom I have sensible arguments with here in the meatspace.

The thing is, I’ve met some of the smartest people on the planet through my site and I don’t want to lose that. So here’s the deal: you send me email, and I send you one back. If I think others might be interested in what you have to say, I’ll post it here on Warpspire.

A comment should mean something to you and it should mean something to me. Typical blog comments just stopped meaning anything to me a long time ago and that sucks. So I’m hoping this is a move toward fixing that.

What's your focus?

2010-03-29T00:00:00-07:00

Every great website has a focus. If you can’t summarize the purpose of your website into one sentence, ten words or less — your idea will almost certainly fail. Talking to founders, I’d say this idea is pretty well established. Now let me reveal a secret that is not so well established: your website’s design should follow this same focus.

Learn by example: source hosting sites

Let’s start off with a field I’m pretty familiar with: source hosting sites. I’m talking about GitHub, BitBucket, SourceForge, Google Code, Launchpad and the likes. These sites all have a common focus: sharing code. I’m going to show you why GitHub is the only site who’s design follows it’s focus.

If your site’s focus is sharing code, the design should focus on sharing code. If you ever talk to any of us GitHubbers, we’ll always say that the site is all about the code. Let’s look at project landing pages in each of the above sites.

GitHub

When you visit a GitHub project page, the first thing you see is the source code. Right below is the README pulled straight from the code.

BitBucket

BitBucket chose to highlight the shortlog (recent commits) on the project page. If you want to see the code, you need to go to the 3rd tab.

SourceForge

Sourceforge chose to highlight downloads (in this case, a compiled jar file — not the code) on the project page. If you want to see the code, you need to click Develop, and then fish around in the sidebar for the correct VCS and click browse.

Google Code

Google Code chose to highlight the wiki on the project page. Getting to the code in Google Code is probably the most interesting of the bunch because many projects don’t even host their code there (example: redis).

When you click the Source tab you actually get a wiki page which many projects use to point to another repository. If the project hosts it’s code there, there is a sub link under Source that is labeled Browse that you can finally see the code.

Launchpad

Launchpad decided to highlight everything but the source code on the project page. If you want to see the code, there is a tiny link in the middle of the page that says ’View the branch content.’

Great examples from other fields

Source code hosting is just something that I’m extremely involved with. That doesn’t mean that focus is limited to code.

Flickr

Flickr is all about sharing photos.

Facebook

Facebook is all about connecting with your friends.

Daring Fireball

Daring Fireball is all about John Gruber’s writing.

Sites that have lost their focus

There is a huge genre of sites that seem to have completely forgotten their focus. I’ll see if you can guess the genre.

MSNBC

NYTimes

Rolling Stone

It’s no wonder news sites can’t get people to pay for their content. You need to focus on your content to get people to pay for it.

Charging for your focus

Many sites don’t want to give away their focus for free. That’s perfectly fine. But it doesn’t change a thing. Replace what people are going to pay for with an opportunity to pay you.

PeepCode’s focus is great tutorials. But the tutorial is not the focus of the product page — instead a teaser and a purchase button are.

Lots of people think that replacing their paid focus content with advertising is the solution — but that just redirects the focus on advertising — not getting paid.

Premium content is not about removing access, it’s about charging for access. Don’t focus on removing content, focus on charging for it.

Find your focus and focus on it

If you work on a website for a living, you should be thinking about your focus every single day. It doesn’t matter if you’re a copywriter, project manager, designer or sysadmin. What’s the focus of your site? Does your design reflect this? Run that through your head for every decision.

The beautiful thing about focus is that it’s not about the details. It doesn’t matter if you add some advertising to a sidebar, links to your header, change the background color or add administrative debris — these are all minor subjects. Focus is more about aiming in the right direction. Worry about the details later — but never aim in a different direction.

Optimizing asset bundling and serving with Rails

2009-11-19T00:00:00-08:00

I wrote up a pretty lengthy post over at the GitHub blog explaining how we do asset bundling and serving. Well worth the read for anyone who’s interested in front end performance and works on ruby apps.

It's not about how many hours you work

2009-10-11T00:00:00-07:00

My favorite discussion amongst web professionals is when people start talking about work/life balance and how many hours they’re working. There’s been no end of interesting ideas to pop out from this — everything from 4 hour work weeks to 100 hour work weeks. And everyone thinks that they’ve got the answer. But I think everyone’s just arguing about an irrelevant metric: the hour.

Let’s talk about that work/life balance thing

Most of this discussion always seem to revolve around the idea of a work/life balance. The basic idea is to keep yourself sane. Don’t abandon your real life for your work. That makes sense, until people start attaching hours to it. I’ve had discussions with people where they try and argue to me that 40 hour work weeks keep them balanced. But I have to wonder, where does that magical number 40 come from?

The fallacy here is that people are thinking in black and white terms of “work” and “life.” I never really understood that, and I think I’ve gotten to a point in my life where I can see why: it’s a bunch of bullshit that employers made up to promote 40 hour work weeks. If you really think that there is a certain number of hours you can work a week to balance your life, you’re doing it wrong. So let’s ditch this idea of a work/life balance, because it just doesn’t make sense.

It’s about creating a creative environment in your life

It’s just that simple. If you’re in the creative field, you need to make sure your life promotes a creative environment. There isn’t one catch-all formula to do this. There isn’t a number of hours you need to work. You just need to experiment and find out what works for you. What I will do is try and offer some advice.

Find your passion in life and try to make money from it

If you hate your job, it’s unlikely that you’ll be successful in fostering a creative environment. Try your best to fix this. Find out what you’re good at, and try to make money from it. You’ll be producing better (more valuable) work and enjoying life more.

Explore projects that are explicitly not for profit

Money taints things, there is no denying this. So I suggest to find an outlet that you purposefully can’t/don’t make money from to help exercise your brain. That might mean creating websites, making music, or hacking on an epic perl script that no one but yourself will use. It doesn’t have to be something different from your work — it just has to be separated from your work. Something you can change or destroy without worrying about what others think.

Stop working if you’re producing crap

The only thing worse than being unproductive at work is forcing false productivity. If you find yourself at your desk and you can’t come up with anything useful, just stop trying. Leave your desk and go do something else. Maybe for a few hours, maybe for a week, maybe for a year.

Accept that there is no way you can be productive for 40 hours a week

The 40 hour work week is completely unsustainable. Human beings are not meant to sit down and really focus for 40 hours a week, 50 weeks a year. Our brains can’t handle it. I’m sure startup founders will come in here exclaiming how they’ve been working 100 hour work weeks for 6 months now and every hour was well spent. They’re lying.

Your brain needs to purposefully not think in order to come up with creative ideas. That might mean relaxing to your favorite book or movie while your subconscious attacks your latest project. You’re not working in the strict sense—but you’re getting work done.

That’s not to say you can’t have weeks where you get hundreds of hours of work done. But in my experience, after a week like that, I need another week or two to decompress.

Focus on what matters

My goal with this post is to hopefully get people to stop thinking in hours. Start focusing on making great things. It’s about the things you produce, not the hours required to make them.

Once you realize you’ve been focused on the wrong metric I think you’ll realize arguing about a work/life balance is just ridiculous. Spend time on your life. Spend time on your work. But always strive to do better. That’s all you need.

Joining GitHub

2009-10-01T00:00:00-07:00

I still feel like it was last week I decided to give up my “safe” job at ~~Web Associates~~ Level Studios to play around with the ENTP crew. Well, it’s time for another move. Last week I was given an offer I just couldn’t refuse—to join the amazing GitHub team (my GitHub profile. For those of you who don’t know who GitHub is: shame on you. GitHub has taken something as boring as source control and made it something that brings people together. Social coding, indeed.

A brief look at the past couple years

The past couple of years have been a crazy blur of projects for me. Most of what I did for ENTP was for [redacted], so you won’t be seeing most of what I did, but I thought I’d spend a few minutes to archive (for my own good) some of the public-facing projects I completed.

Tender

By in large, the biggest project I worked on ENTP was Tender — and I’ll be honest, it’s going to hurt to let this go. Tender was my baby, and I did all of the IA, design and front-end work for the site as well as some marketing and analytical work. The shining side of that tunnel is that of course GitHub uses Tender for their support, so I’ll at least get to use it and see how ENTP shapes the product.

Lighthouse iPhone

Designing an iPhone optimized interface was one of my first projects at ENTP. It doesn’t benefit from any of the OS 2.0+ features (HTML5, CSS Animations, Etc) since the code was created before these came along, but it gets the job done. It was a great exploration in turning a complicated interface and trimming it down to the bare essentials.

ENTP.com

I designed this in collaboration with Justin Palmer when ENTP decided they needed a new site. It’s got a few interesting features (like pulling in our current GitHub projects on demand in the footer), but it’s mostly just a brochure site for the agency.

Hoth

Hoth is ENTP’s blog. This design accompanied the new ENTP.com design and added in a bit of tumble-like functionality to the templates.

On to the next chapter

So now I enter the third dream job I’ve had in the 4 years since I graduated college (none of which have been slightly related to my degree). I’ll be diving into a design/front-end role for the team and help clean up and take the product to the next level.

I’ll see ya’ll at the next GitHub drinkup.

Installable apps

2009-05-03T00:00:00-07:00

I’m getting kind of tired of all these web developers complaining about the time it takes to get updates to their apps up on the iTunes App Store. The truth is this complaining has some merit. But you have to realize that these people are not making web applications, they’re making installable applications. The problem is not Apple. The problem is lack of QA testing.

Your application will have many bugs

The first rule of development: your code is going to have a lot of bugs. I don’t care if you’ve got 3 days experience or 30 years experience in the industry. Your code will have bugs. This isn’t a pride issue, it’s a fact of life. Good developers know this and rely on testing (code, user-acceptance, performance) to expose bugs so they can fix them.

Bugs will appear after your code is deployed

Whether it’s the Y2k bug, deprecation of a technology, or your application getting blacklisted from a web service — some bugs are going to show up after your code is deployed. This is something you should expect. Again, this is not negotiable. It is going to happen.

The web makes us lazy

The truth is, developing web applications makes us lazy. I can fix a bug, deploy, and it’s fixed in about 15 seconds. This is why I love working on hosted web applications. You’ve got such immense power over the deployment process. Some things that rock about web apps:

You can be really lazy with UAT (User Acceptance Testing). Users will do your UAT for your and you can fix it on the fly.
You can be really lazy with bugs that will appear after deploy. If a web service changes, you fix it and redeploy. Done.
You only need one computer to test your application. No need to purchase multiple hardware platforms, video cards, or install multiple operating systems!

You can’t be lazy with installable applications

I once worked on a desktop application that was being sent out on millions of machines. This application was going to be the first thing that started up when the user booted the machine. It also meant we didn’t have the option to issue updates for the application after deployment. We spent tons of time doing user testing on dozens of machines. And then the client did user testing. And then the client’s QA department did even more testing. And then the client’s QA department did more testing throughout the whole time they were writing hard drives.

Remember the days when you updated applications with CDs or floppy disks? My god, for a while there it just wasn’t feasible to update installable applications over the internet. The end result? Software development firms spent a lot of time and money on QA. Same goes for game development companies.

My point is: if you know that one of your restraints is updating can be slow or impossible, you spend more time testing the application.

The App Store is slow

It’s true the App Store is slow when it comes to delivering updates. To me, this is just a known variable. Wouldn’t it be awesome if they had 24 hour turnaround? Sure would be. But it’s one of those tradeoffs you get with a closed system. If you want to trade it for an open system — build a web application. It’s not that hard.

I know it sucks testing your application. I know as a lone developer you don’t have the money to hire testers.

But think of the rewards. The App Store is something of a gold rush right now. A small group of people have made obnoxious profits off very little effort. There’s almost no overhead ($100 application fee? psh) — and anyone can submit apps. It’s a shitty closed ecosystem controlled by Apple. But it’s a shitty closed ecosystem of chocolate-filled pools lined with gold and supermodels dressed in nothing but $100 bills if you strike it rich.

Xcode window management sucks

2009-02-23T00:00:00-08:00

Hi, did you come here to tell me that Xcode offers "all-in-one" editing? Please, don't send me an email. This is addressed in this article if you take time to read it.

I posted some thoughts to twitter last night about how much the Xcode window management drives me insane. What I got back was a huge reaction of “it’s perfect” and “this is how OSX works” Suddenly I was wondering, am I just insane for thinking the window management is absolutely horrible?

No, no. I’m not. It’s horrible. Just because Apple built it, does not make it perfect.

Tabs are the future (actually it’s been the standard for years)

Tabs have clearly proven themselves to be a superior method for editing multiple code files. Why? Because the most recognizable thing about code file is it’s filename. Not the look of the text. Let’s look at this through some examples.

Case #1: Window-based management FTW, Photoshop

Example of window management in Photoshop

Window management in OSX defaults to a new window for each document. This works wonderfully for most applications when you can see the differences visually. Photoshop is a great example. Using Exposé, I can see which document I mean to be working on at a glance The visual representation of the document is the unique identifier.

Some more points on why this works so well:

Image documents are the only windows you will ever see in Photoshop. Everything else is a panel. This functionality is the same for all five-star document-based apps. iWork, iLife, etc. There is a really good reason Apple chose to hide panels when activating Exposé.
Photoshop is a document immersive program. It’s unlikely you’ll be working on more than one PSD at a time. The document is all that matters. Conversely with code, the project is all that matters (not one code file).

Case #2: Tab-based management FTW, Texmtate

Example of window management in Texmate

Window management for Textmate is handled via tabs and a persistent sidebar. At a glance, you can see all files you’re currently working on. In the case of Cocoa, you are often switching between interface & implementation files, but this is easily handled via cmd-opt-up, so long as you have the name of the class right, you’ve got the right file.

Some points on why this works so well:

Windows provide a way to group files in a meaningful manner. Each window is a unique project. Remember, the project is the important thing — when coding in Cocoa, you’ll need to edit multiple files at once to make them work with one another.
I can quickly move between individual files via the keyboard. Considering coding is almost purely typing, keeping my hands on the keyboard is killer.

Case #3: WTF-based management FTL, Xcode

Example of window management in Xcode

Window management for Xcode is handled via a combination of this thing called a Project window, which morphs depending on it’s toolbar state, windows for each document, and windows for ancillary programs (like the model editor). Please note I have the same number of windows open in this screenshot as I did in Textmate (7). It’s actually a pretty small program, but completely overwhelming.

Some points on why this doesn’t work so well:

Windows mean different things. Some mean code documents, some mean visual aid, some mean a kind of “project” that groups all things.
The project window continually morphs it’s state as you enter and exit debugging. It’s appearance is different, not upon your application’s state, but rather the toolbar button in the upper left, that automatically changes (one-way).
All the code looks the same. There is no unique identifier in Exposé mode. I must selectively hover over each file and read it’s filename. Or, I can exposé to try and find the project window (which can look much like a code window too), and then open a new document.
If I accidentally Cmd-W the Project window, I have to start from scratch, opening the whole project and each document again. This often happens as you accidentally open windows and want to immediately close them.

Some may counter, telling me that Xcode offers editing inside the project window. Sure, this works, but offers just as many frustrations.

You must single click on files to open them. Double-clicking them still opens them in a new document.
Because of the above, and the last bullet on the previous list, I constantly find myself accidentally closing the project because I was trying to close an accidentally opened window.
Unless I choose not to run my program, I constantly have to switch out of debug mode and back into editing mode via the toolbar.
Every single time I open Xcode I have to force it into editor mode.
There is a delay in single clicking a document. You click the file on the sidebar, the sidebar highlights, but the new document doesn’t open in the editing window for a second or two. When trying to scan documents for some code, this results in endless confusion.
There’s no idea of “open files” in this mode. No context for which I’m working. I can’t say, work on the View Controllers by opening each of them. Each time I must select the unique view controller in the sidebar, ordered alphabetically.

It’s a shame

It’s a shame, because other than the window management, Xcode is really an awesome IDE. The actual text editing is great as is debugging, scriptability, and file management. It really helps solve all the problems that Cocoa apps force upon mere text editors (long method names, class names, files being in one directory, different types of files in the same directory, etc).

It’s the program’s fatal flaw in my mind. It isn’t that it’s sub-par, or not good enough — it’s downright infuriating to use. I want to do mean things to cute kittens whenever I use it. So I don’t. I use TextMate. Which actually is very good at Cocoa & Objective-C. But it means much more typing (especially with the shift key) since TextMate favors tab-triggers rather than tab-completion.

At the end of the day, this is the kind of stuff I hope Mac developers care about. It’s about making the user experience the #1 priority in software development. And it’s something that I’m confident Apple knows about and intends to fix in future versions of Xcode. Because they care about the user experience.

Top reasons your CSS columns are messed up

2008-05-12T00:00:00-07:00

I believe the recent surge in popularity of CSS frameworks comes from a lack of basic understanding of the CSS box model and how it’s implemented across browsers. I wanted to share with you some quick tips on how to avoid easy pitfalls so you can create your own CSS framework in no time flat, without all the cruft of having ten thousand column combinations available. Keeping these quick tips in mind at all times will allow you to do something I like to call defensive coding — and really that’s all CSS frameworks are: defensively coded snippets of CSS.

Your margins are doubled in IE6

Here’s a super common pitfall: IE6 will double margins facing the direction of the float. Example problematic code:

.sidebar{
  float:left;
  margin-left:20px;
}

This sidebar will have a 40px left margin in IE6 — almost certainly throwing the sidebar down below the content, and not next to the content as it should be. Easy fix: add display:inline; No side effects in any browser, and IE6 obeys margins perfectly.

.sidebar{
  float:left;
  margin-left:20px;
  display:inline
}

Why it works: By declaring float on an element, you implicitly demand that it must be rendered as a block element — thus rendering the display:inline inert. However, due to IE6’s awesome CSS engine, it fixes a bizarre bug that is the #2 reason I see CSS columns fail in IE6.

Your content is wider than your column

Let’s pretend you’ve got this simplistic setup of code:

.columns{
  width:500px;
}
.columns .main{
  float:left;
  width:400px;
}
.columns .sidebar{
  float:right;
  width:100px;
}

HTML:

<html>
...
<div class="columns">
  <div class="main">
    <img src="/images/awesome.gif" />
  </div><!-- /.main -->
  <div class="sidebar">
    <p>Sidebar rules!</p>
  </div><!-- /.sidbear -->
</div><!-- /.columns -->
...
</html>

Harmless right? You might view this in Firefox and everything will be fine. But then you look at it in IE6 and your sidebar has mysteriously dissapeared below .main. WTF? You look at the HTML, the CSS, and everything’s fine. What could possibly be wrong? A common problem here is if awesome.gif is 510px wide. What this does is push out .main to 510px, and suddenly there’s not enough room for .sidebar inside .columns any longer. Ack!

Easy fix: add overflow:hidden to your columns. This forces the width restriction to crop any extruding content. New magical CSS:

.columns{
  width:500px;
}
.columns .main{
  float:left;
  width:400px;
  overflow:hidden;
}
.columns .sidebar{
  float:right
  width:100px;
  overflow:hidden;
}

Your margins extend past your container

So you’re building out a simple product listing template out, and you throw it in an unordered list:

ul.listing{
  margin:0;
  width:400px;
}
ul.listing li{
  list-style-type:none;
  float:left;
  margin:0 20px 0 0;
  width:85px;
}

HTML:

<html>
...
<ul class="listing">
  <li>Product #1</li>
  <li>Product #2</li>
  <li>Product #3</li>
  <li>Product #4</li>
</ul>
...
</html>

This CSS will work just fine in something like Firefox, but for mysterious reasons you’ll see that Product #4 appears on it’s own line in IE6. What’s happening here? I mean 4 columns x 85px + 3 gaps x 20px = 400px, right? Except that your 4th gap is hanging over the right edge — pushing the true width of the blocks to 420px. Firefox is smart and lets that margin just hang out there — but IE6 will apply that margin within the parent wrapper — throwing the 4th item down since it takes up 20px more than it should have.

The fix? Apply a left margin to each item, with a negative margin to the wrapper. This means that every item has a visible margin, but the whole block of elements are yanked back by the negative margin:

ul.listing{
  margin:0 0 0 -20px;
  width:420px;
}
ul.listing li{
  list-style-type:none;
  float:left;
  margin:0 0 0 20px;
  width:85px;
}

This gets around the nasty solution of adding a class to the first or last item in every row — something I’ve seen with abundance around the web.

Building a CSS framework in no time

Wev'e got to start out with some basic HTML. Here’s what I’ve been using lately:

<html>
...
<div class="columns col2">
  <div class="column first">
    ...
  </div><!-- /.first -->
  <div class="column last">
    ...
  </div><!-- /.last -->
</div><!-- /.columns -->
...
</html>

For different column widths, I’ve been changing out the col2 declaration to things like col2A, col2B, col2C and so on. You could easily give them more semantic names like products-columns too.

Self clearing is the future

The first step for any column framework is self-clearing. It’s easy, practical, and reduces all those damn clearing divs.

.columns:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}
* html .columns {height: 1%;}
.columns{ display:inline-block; }
.columns{ display:block; }

Float those columns

Next step is to actually float those columns. So let’s add a couple more declarations:

.columns .column{
  float:left;
  overflow:hidden;
  display:inline;
}
.columns .last{ float:right; }

.col2 .first{ width:500px; }
.col2 .last{ width:100px; }

.col2A .first{ width:400px; }
.col2B .last{ width:200px; }

.col3 .first{ width:100px; }
.col3 .second{ width:280px; margin-left:20px; }
.col3 .last{ width:200px; }

Done… uh, what?

Oh, yeah. That’s it. That’s all it takes to create reliable columns in CSS. Really.

Here’s an example page to prove it!

Why I don't use CSS Frameworks

2007-08-17T00:00:00-07:00

CSS Frameworks seem like an awesome advancement at first glance: speed up your development, normalize your code base, and eliminate those nasty browser bugs! Hot damn, where do I sign up? Unfortunately there’s some pretty strong caveats that go with those statements.

The frameworks themselves are very good

I’d like to start this off by saying there’s nothing inheritly wrong with any of the CSS, HTML, or ideas put into these frameworks. I also think it’s an absolutely fabulous idea that people are writing them — it gives newcomers an easy way out to create professional looking designs using semantic XHTML and CSS.

Advantages of Frameworks

Most CSS frameworks offer three primary selling points:

Speed up your develoment (don’t have to write all that HTML/CSS)
Don’t worry about those nasty IE bugs!
Normalize your code/class base

Speeding up your development

For those who have intimate knowledge of the framework, I do believe the frameworks will speed up development. But for the average user, I think that the time required to understand the architecture of the framework far outweighs the menial task of coding it from scratch.

Over the past three years, I’ve built unknown dozens of layouts, with most of them being extremely visually complex. On average, it takes me about 8 hours to build out a Master design into a functioning bug-free template. Of that time, I would have to say that doing the basic layout & typography (framework material) takes less than 20 minutes. That’s less than 5% of development time.

You may save time, but the question quickly becomes how much time, and at what cost? We’ll cover that later. My point being that frameworks do not solve the hard problems in CSS — the ones that pop up when you’re knee-deep in HTML and suddenly the goddamn box doesn’t show up in IE6. These are the problems that take the majority of time when developing a website.

Don’t worry about IE bugs

Well, gee that sure would be a wonderful thing if that were the case, wouldn’t it? The truth is the frameworks do eliminate some bugs — but they’re the easy ones to pick off. The ones solved by a quick display:inline or height:1%.

The frameworks don’t solve bugs where none of the public hacks work. Or where IE inexplicably adds a 30px top margin to your element, but then dissolves in when you hover over your main navigation. It doesn’t solve the problems when IE displays the same HTML and CSS differently on two different computers.

It doesn’t solve the hard problems.

Normalize your code base

This is one area I think frameworks are great at: getting a large team of people all using the same code structure. But then again, I think this can be solved by an internal styleguide just the same.

Disadvantages of frameworks

There are a few pretty severe disadvantages of frameworks in my eyes:

Familiarity with your code’s architecture
Inheriting someone else’s bugs
Not learning

Familiarity with your code’s architecture

This is the largest reason I’ve never built or used a CSS framework. By building a site from the ground up, you gain a knowledge of your site’s architecture that can’t be learned through any study or documentation. When a programmer asks you a question about restructuring the HTML, you can answer right away. You know where the CSS styles are (hopefully) and you know how the layout works.

This is increasingly relevant in today’s Javascript-out-the-ass world. Once you start manipulating the XHTML/CSS of your site through dynamic scripting: you better know how it’s laid out. Javascript-based effects are tied very closely to the CSS structure of the site. You’ll have to know when you can use float and when you can use position to lay out elements. Should you use line-height, margin, padding, or height to get that container to extend? It’s a very important decision: and laying out the architecture helps you achieve this.

Inheriting someone else’s bugs

At the end of the day, no framework is perfect. No design is perfect. But instead of fixing your bugs, you’re fixing someone else’s bugs. Do you know how much it sucks fixing your own bugs? It sucks 10,000x worse fixing someone else’s bugs.

Not learning

Again, on my mantra of why I wouldn’t recommend frameworks comes the lack of knowledge gained by fixing those problems frameworks solve. I’ve advocated before how important it is to build websites. I can guarantee you that if you keep building sites from the ground-up, you’ll learn new things each time. You’ll learn not only how to fix and avoid browser bugs, but how to make your markup more elegant. You’ll transform the act of building websites from a job into an art.

Conclusion

Hopefully this clears up a bit of why I don’t like CSS frameworks. It’s not that they’re bad — it’s just that I don’t think they offer enough value for the drawbacks. It all comes down to intelligently analyzing your situation before you jump head-first into someone else’s code.

The one “framework” I do use

On that note, there is one framework I do use. It’s the CSS reset — not that I’d even call it a framework. Here it is in all its glory:

/*------------------------------------------------------------------------------------
  Global Styles
------------------------------------------------------------------------------------*/
* {
    padding:0;
    margin:0;
}
h1, h2, h3, h4, h5, h6, p, pre, blockquote, label, ul, ol, dl, fieldset, address { margin:1em 0; }
li, dd { margin-left:5%; }
fieldset { padding: .5em; }
select option{ padding:0 5px; }

.hide, .print-logo, .close-button{ display:none; }
.left{ float:left; }
.right{ float:right; }
.clear{ clear:both; height:1px; font-size:1px; line-height:1px; }
a img{ border:none; }

What’s your take on frameworks? Do you use them? If so, what other benefits have you gained from using them?

MooTools Javascript Classes

2007-07-16T00:00:00-07:00

One of Javascript’s major blunders when it comes to Object-Oriented design is the lack of true classes. Lucky for us, we’ve had every library author out there have their whack at creating a class structure.

What is a class?

A class is kind of a template. One of the big concepts of OO is treating your code as real world objects. Let’s say you want to have three variables for different dogs: ollie, rowdy, and killer. Each of these variables should be an instance of a class. That class’s name would be Dog. Each particular dog is an instance of the generic Dog class. I won’t go into much more detail here: there’s plenty of reading to do on what classes really are, and how to use them best.

MooTools = <3

Out of all the class systems I’ve used, I’d have to say MooTool’s class system (spanwed from Dean Edward’s Base) is the cleanest, most extensible system yet. Creating and extending classes is ridiculously easy.

Create a class

var Animal = new Class({
    initialize: function(){
        this.text = "Animal Runs!";
    },
    run: function(){
        alert(this.text);
    }
});

var pet = new Animal();
pet.run();
// ==> "Animal Runs!"

(It’s also fair to note that MooTools supports Prototype’s Class.create method as well)

Extend a class

var Dog = Animal.extend({
    initialize: function(){
        this.parent();
    },
    bark: function(){
        this.run();
        alert("Woof! Woof!")
    }
});

var pet = new Dog();
pet.bark();
// ==> "Animal Runs!"
// ==> "Woof! Woof!"

You’ll notice you still get access to parent methods (through this.parent()), as you can see where this.text gets initialized when a new instance of Dog is created.

The syntax is short, sweet, and to the point. Furthermore it allows me all the flexibility I need… well, almost. MooTools team gets bonus points for the next section.

Javascript mixins… kinda

There are two common actions that many Javascript actions have: options, and callbacks. MooTools have created a sort of ruby-style mixin for classes to handle these functions. MooTools calls these mixins Utility Classes. To enable these, add this line to the code above:

Dog.implement(new Options, new Events);

Options

What does this do? First off, it allows for quick, easy, extendible options. All you do is set your default options in an options property, and then call the setOptions method inside your class. Here’s an example:

var Dog = new Class({
    options: {
        age: 5,
        type: "Jack Russel Terrier"
    },
    initialize: function(name, options){
        // Here's the magic!
        this.setOptions(options)

        this.name = name;
    },

    bark: function(){
        alert("My name is " + this.name + " and I am " + this.options.age + " years old");
        this.fireEvent('afterBark', this);
    }
});
Dog.implement(new Options, new Events);

var ollie = new Dog('Ollie');
ollie.bark();
// ==> "My name is Ollie and I am 5 years old"

var rowdy = new Dog('Rowdy', {age:15});
rowdy.bark();
// ==> "My name is Rowdy and I am 15 years old"

By mixing in the Options methods, you now have access to setOptions, which either uses user-defined options or class-based defaults (with one line of code).

Events

You can also define custom events (usually called callbacks). Notice the this.fireEvent('afterBark') bit in the Dog class above? Check it out:

var killer = new Dog('Killer');
killer.addEvent('afterBark', function(dog){
    alert(dog.name + ' just barked!');
});
killer.bark();
// ==> "My name is Killer and I am 5 years old"
// ==> "Killer just barked!"

It allows you to tie into the same event functionality used for the DOM, but with your own methods you create in your classes. I’m in love with this easy functionality — sure there’s been other ways to do this, but none so elegant as what the Moo team has come up with.

Chain

The last utility class is the Chain class. This allows for some nice chaining of classes: I’ll leave it up to you to explore this one since I haven’t used it in great detail yet. In a nutshell: it allows for time-dependent chains (so that events fire after another one is complete).

Conclusion

Every good Javascript developer knows that there’s 50 ways to skin a cat when it comes to classes and Javascript. But for me, one of the largest reasons MooTools is my framework of choice is the underlying class system. No extending Object, and no overriding of parent methods. The syntax is clean and easy to remember, giving it huge bonus points in my book.

Personally, I would like to thank the smarter developers who have taken the hard hits with Javascript to implement these nice OO techniques. Without them, my Javascript would still be procedural-based with tons of global variables thrown about. Yay for frameworks!

Using TextMate's TODO bundle

2007-06-25T00:00:00-07:00

If you use TextMate, you should really think about using the TODO bundle more often. It’s a simple, low-maintenance bundle that adds tremendous value to your code.

Setting TODO, FIXME, and CHANGELOG

Using the bundle is pretty easy. In any language, just type in a quick comment with the prefix TODO, FIXME or CHANGED like so:

def view
  # TODO: different display for different types of clips: active, processing, etc
  @clip = Clip.find(params[:id])
  # TODO: Make a real related clips dealieo
  @related_clips = Clip.find(:all, :limit => 6, :conditions => ["clips.status = 'processed'"])
end

Using this syntax lets you keep pushing ahead at full steam and leave the hard stuff for later. For example, in the above example I wanted to get a quick functional prototype out the door. It wasn’t mandatory that the Related Clips actually be related: it was only mandatory that there was content present.

You can also use the keywords FIXME or CHANGED throughout your code, like so:

def view
  # FIXME: This totally breaks if an invalid ID is given
  @clip = Clip.find(params[:id])
  # CHANGED: @related_clips now uses a model method related_clips
  @related_clips = Clip.related_clips(params[:id])
end

This lets others working on the code let you know that you know something is broken and/or changed, but you just don’t have time to get to it.

Getting the information back

Well, that’s all fine and well.. but how do you know what needs to be fixed/changed/done ? Just hit Ctr+Shift+T and TextMate will pop up with a pretty little list, hyperlinked and all

Ctrl + Shift + T brings up a list of all your todo's

I use this bundle practically every time I open up Textmate. It allows me to keep on a focused track of development, while still keeping a lot of “ooh, I need to do that sometime” kind of tasks on the radar.

Warpspire

Knyle Style Sheets

Maintainability comes from shared understanding

Documentation

Enter KSS

KSS aims to create a shared understanding

Knyle style recruiting

Employees are the best recruiters

How I hire people

Friendship

Research

Grab a beer

Job boards, Twitter, and advertising

Credit where credit is due

Mustache, ERB and the future of templating

I mustache you, why mustache?

You want me to switch templating languages on my legacy app?

Mustache-style ERB templates

Graceful upgrade path

Brew Methods

Design Hacks for the Pragmatic Minded Video

Relentless Quality

Quality versus the Ego

Move fast and break things

Quality is contagious

Deploying: Then & Now

2004

2011

Designing GitHub for Mac

Why should we build it?

What are we building?

Sketches & early ideas

Let’s get some designers on this

A slow process

The aesthetic

Lessons learned

Welcome to 2004 — everything is a sliced image

Change is painful

Objective-C is easy, Cocoa is hard

Secrecy is overrated

Here’s to a bright future

Excellent embedding markup

Build your business around an idea

Build something incredible

Ideas are lasting, products are not

Ideas are sexy

Evolving ideas from products

Infinite Scroll + HTML5 History API

Product design at GitHub

Everyone is a product designer

Write down ideas like crazy

Constantly experiment and iterate

Abandon features

Argue all the time

Talk to your customers

Product design is in the eye of the beholder

Design hacks for the pragmatic minded

Documentation is freaking awesome

Speaking at Magic Ruby

URL Design

Why you need to be designing your URLs

Top level sections are gold

Namespacing is a great tool to expand URLs

Querystrings are great for filters and sorts

Non-ASCII URLs are terrible for english sites

URLs are for humans — not for search engines

A URL is an agreement

Everything should have a URL

When to use onReplaceState and when to use onPushState

A link should behave like a link

Post-specific URLs need to die

A great example

The beginning of an era

My TextMate Snippets & Triggers

The Geek Talk Interview

RSS Feeds for Warpspire

Rethinking Warpspire

Getting rid of cruft

Abandoning old baggage

On the subject of comments

When to use `onReplaceState` and when to use `onPushState`