Cover image for Kick-start learning a new Framework: How I started with Ruby on Rails

Kick-start learning a new Framework: How I started with Ruby on Rails

bruck1701 profile image Bruno Kümmel ・5 min read

This is my very first post and it's a bit long, but I really wanted to share my experience with this community and to connect with other beginners on Rails!

The context

Classically, I believe there are three ways to kick-start learning a programming language or a framework:
• Purchase a course - online or a regular classroom (bootcamps);
• Read the tutorials online and start a project, or
• Buy a book (although not much recommended: by the time you finish there will be a new version of the thing… 😊).

OR, a friend of yours can convince you to apply to a company that uses said language or technology - you desperately try to learn as much as you can, and as fast as you can before the Tech Interview. That was me trying to learn Ruby on Rails in 4 days...

typing quickly

Long story short, lately I have been looking for a job as a developer, but my tech experience has been more on academic research and as a one-man team sysadmin on my previous workplace. The well-known "Jack of all trades, master of None" that checks every item on a tech recruiting ad, but not really!

So my friend sent me a message saying that the company where he works, would open a developer position, but they use Ruby on Rails. He said I should apply, since they would value good programming fundamentals and not newcessarily knowledge of the framework. And Ruby is not that much different from Python (the language I have been working with for some time).

Well... in this case, why not? From my previous experience, I could apply for the role and wait weeks, or even a month before the first interview. In the meantime, I could learn the basics.  TWO days later (on a Wednesday) I received a message from HR trying to schedule a “get-to-know-you” interview. As soon as the interview was over, I received an email from the CTO asking me to develop an investment portfolio web app with some API calls. The portfolio should not take more than 10 hours to finish it. It took me 3 days!

Although I finished the project with a working app and even got some thumbs up from the reviewer, obviously I did not get the job! However, I got to learn quite a lot to get me on the starting track to become a Rails developer. Not only through the process of reading, watching tutorials and googling my way through the project, but from the feedback I got from the code review (the CTO himself answered me, which was super nice).

Lessons from the experience

• You need a deadline to learn what you want to learn. If you have discipline to self-impose a deadline and keep it, good for you! But maybe for some people, putting yourself in a position similar to mine will keep you on the schedule to develop and learn a bit (in my case, a lot) everyday.

ALWAYS ask for the feedback on why your project did not pass the requirements. Unfortunately it is pretty normal not to receive any feedback or notice to let you know you did not make it. So, if you receive the message, take the most of it and ask how you could have done it better.  It can be a little awkward, but the best mistakes are the ones you can learn from, right?   Every company has some particularities about what they are looking for in a developer, although if you are a beginner, like me, the negative notes are mostly not on the style, but on the solution you provided!

• Your past experience with coding helps a lot to learn a new framework, but it is not enough to get you on the other side with a working app and an elegant source code. Your result will probably be a mess of code overdoing a lot of stuff that could be done using the tool correctly.

From the code review, I got first hand - and for free - a set of concepts that I could have listened to on an online course, or read it somewhere. Since I got them as review on a “failed” project, I will not easily forget them.

Code Review key points

• Fat models and skinny controllers. Actually skinny everything! If you feel you are having to type a lot of constraints in your controller, you probably are! The controller must be as concise as possible when passing data from the model to the view and vice-versa. However, if your model gets too fat, maybe there is a need to break it down in smaller models. Remember that one of the main ideas of MVC is to have reusable code. If your model is too constrained, it will be difficult to use it on another project.

• Scaffolding helps when you are in a hurry, but it is a bit messy. If you don't have much time to put some service up, scaffolding will help you. But, in exchange, by default it will throw everything but the kitchen sink in your code. In order to keep it readable and maintainable, you will have to erase a lot of unused code. The question is: which will give you more trouble? To code everything or to erase what you don't need? As a beginner, it is better to erase it and see it breaking to understand what is going on, but as you get more experienced, I feel that you will opt to customize your code to keep it in order.
• Everything that is not directly linked to the MVC, should be somewhere else on the code! This was one of my main fails on the project. Since I was just starting with it, I thought that the API calls should go on methods inside the controller. NOPE! As I mentioned on the first point: skinny everything! And this implies that not everything should be in the MVC pattern. In my case, it would have been better to put the API calls on a service inside the app folder and call it from the controller, kind of in a similar fashion as helper functions for the views.

• Automated testing! Another mistake on my part was not to give the proper attention to testing. In my past experience I have mostly worked alone as a sysadmin, and the codes I have developed in Python were only occasionally verified with a unit test. For web frameworks, on the other hand, everything must be tested and well documented! In fact, Test Driven Design, where you write the tests before the code, is an approach well used and accepted in the Rails community. So if you are a beginner like me, it is something to keep in mind that is not quite clear at first in introductory courses! Planning to start with this material .

Anyway, that was my experience to get started with Ruby on Rails!  Now, after a not so ideal beginning, I feel that, after these past few weeks of studying it more, I could come up with a much better project with cleaner and tested code in a much shorter time.

We all see posts on social media from experienced developers saying that the best way to learn a new language (or Framework) is to build a project with it - I couldn't agree more. The hard part is to be consistent and to develop it everyday. So maybe setting a real deadline to a project is not such a crazy idea... :)

I'll try to post my progress here and share any interesting features that I find along the way with all the new learners as well. If you want to connect with me, just send me a message!


Posted on by:

bruck1701 profile

Bruno Kümmel


Freelance developer and Cloud professional.


Editor guide