Writing and code from the engineering team behind Trello.
Trello loves data! Here at Trello we try to incorporate data into our decision making across the company, from marketing campaigns to product roadmaps. Our goal is to delight users, and we do this using data.
Trello has been using RabbitMQ for the last three years. Prior to RabbitMQ, we were relying on a Redis Pub-Sub implementation. Recently, due to RabbitMQ’s questionable behavior when network partitions occur, we’ve made the switch over to Kafka.
Bugs! No matter how many times I decree that my coworkers and I must stop writing bugs, we keep on doing it anyways. Even worse, sometimes those bugs make it into production, where users run into them!
Have you ever returned to work in the morning and found a couple of Trello boards with this lovely cryptic red box?
This post is intended to be a sequel to the Talking Kotlin podcast episode that featured Huyen Tue Dao and me. We recorded it in May 2017. If you haven’t given it a listen, go check it out! A quick recap from the conversation: We started using Kotlin in October of 2016, right around when Kotlin 1.0.4 was announced.
We’re excited to announce that there’s now a great place to talk about building on the Trello Platform in the Trello Slack community!
Want to authorize with and use a third-party service in your Power-Up? This post has you covered!
You made it to part two! 👻 At the end of the previous post, we had a functional Power-Up that included a button on the back of a card that you could use to add an estimate to the card. Now we want to take this new data we’re collecting and display it in such a way that it adds more perspective to the Trello board.
For the past few months we’ve been working on bringing Unsplash into Trello. Check out Trello’s blog post announcing the launch if you missed it! It was a great experience because Unsplash is really cool and we knew our users would love it (I know WE do ❤️). It was also a great experience because we followed a simple and effective development process using Trello. What follows is my take on the integration work and process as a developer on Trello’s Web Team.
In this post, we’ll walk you through building a Power-Up for Trello. We’ll build a Power-Up that gives teams the power to add size estimates to Trello cards.
In my last post I talked about the ICE prioritization framework and how it can be used to figure out what tests to run. In this post I’ll go over how we use Trello and a custom Power-Up to keep track of our ICE scores and what we want to test next.
Here at Trello we like to test things. We’re constantly looking for new ways to improve our user experience. When we do make a change we want to make sure it’s having the impact that we expect. Our go-to tool for this is the A/B test. On the growth team at Trello we spend a lot of time talking to users, looking at our event data, and running user studies to come up with great ideas for tests. Along the way we end up with a pretty large backlog of tests to run. Figuring out what to run and when to run it can be a really daunting task.
tl;dr: Don’t use Node 7 until this PR is released.
Early on, we realized that we needed some way to communicate to the user when data isn’t synced with the server yet. Otherwise, you could end up in a frustrating situation where you see a card you created on your device, but no one else can see it and you don’t know why.
Most of what I’ve written so far has been about uploading changes from the client to the server. But we found it is equally important to download changes from the server periodically, too. What use is offline mode when you aren’t viewing fresh data? How can you share perspective with someone if you only ever push data and never pull?
When coding i18n support in an iOS app, you need to know technical things like how to use Localizable.strings files and NSLocalizedString(). And when designing the UI, you need to understand right-to-left interfaces and remember that any element with text can vary in width considerably. But one thing I didn’t anticipate was how important the translation files were for making the app easy to translate. Before we get started, if you missed part one on Internationalizing Trello, you can check it out here.
When writing offline mode, attachments proved to be a uniquely difficult aspect of syncing.
Tuesday, February 28th, 2017 was an exciting day for a lot of engineering teams. A large portion of the internet was affected by Amazon’s outage, and as our status page update details, we were too. From approximately 12:45pm–4:49pm ET Amazon Web Services suffered a major service interruption to their S3 service in the US-East-1 region. Trello went down at 12:55pm–3:57pm because our static assets (web client bundle, attachments, file previews, fonts, icons) are stored on Cloudfront, which is backed by Amazon S3.
I want to call out a surprisingly tricky problem we ran into when developing offline mode: handling identifiers.
Analyzing time to an event can answer many questions about a population. Medicine, epidemiology, and actuarial science have historically analyzed lifespans. For example, actuaries use life tables to assess the probability of someone living to a certain age. Researchers may analyze the likelihood of a new treatment improving survival rates.
In the last article we discussed how we sync our changes with the server. Ideally, those HTTP requests would always work - if only we could walk the rosy path of best-case scenarios! Unfortunately, when it comes to network requests, all sorts of madness can occur. It’s best to bake madness-handling systems into your code instead of assuming everything will be alright.
Going offline meant using our database for all immediate changes to the client. But obviously we later want to sync those changes with the server.
Good news, everyone! The Trello mobile apps now work offline!
Ever been frustrated by complicated parsing tools that somehow still manage to have terrible error reporting for your users? In this talk Jeanine Adkisson outlines a modern parsing technique using “skeleton trees” that improves the UX of parsing errors by delaying decision-making as long as possible.
Jon Chan from Stack Overflow shared one of his side projects with the engineering teams at Trello, Fog Creek, and Stack Overflow. Descartes is an experimental library for writing CSS in JavaScript.
On page 52 of my copy of K&R, in a discussion of the ?: operator, is this line of code:
For many years, Trello Android has used a simple system for upgrading the database schema: drop the entire database, recreate it, and repopulate the data from the server!
We’ve talked about our CSS a lot in the past. We did a State of the Trello CSS and published a guide for writing CSS. We’ve wrapped up everything we’ve learned into Trellisheets, a public repo for all things CSS at Trello.
We, like all of you, watched with great anticipation in September as Apple announced their latest technological marvel. At the time we had no idea what this meant for our current iOS app. What kind of capabilities would WatchKit have and how could we integrate that into our existing codebase?
The Android team at Trello is happy to announce our first open source Android library, Victor! It’s a Gradle plugin that lets you use SVGs as resources in your Android apps.
Looking to build apps, extensions, and Power-Ups for Trello? We’ve got everything you need over at developers.trello.com!