05:18:00
Hello, my name is Melony Erin Franchini, or Mel for short.
How appropriate that I'm the second in line because this talk is about 'The First Follower.' This is inspired by a TED Talk given way back in 2010; it’s an oldie but a goodie that lasts less than three minutes. I highly recommend you watch it when you have the time. It describes a music festival and how momentum and movements get started.
There’s always first a leader, a lone nut who's dancing wildly. They follow and continue dancing, and then the first follower shows up; they join in and now there are two people dancing. So maybe that lone nut is on to something. The first follower calls over a buddy, and now there are three—three is a crowd. More people join, and momentum begins to build. People rush over to the dance party, and by the end, everyone is dancing—all thanks to that lone nut.
The lone nut may be the one remembered, the leader or the founder, but if you look closer, it’s that first follower who transforms the lone nut into a leader. So, you might be thinking 'great Mel, I now know what to do next time at a music festival,' but what does this have to do with software engineering?
I was talking to a new acquaintance yesterday, and one example I thought of is that maybe one person is working on a corner of the application that no one really wants to touch, but everyone agrees it needs to be addressed. Another person may join, and then others start paying attention. Eventually, that part of the application might become essential.
For those of you here today, think about who might be afraid they’re not good at networking or a little shy. If you see someone you know talking to someone you don’t know, gather the courage to listen in on the conversation or even join it.
Just yesterday at the conference, we witnessed many projects that looked overwhelming at first glance, prompting us to ask the team leader or manager how they would get everyone on board and motivated. But I think we should turn to the team and ask who has the courage to stand up and be the first person to actively participate, to show others how to join in.
That’s the first follower. What I'd like to challenge you with today is to expand your definition of leadership to include that first follower and to recognize leadership through followership. Acknowledge when you see a prospective new hire walk in or a colleague working hard; everyone likes to be noted for their contributions, especially when they see it in themselves.
This value you add to your company and team often goes unrecognized. Bringing it up in your performance review can be crucial; I know some of you have that coming up soon.
Without this form of leadership, we would just be a bunch of lone nuts sitting at our computers, but together we can create something truly great.
09:08:00
Okay, so apparently my handwriting is bad. When I wrote on the giant poster, it looked like I was going to talk about 'How to Boil Water,' which is a super interesting topic, but not one I’m qualified to discuss. Instead, I will talk about 'Building Broken Gems.'
I'm Samuel Giddins, the security lead of RubyGems, and I work for Ruby Central these days. This will be a fun, fast-paced story, so stick with me.
So what’s a gem? Raise your hand if you’ve built a gem like this before: gem build something great. I promise you, if you've ever run 'Rake release' on a gem or something similar, you've built a gem. Here's the process: you give it a gem spec, run 'gem build,' and it successfully builds.
So what's in that gem? It’s a tarball. If we list that tarball, we can see it has three files: a metadata json, a data tar.gz, and a checksum file. Inside the metadata file, after extracting and gunzipping it, you'll find YAML, which is everyone's favorite format.
This is an abbreviated version of what the Rails gem spec looks like inside the Rails gem. Notice it’s YAML and not Ruby.
So, what do I have to do with security? Unfortunately, it turns out I do. Let’s package our own gem. Here’s a short code snippet I borrowed from the RubyGems.org test suite this morning. We can create a tarball, add some gem files to it, and pretend we have our own gem specification.
Nothing says we have to use 'gem build' or a proper gem spec—we can cheat. Instead of declaring it as an object, we can treat it as something risky with Ivars, which might be problematic for installation. If we load that gem spec and rely on an unsafe load, we could potentially overwrite passwords or execute arbitrary code.
You could push it to RubyGems.org, but there was a problem when saving your gem. Earlier this summer, I published a CVE that enabled users to push broken gems like that to RubyGems.org. Luckily, no one exploited this issue, and I managed to find and fix the bug. Thus, all’s well that ends well.
It is possible to build broken gems, though, and I hope you support maintaining clean security in our ecosystem.
12:48:00
First of all, let’s talk about immutability. We’ll delve into that in two slides; there are only four. Let’s write a service object that does some work, though not real work—real work is for Monday. This example features a FooDo class and a Bar class. It's going to call something and do some operations—feel free to read, but it’s not particularly important.
Instead, let’s look at a version that does a bit more meaningful work. It handles errors and exposes them because something is calling FooDo or Bar and they care if it fails. You might find yourself writing that class; it certainly looks familiar.
However, this discussion was about immutability, and I’m straying from that point. Let’s proceed to the next important aspect.
The gem called 'memory' adds a memoization decorator, essentially a successor to the memoist gem. It works with methods that have specific signatures, but I often don’t use them due to the behavior I’d like to promote.
Here's a class that does the same as FooDo but in an immutable style. This approach helps expose errors while ensuring all methods are nouns, and none of these methods return different values upon repeated calls. This avoids side effects since once you understand a function’s behavior, you do not have to worry about surprises.
This consistency is significant for those, like me, who struggle to hold multiple concepts in their mind simultaneously. Everything in almost every class I write is consistent and immutable. As I mentioned earlier, I rarely use the memoized keyword solely as a performance optimization. Instead, I treat it as an annotation indicating that a method's value does not change.
Understanding that a piece of code is immutable makes reasoning about it much more accessible, and I’ll present further proof with the next code example.
None of us have a solid grasp of what this code does. If I had written something meaningful with descriptive method names, you could trust those names and reason about its functionality. However, this is where state mutating and examining become problematic. You need to simulate the state's evolution through time to understand the class's output, leading to much deeper contemplation.
In the alternate version, everything is easier to comprehend. This is unsurprising, as it's divorced from state changes; thus, you don’t need to simulate it to grasp its workings. In past experiences, I often encountered classes that, despite their capacity to make sense, become convoluted when they contain state changes.
Such classes make reasoning difficult due to instance variables being updated as a byproduct of actions within methods—this convoluted state management leads to unintended complexity as the class size increases.
17:49:00
I want to thank Mark for the great talk on Packwork yesterday. By the way, this is my contribution; it’s called the 'Excited References, Extensions, Explorations Section' to Mark’s Talk. Although talks don’t typically have such detailed sections since you can look that up later, I aim to provide rapid assertions and explorations related to Mark's remarks.
Hi, I’m Stephan, and I work at Gusto; we also use Packwork. I’ll provide quick references to all the points Mark covered yesterday and highlight what’s out there. He discussed documenting APIs and the significance of lists; it turns out you can make undocumented APIs another list.
Mark talked about return types—Active Record’s propensity for scattering throughout codebases can be hazardous, and treating return types as a list can enhance clarity. We also watched him draw boxes representing architectural layers, which should be conceived as lists of information.
He emphasized ownership questions, which too fit in this way—keeping track of which team owns what is crucial. We have a code ownership gem providing extensive capabilities beyond classic GitHub file acknowledgement.
There’s also a significant but still undeveloped topic in our community. While we currently lack comparable resources, we know other communities—like Java—are advanced in this arena. As for VS Code extensions, there are visualization tools to illustrate the structure of your packages.
To give feedback on PRs, you can rely on a metrics emitter for Datadog. You might find that using Packwork isn't necessary anymore, as a built-in pack is available that performs this task much faster.
I feel a bit like this guy, as I’m currently writing a book on these topics. Drew, you’re here! Please tell me, Drew is here! There’s also a discount code available, allowing you to grab this book. I think we all know what this is about; it's a Ruby promotion to explore. When you output this in an environment, such as IRB, you witness these seamless integrations.
22:07:00
In addition, there's a Ruby on Rails modularity Slack channel where numerous individuals discuss these themes. That link is cumbersome, but if you’ve noted changes in your app becoming smaller, don’t overlook these details regarding our community.
Addressing the recent news: Dojo4 is faced with closure, thus prompting us to find a new venue for our Wednesday morning 'Coders and Coffee' gatherings. This gathering has been a vital part of the Ruby community in the Front Range, and we wish to continue it. I’m looking for options; perhaps the new Southside Cafe could work, so if you have suggestions or know other suitable venues, please reach out to me.
25:14:00
Thank you!
