00:00:00
Welcome to the presentation.
00:00:27
All right, good! We've got the screen, we've got slides, my clicker works, and we're going to start off with some fun. Before we get into anything else, I want to show you a little bit of what we've been playing with back in the office.
00:00:56
This is a Parrot AR drone flying under the control of one of my coworkers, Karen Meyer. We have a nice big open atrium area in our office that allows us to fly these drones, so during lunchtime or after work, we'll go out there and have fun! There goes Karen. Now, what you need to realize is, I’m videoing this with another drone that is also flying. That’s why the camera is a little bit wobbly.
00:01:23
We’re trying to fly around the big open area, keeping Karen in my field of view. Looks like we’re good! We're just having fun playing with these drones, moving them around. I won't make you watch the entire thing, but let me show you what happens when your drone runs out of battery.
00:02:06
Flying drones is awesome fun! I highly recommend you grab one and have a good time with it.
00:02:23
Now, can you still hear me? Are we good? Yes? Great! So today, we're going to talk about Ruby, code, threads, events, and yes, flying robots.
00:02:35
Before we dive in, I want to share a concept called the narrative chart. We're going to tell some stories here, and I think storytelling can be fascinating in different contexts. One thing you can do with movies is go through and chart them, observing how the narrative moves along and how the protagonists evolve throughout.
00:03:01
For instance, let's consider the classic film '12 Angry Men.' Has anyone seen it? It’s a remarkable psychological drama where twelve jurors argue for the entire movie in one room. Here’s the narrative chart for '12 Angry Men'.
00:03:27
Now, another movie you might be more familiar with is 'Star Wars.' How many of you have seen it? If you don’t raise your hand, you might lose your geek status!
00:03:47
The narrative chart for 'Star Wars' shows various important moments like Luke by himself, the rescue of Leia, and the duel where Obi-Wan dies. This chart highlights the characters' journeys throughout the film.
00:04:31
There’s a third movie that I'd like to mention. How many here have seen it more than once? Raise your hand if you understand exactly what was going on. This is the narrative chart for that movie.
00:04:54
I want to ask a question: how many people in this room consider themselves primarily Ruby programmers or developers? Please raise your hands.
00:05:15
Now, keep your hands up if you consider yourselves primarily web developers (this includes Rails or Sinatra). Okay, a few people are still up.
00:05:38
I’ve been using Ruby since before Rails was even a thing, so to me, Ruby is a general-purpose programming language. I’ve used it for a lot of tasks. For instance, I got frustrated with a build system at one of the clients and ended up writing an entire build system in Ruby just to make my life easier.
00:06:10
I want to encourage you to consider using Ruby for non-web-related projects. There are numerous applications for Ruby beyond just web development.
00:06:21
Today, I'm going to talk about a particular project we completed that was not web-based. While it was tied to a web interface, this project mainly involved backend processing.
00:07:03
When we arrived at the client's site, several hardware management systems were already in place for devices such as Roombas and general-purpose robots. The client had numerous Roombas and general robots communicating with their servers through respective management programs.
00:07:28
They asked us to write a drone manager program, which I was very excited about because this would allow drones to connect to it via TCP and create sockets to send information. The key point is this was not a web program; it was a program communicating over sockets to hardware devices out in the wild.
00:08:01
We needed to support thousands of connections simultaneously while efficiently transferring data.
00:08:25
You might wonder if we can handle thousands of connections. The original Java programs made 4,000 lines of code. After completing our Ruby version, we managed it with only three to four hundred lines.
00:08:51
Now, we intend to keep our drone manager relatively simple—essentially a data pump without too much intelligence embedded. This was to avoid issues we encountered with the original versions—a common problem called the 'sundering herd' where all the devices attempted to reconnect simultaneously.
00:09:22
In this way, the complexity and size of our Ruby code greatly reduced while maintaining functionality.
00:09:47
The system architecture involves a manager that talks to a message queue, a set of workers pulling data, and a Rails web portal displaying the information to users.
00:10:11
The monitor’s job is crucial; it displays the positions of all the drones in a sophisticated graphic environment using a high-definition interface.
00:10:41
The monitor receives specific commands to track drones by their unique IDs that the manager creates upon connection. This system is efficient and allows communication among all components.
00:11:12
Now, regarding our drone session: we created a protocol called the Flying Robot Objects with Navigation Protocol (FROWN). It consists of four main commands: two sent by the drone and two received by it.
00:11:44
The commands include a position command where the drone reports its coordinates, a name command that identifies the drone, a name query command sent to the drone, and a crash message indicating that the drone should disconnect.
00:12:12
Here’s an example workflow: when a position update is sent, the monitor will send back a name query, which will prompt the drone to respond with its name, and movements will be updated accordingly.
00:12:42
The monitor's responsibilities also include maintaining a constantly updated view of all drones, utilizing graphical indicators to represent each drone's location and status.
00:13:06
Next, I’ll show you the code we wrote for this drone manager—this part remains fundamentally connected to what we did in real-life settings. I'm omitting some error handling and logging details to focus on the code that ensures everything works together.
00:14:05
This manager program mediates communication between drones and the monitor, efficiently transferring data by tagging messages with the correct IDs.
00:14:44
We utilized EventMachine, a Ruby library that allows you to handle asynchronous events similarly to Node.js. Setting up the main program required configuring the servers listening for incoming connections.
00:15:08
Now, upon detecting an incoming connection, we create a new instance of the drone session in EventMachine. After initialization, our session waits for incoming messages that will be parsed line by line.
00:15:34
Once the connection closes, we handle cleanup, ensuring the session is removed from the active connections.
00:15:53
Our NQ private method sends serialized message data to the monitor, integrating data into the broader system.
00:16:03
Questions about how we merged all these components into a streamlined drone management system?
00:20:57
This project emphasizes the immense utility of Ruby for handling many simultaneous connections while maintaining simplicity in code structure.
00:21:48
Eventually, we ran performance tests with hundreds of simulated drones, which confirmed Ruby’s capability in this area. So, what didn't we like about the project?
00:22:18
While Ruby’s evented IO is powerful, it limits access to multi-core processors because everything runs on a single thread.
00:23:01
In scenarios like these, event programming can make error handling a bit tricky, leading to challenges like callback spaghetti that can confuse newer developers.
00:23:28
Alternatively, in threaded programming, you must look out for race conditions when multiple threads share mutable data, which can complicate design.
00:24:06
Using techniques such as message queues helps avoid data sharing issues but can get burdensome due to potential inter-thread communication challenges.
00:24:45
Erlang approaches this by sending messages between processes, allowing for easy communication without data sharing issues.
00:25:18
Celluloid offers an actor-based solution; each actor operates independently, sending messages asynchronously, making it easier to manage parallel tasks.
00:26:14
With Celluloid IO, you'll be using a familiar syntax while allowing behind-the-scenes evented IO to occur, maximizing your use of Ruby’s threading potential.
00:26:55
The best part is, we can implement a robust drone management system effectively using this method.
00:27:14
I want to show you a video that captures the drones in action—these are drones controlled in real-time, illustrating our work.
00:29:05
They showcased response times, demonstrating the effectiveness of this Ruby-based drone management system. That’s exciting!
00:49:02
I'm Jim Wyrick, and I work for Neo. Thank you for your attention today!
