I had a pleasure of giving a presentation about dRuby with Masatoshi Seki, (I call him "Seki san") the author of the library, at this year's RubyConf, and I would like to take you through the journey we've been through.

In this blog post I will talk about

• How to prepare talk proposals
• Being inspired by other speakers to strengthen your talk
• Learning by coding

I hope this blog post gives you an overview of the conference from an angle of "Distributed and Parallel computing in Ruby" and also inspires you to submit a talk proposal of your own at next year's RubyConf in Miami.

Preparing a talk proposal

At the beginning of August, Kakutani san(the organiser of Japan RubyKaigi) suggested Seki san and I submit a talk at RubyConf together.
Seki san has been a regular speaker of RubyKaigi since the Kaigi started in 2006, so he has plenty of topics to talk about.

I also gave a talk about dRuby at London Ruby User Group (LRUG), and had a good response when I explained the internal of dRuby. So, we decided to give inside story of how dRuby was born.

Our initial title was

The dRuby Begins (Metaprogramming rises)

However, Gwyn suggested

The title does not tell you the topic itself and what kind of benefit the participants can gain by listening to your talk. Also, the topic should be more controversial so that people want to hear your talk whether they agree with you or not.

With that in mind, here is the revised title.

Rails Is A Follower: what we can learn from dRuby’s metaprogramming magic

It sounds pretty controversial to call Ruby On Rails a "follower", but this is actually from Matz's forewords in the The dRuby Book. The title also tells the audience about their objective, learning metaprogramming.

Preparing the talk once accepted

Seki san lives in Japan and I live in UK, so planning is a bit harder for us than other participants.

We started planning for the talk after we received the acceptance email in early September.
Seki san drafted a history of dRuby including how he used to programme before he developed dRuby, and Kakutani san and I gave some feedback to polish the draft.

Since this was a joint talk between Seki san and I, we needed to split responsibilities. We decided that I would give the initial introduction and demo of dRuby. Seki san talked through his history of various programming styles, some frustrations of the style due to constraints of Web Programming, then how he came up with initial design sketch of dRuby and various metaprogramming techniques used inside it.

Seki san finished writing the draft in Japanese, then I translated it into English. I have a fear live coding, so I created demo videos in advance( using an online screen recorder called Screenr) and embedded them into our slides.

Preparing a talk for a foreign language.

Speaking at a conference is nerve-racking for most of us, but especially for Seki san, since this was his first trip outside of Japan, and he has never given a presentation in English.

Once the transcript was ready, I rehearsed the whole presentation including Seki san's part in front of the Bambinos, and then Mark "The DragonFly" Evans corrected the grammar and recorded the transcript of Seki san's part. I was hoping that Seki san would have mastered the queen's English by the time he presented at the conference.

We started rehearsing as soon as we arrived in Denver.

Seki san practiced the presentation with the audio I gave by splitting the entire audio files into each sentence, so that he could practice them individually.

His pronunciation was really good, so I did not have to correct much. However, he often struggled to breathe in a sentence.

Let's look at the following example.

You also spend time trying to come up with cool urls, but that’s not the core of your application.

You may think you only need to breathe once after the comma, but the sentence is a bit too long for non English native speakers speakers because they speak more slowly. In addition, Japanese is a very flat sounding language, so it's harder to understand where to put the right pause or emphasis. I saw that Seki san was pausing for breath in the wrong positions such as "that’s not the * core of your * application"

To overcome the problem, we listened Mark's audio file repeatedly to mark where to put breaking points as follows:

You also spend time * trying to come up with cool urls, * but that’s not the core * of your application.

After our preparation, we went to Bubba Gump Shrimp Company (a restaurant inspired by the 1994 film Forrest Gump) and played ping pong with Igarashi san, and Urabe san(he is one of the CRuby core committers).

dRubyConf Day 1

There were lots of interesting sessions, but Seki san and I attended talks which seemed relevant to our dRuby talks.

Allow me to reintroduce myself. My name is MagLev. 11:30am - 12:15pm (45m)

This talk explained how to use object database in Ruby using MagLev, a Ruby implementation running on a Smalltalk VM.

MagLev's strong selling point is Stone, an object database that lets you save not only data, but also code, and each virtual machine (sounded like an equivalent of one ruby process) can synchronise its data using transactions.

1 # VM #1
2 PROOT = Maglev::PERSISTENT_ROOT
3 pierre = Cat.new("Pierre")
4 pierre.object_id
5 # => 1234567
6 PROOT[:pierre] = pierre
7 Maglev.commit_transaction

In the above example, the beginning of the transaction is automatic and it is committed transaction when "Maglev.commit_transaction" is executed. You can also change the starting option of MagLev so that you can restrict transactions only within a transaction block. One interesting syntax is "transient" that allows a virtual machine to keep the block unique to the local VM, and let everything else be synced to the Stone.

1 Maglev.transient do
2   # Will only be persisted locally
3   # Won't be written to the stone
4 end

During the talk, Redis's SortedSet was used as a comparison. Redis has a rich sets of data structure and SortedSet can be used for calculating leader board. You may be okay as long as your leader board has only one comparator, but it will cause a problem when you have to solve tied score where you need to sorted by a second comparator (Of course, you can specify multiple order columns easily using "order" in relational database ).

The point he wanted to make was not whether relational database or Redis was a better fit for the leader board, but you can keep using any Ruby's data sets to solve your problem using Maglev.

Seki san's opinion about Maglev was

MagLev seems good fit to provide persistency for objects, but not sure if that's sufficient to synchronise distributed processes. It may be a good idea to distribute MagLev via dRuby.

Interestingly, Jesse Cooke (the speaker) came to speak to me after our dRuby talk, and suggested exactly the same idea.

