At Simple Thread, Rails is our favorite framework for building web applications. Even after all these years, we still think it is the most productive framework out there for building awesome web applications. Because we love Rails so much, more than half of the team traveled to Pittsburgh this week to attend RailsConf 2018. Here’s a bit of what we learned from our time at RailsConf.
Compress All The Things!
Conceptual compression: Look at all the things I’m not doing! #RailsConf
— DHH (@dhh) April 17, 2018
RailsConf started out with DHH making a keynote about progress and “Conceptual Compression”. Conceptual Compression is the idea that over time, we make progress by tightly packing the mental load on concepts so that we no longer need to think about the underlying complexity of them in order to leverage them.
When Rails was introduced, there were many complexities to web development which Rails smoothed over and which appealed to developers of that time. While understanding these details might be beneficial for experienced developers today, how are we to quickly bring new developers into the fold if we require them to understand every underlying detail and the context of web programming from ten years ago? Do you need to know the underlying details of your operating system in order to use it effectively? We all get to stand on the shoulders of giants and now it is the new Rails developers turn.
For those new developers, Rails might be a huge framework, but the beauty is that you don’t need to understand every nuance to be productive. The lesson here is to take heart in building something even if you don’t know how everything works from the outset. Learning the conventions, rules, and constraints is very important, but never underestimate the power of building something as a means for gaining more knowledge to then apply later on. Knowledge which will then be compressed on the next big thing and on and on it goes.
RailsConf Got Real
— Stella Miranda (@fashionate) April 17, 2018
Programmers who are guiding business units through the process of digitally exploring new ventures or mapping existing workflows to applications need to embrace the authority, responsibility, and stewardship that come along with it.
We shouldn’t try to specialize to the point where folks become experts in tiny pieces of the whole picture. Complexity of software forces specialization. Systems built in Rails are not magically less complex, but managing the complexity requires less effort. The history of Rails is largely a story of identifying complexity shared by the community at large and then pushing that complexity upstream into the framework, with well-reasoned abstractions and opinionated conventions for handling the complexity.
In other words, Rails is a force for compressing concepts to the point that small teams of people can manage highly complex systems and own the whole experience. Seeing the whole picture provides a context for responsible stewardship and other higher level concerns.
Engineers should be guides to the business teams — not just transactional ticket-takers. Software developers got into the field to change the world… and as the economic explosion of the last ten years have proven, it’s working.
But once software eats the world, like the ouroboros, will it eat itself? If we don’t assume the ethical and moral responsibility that goes with it … it just might.
Rails Isn’t Dying – Rails Is Maturing
— Jamie Gaskins (@jamie_gaskins) April 18, 2018
Rails is one of the best ways to quickly build stable and scalable codebases, and while other frameworks have exploded in popularity, Rails is still one of the most actively developed in the world with almost 4700 commits made to it over the last year. The takeaway here is that frameworks are tools to the task and Rails has been optimized for a specific purpose that few other frameworks can match.
Are there ways that Ruby could be better? Of course.
I’m still processing the week at #RailsConf. I think the overriding feeling I have so far from the week is that we’ve grown up. We are a mature technology. So what are we going to do about that? Make things easier, even more robust, and even more enjoyable.
— Barrett Clark (@barrettclark) April 20, 2018
For instance, scalability isn’t the issue it is perceived to be. So battling those sort of constraints – or once they’re removed, the perceptions of those constraints – seems like a major theme for the community in the last few years and ahead in 2018.
Dev.to’s Ben Halpern wrote a stirring article about how, as he puts it, “the Hacker News mindset on Rails eats at my insecurities” but attending RailsConf made him realize how vibrant and crucial the Rails developer community is to what software developers are building and maintaining.
In other words, Rails might be getting older, but it definitely isn’t slowing down.
Slow Down And Do Your Dishes
What is worse than coming home to a sink full of dishes with dried up food stuck to them? Not much, but allowing for technical debt to build up in your codebase is essentially the same thing.
The solution to a big mess of code isn’t a big rewrite but changing your programming habits, so every small change turns the tide and leaves the codebase better every time. “Everyone has to do the dishes” – @sarahmei #RailsConf
— DHH (@dhh) April 19, 2018
— terian 💀💾🌸 (@spine_cone) April 17, 2018
Take a lesson from the White Rabbit which can apply to programming, business and the rest of life … sometimes you have to SLOW DOWN to go further!
We know what makes a codebase most equipped to be its best self: low complexity, high test coverage, upgraded dependencies, minimal duplication, sound data schemas and stable churn rates. Violating those ideals is like leaving a dried up lasagna dish in the sink. There’s a time and a place for it, but don’t let it sit too long and don’t do it everyday for a year.
And on that note … it might be time to upgrade your version of Rails!
We learned a lot at RailsConf this week, but I think the most important lesson we learned is even after all these years, the Rails community is as powerful as ever. If you want to hear more from us about what we learned and how it could help you and your business, please get in touch. We’d be excited to tell you more!
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.