RubyConf Roundup: Day Two

I just finished the second day of RubyConf 2012 in Denver.  There were more great talks and a ton of information to digest!  Check out the following for synopses of some of the talks I attended.


RUBY VS THE WORLD
Matt Aimonetti
Slides

Here, Matt gave us a tour of three modern programming languages: Go, Clojure and Scala.  Matt discussed strengths, weaknesses and applications of each, and described them in relation to Ruby.

Matt compared programming languages to human languages, in that the way languages are designed affects our worldview and the way we solve problems.

Bad ways of evaluating a language:

1. Looking at "hello world" only
2. Looking purely at syntax.  This might give you a feeling about the language or its aesthetic, but no deep insight.

Good ways of evaluating a language:

1. Looking at the language's philosophy
2. Looking at use cases for which the language was designed
3. Trying to look at the language with new eyes, like it's the first language you learned

GO:
Compiled, structural, typed, object-oriented, and functional.
Learning curve: normal.
Has the concept of a pointer, so C experience helps.

Matt showed a Go use-case with concurrency, walking through a short program to fetch three URLs at once.

Matt created a function that fetches URLs and created a channel (a broker for concurrent tasks) to do the work.  He then created a "go" function, which runs asynchronously and fetches the URLs.  Finally, Matt implemented a for loop where you (a) ask if there's anything ready in the channel, (b) get it, if it's there, and (c) add it to an array.

Philosophy: Go tries to be the new C. It's not a big language and it's easy to remember.

What's bad about it?  It can be too low level, it doesn't have great garbage collection, and it has "weird" conventions at times.

What's good about it? It has simple specs, modern standard libraries, great concurrency support, very fast compilation, flexible code organization, a simpler take on OO, functional programming features, good error handling, and good documentation.

CLOJURE:
Clojure is a compiled, dynamically typed, functional, mostly object-oriented language.

Learning curve: difficult.

One use case: data processing.

Philosophy: Clojure is "the pragmatic scheme." Scheme and Lisp are great, so Clojure adds more object-oriented features to make it more useful in the real world.

What's bad?  It's not very simple, not always consistent, one needs to know lots of functions and macros, it's not really web-focused, it can cause a "brain stack overflow," it can be a difficult mental context switch, and it has cryptic error stacks. (whew!)

What's good?  Matt didn't go into this in great detail.  He didn't really sell this one.

SCALA:
It's the closest of these languages to Ruby, according to Matt.  It's both OO and functional. It's compiled and can have either static, inferred or dynamic types.  Learning curve is moderately difficult.

One good use case, according to Matt, was for Service Oriented Architecture, or whenever you need a more "enterprisey" Ruby.

Scala has lots of familiar elements if you're coming from a Ruby background.  It has enumerable objects, anonymous methods, default method parameters, metaprogramming features like method_missing, duck typing, mixins, and a focus on testing.


Philosphy:  Scala is like Ruby, minus the scripting, plus static typing.  Matt called it "the academic version of Ruby."


What's good?  Scala has a focus on tests, inner methods, lazy evals and streams, a great garbage collector, good performance, and good tool/IDE support.  It's it's easy to get started, has inferred types, uses flexible functional approach, includes modern concerns like parallelism and pattern matching, and has a very active community.

What's bad?  According to Matt, Scala has a huge surface, a stiff learning curve, "abused" OO syntax, and poor documentation.

OVERALL:
How did this language exploration affect how Matt writes Ruby?  Matt noted that Ruby is as functional as it is object-oriented,  and these two paradigms are complementary.  In Matt's view, functional programming should be used to extend your program with new operations.  Object-oriented programming should be used when the data in your program evolves.


HOW TO BUILD, USE AND GROW INTERNAL TOOLS
Keavy McMinn
Slides

Keavy, who works in a large distributed team at Github, discussed (a) use-cases for developing internal tools and (b) best practices for using internal tools.

Central theme: Create the culture you want at your organization through internal tools.

Most people use and abuse internal tools, like using email threads for "everything."

Keavy discussed three use-cases for internal tools, each brought about by someone's "pain."

PAIN #1:
"I don't know who is working on what."

Keavy showed how Github built a simple social tool where you can say what you're working on.  "I am next shipping X."

Keavy observed that this visibility makes developers more motivated to do a great job on projects, and added a sort of "friendly competition" dimension to communication.  "We see awesome get shipped, so we want to ship awesome too."

PAIN #2:
"I feel disconnected because I am remote."

I was surprised to see that about half of the audience works remotely when Keavy asked!


Keavy said that Github deals with this, in part, by not "abusing" tools that require everyone to be in the same place at the same time, like physical meetings and phone calls.  Github employees are spread out across many different time zones, so coordinated meetings can be tough.

