Meeting notes, September 2011
Jesse Hallett
The New Engine Yard Office
1009 SW Yamhill
503-750-5378
415-235-8938
The Beginning Ruby meetups have been a big success. Sign up for the
mailing list! http://groups.google.com/group/pdxruby-beginners
George from New Relic announces that New Relic will have a Q&A session
at the Ruby meeting next month. They will also show off some new
features. In the meantime he collected some questions to prepare
answers for for next month.
Markus Roberts puzzles us with a new hangman. He points out that in
Ruby 1.9 you can give a hash as the second argument to gsub. Also,
hash keys are ordered.
Koichi Sasada, @_ko1, came all the way from Japan to talk to us about
Ruby MRI 1.9.3 and 1.9.4 and future research. Koichi is the creator
of YARV. He demonstrates a "hello world" program written using only +
and - symbols. He also showed off a program written by another Ruby
committer that looks like an ASCII-art globe and that outputs the same
globe, rotated a few degrees. Feeding the output back into Ruby over
and over shows the globe rotated a bit more each time.
Koichi's slides are available at http://atdot.net/fp/view/9ps4rl (this
URL does not seem to be working at the moment - does anyone have a
variation that does link to slides?)
Ruby Interpreters in the Parallel Worlds
In 2008 Dave Thomas said, "f**k Ruby." We got the message: "fork
Ruby!" Now we have Jruby, Maglev, Ruby2JavaScript, Rubinius, and
others.
Ruby is becoming a standardized language. JIS X 3017 (Mar/2011) is
the standard for Ruby according to the Japanese Industrial Standards.
An ISO standard is in progress
People are even getting jobs working with Ruby. Dreams came true!
Ruby 1.9.2 is the current stable version and 1.9.3 will be finished soon.
1.9.3 introduces a stop-the-world mark and incremental sweep garbage
collector, replacing the older mark and sweep GC. The incremental
sweep feature means that the "world" does not need to remain stopped
during the entire sweep process.
1.9.3 also replaced fixed 10 ms wakeup intervals for Ruby threads with
threads that can sleep an arbitrary length of time. This can reduce
power consumption slightly. According to the measurements that Koichi
showed us the savings amount to about 0.3 W difference from a starting
point of about 50 W.
It is not clear yet whether the next version after 1.9.3 will be 1.9.4
or 2.0. If the next version is 2.0 it will include some new syntax
like Module#mix and Module#prepend.
Koichi's research goals are to improve performance, memory
consumption, and power consumption. One possible future change is a
generational garbage collector.
Looking at concurrency, Koichi believes that both threads and multiple
processes have drawbacks. Threads lead to bugs, and isolated
processes require marshaling overhead to send information between
processes. Koichi is working on a new system where a single Ruby
process would run multiple VMs, each of which in turn could run
multiple threads. The VMs would act like separate processes, except
that they would share memory so that references could be passed
between them with little overhead. If this works out we could have
the safety of processes with the performance of threads.
Milind S. Pandit talks about Heroku and Toto. Milind works at
tenfouragency.com. Heroku is a worry-free PaaS (platform as a
service). It runs your apps, backed by Postgres.
You can run a low-traffic production app for free. Heroku gives you
one app process and a small amount of database space at no cost.
Beyond at resources are charged by the hour, like EC2.
There is one step to deploying an application to Heroku: git push heroku master
There are a fewt steps to setting up a project to run on Heroku: git
init && git add . && git commit -a && heroku create your-app-name
--stack cedar. The last command adds a git remote to your local
repository called "heroku".
Cedar is the new Heroku stack. It supports Ruby 1.9, Node.js, and
Java. It will become the default stack eventually.
You may need to configure the PATH in your Heroku environment to
include the node.js executable if you are using Rails 3.1 and you want
to use the Rails asset pipeline. You can modify PATH as you would any
other environment variable:
heroku config:add
PATH=vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin:bin
But wait, you need to run your database migrations!
heroku run rake db:migrate
You can use the heroku log command to find out why your app is not working.
heroku logs
Toto is a tiny blogging engine written in Ruby. It is about 300 lines
of code. Toto is distributed as a gem. There is also a standard file
layout for a toto blog in a git repostory:
git://github.com/cloudhead/dorothy.git.
Because toto is a Rack application, you can embed it in your Rails
application as middleware. There is a bit of configuration required
in your rackup file to get toto to run in a subdirectory. You also
need to fiddle with asset paths and URL helpers. The toto
documentation covers this nicely.
Toto has no search or commenting functionality. For comments you can
use the Disqus service.
Heroku gives you a read-only filesystem. The only writable files that
you can write from your app are temporary files. The one dyno that
you get for free shuts down after 15 minutes of inactivity - which
makes the next request really slow. The free New Relic uptime
monitoring addon will keep your dyno alive all the time by pinging it
- if you are comfortable with that arrangement.
Tim Felgentreff, an intern at Maglev, gave a talk on debugging code in
Maglev. Smalltalk VMs generally provide better tuning and debugging
options than Ruby VMs do. Tim hopes that Maglev can bring those
features to Ruby.
Tim has a prototype that will catch errors in an application and will
store a continuation that has been paused at the point where the error
occured. That includes the full stack and variable assignments of the
process at that point. You can load the continuation at any time to
track down the problem. Continuations are stored using Maglev
persistence. The prototype is implemented as an in-browser debugger.
You can tinker with the application memory and resume the request,
assuming you are working with a web application, to fix the problem
without restarting the server. Since Ruby is very dynamic, there is a
heck of a lot of tinkering that you can do. Once method definitions
and variable assignments are modified sufficiently the request can
resume and complete as though no error had ever occurred.
Tim's prototype functions as middleware. You can throw it into pretty
much any web application.
If you are not comfortable fiddling with your production code while it
is running, you can pull stored continuations onto a development
machine. In this case the continuation is not executable because
sockets and file handles and whatnot that it references are no longer
accessible. But you can still get valuable information by inspecting
it.
Theoretically you could get a snapshot of a process as a continuation
without stopping the process. There would just be a slight pause in
the request. This could allow you to grab stack to inspect later even
if no error has occurred.