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!
