Josh Thompson     about     archive     turing     office hours

POODR Notes: Acquiring Behavior Through Inheritance (Chapter 6)

I’m reading through Practical Object Oriented Design in Ruby .

These are some notes from chapter 6, Acquiring Behavior Through Inheritance; mostly these are for me, and they don’t intend to stand on their own. Read the book, work through chapter six, and then come back and read through this.

The current state of the code is we have this RoadBike object and MountainBike object that share significant code.

We’re going to extract common functionality into the Bycycle superclass.

Step one, according to Sandi Metz, is always move code from the base class to super class, never start with code in the super class.

class Bicycle
  # Please note how empty this class is.
end

class MountainBike < Bicycle
  attr_reader :size, :front_shock, :rear_shock
  def initialize(args)
    @size         = args[:size]
    @front_shock  = args[:front_shock]
    @rear_shock   = args[:rear_shock]
  end
  
  def spares
    { chain:      '10-speed',
      tire_size:  '2.1',
      rear_shock: rear_shock
    }
  end
end

class RoadBike < Bicycle
  attr_reader :size, :tape_color
  def initialize(args)
    @size       = args[:size]
    @tape_color = args[:tape_color]
  end
  
  def spares
    { chain:      '10-speed',
      tire_size:  '23',
      tape_color: tape_color }
  end
end

mtb = MountainBike.new(
  size:        'small',
  front_shock: 'manitou',
  rear_shock: 'fox'
)
road = RoadBike.new(
  size:       'large',
  tape_color: "Red",
)

We have three broad goals:

  1. Clean up the initialization methods, so the sub-classes have sensible defaults
  2. Clean up the spares method, so sub-classes have sensible defaults
  3. Accomplish 1 and 2 in such a way that the next developer who adds a sub-class doesn’t have to inspect the existing classes in great detail to figure out subtle nuance.
>> Read more

Aggregate and deduplicate your deprecation warnings in Rails

We know we all stay on the cutting edge of Rails; no one, and I mean no one out there is making a 4.2 -> 5.2 upgrade because Rails 4.2 is no longer supported.

You, dear reader, have just suddenly found an interest in resolving deprecation warnings, and as one jumps a few Rails versions in short order, finding and resolving them systematically will save you a lot of time.

Sure, you could run tail -f log/test.log | grep "DEPRECATION WARNING", but that’s not systematic. If the same line of code gets called 50 times, and prints a deprecation warning each time, that generates a lot of noise, not much signal.

This does no one any good:

endless repeat warnings

>> Read more

Notes from 'Why We Sleep'

I first read Why We Sleep: Unlocking the Power of Sleep and Dreams about two years ago. It immediately led me to prioritize sleep over almost everything else.

Most of us don’t get enough sleep, and are worse for it. Usually when the topic of sleep comes up, I say

Hey, there’s this great book I read on sleep. You should read it, and then sleep more…

The people most in need of more sleep are also usually the people most unable to make time to read a book about sleep. So, here’s an effort to help these people save time, prioritize sleep, and then maybe give the book a read anyway.

I hope to use this post to accomplish two things:

  1. Convince you that sleep is massively important and you should sleep more
  2. Convince you to read the book. If you find anything below compelling, you’ll find it even more compelling if you read the whole book yourself.

Everything that follows is a quote from Why We Sleep.

If I add my own comments, they’ll be inline and italicized, like this:

Josh: here’s a comment I’m adding

Index

I’ve quoted from this book, extensively. I don’t recommend reading this post top-to-bottom, but rather jumping around the post, from this following index, to a section that looks interesting, then going back to the top, jumping to a different section, etc.

Quotes from Why We Sleep:

Two-thirds of adults throughout all developed nations fail to obtain the recommended eight hours of nightly sleep.