On the other hand, one audience member noted that these distributed practices (email, pull requests, tickets, social feeds) can be much more time-consuming than coordinated meetings, because of the long feedback cycle.


Github has also implemented "fun" tools to help folks feel connected.  They have a company music feed where everyone can listen to the same music, and everyone can rate/select songs that are played.  Employees can even change the volume!

Keavy noted that digital communication can be tough. When the message is neutral, it's usually perceived as negative over the Internet.  Positive language is generally much more powerful.

Keavy mentions: A big challenge with distributed teams is that people have a tendency to "hide" until their work is  complete and "shiny," and then show their work after.  This is usually bad for both company culture and project momentum.  Committing early and often works much better.

Keavy calls Github's paradigm "cooperation without coordination," as most work is asynchronous.

PAIN #3:
"I don't like {something that's being done in the company}."

Keavy said that teams should always be giving and receiving feedback on internal processes.  ALWAYS.  Don't just "go with the flow" in terms of internal tools/processes; think of ways to constantly improve them.

Github has an "ideas" feed, where employees are always suggesting ways to work better together.  They receive over 30 ideas per month and even more comments on those ideas.

If there's a tool you're using for everything, that's a red flag.  It's hard to opt out of long email threads, but not as hard to opt out of a ticket you're watching, a pull request, or a more specific tool.


ARDUINO THE RUBY WAY
Austin Vance
Slides

Austin gave an overview of his experiences with Arduino, and discussed the use of Ruby to control Arduino devices.

Arduinos ship with a basic IDE and a "stock" C++-based DSL.  It lets you compile and verify code.

Austin showed us RAD, a system for Ruby Arduino Development.  Debugging is hard in RAD, and it's not under active development, so he avoided this.

Austin noted that Node.js works really well with Arduino, since Arduino devices are asynchronous as well as Node.js.

He also showed us Duino, a C++ library you put on the Arduino that acts as a service.  You can use node.js to talk to service, just like any web service, and abstract away some of the hardware details. Austin wanted to write Ruby, though, so he created a Ruby library to do what Duino did.

Goals of this library: Fully tested, easy to extend, great documentation, zero startup time, fun.

Architecture:
There's a "Board" class that's the programmatic representation of the Arduino.  It has pins, it has I/O, it knows how to talk to and read things. One thing it doesn't do is communication, though.

The "TxRx" (domain-specific term) class handles sending and receiving messages.  TxRx functionality is injected into the board, so you can write an adapter for Wifi or Bluetooth  as long as you adhere to same public interface.

There's a "Components" module that sets up pins, makes sure the board is there, etc.

The architecture involves passing functions around, as procs, so the system can respond to future events like button presses.  You can pass event-specific data into the procs, like the magnitude (distance) of a proximity sensor event.

Finally, Austin hooked all of this up to a Sinatra app, and used it to control his Arduino-based t-shirt cannon.  He let the audience interact with the app through their laptops, fire t-shirts, and much fun ensued!


INSIDE RUBYMOTION
Rich Kilmer
[no slides yet]

Rich showed us RubyMotion, a system that lets us write Ruby Code, compile it to Objective-C, create iOS apps, and ship them.

EverClip, for example, is built completely in RubyMotion.  It makes use of 3rd-party objective-C libraries, won an award, and is for sale in the app store.  Upshot: It is possible to make money with RubyMotion.

RubyMotion is like Ruby, but statically compiled.  It features a terminal-based toolchain, and you can keep using your favorite editor.   You can use any Ruby feature, including metaprogramming ones, except eval.

Rich showed us how much more complex and verbose an Objective-C "hello world" app is compared to Ruby.  He then showed how we can actually write OpenGL code in Ruby, using C constants and C libraries directly.

RubyMotion starts with Ruby source code, creates an abstract syntax tree, as usual, and then compiles it down into LLVM portable assembly language.  Objective C classes map one-to-one with Ruby classes.

Rich showed us how we can debug in RubyMotion, do the typical "breakpoint" stuff, debug, and see where we are in the Ruby code.  He then showed us how testing support is much more robust in RubyMotion than in Objective-C.

Interestingly, Rich surveyed the audience and found that almost none of the Objective-C developers wrote automated tests for their apps!

Finally, Rich showed us the "console," which looks like ERB, but dynamically compiles your Ruby code, sends it to the iOS emulator, and returns the result.  In other words, you can fetch a button object, change the text, and see it on the simulator in real time!  Lots of "oohs" and "aahs" from the audience there.

When taking audience questions, Rich couldn't come up with a single use-case where vanilla iOS development would be preferable to RubyMotion.  I'm a bit skeptical about that, as mobile developers always talk about how they need to "go native," but I enjoyed this talk nonetheless!

Questions?  Comments?  Let me know!  Read more about all the talks here.