Makers Academy remote week 7

Week 7 has been Rails week. The big one. As a cohort we've grown accustomed to coding in Ruby, but it's been at the back of my mind for some time, and for others on my cohort I'm sure, that a large Ruby framework called Rails was looming, and that it seems to be what all the professional Ruby developers are using.

Until now we've used Sinatra as our back end framework, which has been a fine solution, but as a simple Google search for solutions to any arbitrary Ruby problem will attest, Ruby and Rails seem to go hand-in-hand, and until now we'd been missing one half of the relationship. There appear to be so many employment opportunities and learning resources pertaining to Rails, that I was keen to finally use it for myself.

Makersbnb review

First however, with this week following a whole weekend of wrangling last week's Makersbnb project in to shape, we began with group presentations of those projects to the rest of the cohort. The presentations were reassuringly casual, with each group in turn being asked to demonstrate their project in a familiar group video meeting environment. I initially stepped forward from our group and began to demonstrate the interface, before proceeding to explain the structure of the code. We put some effort into the presentation of our project, however functionality is the clear priority at Makers Academy, and as such our coach Sam was much more concerned with how it worked than how it looked. Others from my group joined in to discuss specifics that they'd each worked on or had particular knowledge of, and in what felt like a very short space of time our presentation was at an end.

It was fascinating to see how each group had tackled similar problems in different ways. Some groups presented fantastically polished front ends that wouldn't look far out of place on any large professional site. These sites received an initial ‘wow' from me, I've always had an interest in front end design, and having previously worked as an interface designer for six years I can't help but be visually led. However I had to shift my brain back to the code and assess each offering based upon how the team had implemented its features. As would be expected some teams produced come very similar code, after all we've all been through the same curriculum to bring us to this point. As Sam noted at the end of the presentations each group had managed to produce a well coded product that adhered to best practices and professional workflows, so no matter how complete our projects were at this point, every one was a success. Go team!


In the afternoon we were introduced to the new topic for the week, Rails. Rails was initially introduced to us as a powerful framework that we might just initially hate, due to it's ability (aided by a series of Ruby packages called gems) to produce huge amounts of code and functionality automatically. Sam demonstrated that in under a minute with one single line of code entered into the command line, Rails would produce an entire user sign-up, sign-in and sign-out system, which integrated with a database, and even came with some additional features such as a fully working ‘I forgot my password' system. It took us several days to implement a lesser version of those same features by hand in Sinatra, and here was Rails doing even more automatically!

As expected Rails comes with a big ‘with great power comes great responsibility' kind of warning. It was explained that while automatic code generation has its uses, it can quickly overwhelm the developer with more code than they can handle. Reportedly it can be easy to fall into the trap of being a developer who thinks they know Rails well, but really they only know how to use commands to make Rails do things automatically for them, a subtle but important distinction. We've been told that Rails comes with another feature called scaffolding, that takes this auto code generation to the extreme. As expected after receiving such a warning, we began by learning Rails in a very manual way.

Ruby on Rails, or simply Rails as it's often referred, is a web application framework written in Ruby. Its same features can be built from scratch by anybody using only Ruby, however beginning a project with Rails enables us to take advantage of a whole host of features, security enhancements and years of ongoing development that would be difficult or impractical to implement otherwise. Rails is hugely prevalent in the development community, and organisations from the smallest of startups to the largest of corporations use it for some of their most important work. As such there are a huge number of employment opportunities at any time for Rails developers, and it's incredibly useful for us to learn.

Interestingly however I quickly picked up on a strong feeling that the use of Rails is on a decline. More modern technologies such as Node, which allow for back end development to be handled in the usually front end focused JavaScript language have decreased Rails' market share significantly. Sam remains insistent that Rails is still very much in use the world over, and still will be for some time, but even this insistence came in a worryingly defensive way. This may well prove to be unfounded, I have very little experience of Rails yet and am in no way able to make that kind of judgment. However I found it interesting that I'd approached this week in awe of Rails' status, and have quickly come to learn that many consider it outdated already. It seems the most important takeaway is that frameworks come and go, it's the languages that we have to really learn properly, then we'll be able to pick up any new frameworks that come along in the future.

Yelp clone

As usual we learned this week by pair coding to create a project. Interestingly while previous weeks have tasked us with challenge-led learning, the curriculum for Rails week is the only to remain unchanged from the earliest days of Makers Academy, when challenges did not yet form a part of the course. Because of this the week's work has seen us following a clearly defined series of instructions, which has still been enjoyable and effective, but in my opinion much less engaging than the rest of the course has been.

The task for this week has been to build a clone of Yelp, the popular restaurant reviewing website. The interesting thing about this project was that it required us to implement the uploading and displaying of images for each restaurant. This required us to create an Amazon Web Services account, of which we used the S3 storage service to host our images. We then had to implement thoughtbot's Paperclip Gem to allow for the attaching of files to an HTML form, and pointed the upload toward our AWS storage buckets. This wasn't a hugely difficult task when running the code locally, but it became much more complicated when running the project on the cloud via Heroku, a cloud hosted deployment environment.

The task for the weekend challenge was to use largely similar technologies as in the week to produce a clone of Instagram, the popular image uploading and sharing service. This offered a great chance to solidify our understanding of Rails, which can initially be overwhelming to understand. I still have a long way to go before I'll feel comfortable using Rails, but I'm becoming familiar with the concepts behind it.