Notes from RubyConf2020 Day 3

Published Thursday, November 19, 2020

Keynote: Kent Beck

No slides! Just a sketchpad (what a boss)

Upgrading GitHub to Ruby 2.7 (Eileen Uchitelle)

How to Fix More Than 11K Deprecations

  • Dual booting with env vars
    • Allows testing and CI to run against multiple versions
    • Use CI to enforce that new code changes work w/ $RUBY_NEXT_VERSION
  • Monkeypatch warning module
    • Enable raise on warnings to prevent regressions
    • Enable ability to output stacktrace (for easier debugging)
    • Collect callsite from backtrace to get list of violation sites
  • Fanout work to CODEOWNERS for each file with violation

What about gems?

  • Recommendation: audit gemfile first
    • Update if possible
    • Replace unmaintained gems
  • Upstream > fork
  • GitHub devs pushed up upstream changes to maintained gems
  • Then we replaced abandoned gems

Prevent regressions

  • After fixes are in, raise on warnings everywhere via monkeypatch

Deploy process

  • Prerequisites:
    • System observability
    • Test coverage
  • Push changes in small increments
    • Rely on CODEOWNERS to push and monitor changes to their areas of responsibility
  • Deploying the version bump
    • Incremental rollout (2% -> 10% -> 30% of servers, and so on)

Wins!

  • Performance boosts
    • Boot time decrease
    • Boot time object allocations decrease (more available memory)
  • New features
    • Method#inspect improvements
    • IRB improvements
      • Multi-line editing (HUGE!!)
      • Autocomplete
    • Manual GC Compaction
      • See Aaron Patterson and Emily Giurleo’s RubyConf2020 talks for more on this

GitHub is one of the largest Ruby codebases in the world, but our problems are not unique to us.

  • Opportunities to improve Ruby for everyone
  • “If you don’t like how Ruby works, change it”
  • So we pushed another upstream fix to Ruby: warning categories

“Nothing makes an upgrade harder than waiting”

“GitHub’s running on Ruby 2.7, so you can too”

Coaching Through Coding (Mercedes Bernard)

Decideing between “management” vs IC roles is like deciding between changing into bus lane vs bike lane.

  • “Management” is in quotes because it also refers to senior devs, tech leads, people who are still writing code, not purely people managers
  • Management is like driving a bus, helping your team get to where they need to go. Stops along the way are skills. You can mentor them along the way, taking them from stop to stop. Coaches offer directions, etc.
  • IC is more like riding a bike. More effort for you, but also maybe faster and more straightforward.
  • But remember: it’s not really in your team’s best interested for one individual to get somewhere faster. Better to find a way to lift the entire team.

Mentorship:

  • Relationship oriented
  • Long term
  • Requires trust, vulnerability

Coaching:

  • Performance oriented
  • More grounded in the present
  • Feedback and guidance for task at hand
  • More skills focused
  • Less long term

Coaching opportunities:

  • Pair programming
    • Use pseudocode liberally
    • Acknowledge mistakes (model polite pairing ☺️)
    • Talk through your decision making process
    • Ask questions to draw out the same from your pair
  • Debugging sessions
    • Don’t get too focused on the fix
    • Explain change before making it
    • It’s ok to go slow - check assumptions, don’t make too many changes at once
  • Code reviews
    • Make suggestions with open ended questions
    • There’s always something positive to highlight
    • No one benefits from a “lgtm” approval. Ask questions
  • PRs
    • Be intentional with your description
    • Provide context and direction
    • Think of your PR as a type of documentation
      • Treasure trove of knowledge/links/resources your team can refer back to in the future
      • Historical record
  • Estimates
    • Opportunity to highlight non-obvious considerations
    • Help team broaden thinking

Ruby Mixology with Sarah Wasser

Ingredients:

  • Lime juice (preferably fresh squeezed)
  • Gin (can substitute vodka or tequila if preferred)
  • Aperol
  • Grapefruit juice (preferably Ruby and fresh squeezed, can substitute orange juice)
  • Ice
  • Cocktail shaker
  • Peeler
  • Champagne flute (or cocktail glass of your choice)

Instructions:

  1. Add ice cubes to your shaker
  2. Measure 1/2 oz. lime juice and add to shaker
  3. Measure 1/2 oz. grapefruit juice and add to shaker
  4. Measure 1/2 oz. Aperol and add to shaker
  5. Measure 1 1/2 oz. of gin (or substitute of your choice) and pour into shaker
  6. Shake for a good 30 seconds
  7. Strain drink into your glass
  8. Peel a slice grapefruit rind and rub around the edge of your cocktail glass for extra aromatics. For extra oompf, apply flame to the inside of the rind first (!!)
  9. Twist the rind and hang on the edge of your glass for fancy garnish (optional)
  10. Enjoy!

Closing Keynote (Aniyia Williams)

How to build the future

Considerate Capitalism?

  • Maybe. Jury’s out on capitalism, let’s be honest.
  • Capitalism in its current form is built on exploitation
  • Ultimately focus on the goals, not the model. The goals will reveal the right model

Rule 1: Fuck the status quo ✊

Rule 2: Reshape the role of markets

  • Untether worth from money and tie to to common goals/collective good
  • “Person’s quality of life is best measured by quality of their relationships”

Rule 3: Design with human nature in mind

  • Every human is corruptible. Seek to maximize your happiness while minimizing harm to others.

Rule 4: Seek to minimize harm to others.

  • Place greater value on contributions to the common good.
  • Community comes before individual needs
  • Be willing to be held accountable
    • How? Model the behavior you want to see in others
    • We need role models first

Rule 5: Figure out what role you’re going to play

  • Think of changing the world as changing your world
  • Start with yourself and what’s close to home
  • What can you consistently show up and do?
  • Join a community that aligns with your values
  • WE are the saviors we’ve all been waiting for

Tools for change:

  • Define your “why”: the “why” doesn’t change, but the “how” always does
  • Make space for others
  • LISTEN, mirror, validate
  • Accountability
    • Privilege equals responsiblity
    • Be a good steward of your power

Conflict is inevitable. How you respond to it is important.

Comfort zone -> fear -> learning -> growth zone

Matz Q&A

Elixir shoutout!

Worried about introducing static types because the whole community will rush to use them, and then we lose the Ruby-ness of Ruby.

Alternative: run tests with type checking, otherwise it’s off.