This is the latest in our “Inside the Stack” series featuring Underdog.io customers. This week, we hear from Chris DiLorenzo, the CTO of Suitey. Chris goes into great detail on DevOps tools, specifically Suitey’s choice to use Vagrant and Ansible to save developers time and energy. Suitey is hiring developers and real estate specialists.
Suitey is the refreshingly simple way to find a home. We’ve removed all of the traditional obstacles and hassles from the process by combining technology, teamwork and personalized service like never before. Now, it’s a transparent, productive experience free of pressure and confusion. At Suitey, we’re delivering better ways to help you find and enjoy the home you’ll love – from the second you begin looking until you’re fully settled.
Our backend is in Python (Django) and our frontend uses the usual mix of HTML, SASS and JS. We chose Python because our first developer (way back in the early days) knew it well. But it hasn’t been a choice we have regretted at all! The community is fantastic and if you are following PEP8 it essentially documents itself. A lot of people have actually commented that our codebase reads like a book (#humblebrag).
While perhaps not technically being a web framework, we use requireJS + jQuery to handle most of the functionality in our front-end. Templates are rendered serverside. We have become quite dependency-averse and agree with Spolsky that doing a full rewrite is generally a bad idea.
As we decouple our frontend from our backend, we will be adding a framework so that we can be a bit more opinionated about what constitutes a well-written frontend feature. Right now, React has my eye due to its “do one thing well” philosophy.
PostgreSQL + PostGIS. We’ve been super happy with PostgreSQL as our database and using PostGIS for location-based queries helps a lot when dealing with significant amounts of location-based data.
We use Vagrant to run our local development environments. All of our environments (including the local ones) are also provisioned using Ansible. The three wins that stem from this are (1) differences between our developers dev environments are minimal, (2) our dev environment is very similar to all of our other environments and (3) our dev environment is easily reproducible.
If you’ll indulge me, I’d really like to dig into this topic a little bit because even if it seems obvious, very few people actually pick the low-hanging fruit of caring about their development environments, and I think that is a mistake.
Having similar dev environments is excellent because any weirdness that happens in one environment is bound to have happened or be reproducible in the other environments. Running a Vagrant (or other virtual environment) also makes you more agnostic as to which OS other developers on your team are using. Having the development environment be easy to reproduce means that you can now have a fresh and shiny dev environment whenever you introduce your breaking change that you were “super confident”(™) worked, but has now semi-irrevocably changed the state of your dev environment. It is one of those things that just makes sense: why would you be running your dev environment on OS X, testing on Windows, staging on CoreOS and hosting on Ubuntu? Ubuntu all the things! You don’t even have to leave your host environment behind, it can be whatever you want because you are running the dev environment as a guest!
This is something that is only recently becoming obvious to junior and mid level software engineers because it is preventive. No one gets a medal for preventing a fire; only when you arrive on the scene when it is almost too late and you fix a clutch environment variable in the ~/.profile are you rewarded for your brilliance.
Should you use the dev environment even if you are the lone developer on a project? I would argue yes, because even if there will be no weirdness between different dev environments you will still be able to quickly re-provision and your dev environment will be more similar to the production environment. Also, this way you are prepared for when you get some coworkers.
TL;DR Use Vagrant (or something similar) to save time and give your developers confidence. They will save tons of time and not be as afraid to test things (as long as it doesn’t get committed to the master branch but that is another story). Dare to make your developers happy and productive.
Oh man, put a gun to my head why-don’t-ya? I’m really excited about our frontend prospects. The frontend landscape has been shifting a lot with frameworks/platforms coming into their own and redefining how we think about the interaction and organization of data and logic between the frontend and the backend+datastore. We just brought on a really awesome designer to help inform some of the frontend engineering decisions and I think the marriage between exposing that information and beginning to leverage a more structured approach (probably by using a frontend lib such as react or ember) is going to lead to really happy developers, and happy developers build awesome things!
Thanks to Chris and the whole Suitey team for a great post. Visit suitey.com to read more about the company and to see their technology in action.
