Ariel Caplan - "Building a Better OpenStruct" & Jason Toy - "Tensorflow"

Public group
Location image of event venue


Jason Toy - "Tensorflow"

Ruby has never been able to enter the world of machine learning...until now. tensorlfow is being ported to ruby. ruby has the potential to surpass python and the other languages as the standard language for deep learning and machine learning

Ariel Caplan - "Building a Better OpenStruct"

OpenStruct, part of Ruby's standard library, is prized for its beautiful API. It provides dynamic data objects with automatically generated getters and setters. Unfortunately, OpenStruct also carries a hefty performance penalty.
Luckily, Rubyists have recently improved OpenStruct performance and provided some alternatives. We'll study their approaches, learning to take advantage of the tools in our ecosystem while advancing the state our community.

Sometimes, we can have our cake and eat it too. But it takes creativity, hard work, and willingness to question why things are how they are.

This talk will be highly technical and full of feels, coldly objective and extremely personal, all rolled into one. We'll dive into how OpenStruct works, appreciate the work that has been done to make it better, look at some alternatives built by Rubyists including yours truly, and bust a myth that still haunts the Ruby community.

Our journey will take us through James Golick's hierarchical method cache (around since Ruby 1.9, but you've likely never heard of it!), Erik Michaels-Ober's lazy method definitions (included in Ruby 2.3), Arturo Herrero's OpenStruct alternative OpenFastStruct, and 2 OpenStruct alternatives I personally wrote.

By tracing these various approaches, and analyzing their advantages and shortcomings, we'll come to understand that there are many ways to tackle a performance problem, and sometimes the right answer is different solutions for different use cases. There is room for multiple solutions to coexist and complement each other.

Along the way, we'll rethink the worshipful attitude toward the standard library, unintended consequences of code changes, Big O versus benchmarks, the value of laziness, curating an intuitive public API for your gems, and the sometimes-amazing effect of terrible code hacks.

Most importantly, you'll walk away feeling empowered to innovate through questioning the standard approach and starting to ask: "Can we do better?"