Day 35 – Partials, Partials Everywhere

Day 35 was the last day of the first week of Ruby! I learned a lot this week, not just about Ruby and Rails, but also about strategic app architecture. Being able to compare and contrast Ruby/Rails, and Python/Django along the way has been really helpful for me when it comes to seeing the big picture of web development. Plus, while here at the Dojo they say that moving on to the next stack is like a full reset, it doesn’t feel like that to me. The way I see it, I’m picking up right where I left off at the end of Python, only with a few new tools to use! I can already imagine how I’d like to implement the new architecture strategies I’ve been learning with Rails in future projects, whether they use Rails or Django or some other framework I have yet to use.

Anyways, back to the events of day 35. At morning algorithm time, Instructor David finally stumped me! I was tasked with coming up with an algorithm that, given a number, would generate an array containing all the possible arrangements of that number of pairs of parentheses. For example, given 1 the output would just be ["()"], given 2 the output would be ["()()", "(())"], and so on. Algorithm time ended before I could crack it, but I’ll finish it up on Monday.

After algorithms, I spent a little time finishing up day 34’s blog post before diving back into an assignment I had been working on the previous day. I was getting a little frustrated trying to fix a bug in the assignment related to Rails’ form_for() helper function. Remember how I was saying Rails has so many helpful helper functions? Well, they’re only helpful when you know how to use ’em! It turned out that I was writing an app with nested resources without knowing it (I was writing out all the routes by hand instead of using the :resources helper to generate them… oops!), and after getting a hint from Instructor David that I should just use Rails’ built in functionality to generate my “nested resources” I finally had the keyword I needed to get a good stack overflow result out of Google! A few seconds later, I had the solution to the problem that was causing my bug. The form_for() helper can either take in a single model object OR it can take in an array of model objects (the one you want the form for + the one it’s nested under), which is required if you want to use form_for() to generate a form with the correct action (the update route in this case) and field data for a model with nested resources. I still don’t think I’m totally comfortable with nesting model resources and the effects doing so have on other helper function usage, but I’m sure I’ll get more practice with it soon.

Instructor David threw together a fun Ruby Jeopardy game in the afternoon. Each question was about predicting output of some Ruby code. I won’t go into details, but we learned about some interesting/obsucre Ruby interactions, like how keys can be assigned to in a hash multiple times and Ruby will accept the last one, but print out a warning.

If you’re wondering what the heck the title of this blog post is about, I’m finally getting to it now! After Ruby Jeopardy, I did some more reading on the platform and started a new assignment about… layouts! Let me first say that I noticed a couple days ago that the view files auto-generated by the Rails generate controller command didn’t have any part of the normal html, head, body structure. Auto-generated views only have an h1 tag and a p tag.I originally attributed this to some kind of Rails magic that would generate all of that stuff automatically in order to stay focused on just the content. Now I know that all those missing pieces of the view files were actually located in the application layout files all along. Turns out, whenever Rails is told to render a view, what it really does is look for a “layout” file with the same name as that view first, and then it renders the “view” file inside a specified section of the layout file. If no “layout” with the same name as the controller method is found, Rails will automatically use the auto-generated “application” layout.

Basically, all the view files corresponding to controller methods are actually partials! Everything is a partial! I already knew I was rendering partials when I was using the <%= render 'form' %> tag, but it turns out I was really rendering a partial inside of another partial! I don’t know if you can tell from this post but it kinda blew my mind a little bit. The fact that Rails sets up all this stuff automatically is pretty amazing actually. I still remember having to write the whole HTML skeleton and then copy/paste the head for every HTML file I ever wrote back in Python.

This ties in pretty nicely with what I said before about continuing to learn new and useful techniques rather than just starting from scratch in a new stack. Now that I know how awesome layouts are, I can implement them in Django later as well. Sure, it might take a bit more setup compared to when Rails does everything for me, but that’s still better than copying and pasting the same heads into every HTML file!

Alright, it’s pretty late and I need to wake up early tomorrow to tile my kitchen. Time for bed. I’ll be working with layouts and finishing the parentheses algorithm on Monday.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s