Three Mini-Talks

by Sarah Mei, Tony Arcieri, and Chris Eppstein

This video, titled "Three Mini-Talks," features three speakers sharing their insights at the GoGaRuCo 2012 event. Each speaker presents unique topics, providing a diverse exploration of programming and personal growth.

Tony Arcieri on Celluloid:
- Introduces Celluloid, described as a comprehensive framework for building multi-threaded applications likened to “threads on Rails.”
- Discusses the combination of object-oriented programming with the actor model for easier concurrency handling.
- Describes how Celluloid allows for both synchronous and asynchronous calls using futures to manage concurrent tasks efficiently.
- Highlights the usability of actor pools for managing groups of actors and task scheduling in concert with system resources.
- Provides practical examples illustrating Celluloid's functionality, encouraging viewers to utilize resources like Railscasts for in-depth understanding.
Chris Eppstein on Naiveté:
- Shares personal anecdotes reflecting on his life experiences that were driven by naiveté, leading to unexpected opportunities.
- Recounts moments from high school and junior college, illustrating how seemingly risky decisions often resulted in growth and success.
- Encourages listeners to embrace their dreams and take leaps of faith, emphasizing growth that comes from pursuing passions regardless of apparent challenges.
Sarah Mei on MRI Internals:
- Discusses the creation of the Ruby programming language, presenting a narrative that goes beyond its historical reception to delve into the process of its development by Yukihiro Matsumoto (Matz).
- Highlights Matz’s gradual innovations in C that culminated in the birth of Ruby, illustrating how incremental changes can lead to significant advancements.
- Concludes with a reminder that extraordinary achievements often stem from consistently addressing small problems, advocating for a mindset of progressive improvement in programming and technology.

Overall, these mini-talks not only provide technical insights into concurrency, personal risks and decisions, but also the innovation process behind programming languages. The discussions resonate with the idea that both personal and professional growth often emerge from naiveté and perseverance, and that major advancements can arise from gradual improvements.

00:00:02.760 Welcome to the session featuring three mini-talks.

00:00:08.400 Rather than deal with the madness of trying to manage multiple lightning talks, which can be expensive and stressful, we decided to select three individuals to give awesome talks and squash them all into one session. This way, they can have a few extra minutes compared to the usual lightning talks.

00:00:20.279 Without further ado, our first speaker is Tony Arcieri, who is going to talk to you about Celluloid. Tony works at LivingSocial and will introduce himself further.

00:00:33.780 Thank you, everyone. I'm Tony Arcieri, and I assure you, I know what I'm talking about, despite sounding somewhat like Josh.

00:00:43.320 So, how many of you have heard of Celluloid? That's a good showing of hands! I work at LivingSocial on the architecture team, and in case you forgot, we're hiring. Celluloid is a comprehensive framework with many features for building multi-threaded applications.

00:01:03.059 I like to refer to Celluloid as threads on Rails. It offers various abstract and generalized solutions for concurrency, particularly around fault tolerance. One notable project utilizing Celluloid in production is Sidekiq. Many people are successfully running it in their applications.

00:01:21.600 Celluloid combines object-oriented programming with the actor model, which I believe complement each other like peanut butter and chocolate. One of my favorite quotes from Alan Kay, which I've included in many talks, is that object-oriented programming should naturally facilitate concurrency.

00:01:39.540 Alan Kay viewed objects as servers or biological cells. Celluloid provides active objects compared to the typical sequential passive objects.

00:01:50.640 Unlike other concurrent object-oriented programming techniques, Celluloid is based on the actor model. I am a big fan of Erlang, which pioneered many excellent techniques for building concurrent programs.

00:02:06.959 The actor model may sound intimidating, but it's actually quite simple. Each actor has an address, akin to sending a letter. If you know the address, you can send a message. Actors can create new actors.

00:02:20.760 I am not the first to merge these concepts; this has been a significant research topic since the late 1980s and early 1990s. A similar project was called Atom, developed in Python in 1997 as part of a PhD thesis. However, it did not gain much traction at the time.

00:02:35.760 When we discuss concurrency today, we often hear about functional programming or languages like Go, while actor-based object-oriented programming has become less common. I aim to breathe new life into it, and I've gotten great feedback from people saying that Celluloid simplifies concurrent programming.

