Recap of My First Year as a Ruby on Rails Developer
I have been working as a Software Developer for a small firm for a year now and Ruby on Rails is the first framework that I’ve worked with professionally. It is a beautiful framework with a lot of care and thought put into it. Before Rails, my experience with web development was limited. I had delved into Node and React, but I had never worked with those at a professional level. Before I summarize my journey, I would like to give a brief introduction to Rails.
Ruby on Rails (RoR) is a web development framework that is built upon Ruby, a pure Object-Oriented language. Rails follows the MVC (Model-View-Controller) architecture. It was released on August 2004 and is maintained to this day. Rails is a sensational frameworks that is an inspiration for other frameworks like Laravel and Phoenix.
Enough with the introduction, let’s move on with my journey:
Ruby is Awesome!
Before Rails, I had never heard of Ruby, but I liked what I saw. The philosophy behind Ruby is developer’s happiness. It has a lot of methods baked in for many use cases, which make your code concise and elegant to look at. It almost looks like pseudo-code and even reads like English sentences at times. Additionally, I am a big fan of bundler when it comes to building and packaging your Ruby code. In summary, I love the methods Ruby provides, its ease of use and polished package management system.
Ruby’s meta-programming ecosystem is also amazing. Ruby is my introduction to meta-programming and I like what I am seeing. The use of blocks, the methods the Ruby provides like #send, #define_method etc. is quite nice in the meta-programming ecosystem. The Rails internals use a lot of meta-programming, which explains most of the ‘magic’ behind many components of the Rails code, and this would not have been possible without Ruby’s powerful meta-programming. All in all, Ruby is just a wonderful language to code in.
But it’s not all glitters…
Ruby is nice, but it does not shine everywhere. As Ruby is quite lenient in its syntax, in my experience with some Rails projects, it is easy to write unmaintained, spaghetti code if the writer is not careful and good practices are not in play. There are certain Ruby gotchas that can be annoying to deal with when you face them. A simple example I would like to give (using Ruby 3.2.1):
def foo
num = 1
end
puts foo # Prints: 1Now, this irked me a bit when I first saw it. I have not returned num at all (either by using the return keyword or by implicit return), but it still returns the value 1 when calling foo (most likely because the last statement is also executed and returned). When I first saw this while debugging a problem, I thought that it will return a nil and I had figured out the issue that I was facing, but this wasn’t the case. This, and some other gotchas and problematic code that I faced annoyed me. That’s why I believe that following conventions, code analyzers (like Rubocop), and good design patterns are keys to write elegant, maintainable, and readable Ruby code. Otherwise, it can get out of hand pretty quickly.
Rails is Beautiful!
When I started out with Rails, I was pretty iffy about its modern trends, its prospects and whatnot. When I delved into it, and got a basic CRUD web app running by following tutorials, I thought to myself “No way, it can’t be this easy”. I mean, just execute a rails generate scaffold command and you already have a foundation of a simple CRUD web app. Since then, the more I explored this framework, the more sense it made. And after working with this for an year, I am happy to say that it is the first framework that I have learned.
Rails is an intuitive framework. It follows the principle of ‘Convention over Configuration’. Once you get yourself comfortable with its defaults and conventions, you will find yourself more efficient and productive. You do not need to think about certain complexities like naming your tables, controllers etc. as Rails conventions will guide you through those questions. Instead, you can focus on actual coding. These conventions have also guided me through non-Rails frameworks as well when it comes to writing my routes, table names, models etc. In short, Rails is a highly productive framework which is fun to work with.
Talking about some features of Rails that I enjoy the most: Rails is a batteries included framework which comes with everything you need for a complete web application. You need mailers? You have ActionMailer. You want to process jobs? You can use ActiveJob. You want to avail web sockets? ActionCable is there for you. Secondly, I am a big fan of ActiveRecord. It makes communication with the database so easy. It is possibly one of the best ORM out there. Additionally, the command line tools of Rails are exemplary. The generators Rails comes with are extremely powerful. Lastly, I love the Hotwire stack that was introduced in Rails 7. Turbo makes your apps faster and dynamic, and Stimulus helps you with your JavaScript. In summary, Rails truly is a one-man framework and empowers you with all the tools you would need for a complete web application.
But, it is not perfect…
There are definitely certain set of hiccups that I faced in my Rails work too. First of all, I personally think that starting with Ruby on Rails can be a tad bit cumbersome. There is a certain barrier which you should cross first so that things start making sense to you. For example, when I was learning RoR, connection between routes, controllers and views was a little hard to digest. Sometimes, when I would create a new folder or rename my files or make a typo in my code or file name when following a tutorial, errors would start appearing — thanks to Rails CoC (Convention over Configuration) motto. So, at the start of my learning, it was not so simple to wrap my head around those conventions.
Secondly, maintenance of old Rails projects can be painful. Upgrading the Rails version, updating the dependent (and usually the old) gems, fixing the JavaScript — these aspects make updating some old projects quite a chore. Furthermore, Rails has developed quite a number of solutions for JavaScript in its iterations (Importmaps, JS Bundling etc.) and choosing or switching one over the other is not an easy choice. I really wish if the whole process was seamless.
Finally, ActionCable is not good on its own. If I had to develop a chat app which highly depends on live updates, notifications and chatting, Rails might not be my preferred choice. This is not something Rails has to focus on though as it already does quite a lot for us, but having fast, scalable and efficient web sockets would have been a cherry on top.
Other Pointers I would like to share
Documentation Helps
Before I had started to work professionally, I considered writing long SRS documents to be superfluous and was of the notion that they provide little benefit. But after working on a couple of projects, I have gained a little more appreciation for documentation. On one project, the requirements would change every single day and the features would have barely any discussion, which was an unpleasant experience. On the other, there was a little more direction to the tasks which made working on that project slightly more palatable. So, having a direction for a project via documentation definitely helps.
Testing is good
My current experience with testing is limited. I have dipped my toes in RSpec and FactoryBot, as well as the Rails default testing framework. But after working on a project which had no testing at all, I have started to value thorough tests quite a lot. There are cases where I would make a change to fix something, but that change would affect some other part of the application without my realization. Such mistakes can fly under the radar and erroneous code can get pushed to the repository if there is no test coverage.
Architecture matters!
Lastly, one more point I would like to share is that software architecture matters a lot. I would like to give you an example of a project where I was working on. The portion of the project under me was a micro-service. My micro-service would have to make quite a lot of API calls to a central ‘monolith’ to communicate the updates. But the nature of new features and tasks was such that my micro-service could not live without communicating with the central monolith — it was almost a case of tightly coupled micro-services, which raised the question: Why even create a separate micro-service when all the changes are related to the same monolith. This is why forward planning the features and setting the direction of a project is crucial when designing software; otherwise, you risk wiring up poorly engineered software, making future fixes excruciating down the road.
Other General Tips
- Debugging is an important skill to have. Navigating a problem on its own is a crucial skill.
- Learning DevOps tools like Docker, GitHub actions, Kubernetes etc really boost your productivity and skill set.
- Good communication skills, conveying your ideas clearly and many other non-technical skills are quite essentials.
Concluding thoughts
I have put a short summary of my thoughts and experiences in this article. My experience with Ruby on Rails has seen both good and bad days, but at the end of the day, I believe it has only made me a better programmer. There is a still a lot to learn, code and write. Hoping you enjoyed the article. Until the next one!
👋
