Learnings @ #RubyConf2018 DAY TWO

 I focused on the “incident response” and “make it faster” tracks. If you look closely at the image above, the star, you will see something important.  

[1] “Opening Keynote : How to Build a Magical Living Room” by Saron Yitbarek. Organizing conferences is HARD. Trying to account for all of the differences is not impossible, but you can’t please everyone. Learn from each event and iterate. This screams “Lean Startup” and is exactly how I handle the #FullstackPDX meetup. We have made major changes every year since starting with #RubyOnRailsPDX. Listen to feedback and respond. She mentioned a quote “I don’t do this for everyone. You’ll do something about it!” from a member of one of her communities. This resonates because anyone can click a thumbs up or down, but comments like this invoke change and should draw more of your attention. Keys: Safe! Wanted! Welcome!

[2] “Retrospectives for Humans” by Courtney Eckhardt. Keep conversations blame free, encourage friendly dialogue, think safe space. Follow Miller’s Law. Be careful of using “all inclusive” terminology. It puts the listener in the corner and equates to blaming. Be inquisitive first. The human you have today is the same human you will have next week. You can’t plan for the idealized human. Stay on time and on topic, stop derailments. Facilitators need to practice interrupting to keep the meeting on track! Make sure everyone has space to speak. Advocate for appropriate humor. Leave out uncomfortable jokes. You don’t have to be witty. Avoid blame and inform people not to blame themselves. If you want to hire, grow, or retain high quality talent, you NEED to watch this talk.

[3] “What poker can teach us about post-mortems” by Cory Chamblin : A post-mortem is a blame free account of what went wrong, and what we are going to do about it. Use Results Orientated Thinking over uninformed risky decisions and assumptions. Should we have prevented this? Not all outages are worth preventing. Should we try to prevent this in the future? Did we understand this risk upfront? How should our decision making change in the future? The four questions will help drive a great post-mortem, and remember this is not a perfect science. Long Term > Short Term. 

[4] “It's Down! Simulating Incidents in Production” by Kelsey Pedersen. Focused on Chaos Engineering. Scenarios. Teams. Gameday. Interesting to learn just how unpredictable chaotic events can have on an application. Do we plan for them? 

[5] “Optimizations in Multiple Dimensions” by Jamie Gaskins. Use metrics! Time between feature inception and release. Time between deploys per developer. Time between bug discovery and bugfix deployment. How long do things take to run once, versus an aggregate time period at scale? CPU versus I/O. Database. The most important measurement at any given time is subjective. CPU versus RAM. Small versus Large Datasets. Caching versus Recalculation. Be careful how you are invalidating caches, and naming things. Monitor your cache hit rate. Readability versus Throughput. Performance under load versus idle. Measurements are not a one size fits all solution, and you need to continually evaluate and reevaluate how you are measuring optimizations.  

[6] “Cache is King: Get the Most Bang for Your Buck From Ruby” by Molly Struve. Decrease database hits. Be selective. Know your gems. Make sure you understand what your selected gems are doing. There could be hidden gotchas that can cause you major pain down the road. Use the .none scope where you can to replace empty arrays. Prevent useless datastore hits. Process in bulk. Hash Cache. Framework Cache. Database Guards. 

[7] “Practical guide to benchmarking your optimizations” by Anna Gluszak. When to worry about performance and start benchmarking your code? Systematic Random Sampling. Multi-Stage evaluations. Strata versus Random Sampling versus Clusters. Use statistics over assumptions. Write Tests. Use tests to help generate metrics. Aways document your metrics. Take ownership of your code’s performance. 

#sdtech #latech #rubyonrails #startups