CLI projects, Rails & HTTP Requests
You may have read in my last blog entry that I’d failed a project review due to some messy code on a previous CLI project (a basic review system). Well, thanks to some thorough planning, and a bit of perseverance, I’ve managed to pass the review with a new project, a historical quiz. One of the most important lessons I’ve taken from this initial experience in my coding bootcamp journey, was being able to enjoy your work.
Pretty much anyone who has gone through a coding bootcamp, or know someone who has, will have heard about how dealing with impostor syndrome is one of the main challenges a beginner will continuously wrestle with. Inserting the element of play into your work, and experimenting, rather than simply trying to get everything right on your first go at writing a function or building a relationship, removes a lot of the pressure you can put on yourself, and allows you to be free to learn and enjoy the process. This is certainly what happened with me.
A small example of how much more concise my code was this time around can be seen below. As I’d used my home_menu as an example of ‘messy’ code in my last blog, I’ve put it side-by-side with the home_menu I built this time around. This is just a small example of how the two apps differed in organisation, and how strictly each one adhered to basic programming principles (single source of truth, single responsibility principle, etc.).
Rails, HTTP requests and the Web
So with those lessons learned, we’ve moved on to using Rails and learning how to respond to HTTP requests. HTTP requests are comprised of clients (web browsers) sending requests to web servers for web elements such as web pages and images. After the request is serviced by a server, the connection between client and server across the Internet is disconnected. A new connection must be made for each request. See table below:
In order to respond to these requests, we’ve been introduced to controllers, views and routes, among other things. Models (which we were introduced to in the previous module), controllers and views make up the M-V-C application design model which is commonly used for developing modern user interfaces. It is provides the fundamental pieces for designing programs for desktop or mobile, as well as web applications. Each of these files play their own part in providing the client with the information they are seeking from your website/app.
Model — The central component of the pattern. It is the application’s dynamic data structure, independent of the user interface. It directly manages the data, logic and rules of the application.
View — Displays data from the model to the user and also enables them to modify the data.
Controller — Accepts input and converts it to commands for the model or view.
Ruby on Rails
Our introduction to Rails has been slightly bittersweet. It is extremely powerful and can generate a lot of the files you need, but this can lead you down a road where a greater understanding of the tools you’re using is more difficult to develop (see, first blog post). Generators for example, are an extremely powerful tool in Rails, see a list below of rails generators that you can make use of.
Let’s talk about one of the rails generators that you should most likely avoid, scaffold . It will create a lot of extra stuff that you likely won’t need. The scaffold generator creates a full set of a model, a database migration for that model, a controller to manipulate it, views to view and manipulate the data, and a test suite for each of the things listed before. Sounds tempting, right?However, this doesn’t give you much flexibility in how you want things to interact since it’s all being created for you. There’s also the chance that something could go wrong if you don’t follow the proper naming conventions for Rails, and if you have any other issues, it will be much harder to debug as it’ll be much more difficult to determine where you’ve gone wrong.
So, as we proceed through the second module of Flatiron’s software engineering bootcamp, I’m excited to show you what we can create next week for our projects as we continue to develop our understanding of HTTP requests and how we can use the powerful tools we have at hand to respond to those requests both efficiently and creatively. Leave your comments below and let me know about your experiences (both good and bad) building Rails apps and using generators. Until then!
