Ruby Conf 2008 First Morning
Woke up 15 seconds before my alarm went off again today. Perhaps I'm a little keyed up?
Keynote - Matz "Reasons behind Ruby"
Matz's presentation started out with the question: Why Ruby? He asked why even though Ruby has lots of problems, like all languages, why do we love it? Which is interesting. I've seen Matz talk a few time now and he always talks about the love of languages. The idea of loving what you do is never far from his mind. When Matz was young, his first computer was a pocket computer in 1980 -- only 1400 steps allowed. Only 150 memory places. And the Language was BASIC.
Later he found Lisp and it was the opposite of everything in Basic -- total freedom to do just about anything. And he loved it. That was, however, before he started using Lisp. When he started using Lisp in practice, he wasn't having a good time.
Basically Matz felt that Basic took all the power from him, but Lisp gave too much back. He wanted to have a framework to guide him, but also to have power when he needs it. Which lead to Ruby.
As always, Matz's talks are hard to sum up. You really have to experience one to know what happened.
Scaling Ruby (without the Rails) by Gregg Pollack
This talk was another one of Gregg's great survey talks where he picks a topic and then reviews all the cool things going on in that area. And his Keynote-Fu is strong. This time he was covering tips and trick to make your Ruby code faster.
In a situation where you have a bunch of threads, each will get a slice of time. But anytime Ruby drops into some C part then it blocks all the other threads because it doesn't know where it can pause the C stuff. Any IO operation is typically blocking. Making database calls is another common example of this. You can use Neverblock to have concurrent db calls.
If you have 4 CPUs and 4 threads you still only get 1 CPU. This is Green Threading and it really doesn't use all your processors to their fullest capacity. If you want use all 4 CPU, then you need 4 processes. Many Mongrels is an example of this. Most Rails apps typically run a whole pack of Mongrels to take advantage of multicore processors. Unfortunately, now you have a full stack duplicated a whole bunch of times and the memory waste is huge.
Native threads are cool and coming in 1.9, but are not concurrent due to Global Interpreter Lock. Of course you always go to JRuby (which runs on the JVM and has true native threads).
Event Machine - a fast single threaded application. It runs one thread at a time until it's done - this can be much faster (instead of each getting a slice of time). However slow requests can hold up fast requests. So Event Machine is best for fast requests. In Merb you can optimize certain requests to be deferred requests (if you know what's slow). Then you get the best of both worlds.
DBSlayer sits between the DB and your processes. You can add more DB's on the fly -- which is kinda wild.
Message Queuing with Starling. If the server dies it can recover -- nice. Very scalable as you can just add more workers.
Dropping into C -- Ruby Inline lets you drop into C inline in your Ruby code if you need close to the metal speed.
You can use Ruby-prof to profile your code like so:
RubyProf.profile do
# some code
end
You can print out fancy html output and even show call trees.
Speed up Tricks:
Method calls are slow:
"Hello " + @name + ", how are you?" vs
"Hello #{@name}, how are you?"
less calls == better
The first example is slower because of the two extra "+" calls
Destructive methods are faster than their non-destructive counterparts as they don't create a new object. So gsub is slower than gsub!
If you are doing case switching then you should put the most popular one first so the other, less popular, conditions are not evaluated.
Rails 2.2 has built in support for memoize so you can save the output of a method call and return that response the next time the method is called.
Gregg asked all bloggers to mention that Envycasts are available online (including this talk). So I hope you're happy now, Gregg.
Also you can go to RailsEnvy.com/rubyconf for the pdf of this presentation.
Simplifying Desktop Development with Glimmer by Andy Maleh
Andy wanted to create a multi-platform Ruby rich client application framework. His goals were to be concise and DRY, to only ask for the minimum info needed, and to value convention over configuration. He came up with Glimmer.
Glimmer uses Data Binding
The view and the model observe each other so that changes in one are automatically propagated to the other. Which is nice and effortless. An example he showed is where in the view he bound two different text fields to the same attribute on a model. Then when he typed in one field, the changes just showed up on the other. Without adding any additional code. This Blew My Mind as I am a guy who lives and breaths the web.
He showed the code behind the a simple TicTacToe game. It was concise and easy to read.
Home:
http://rubyforge.org/projects/glimmer/
Introduction:
http://eclipse.dzone.com/articles/an-introduction-glimmer
Glimmer will soon become an Eclipse project.
OK, off to lunch. Back at ya later in the day.
Keynote - Matz "Reasons behind Ruby"
Matz's presentation started out with the question: Why Ruby? He asked why even though Ruby has lots of problems, like all languages, why do we love it? Which is interesting. I've seen Matz talk a few time now and he always talks about the love of languages. The idea of loving what you do is never far from his mind. When Matz was young, his first computer was a pocket computer in 1980 -- only 1400 steps allowed. Only 150 memory places. And the Language was BASIC.
Later he found Lisp and it was the opposite of everything in Basic -- total freedom to do just about anything. And he loved it. That was, however, before he started using Lisp. When he started using Lisp in practice, he wasn't having a good time.
Basically Matz felt that Basic took all the power from him, but Lisp gave too much back. He wanted to have a framework to guide him, but also to have power when he needs it. Which lead to Ruby.
As always, Matz's talks are hard to sum up. You really have to experience one to know what happened.
Scaling Ruby (without the Rails) by Gregg Pollack
This talk was another one of Gregg's great survey talks where he picks a topic and then reviews all the cool things going on in that area. And his Keynote-Fu is strong. This time he was covering tips and trick to make your Ruby code faster.
In a situation where you have a bunch of threads, each will get a slice of time. But anytime Ruby drops into some C part then it blocks all the other threads because it doesn't know where it can pause the C stuff. Any IO operation is typically blocking. Making database calls is another common example of this. You can use Neverblock to have concurrent db calls.
If you have 4 CPUs and 4 threads you still only get 1 CPU. This is Green Threading and it really doesn't use all your processors to their fullest capacity. If you want use all 4 CPU, then you need 4 processes. Many Mongrels is an example of this. Most Rails apps typically run a whole pack of Mongrels to take advantage of multicore processors. Unfortunately, now you have a full stack duplicated a whole bunch of times and the memory waste is huge.
Native threads are cool and coming in 1.9, but are not concurrent due to Global Interpreter Lock. Of course you always go to JRuby (which runs on the JVM and has true native threads).
Event Machine - a fast single threaded application. It runs one thread at a time until it's done - this can be much faster (instead of each getting a slice of time). However slow requests can hold up fast requests. So Event Machine is best for fast requests. In Merb you can optimize certain requests to be deferred requests (if you know what's slow). Then you get the best of both worlds.
DBSlayer sits between the DB and your processes. You can add more DB's on the fly -- which is kinda wild.
Message Queuing with Starling. If the server dies it can recover -- nice. Very scalable as you can just add more workers.
Dropping into C -- Ruby Inline lets you drop into C inline in your Ruby code if you need close to the metal speed.
You can use Ruby-prof to profile your code like so:
RubyProf.profile do
# some code
end
You can print out fancy html output and even show call trees.
Speed up Tricks:
Method calls are slow:
"Hello " + @name + ", how are you?" vs
"Hello #{@name}, how are you?"
less calls == better
The first example is slower because of the two extra "+" calls
Destructive methods are faster than their non-destructive counterparts as they don't create a new object. So gsub is slower than gsub!
If you are doing case switching then you should put the most popular one first so the other, less popular, conditions are not evaluated.
Rails 2.2 has built in support for memoize so you can save the output of a method call and return that response the next time the method is called.
Gregg asked all bloggers to mention that Envycasts are available online (including this talk). So I hope you're happy now, Gregg.
Also you can go to RailsEnvy.com/rubyconf for the pdf of this presentation.
Simplifying Desktop Development with Glimmer by Andy Maleh
Andy wanted to create a multi-platform Ruby rich client application framework. His goals were to be concise and DRY, to only ask for the minimum info needed, and to value convention over configuration. He came up with Glimmer.
Glimmer uses Data Binding
The view and the model observe each other so that changes in one are automatically propagated to the other. Which is nice and effortless. An example he showed is where in the view he bound two different text fields to the same attribute on a model. Then when he typed in one field, the changes just showed up on the other. Without adding any additional code. This Blew My Mind as I am a guy who lives and breaths the web.
He showed the code behind the a simple TicTacToe game. It was concise and easy to read.
Home:
http://rubyforge.org/projects/glimmer/
Introduction:
http://eclipse.dzone.com/articles/an-introduction-glimmer
Glimmer will soon become an Eclipse project.
OK, off to lunch. Back at ya later in the day.
Comments