David Stevenson, flouri.sh, talk “Playing With Fire: Running Uploaded Ruby Code in a Sandbox” at Golden Gate Ruby Conference

A sandbox needs to:

• Limit functionality
• Make it so code can’t break out
• Separate code space
• Bounded execution time

Sandbox gems

• Freaky-freaky sandbox gem (MRI Ruby): it’s a gem, but you can’t use gem install.  No support for 1.8.7 and later.
• JavaSand gem (JRuby): same API as the freaky-freaky sandbox, more actively maintained
• Rubinious has SubVMs, David doesn’t have experience with it

acts_as_runnable_code is a sandbox helper:
set up sandbox easily with referenced classes
pass in top-level binding

Built an example in just a few minutes that allowed people to enter experession to be evaluated and opened to the audience (offering cupcakes to anyone who broke it!).  Here’s some of the first experiments from the audience:

talk by Aaron Quint, quirkey.com, at Golden Gate Ruby Conference

very simple framework, define a route, where it goes, return a string
Sinatra is not a framework, doesn’t dictate how to create your code.  It is a library.  A ruby library for making Web applications.

Why? HTTP as a language? with REST and other conventions, it is cool to think of it as a way of two apps speaking to each other.  If your library needs to “speak HTTP,” Sinatra is a good way to do that.  It’s a nice layer on top of rack.

Aaron described a vision where all libraries would have web apps interfaces: to allow you to configure your library or inspect information.  These are designed to be available on localhost, not designed for the “global web.”

For example: Aaron wrote ‘gembox‘ for Ruby Gems, which will display in a browser the list of installed gems.  Simply calls the gem APIs, but provides a UI on it instead.  The app is very little code, low effort for a significant return.

Vegas: super simple Sinatra starter.  Provides simple options for running the app (startup, saving pid, etc.)  (this is a cool idea right now, just a simple class right now)

Would be neat to be able to search for all gems that have Sinatra or Vegas interfaces.  Question from the audience about security issues.  This is still pretty early in development, but there are some neat ideas here and potentially useful tools.

great session by Rich Kilmer at Golden Gate Ruby Conference.

MacRuby, started toward the end of ’07.  It has two ambitious goals:

• Make Mac OSX the best platform for Ruby developers
• Make Ruby the best Cocoa programming language on OSX

Apple has the higher level APIs in Objective-C.  RubyCocoa (2001) mostly written in C will bridge  Ruby & Objective-C.  Quite verbose. Rich showed a “hello world” that was about a page of code in small type.  Problem: it’s a bridge.  Thereare holes, expensive (slow), messaging syntax is diferent.  Ruby uses green threads (it is not re-entrant) — only one native thread can enter the Ruby runtime at any time. Tricky garbage collection, etc.

The development of MacRuby leveraged the key observation that Ruby is actually similar to Objective-C.  MacRuby replaced the Ruby 1.9 garbage collector with the Objective-C garbage collector.  Ruby’s hash is actually an NsMetuable dictionary.  Every Ruby class is an Objective-C class.  You can use MacRuby, at runtime to add methods to an Objective-C object.

MacRuby is 0.4.  Syntax is better, but still a lot of code for “Hello World”

HotCocoa
In the MacRuby “hello world” a lot of the code is in configuring, setting up the app, wiring things together.  HotCocoa is just a library that helps simplify this setup process.

Much more concise, but it isn’t magic.  ‘window’ returns an NSWindow, it isn’t obscured, just decorated.  You have all the NSWindow methods available,

Hello World turns into 7 lines of code!  [update: nice post with code snippets]

hotcocoa <app> (similar to rails <app>) will generate all the files needs for a Mac application.  Framework is dropped in there, so you can give the code to someone and they don’t need

HotConsole: written in MacRuby and it is irb, but {}.methods(true,true) will show you all of the methods in an MSMutable dictionary, but otherwise {} behaves just like a Ruby hash. Also let you interactively create native Mac OS widgets (create a window, add a button, make it do something) all by typing in a few lines into this interactive console.

MacRuby Experimental

LLVM replaces yarv.  In this, using MacRuby the jit generates machine code. This makes it 4-5x faster than 1.9 (which is 4-5 times faster than 1.8).  Goal is to pass all of 1.9 Ruby specs, and it is well on its way to doing this.  Also plans to make it reentrant.  Goal is to automatically generate GrandCentral code hich allows the code to run across all the cores in the machine.  Rich expects this to be complete by the end of the year.  This could also be applied to compiling ahead of time which would enable running the code on a certain devices that don’t run Ruby, yet run OSX code :)