This is the grab-bag of negative impacts on sleeping too little. From the first chapter. The author expands on all of these points later in the book.

  • Routinely sleeping less than six or seven hours a night demolishes your immune system, more than doubling your risk of cancer.
  • Insufficient sleep is a key lifestyle factor determining whether or not you will develop Alzheimer’s disease.
  • Inadequate sleep — even moderate reductions for just one week — disrupts blood sugar levels so profoundly that you would be classified as pre-diabetic.
  • Short sleeping increases the likelihood of your coronary arteries becoming blocked and brittle, setting you on a path toward cardiovascular disease, stroke, and congestive heart failure.
  • Fitting Charlotte Brontë’s prophetic wisdom that “a ruffled mind makes a restless pillow,” sleep disruption further contributes to all major psychiatric conditions, including depression, anxiety, and suicidality.
  • Perhaps you have also noticed a desire to eat more when you’re tired? This is no coincidence. Too little sleep swells concentrations of a hormone that makes you feel hungry while suppressing a companion hormone that otherwise signals food satisfaction. Despite being full, you still want to eat more. It’s a proven recipe for weight gain in sleep-deficient adults and children alike.
  • Worse, should you attempt to diet but don’t get enough sleep while doing so, it is futile, since most of the weight you lose will come from lean body mass, not fat.

Add the above health consequences up, and a proven link becomes easier to accept: the shorter your sleep, the shorter your life span.

The old maxim “I’ll sleep when I’m dead” is therefore unfortunate. Adopt this mind-set, and you will be dead sooner and the quality of that (shorter) life will be worse.

>> Read more

How I take notes, AKA 'Add an Index to Your Notebook'

A while back, sometime in 2017, I wrote this tweet:

Since then, I occasionally have conversations with people, about how we all handle taking notes in physical notebooks. Rather than wrestling with a web browser to find this one specific tweet, I’ll just drop everything I have to say on the topic into this post.

After encountering this “indexing” method, I’m a firm convert to the value of organizing paper notes in this fashion. It helps me get very dense notes in my notebook, and it’s easy for me to organize my notes by topic, rather than in chronological order.

Here’s my current stash of “indexed” notebooks:

image of an index All of these notebooks are full of notes, and they’re all indexed.

Mostly, I talk about indexes with Turing students, getting ready to dive deep into technical topics. A single lesson might reference a new keyboard shortcut for their code editor, a novel way of using Git, several new methods in a given programming language, and more.

Rather than stick all of those on a page marked with the current date (and being unable to quickly look up the Git commands next time I break something with it) I’d just add each new piece of information to a page specific to the topic.

If I didn’t have a page specific to the topic, I’d flip ahead of the first empty page in my notebook, add the topic to the top of the page, and then add that new topic to the front of my notebook, in the index:

image of an index My very first Turing notebook (this single notebook lasted me about half of the program

Lets dig a bit deeper into the git index item (the very first item, top of the page in the picture)

Each of those small black lines marks another page of notes about Git.

image of an index Here’s ‘git’ the index, and you can see that I have at least four pages of notes on git, scattered throughout my notebook

>> Read more

LeetCode: Words From Characters, and Benchmarking Solutions

I recently worked through a LeetCode problem.

The first run was pretty brutal. It took (what felt like) forever, and I was not content with my solution.

Even better, it passed the test cases given while building the solution, but failed on submission.

So, once I fixed it so it didn’t fail on submission… it then timed out. My code was so inefficient leetcode’s test suite took too long to finish.

I have a few learning objectives for doing this kind of code challenge:

  • Improve my knowledge of Ruby’s API
  • Get better at benchmarking code “snippets”.
  • Refresh/document my “process” for learning new things about a programming language, for the benefit of Turing students who are attacking their own code challenges.

The challenge and my (not quite working) solution.

Here’s the given instructions:

You are given an array of strings words and a string chars.

A string is good if it can be formed by characters from chars (each character can only be used once).

Return the sum of lengths of all good strings in words.

Example 1:

Input: words = ["cat","bt","hat","tree"], chars = "atach"
Output: 6
Explanation: 
The strings that can be formed are "cat" and "hat" so the answer is 3 + 3 = 6.

Example 2:

Input: words = ["hello","world","leetcode"], chars = "welldonehoneyr"
Output: 10
Explanation: 
The strings that can be formed are "hello" and "world" so the answer is 5 + 5 = 10.

Note:

1 <= words.length <= 1000
1 <= words[i].length, chars.length <= 100
All strings contain lowercase English letters only.
>> Read more