bobbygrace

FWIW, Trello didn’t launch with an API. It’s something we added in the first few months after launch. Just about everything goes through the API now since the mobile apps also use it, so you could say it’s an API first design NOW.

It’s true that Trello never supported IE8, but we never promised or intended to add IE8 support. We wanted to support the browsers of today and tomorrow, which was IE9 at launch.

That rarely happens in our experience. With our internal board, we know who is working on what and in what area of the code. Plus, all code is reviewed by someone working in the same area.

Everyone runs dev environments locally and tests. A dev environment is really easy to set up with mongo and node. Occasionally, we’ll put stuff on a staging environment if we want to test a database or infrastructure change. Big, experimental client changes go to the alpha channel on production.

It was a joke. =)

er, by stable branch, i mean stable _channel_. or whatever channel.

When it's nobody's job, nobody does it. Any developer COULD do it, though.

If there are necessary API changes, we just need to push updates to the API ahead of time. The API needs to be stable and backwards compatible anyway for the mobile apps (and all third party apps).

Yup. More about the tech stack here http://blog.fogcreek.com/the-trello-tech-stack/

Right. The there is only one version of the API. Multiple clients.

I hope Doug writes a more technical post about the multi-client build/release process. We have unit tests for the whole API and very few automated tests for the front-end. Client builds are stored in S3. We use mongoDB and will do backfills if necessary (pretty rare). Rolling back the client is just pointing the stable branch to another build.

Yes, this was in perceived rendering time, and yes, the trade-off was worth it. We kept the async rendering stuff localized so it doesn't complicate the app much.

trello.com, a.k.a. the "desktop" version, is device-agnostic so that it will actually work on any just about any laptop, smartphone, or tablet. You're getting the same code on every device, so it's cross platform in that sense. The custom scrollbars on the web are just a webkit thing. See: http://css-tricks.com/custom-scrollbars-in-webkit/

That said, we want to create the best experience for your device, and nothing beats the experience of a native app. Try them side-by-side. Each native app is written in its native language (Obj-C, Java, etc.). It's more code, but they just turn out better that way.

Trello does not support IE8. That line is not in production. I just wanted to show you how to add support if you needed it.

It's true that self-closing, non-void elements are not valid. With gzip, it's probably not even worth the savings in size. I know it's bad and we shouldn't do it and it will probably blow up in our face one day, but it doesn't seem to matter in practice and I just like the way it looks.

Ah, well copy protection is definitely not a concern for us, since we serve the raw TTF alongside the other formats. The fact that the WOFF file was about 30% smaller than the TTF was more of a deciding factor.

Awesome. This approach can definitely work for lots of people. We default to WOFF because it's essentially just a slightly more compressed OTF file, it's something all browser venders seem to agree on, and it just seems like The Right Thing To Do for the web. We serve raw TTF files for the stock Android Browser. I had so much trouble hinting the raw OTF font for Chrome on Windows that I gave up and used SVG. As I mentioned in the article, SVG fonts don't get mangled by the browser's font rendering engine or ClearType.

Also, I never had any problems with FontSquirrel.

That's... awesome! We needed something custom for Trello, but I can see font awesome being super useful for getting things off the ground.

Icon fonts are so much easier to work with, I agree. That was a huge draw for us.

That's what the Trello team is trying to do on the public Trelo Development board. https://trello.com/board/trello-development/4d5ea62fd76aa113...

Trello technically has support for downlevel versions of IE, but only through Google Chrome Frame.

Now that the API is 'done', data export will be coming soon.

https://trello.com/card/board/data-export/4d5ea62fd76aa11360...

Data export is at the top of the 'In Progress' list of the Trello Development board: https://trello.com/card/board/data-export/4d5ea62fd76aa11360...

Now that the API is 'done', it shouldn't be long until this is up and running. More about data, privacy, etc. here: trello.com/privacy

From the article: "Our developers bleed all over MongoDB, WebSockets, CoffeeScript and Node."

The blue icon means you're an admin of the board (or organization). The green/yellow/grey icon means you're online/idle/offline.

Thanks! We're glad you like it and found it easy to use.

Thanks! Here's the pitch.

Trello is a collaboration tool that organizes your projects into boards. The site was built ground up using backbone.js for all models, views, and routes.

I would love to see additional type rendering options, but this would have to account for the OS as well and Adobe tools would have to accept WOFF and EOT files, which counters FontFont's point of offering web fonts DRM-free.

And I still don't think there will be a tool that makes code better than a hand, not that such a tool couldn't assist in a great way. TextMate snippets and CSS preprocessors maybe, but that's not exactly WYSIWYG to HTML.