Karl Becker

Thanks to some assistance from FastRobot, we got a great Terraform + Chef deployment mechanism that replaced our previous reliance on Amazon OpsWorks after they decided to stop maintaining that service. Having the configuration checked into source control is more powerful than having it all in the GUI with AWS OpsWorks, and we can see the changes as regular pull requests just like our application code.

The simple add-ons system allows us to add a variety of data stores, data analysis tools, log archiving, and other features in a very simple, Lego block-style way. And they've kept our web hosting and Postgres servers going for years with minimal input from us, which is just what we want.

We build our customer-facing web apps primarily in EmberJS, but we wanted to get some experience with React for a few reasons. The biggest reason is because of its popularity, and we wanted to make sure we had some working knowledge of it.

We ended up using React in our web browser extension project, and it has worked out pretty well overall.

We recently rediscovered Amazon SQS and are using it for two upcoming systems. Back in 2012 and 2013 we wanted to use it, since it eliminated the need to host RabbitMQ ourselves. However, SQS didn't support FIFO queues at the time. They eventually added it in 2016, but we had been using RabbitMQ for years, and we hadn't noticed this new development in a tool we didn't use. But we recently had a little trouble setting up RabbitMQ with Terraform, and we discovered SQS is easily supported with Terraform, and has all the features we once wanted.

We use Ember.js because its convention over configuration helps our team stick with the Ember way of doing things and not have to bike shed or otherwise think about how to structure our app or do certain things. There is indeed a learning curve with Ember, but the amount of tech that Ember pioneered, and that is part of the framework, allowed us to quickly adopt patterns and practices from people who were more focused on web front-end development than our team was when we began our front-end web adventures.

More of our effort still goes to backend work than front-end, so being able to do things "the Ember way" has shrunk some of the decision making time.

We use Node.js because it allows our full-stack developers to have less context-switching when working on different areas of our systems. Whether it's frontend or backend, there's no major syntax changes. Every single member of our team is experienced with a variety of languages, but reducing the cognitive overhead that comes with switching languages lets us more smoothly switch between front-end and back-end development.

It was a pretty hot new technology when we adopted it at the company's inception in 2011, and we're glad it's progressed and matured so much since then... and of course, still has more maturing to go, but we'll keep adopting new versions and features and fixes as they come!

We use TypeScript because type safety in JavaScript seems to be kind of a game changer, providing feedback on certain changes and classes of bugs that doesn't even require a single automated test run to discover.

How nice is it to simply add an element to an existing interface, and then instantly be shown in an IDE all the places that need to be updated to have the new element? 🎉

We use PostgreSQL because it's time-tested SQL combined with all kinds of fantastic performance and modernization improvements, not to mention wonderful time/date support, JSON support, and more.

Legacy code that, although maintained slightly, will be phased out as we migrate the 2 backend tools that rely on it to other, more robust languages. See: http://bjorn.tipling.com/if-programming-languages-were-weapons PHP