00:02:48.840 So today, I'd like to show you the basics of Celluloid and how to use it. Here’s an example from a Railscast on Celluloid, which I highly recommend for further learning.

00:03:01.620 We have a typical Ruby class with Celluloid included. We’ve defined a launch method that performs a countdown and then 'blasts off'. Instead of receiving a typical object back, we get a Celluloid actor.

00:03:12.239 The first thing we do is make a synchronous call to this actor. Synchronous calls in Celluloid function like normal Ruby method calls. Here, we call the launch method, which executes the countdown and returns the result.

00:03:43.860 Behind the scenes, things are a bit complex. A proxy object intercepts the call, sending messages between threads. Synchronization takes place in mailboxes, allowing the actor to process messages one at a time, eliminating the need for manual synchronization.

00:04:06.720 Now, let's discuss asynchronous calls, which allow work to be scheduled for execution without knowing precisely when it will execute. You indicate this by using the '.async' method, which was much improved from previous versions of Celluloid that used '.bang' methods.

00:04:25.139 When calling launch asynchronously, it returns immediately, allowing the current thread to continue while the countdown still runs in the background. Synchronous calls, on the other hand, block the thread until the result is returned.

00:04:49.979 If the return value of an asynchronous call is essential, you can use futures. The analogy I often use is calling ahead to a restaurant to order food. You save time by ordering ahead, but you may have to wait for your food upon arrival.

00:05:20.820 In a Celluloid task, you leverage futures to execute a function that requires a significant amount of processing power. This will allow the function to return immediately, ensuring the main thread is not blocked.

00:05:54.640 Moreover, one of the most appealing features of Celluloid is pools. Pools let you manage groups of actors to schedule tasks effectively. You can create a pool by invoking '.pool' on any class that includes Celluloid and it can be sized according to your system’s CPUs.

00:06:23.220 This is particularly advantageous compared to other concurrency technologies, as it dynamically adjusts to your available resources. For parallel computations, you can create multiple futures and map across them to compute Fibonacci numbers in parallel.

00:06:45.840 Keep in mind the Global Interpreter Lock (GIL) when working with parallel I/O or HTTP requests, which could limit performance if your operations rely on conventional Ruby.

00:07:06.600 Ultimately, for better performance, consider using JRuby or Rubinius for projects requiring significant concurrency. That is all I have for you today.

00:07:20.600 You can find me on Twitter as 'basco', or follow the Celluloid-specific account for more insights, and you can visit celluloid.io for additional resources. I also have stickers, so feel free to grab one after my talk!

00:09:22.200 Now, please welcome back Chris Eppstein to the stage. You may know him from the Compass framework and his extensive work with Sass.

00:09:29.640 Chris doesn't have any AV materials, just the microphone. Let's give a warm welcome to Chris!

00:09:45.420 Hello everyone, can you hear me okay? This is my first time not talking about Sass, so I might be a bit nervous, but I'll do my best.

00:09:57.420 When Josh asked me to give this talk, I took some time to reflect on what I might share. One day, while driving to work, I heard an eco-activist recount their journey over the last 30 or 40 years. This individual had dedicated their life to fighting environmental issues and had achieved remarkable things. At one point, they shared a powerful story about being in a clear-cut forest with their son.

00:10:28.800 This experience profoundly impacted them and motivated the individual to take action. Reflecting on their journey, they admitted that had they known the challenges they would face, they might not have taken those risks but were ultimately grateful for their ignorance.

00:10:58.500 This resonates with my life experiences, where I've often taken risks without realizing it, resulting in surprisingly positive outcomes. I want to share a few stories from my life to illustrate this point.

00:11:29.940 In high school, I once sat down in homeroom, and the girl next to me asked if I had completed my college applications. To my horror, I realized that I had totally forgotten about them, with the due date being that very day. I rushed home to tell my parents the news, and my mom suggested I get a job instead.

00:12:23.880 I got hired at a nearby pizza place, but the assistant manager there took an instant disliking to me. During one confrontation, she insulted me, saying I would never amount to anything, just a 'stupid pizza boy.' Instead of feeling defeated, I took stock of my situation and shared my aspirations with her.

