tylerharper

(This is the text of the keynote I gave at Startup Riot 2009. Will update when video becomes available.)

Hi everyone, I’m Chris Wanstrath, and I’m one of the co-founders of GitHub.

GitHub, if you haven’t heard of it, has been described as “Facebook for developers.” Which is great when talking about GitHub as a website, but not so great when describing GitHub as a business. In fact, I think we’re the polar opposite of Facebook as a business: we’re small, never took investment, and actually make money. Some have even called us successful.

Which I’ve always wondered about. Success is very vague, right? Probably even relative. How do you define it?

After thinking for a while I came up with two criteria. The first is profitability. We employ four people full time, one person part time, have thousands of paying customers, and are still growing. In fact, our rate of growth is increasing – which means January was our best month so far, and February is looking pretty damn good.

tylerharper

- simple
- public over private
- personal vanity
- internet is global
- permalinks
- one important item per page
- don't break the browser
- don't wanker in technology
- a medium is not a grande
- break convention for your users

tylerharper

class CouchObject(object):
    '''
        Convert between a CouchDB document and Python object. 
        Create Python objects while maintaining a schema-free database.
        Define object properties without storing null fields.
    '''

    @property
    def id(self):
        return self._id

tylerharper

Hosting Sphinx docs at GitHub
-----------------------------

Before: Run sphinx-quickstart in docs/

1. Follow "Project Pages" instructions from http://pages.github.com/ to create a gh-pages branch
2. Add Sphinx html build dir as git submodule:

    git checkout master
    git submodule add -b gh-pages [email protected]:arthurk/django-disqus.git docs/_build/html

tylerharper

= Ruby Packaging Standard

The aim of this document is two-fold.  First, to specify a common
structure of how a Ruby package distributed as source (that is, but
not limited to, development directories, version-controlled
repositories, .tar.gz, Gems, ...) should conform to.

Second, to document common and proven ways to structure Ruby packages,
and to point out certain anti-patterns that sneaked into common use.
It is by intent not to innovate.