Building Data Driven Products with Ruby 3:30pm - 4:15pm (45m)

This talk was about how a data scientist handles big data.

Seki san seemed to enjoy the talk. What was interesting was the speaker's very pragmatic approach about tackling his problem. Though people use solutions like Hadoop to solve big data, the majority of big data consists of noise, so having appropriate filtering at the beginning of data capturing phase makes data a lot smaller..

1 STDIN.each do |line|
2   puts line if line.match(/user_id=&/)
3 end

The above three lines of code may well be sufficient to solve your big data issue.

Dissecting a Ruby Block 5:30pm - 6:15pm (45m)

This was a very hard core topic and Pat Shaughnessy spent the whole 45 minutes explaining the implementation of Ruby's block. (More hard core fact is that Pat took 6 months off to study the Ruby source code.)

Why is "Block" so related to dRuby? One of the tricks of dRuby is "Marshal.dump". You can send the value of an object to other process only if the object is serializable and passes its reference information if not. One of the thing you can not serialise in Ruby is the "Block", so getting to know the internal is important to understanding why it does not work.

Pat patiently explained the usually unfamiliar C data structure using lots of diagrams, though I must admit I did not wholly understand. When I told that to Seki san, Seki san gave me a special lecture for 2 hours until I understand (I think I did....)

The night before our talk

The next day was the important day for us. We already had our slides ready, but Pat's talk inspired us to talk about more advanced topics.
If your talk is all easy and understandable, the audience will be satisfied with what they heard. If your talk is beyond their reach, however, that will challenge the audience to learn more.

We decided to add extra topics at the last minute, but we had one problem to conquer, which was myself. Before I explain to the audience, I had to understand what I was about to talk about. We started brain storming about new topics at 10pm, and Seki san patiently explained until I understood. By the time we finished taking all additional demo videos and slides, it was after 1am.

Day 2

DRb vs RabbitMQ Showdown 1:30pm - 2:15pm (45m)

"DRb vs Eventmachine Showdown" was the original title, but Davy Stevenson explained to us it was misleading title because she was initially planning to use EM, but switched to RabbitMQ after submitting the talk proposal to RubyConf (Don't worry, our dRuby talk was nothing to do with Rails even though it was on the title).

Seki san and I were afraid of being attacked by "DRb vs xxxx" war, but her point was to use right tool for the right problem, and she said she still uses dRuby for certain parts and still likes its simplicity and its ease of use. We were so impressed with her talk that I asked her to take RubyFriends photos with Seki san. She not only accepted, but also had our dRuby book and asked us for the autograph. This was the first time someone asked my autograph (apart from banks), so I was so flattered, but Seki san , as a famous dRuby guy in Japan, was used to such an occasion, so he pressed his custom made dRuby stamp (dRuby's symbol is a swallow from the original Japanese book).

Rails Is A Follower: what we can learn from dRuby's metaprogramming magic 2:30pm - 3:15pm (45m)

It's our turn now. Many Japanese participants (many from Asakusa.rb) occupied the front area as well as Matz, and Eric "drbrain" Hodel who is an expert in dRuby. I thought I could ask help to them when someone challenged us with tough questions.

We started with introducing ourselves (including the trivia that Seki san is the Pokemon Master, then started my demo of dRuby.

dRuby allows you to communicate across multiple processes, so the demo often requires you to star tup multiple irb sessions. Handling multiple terminals and explaining at the same time is a recipe of disaster, so recording everything in advance seemed to worked well.

I was a bit worried about explaining the topics that we added at the last minute, but that went well, too. I even put in a trap (code with some bugs) and asked the audience if this code works, and luckily Aaron "Tender Love" Patterson fell for it (Thanks!!).

The talk was done, and it was then Q&A time. There were certain tough questions I could not answer, so I asked Eric and Muraken san(another CRuby committer) to answer on my behalf. People also asked what library uses dRuby and the audience knew more than I knew. Apparently the dRuby is used in RSpec, god, pry and many more!!.

We were overwhelmed by the positive response after the talk. It was impressive to know that dRuby and Rinda have been used at a financial industry over several years.

The last person even came to us with a gist that enhances concurrency in dRuby. Seki san was so impressed that he wrote back a comment in his gist with test code to break his code (I definitely think this is his way of showing appreciation....)

Day 3

I had been waking up around 5am every day mostly due to jet-lag, but also I had some deep technical discussion with Seki san about distributed programming.
Today's topic was

Async programming is all about programming synchronously".

The topic almost felt me like a Zen discussion and he spent good 3 hours lecturing about it until breakfast, and the conversation continued through out the whole 3rd day. He was even writing some code to prove his point during "Intimate chat with Matz" session. I really would like Seki san to talk about this topic in future conferences.

Seki san also told me another profound thing. While I was listening to his lecture, I had a brief moment where I thought I understood the topic,
then I got stuck again as soon as he asked similar questions from different angles.

Seki san's response was

Because you haven't coded.

Yes, what we need is "We Code", which nicely matches the Matz's keynote session.

"d"RubyConf after party.

We all went to a local Russian restaurant after the conference, but our "d"RubyConf hadn't ended yet.
Seki san and I were at a separate table and just kept talking and coding. Matz , Sasada san and Kosaki san(both CRuby committers) briefly joined our "dRuby after party" and talked about embedding mruby on Ruby for ultimate distributed computing environment. I am not sure how much of our discussion we had over beer was possible, but I am excited to hear more about the topic in near future.

Finally

Thank you very much for reading this long blog post, I hope you enjoyed it and my story gave you inspiration to submit your own next year.

Additionally, If you want to know more about our dRuby talk, you can watch our slides, videos, or even buy our dRuby Book!!