00:12:56.840 The next day, I went to the local junior college and enrolled as a music major, focusing on music theory and composition. While I was there, I also took calculus, even though I initially thought it was unnecessary.

00:13:14.820 As my studies progressed, I discovered a love for math and science. I thrived with personal attention from instructors in a supportive environment, which I would not have experienced had I gone directly to a four-year institution.

00:13:35.760 Towards the end of my time at junior college, I approached my physics instructor about my interest in physics. Although he suggested it was a challenging field, he mentioned Caltech as an excellent, albeit competitive, place for further study.

00:14:06.960 Feeling motivated to prove him wrong, I spent a considerable amount of time preparing for the entrance exams. To my surprise, I got accepted into Caltech, where I met students who had been preparing their entire lives to enter that prestigious institution.

00:14:54.420 Looking back, it was a naiveté that allowed me to pursue opportunities without realizing the rigorous commitments they entailed. While there were struggles along the way, my experiences eventually paved the path for my future endeavors.

00:15:16.680 During my time at Caltech, I discovered programming and fell in love with a project called Sass. I became determined to elevate its visibility within the community.

00:15:31.680 Despite having no prior experience in community management or open source contributions, I dove headfirst into the project. Over the years, Sass grew in popularity, and today, it’s recognized as an essential tool for many web developers.

00:15:56.640 It previously amazed me how, after three years, Sass reached a level of popularity where developers began asking if they should integrate it into their projects. Fortunately, I had support from awesome people along the way.

00:16:18.420 As I've matured, I now find myself in a mentoring role, where I offer advice to others. One piece of wisdom I've imparted is that it's okay to take that leap and pursue your passions, even if it seems daunting.

00:16:40.320 If you believe in your aspirations and are willing to invest your efforts, who am I to discourage you?

00:17:01.620 And now, let’s turn to our next speaker, Sarah Mei. Many of you may know her as a co-founder of RailsBridge and for her dedication to community initiatives.

00:17:17.880 Sarah has made significant contributions to expanding diversity in the tech community, including her work with the Diaspora project. I’ll let her take the stage now.

00:17:31.920 Good afternoon everyone! As Josh mentioned, I am Sarah Mei, a developer at Pivotal Labs in San Francisco.

00:17:44.640 I co-founded RailsBridge and have been involved in numerous open-source projects, with Diaspora being the largest. However, today, I'm here to share a story with you.

00:18:02.220 I'm going to delve into the creation myth of Ruby, as it's become a fascinating topic in the Ruby community.

00:18:18.480 Most of you might know the basics: Ruby was created by Yukihiro Matsumoto, known as Matz, who released the first version in 1995. If you look up Ruby on Wikipedia, you'll find a pretty straightforward account of its history.

00:18:41.760 Matz was a C programmer who was frustrated by the limitations of existing object-oriented scripting languages, which prompted him to create Ruby. While this myth holds a lot of truth, it also skips over a critical aspect: the 'how' behind Ruby's creation.

00:19:03.180 Let me share a personal experience from a conference I attended in Singapore, where I ended up having a one-on-one conversation with Matz.

00:19:24.480 For three hours, it was just the two of us, walking around and talking. It was an intimidating experience, but it also gave me the opportunity to ask him about Ruby's inception.

00:19:45.780 I wanted to understand how a C programmer could transition to creating a language like Ruby, and Matz offered some surprising insights.

00:20:07.680 He described how he gradually customized his programming environment over many years, creating C extensions that ultimately resembled Ruby's syntax and capabilities. This process unfolded organically, rather than being a sudden lightbulb moment.

00:20:29.700 In essence, he gradually transformed what he was doing in C into something that looked and felt like Ruby, and eventually brought it to life as a coherent programming language.

00:20:51.500 This insight shifted my perspective on programming languages. I realized that changing the world, or simply our environments, does not require grand ideas or sudden revelations.

00:21:14.680 Instead, we can accomplish significant change by incrementally addressing small issues we encounter every day.

00:21:33.180 So, if you admire those who create groundbreaking technologies, remember that they might just be regular people like us, continuously fixing small problems until they reach something extraordinary. Thank you!