Orienting Myself while Learning Ruby

Before you dive in, I’m going full food blogger recipe format. Life overshare for the top-half, with useful information with the SEO keywords that got you here in the bottom-half. Look for the literal divide to skip to the recipe.

It’s the beginning of May and I have… taken my sweet time moving through my wonderful Flatiron School bootcamp.

I’ve found self-paced difficult. I’m a perfectionist, over-achiever who hasn’t been in a true learning environment in ten years. My career as a creative producer has certainly taught me a lot of new skills and helped me grow as a professional leader. Most of my previous job titles have relied on my independence (a.k.a. chronic inability to ask for help). A desirable trait in most Executive Assistants — I could sell a Nike knockoff “Just Deal With It” in midtown to cover rent–– this approach absolutely does not work in coding.

Learning to code, like any language, relies on communication with other people and asking questions about the details of its context. Sure, they told me this in my orientation but why would I listen? I’m different, right?

It is also difficult to reconcile the collaborative nature of code remotely in a pandemic. It took me months to learn how often I should use the Ask A Question feature to work with Learn’s online tutors. It took me another month to regularly join the Study Halls — even if I wasn’t up to that lesson, it’s still good to be present. And talk to others.

Moving forward, I plan to take my notes differently and ask my questions much differently. Google for the answer for a while but not for days :)

I’m still uncomfortable being wrong and not knowing. But at least now, I can move forward a bit more ready to sit in this learning (wrong) state and ask for help.

For my Ruby CLI project, I referenced the NYC Parks’ GreenThumb API. Here are a few takeaways from the project and overall Ruby course component:

Class Method affects the cake vs. Instance Method affects the slices

CLASS VS. INSTANCE METHODS

I had *incorrectly* understood instance methods as “methods that sit within a class, unable to be used outside of it”. Kind of like a siloed method built for a specific use case. Which is often how it appeared in our test-driven homework. However, I needed to be thinking of them as object-oriented methods. The section is called object-oriented Ruby for a reason.

• Instance Methods work onto/within an instance of an object.
• Class Methods work onto/within a class (maybe that is achieved by referencing @@all , a commonly used class variable set to an array that holds every instance of an object)

“When would you use Instance Methods? You use Instance Methods when you need to act on a particular instance of the class. This is often when the functionality concerns the identity of the instance such as calling properties on the object, or invoking behaviour.”
- Class Methods vs. Instance Methods in Ruby on Culttt

“Due to the duties of these methods being separate, they can’t perform the other’s task, meaning that you wouldn’t call a class method on an instance of the class and you wouldn’t call an instance method on the class.”
- Class vs. Instance Methods in Ruby by Zach Weber

It took me much too long to figure out that I wasn’t even fully understanding the difference. Once again, the earlier you speak aloud to other coders, the better your learning experience will be.

Your output is often showing you exactly what isn’t working.

Read Your Error Messages

The emotional toll of error messages were sometimes more overwhelming than the message itself. Especially important since this was my first project without custom tests to guide me. They’re telling you what’s wrong!! Just take a breath, go wash a dish, come back and listen!!

• This NameError overview by Olúwaségun Adéléye helped me slow down and understand the importance of implicit returns & self in ruby.
• “NoMethodError is raised when a method is called on a receiver which doesn't have it defined and also fails to respond with method_missing:”
  –– ExceptionalCreatures’s NoMethodError explainer helped me orient myself when I would receive this error message when the method was ~*~clearly defined~*~ (reader, it wasn’t).

Iterators help make sense of the mess of objects & assets.

Choose the Best Iterator

This was another practice that became much easier/clearer once I latched onto the idea harnessing of implicit returns. Implicit returns are the best tool for clean code.

• each vs map: “The difference between each and map lies in the return value: .each returns its receiver, but .map returns a new array”
  –– by StellaMaris Njage
• sort vs. sort_by: This explainer by Betsy Sallee reminded me when to use one over the other. I recommend reading her whole post.
• tap method: “When we call .tap on an Object, we can insert extra operations before any other code executes.”

With my project, I had a “report” where I wanted to slightly manipulate, and then print out multiple attributes of the same object. Since I didn’t want to iterate over a Class (or multiple objects), I used .tap to achieve a similar “output” as .map

This was a denser post than planned, and if I were currently enrolled in a Content Strategy bootcamp I would’ve devoted much more time to making it sparkle. I’m going to push ahead and refactor the format in the next module :)

Here’s a cheesy tomato “cake” recipe that is the highlight of ever summer ❤