In this installment of Thinkful’s “Dev Toolkit”–a detailed look under the hood at Amicus, a NYC-based startup that helps nonprofits raise more money and boost awareness for their causes by turning their supporters into fundraisers and advocates.
We chatted with CTO Topper Bowers about the tools that power Amicus’ stack, the major tech challenges they’re facing and some exciting in-house tools that the team is open-sourcing in the near future.
Thanks for chatting, Topper. Tell us a little about Amicus’ mission.
Amicus empowers nonprofits to raise more money, attract more members, and win more votes. We offer a simple fundraising and outreach platform that allow non-profits, political campaigns, and educational institutions to reach the people who are most likely to support their cause in the most effective way possible – through their friends. We graduated from Y Combinator in the Spring of 2012.
What tools and services are most crucial to keeping Amicus up and running?
Our DevOps is all Chef-solo based and it keeps us moving. I can’t imagine spinning up a box by hand anymore. We have a setup that looks at the tags on EC2 and decides what role a box should be (webapps, services, mongo, etc). Chef also manages all our deployments (along with some custom scripts).
A couple of us came from companies that had their own servers in their own data center. Having to re-OS… ugh. Amazon Web Services gives us the freedom to experiment with various scenarios and expand on demand. At our stage, I wouldn’t contemplate having our own hardware. During the election, when we had a surge of traffic, we were able to scale up our 3 Mongo boxes to big-boys with SSD drives and manage a huge surge of traffic and then scale back when the crunch subsided.
Errplane is a new one we’re digging. At a high-level, it’s kind of like a combination of New Relic & Hoptoad–offering reliable error reporting but also time-based statistics on our app performance. It’s a fairly new tool, but we use it a lot.
Errplane combined a lot of different tools that we relied on heavily, like Statsd and Graphite. Making the switch took the operational burden off of us in terms of syncing up those tools, so it freed us up to focus on more important things, like open-sourcing some of the other solutions that we’ve been working on.
What are some interesting tech problems that you’re facing at Amicus at the moment?
Right now, we’re focused on improvements on 3 fronts:
2. Service Oriented Architecture. Any Ruby on Rails app usually ends up being a monolithic app that can become hard to maintain and test, so we’re breaking our app into pieces–a more service-oriented breakdown. The goal is to have the Rails app become purely an API and moving toward a static, front-end. Ideally a single-page app. We’re working towards that.
3. Graph Databases. We’re also putting OrientDb into production–it’s a really cool graph database. We’re just starting to see a return to graph databases–they’re certainly nothing new. Graph theory has been around for 200 years. It was popular in the 70s, and is kind of a forgotten technology that’s coming back. You used to have to write your own in order to play around with them, but now there are finally some strong open-source alternatives.
Graph databases enable you traverse a graph extremely quickly with a query. Something that could take hours in a relational database could take seconds in a graph database. It’s also an easier mental model, enabling us to do things with simple counts that would normally require stats or machine learning, such as (surfacing the strength of various relationships of the number of commonalities you share with other users in our database).
We do a lot with mapping social relationships at Amicus, so this will make coding against that kind of relationship model much faster and easier.
At a high-level, what does Amicus’ tech stack look like?
We also have a custom event layer, open-sourcing soon: Donaghy (Essentially a service bus; a way for apps to fire events and have other apps listen for those events.)
Backbone, EndDash templating language (also opensourcing soon: it’s the bidirectional data binding tool from backbone that I mentioned earlier.)
Team Amicus at work in General Assembly’s NYC “east” campus
What’s different about your stack?
Well, JRuby’s an interesting choice. There are basically 3 implementations of Ruby: (1) Ruby MRI, the original; (2) Rubinius, which I don’t think is production ready, though some are using it in that way; and (3) JRuby, which runs on top of Java.
JRuby runs within the JVM (Java Virtual Machine), so the deployment scenarios it offers are much more advanced than anything that exists for other Ruby implementations. It’s arguably the fastest Ruby, as it offers real, full threads, which enables you to do more than one thing at a time.
We’re a Mongo shop. I realize there’s some back-lash on that now days. In my experience, that’s mostly from people who haven’t worked with it in production. If you structure your data properly, with an eye toward how Mongo works, it’s awesome.
What’s your personal setup like? What tools do you rely on in your own dev work?
Hah–I use Rubymine, which is a little unusual. I catch flack because I don’t use Vim or Emacs–Rubymine is more of an IDE (Integrated Development Environment), but I feel much faster on it. Yes, it may take more than 4 seconds to start, but I can navigate the codebase much easier than something like Textmate. I’d challenge any Vim fanatic to a race to see who’s more efficient.
How did you get started as a developer?
I was a graphic designer, actually, but I’ve always dabbled in programming. I went to art school, and programmed quite a bit for various visual projects. I got a degree in Computer Graphics–mostly 3D and Flash at the time. I taught myself Rails while creating an AJAX-powered polling website during the Web 2.0 movement. It was pretty cool seeing my logo right next to Flickr. I later moved over to Motionbox, became the app-lead there, and worked there for a few years after they got bought by Snapfish.
What advice would you give to someone starting out in Front-end development?
Starting out on the front-end is a great way in, but it also takes years of experience to feel totally comfortable there. There are so many little “gotchas” to internalize. Take browser compatibility, for example–if you’re working with someone more experienced, you can shout at them to ask about some Internet Explorer quirk, but when you’re just starting on your own, you’re going to be looking that stuff up every two seconds.
You guys are hiring–what do you look for in new dev team members?
We have really sweet Iron Men helmets all over our office to remind us of the type of developer we want to hire. One day we asked ourselves ‘who’s our ideal team member?’ and we came up with four things. We want people who:
- are brilliant
- are passionate about what they do
- care about philanthropy
- have a healthy sense of humor
Basically, Tony Stark (minus the alcohol problem).
Whether you’re hoping to become a CTO like Topper or just whip up your own personal website, the front-end is a great place to start. Join our next class on May 27th to get started on your path to programming–learn more here