Day 15

Day 15 and I’m still here. If you didn’t see it I wrote a rather long blog post today as one of my requirements for Flatiron. Since that took up over an hour and I had a 1:10.00+ video as a lesson I didn’t get much done. However, I DO have notes from the past couple of days that I never took the time to share.

So on Saturday morning I did a study group with some people and learned a lot. We went through one of the more challenging Procedural Ruby labs. One thing that I had never thought to do was put my pry in the rspec test file. So I could look at what was going on when everything had already been passed in. I had been putting the pry in my code and then needing to call the methods above it before I could work on the current problem. I’m still not 100% on utilizing pry but I’m getting there. It’s definitely easier and more useful than IRB.

Another nifty thing I learned from the study group, which I’m still not completely comfortable with but makes sense, is calling methods on end. For example, we did this:

def all_holidays_with_bbq(holiday_hash)
  holiday_hash.map do |season, holidays|
    holidays.map do |holiday_name, supplies
      supplies.include?("BBQ") ? holiday_name : nil
    end
  end.flatten.compact
end

The way this works is the .flatten.compact is being called on the return value of holiday_hash.map. It’s still settling in my mind and I haven’t used it since but I can see where this is useful.

Mike who I pair programmed with last night informed me to get a solid understanding of self so I’ve been taking details notes on things I think are of value. I have:

We can define methods in which we tell objects to operate on themselves. We do so using the self keyword, inside the body of an instance method, to refer to the very same object the method is being called on.

I like that definition and it’s not too abstract for me to understand what it’s saying.

Lastly, in one of the lectures, Avi stated to try not to use the return method. He said if you have to use return you’re probably doing something wrong and utilizing return can cause problems. This is because every method has a return. We should be able to get what we need utilizing higher level methods that will return to us what we’re looking for. This makes a lot of sense to me. If I have to use the return method then I’m probably missing something in the code I’m returning. While this isn’t a hard and fast rule it’s something I’m going to try and stick to.

If you’re keeping up, I didn’t look into ||= &. or .tap today.

I’m 55% through Object Oriented Ruby. I just realized this because I took a glance at my Dashboard which I haven’t really been doing lately. It’s moving along but I know it’ll take a while once I get to the end. I have some projects to look forward to!

Time spent today: 3:17
Time spent total: 71:00
Lessons completed today: 2
Lessons completed total: 260