I was doing a lot of programming in Java and Python early on in my career, and it felt like there was a lot of ceremony when dealing with Java — it could be hard to get stuff done quickly. I had been hearing a lot about this thing called Ruby on Rails that promised a faster on-ramp into building, especially for greenfield projects.
When an opportunity came along for me to work on a greenfield app, I decided to try using Rails. This was around 2011, when Rails had just moved from version 2 to version 3, and it was a pretty big generational shift. Things started settling down, it was a little less of a Wild West, and a little bit more mature of a framework. It seemed like the stars were aligning and that it was the right time to jump in.
What sets Rails apart is that it’s an extremely opinionated framework, and those opinions are informed by the idea of building web apps quickly that are going to be useful for end users. If there is something you want to do in Rails, chances are the authors have thought of it, and the framework implements a good set of best practices that you can leverage with very little effort. And Ruby is an extremely expressive language, so these incantations require very little code. As a result, Rails has a reputation of being a little too magical.
That magic can be controversial, because some people find it beneficial to be able to see exactly how the system is working. In Rails there’s a lot of stuff hidden away from you, but most of the time it does exactly what you want. It almost feels intuitive — you only write a few lines of code, or maybe none at all, and you get some great functionality right out of the box. So as long as what you want to build is in alignment with what the creators of Rails anticipated that you will want to build, things go remarkably smoothly. The things that are common from web app to web app are already decided for you, so you can focus your time on what makes your product unique.
At Carbon Five, we place a lot of value in collaborating across disciplines. It leads to really good outcomes if you have close-knit teams that have design, engineering, and product all represented. Rails is a framework that gets out of your way and lets you experiment and iterate quickly. I think those are really powerful things, especially if you’re working with non-technical folks, because sometimes someone on the team will say, “I have this idea. Can we try it out?” As an engineer, you can turn that around and get them a prototype very quickly with Rails.
Knowing Rails allows engineers to more effectively participate in that sort of iterative development. If you’re on a small team — and you’re maybe the only engineer, or only one of a few engineers — you can get a lot done and have some good back-and-forth conversations and exploration with folks from other disciplines.
Rails is currently on version 6.1, and version 7 is on the horizon. Rails 7 is bringing some pretty big changes in the world of front-end development — and the front-end community moves really fast. It seems like every month there’s a new hot framework, or a discussion about the best way to implement CSS, or the best framework to use for client-side code.
Whereas if one team is building an app with Rails, and another team is also building an app with Rails, you’ll likely be very comfortable on both of those teams because Rails prescribes a certain way of doing things. I think that’s why we value Rails a lot at Carbon Five — it’s still one of our go-to technology stacks, especially for greenfield projects, because we know that we are all proficient in Rails. We can quickly assemble a team, and deliver really fast. The commonality of having used Rails aligns people quickly.
Raygun is kind of like the Carbon Five starter kit for Rails projects — we’ve taken what Rails gives you and made some tweaks here and there. Carbon Five has been around for a while, we’ve been working in Rails for a while, and we know how we like to use it. It’s not a big departure from what you get with Rails out of the box, but we’ve changed a few things to align more with how we work.
For example, we prefer using RSpec for testing, whereas Rails uses something called Minitest. So that’s an example of where Raygun is going to generate a new Rails app for you with RSpec instead of Minitest. It’s a small change, but it aligns with our testing philosophy and how we deliver Rails projects at Carbon Five.
Raygun is always evolving because we’re starting new projects and learning from existing ones all the time. We’re constantly optimizing to be able to get from zero to delivering features to a client as fast as possible, but without being over-prescriptive or limiting, since every client has different needs. We’ve been honing the balance in Raygun over the years to reflect that. And if you use Raygun, you’re benefiting from what Carbon Five is learning about how to deliver software quickly.
I’m a really big fan of Rails. It’s not in the spotlight as much as it was 10 years ago, but I want people to know that they shouldn’t sleep on Rails as a framework.
Interested in working on Ruby projects? We’re hiring! Looking for software engineers, product managers, and designers to join our teams in SF, LA, NYC, CHA. Apply at www.carbonfive.com/careers