Skip to content

Instantly share code, notes, and snippets.

@avidas
Last active November 20, 2018 15:27
Show Gist options
  • Save avidas/eb9b5d4ae57b1d67f0464a281a00e8a6 to your computer and use it in GitHub Desktop.
Save avidas/eb9b5d4ae57b1d67f0464a281a00e8a6 to your computer and use it in GitHub Desktop.
RubyConf 2018 Notes

RubyConf 2018 Notes

Keynote by Matz (Ruby Creator)

  • Why do people create programming languages?
  • C was designed to replace assembly to write OS
  • Matz wrote Ruby for fun
  • People write programming languages, why not me
  • Japanese aesthetic/minimalism in Ruby

The games developers play (Andy Croll)

  • Punitive, parental seniority can be used to protect codebase
  • Take time to build mental health habits everyday
  • Your adult can be a better arbiter based on keystone habits
  • Sitting with discomfort necessary for learning and growing
  • Examine overpowering feelings before acting on them

Graphics/Simulations (Ryan Davis)

  • Author of Graphics gem in Ruby
  • Primarily for graphics simulations but can also be used for game dev
  • Generative art demos

It's Down! Simulating Incidents in Production (Kelsey Pedersen)

  • TLDR; Stitch fix built a Faraday middleware to replace http calls from downstream services with 500s for certain systems to test how their service would react
  • List use cases in runbook
    • Did app load
    • Can you view inventory/details
    • Did alerts go off
  • Called game day exercies, entire remote team monitoring system behavior
  • Gated by feature flags so can rollback anytime
  • The service failed in unexpected way
  • Also uncovered a lot lacking in their monitoring/alerting strategy

Uncoupling Systems (Jeremy Hanna)

  • Separate but interconnected tower of responsibilities
  • Anti pattern: Not discussing trade-offs of decisions
  • Strategies
    • Async calls
    • Load balance the work
    • Replicate Data
    • Read through cache, explicitly tell when to expire and when to rebuild
      • Invalidation, stale data
    • Batch IO work in threadbare workloads
  • events != streams
  • last write wins, if can ensure that, process queue last in first out
  • determining systems of record and derive meaning can get hard
  • Out of band precompute as much as possible
  • id where data is derived
  • retryable
  • Publish an artifact instead of redoing the work
  • improvement over table scan

Optimizations in multiple dimensions (Jamie Gaskins)

  • Optimization benefits/drawbacks may not be linear
  • To monitor
    • Systems
      • RAM consumption
      • App bootime, delays (minimize restarts)
      • time for each transaction (latency)
      • transactions per second (throughput)
    • Team level
      • Time betn feature inception to release
      • Time betn deploys per developer
      • Time between bug discovery and bug fix deployment
  • Optimizations
    • CPU bound
      • parallelization
      • caching
      • Frequency of GC runs
    • I/O
      • Remote APIs, persistent connections
      • Remote cache
      • Remote Filesystem
      • Databases
        • (Vacuum/Index)
        • Great if enough memory to fit whole dataset
  • Latency vs Throughput
    • Most important metric at any given time is subjective
    • If latency is already good, only then we can handle throughput
  • Algorithms, optimize for RAM/CPU space time complexity
    • Memory allocation within Ruby. 16kb page of memory. All ruby object live in those page
    • Ruby allocates a batch of RAM, and optimize that
    • MRI reserve RAM
  • Memoization — caching at object level
    • lifetime of process level
  • Small vs large datasets
    • If optimized for large datasets. MRI hash uses different underlying data structure for 3 keys vs more
    • Ruby sort mergesort for small, quick sort for large
  • Remote cache
    • Costs roundtrip
    • Cache is about mitigating costs
    • App remote network latency to remote cache
    • 10 ms of cpu time not same as 10 ms of wall clock time for throughput reasons
    • Cache hit rate — want over 99%
    • When are we invalidating too little vs too much
    • If less than 90% util, cache isn't being useful
  • Question if abstractions like AR help
  • Perf under load vs perf at idle (prod workload)
    • Optimize for production workloads

Cache is King (Molly Struve)

  • Batch processing
  • Avoiding n+1 queries
  • local cache
  • Divide into two classes
    • Ruby to replace data source
    • Bulk serialization, hash cache, framework cache
  • Use ruby to prevent useless datastore hits
    • Database guards
  • return unless user_ids.any? (No db hit)
  • RDS cpu on fire, wasn’t long running queries
    • Lots of fast queries
  • Serialization of vulnerabilities
    • Active Model serializers
    • Use Bulk Serialization in batches of thousands
    • Bulk serialization deploys (no of db hits)
  • RDS CPU utilization
  • Ruby process data in bulk
  • Elastic search vulnerabilities indexed by client
  • get all serialized vulnerability cache
  • Ruby hash to cache the index name
  • Call made now once per client not per vulnerability
  • 65% job speed up
  • Redis is so fast easy to forget its a network call
  • Hash cash always faster
  • Shard mysql db
  • Active Record Connection
  • Proxy object
  • Know your gems
  • Active record none can avoid db hit
  • Empty dataset hit
  • Goal: Prevent useless datastore hits
  • Took reporting time down from 10 hours to 3 hours
  • How many MB per second of data is getting read from Redis
  • Redis network traffic spikes resolved

