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
selfkeyword, 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
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