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…
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…
It was a joke. =)
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…
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…
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…
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…
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…
From the article: "Our developers bleed all over MongoDB, WebSockets, CoffeeScript and Node."
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…
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…
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…
It was a joke. =)
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…
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…
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…
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…
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…
From the article: "Our developers bleed all over MongoDB, WebSockets, CoffeeScript and Node."
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…