Talk on GC in Ruby (Colin Fulton)

  • OOM errors
  • Ruby does not free garbage collected objects
  • Ruby allocates page of memory to avoid calling expensive malloc/free
  • Ruby can still leak memory
  • Ruby can leak when accidentally make a reference to something can’t be deleted

Reducing memory usage in ruby (Aaron Patterson)

  • Same talk as in GoRuCo 2018
  • Direct ISeq memory
  • ObjectSpace allocation_tracer

Ruby Code Generation(Alex Stephen)

  • Use Ruby in Google for Google Cloud management
  • magic-modules gem
  • Auto-generation: Write once, write anywhere
  • You want as much logic in templates as possible
  • not clever
  • be verbose
  • Alterations make to template get to final state

Standard (Lightning talk)

  • Justin Searls is building an opinionated Rubocop wrapper!

No Title Required (Jim Liu)

  • How can you have outsize influence without official leadership role?
  • Leadership is something really personal, we all have own timelines
  • If you can positively influence people, you can have most influence
  • Build consensus, celebrate wins, push for change
  • Leadership is not a static milestone
  • Flywheels, serious of steps that built off of one another and result in higher performance
    • Id, fix, prevent similar classes, teach others, repeat
  • Not your idea: Once idea is out there it becomes everyone’s
  • Observations on leadership
    • title != ability to lead
    • Give equal weight to engineers
    • Don’t be subconsciously influenced by those ideas of levels
  • Leadership is continuous practice of positive influence
  • Incentives and values of organization influence what kind of leadership bubbles to the top.
  • Lots of different leadership styles
  • More inclusive type of leadership styles
  • You cannot be passive about leadership
    • We as individuals have to advocate for yourself
    • If measurable impact, be super direct and call it out
  • Busy work: Best most/impactful impact
    • Busy work in one domain doesn’t mean busy work for everyone
  • Say no a lot
  • Don’t talk, listen
  • Strive for continuous improvement
  • Honest assessment of your skills
    • What am I good at? What do I want to improve?
    • Hour each month to talk about longer term goals
    • Areas of success/development (Photo)
  • Feedback
    • Evaluation of trust (Feedback)
    • Ask specific feedback
    • How were the technical aspects of my presentation to the leadership team last Tuesday?
    • eedback good cadence, habit of giving feedback
  • Work
    • Dive deep, top customer problem
    • How that get translated into code
    • Really understand Requirement -> Spec -> Code
    • Team appreciate, hires appreciate
    • Dive deep enough to uncover what really is happening
    • Better systems and tools
    • Best practices, designs
  • Extra work, read source code, read interview feedback
  • What components do I need to get better at
  • Technical parts super important
  • Project management, Launch plan (how will we release/rollback), Stakeholder communications, Metrics
  • Measure as often as you can
    • Track OKRs
    • Writing on paper and come back later
  • Always mentor, new hires. Best leaders take ideas to harness
  • Find mentors
  • Someone trusts you enough to answer
  • Physical and mental health

The New Manager's Toolkit (Brandon Hays)

  • Talk to everyone
  • Team feels no career progress
  • Design engineering ladder
  • Help define and defend team values
  • Performance improvement plan
  • Manager primary job is to be available (Office hours)
    • Listening means following up
    • Backlog what is next up
  • Interpersonal conflict: Trust is critical
    • Find common ground
    • Book: Crucial conversations
    • Culture change process
    • Team offsite, find team to do, managers
    • The power of vulnerability
  • Programmers, why are we so focused on brains in jars rather than taking care of our body
  • If you want to be able to take responsibility for others, work on yourself first
  • As IC not exposed to what is happening at management level, how do we make it easy?
  • Being your authentic self is good enough
  • You get to take another swing at it
  • Leave this industry a little better than you found it
  • Podcast: Managing Up

Eiffel's Tower (Nicholas Means)

  • Every organization is political
  • To influence change, you must engage and participate in politics of company
  • Networking and self promotion
    • Reframe as making friends and telling stories
  • Grab coffee with your PM, sales
  • Self promote: Doing good work is sometimes not enough
  • Tell boss what you have been upto
  • Telling stories
    • Book: Dale Carnegie
  • Negotiation
    • There is always a middle ground
    • Go into negotiating understanding everyone’s needs, including your own
  • Don’t become chokepoint of information for your team
    • Can’t save from all shit umbrella
    • Blocking all noise is comfortable, but keep from delivering all value they are capable of
    • If they never see org politics, never learn build their ideas or sell them
    • Obligation to help your teams how to navigate the org
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment