Tuesday, October 30, 2007

MountainWest RubyConf 2008: Call for Presenters

MountainWest RubyConf 2008 is scheduled for March 28 and 29, 2008. It will be in Salt Lake City, at the same great venue we had last year, and it is again our intent to record and make available all the talks under a Creative Commons, Share-Alike license—you can see last year’s talks here: http://mtnwestrubyconf2007.confreaks.com/

If you’ve been working on a problem or project in Ruby, this is a great opportunity to talk about it. We looking for short (250-500 word) proposals outlining the content and target audience for your talk. Proposals will be accepted until Midnight (MST) on Dec 31st. Our selection committee will then review the proposals, select the primary and alternate presenters, and contact them in January of 2008.

We’re looking for all sorts of Ruby and RoR related talks (and talks that aren’t strictly Ruby related but which would be of interest to rubyists). Talks will be 45 minutes in length, and should allow some time for audience questions. If you’d prefer something shorter, we’re hoping to run a lightning talk sessions on Friday and Saturday, with 8-10 five minute presentations each session—proposals are not required for lightning talks.

Proposals should be submitted to me

Last year, we received a number of high quality proposals for talks at the 2007 MountainWest RubyConf. These talks made our regional conference a huge success. This year, we’re hoping to do even better but we’re going to need your help—please, propose a talk and plan on coming to enjoy this regional conference.

Tuesday, October 16, 2007

SICP 1.1.6 (Ruby) A look back at a look back

I didn't think to try the abs benchmarks in rubinius when I wrote up my first looking back post. A bit later, I decided to give it a whirl, and the script worked (minus a bug in the real time column). Here are the rubinius results:

$ shotgun/rubinius benchmarking_abs.rb
                     user     system      total        real
ternary:            0.985418   0.000000   0.985418 (       nan)
explicit:           1.039927   0.000000   1.039927 (       nan)
implied:            0.824196   0.000000   0.824196 (       nan)
system:             0.821973   0.000000   0.821973 (       nan)

Not quite as good as Ruby, but comparable or better than JRuby (interpreted and no special switched). I'm intrigued that the implied version looks better than the ternary or explicit (and in line with the system) though.

SICP 1.1.6 (Ruby) A look back

In my post on SICP 1.1.6, there were a couple of questions raised about my Ruby code.

Fabio Akita Your first example would be better written off as:

def abs(num)
num < 0 ? -num : num

Personally, I really hate the ternary if, I’ve always thought that it makes code harder to read. It’s probably still worth looking at though, since my biases are just that.

Peter Cooper ... I was just intrigued as to why you wouldn’t use idiomatic Ruby, when SICP tends to use Scheme very idiomatically.

This is another one of my failings, I’ve been doing enough non-Ruby stuff lately that I wasn’t thinking in it. Couple that with sitting down to ‘translate’ the code in separation from reading the text, and I was set to really mess up. Hopefully I can correct this going forward.

In any case, it’s worth looking at how well the various versions of abs perform in Ruby, so here’s a simple benchmarking script to try

def tern_abs (a)
  a < 0 ? -a : a

def explicit_abs (a)
  if a < 0
    a = -a

def implied_abs (a)
  if a < 0

require 'benchmark'

n = 1_000_000

Benchmark.bm(15) do |x|
  x.report("ternary:")  { n.times do ;tern_abs(-5);tern_abs(5); end }
  x.report("explicit:") { n.times do ;explicit_abs(-5);explicit_abs(5); end }
  x.report("implied:")  { n.times do ;implied_abs(-5);implied_abs(5); end }
  x.report("system:")   { n.times do ;-5.abs;5.abs; end }

And here are the results of running it:

ruby benchmarking_abs.rb 
                     user     system      total        real
ternary:         0.550000   0.000000   0.550000 (  0.558707)
explicit:        0.330000   0.000000   0.330000 (  0.324859)
implied:         0.320000   0.000000   0.320000 (  0.322541)
system:          0.240000   0.000000   0.240000 (  0.241916)

It turns out that (at least in this case) the ternary form is the least performant. It’s probably no surprise that the built in version is the fastest. From now on, I’ll stick to using the built in abs.

Just for grins, here’s the result of the benchmark when I run it on JRuby:

$ jruby -v
ruby 1.8.5 (2007-08-23 rev 4201) [i386-jruby1.0.1]
$ jruby benchmarking_abs.rb
                    user     system      total        real
ternary:         1.768000   0.000000   1.768000 (  1.767000)
explicit:        1.734000   0.000000   1.734000 (  1.734000)
implied:         1.729000   0.000000   1.729000 (  1.730000)
system:          0.716000   0.000000   0.716000 (  0.716000)

It looks like the system is an even better deal compared to the ‘roll your own’ versions, though there appears to be less of a difference between them. (Any JRubyists out there care to venture a guess as to why that might be?)

SICP 1.1.7 (Factor)

I’m going back to the idea of treating each langauge in a separate post. Hopefully this will make the comments a bit more manageable (especially since I cross posted the last one onto my erlang blog as well).


There were several factor related comments on the last post that I wanted to address before I moved on to section 1.1.7.

Anonymous Is Factor “done”? Seems like it’s still very much a work in progress.

Can you comment on your choice of Factor and what has made it enjoyable for you?

Anonymous is right, Factor isn’t done yet. It is getting close though, and for what I’m doing, it seems to be “done enough”. I’m using it because I’ve been thinking about learning a stack based language for a while, just to learn to think a little bit differently. So far, it’s fun because it’s doing just that.

And the related:

Ed Borasky Factor? What does Factor have that Forth doesn’t have? At least Forth has an ANS standard and some vendors and a few thousand person-decades of programmer experience.

Ed, I think the big thing that drew me to Factor over Forth was an active Factor community that I sort of tripped over. Sometimes, it’s the squeaky wheel that draws a user.

The last two weren’t specifically related to Factor, but did show better ways of solving exercise 1.3 (without resorting to lists), so I worked up a factor solution in their vein:

: min ( a b -- a b ) 2dup <
  [ swap ] when ;
: top-two ( a b c -- d e ) min rot min -rot ;
: sum-of-squares ( a b -- c ) sq swap sq + ;
: sum-squares-of-larger ( x,y,z -- x ) top-two sum-of-squares ;

I agree that this is a much better way of solving the problem.

SICP 1.1.7

Okay, on to some code. I’m going to use the built-in sq and abs words from now on. There’s no sense in continuing to use mine when there’s a perfectly good version of the word already there. SICP built a series of procedures to find square roots using Newton’s method: sqrt, sqrt-iter, improve, average, and good-enough?. I rewrote these into the following Factor:

: average ( a b  -- c ) + 2 /f ;
: improve-guess ( num guess -- guess ) dup swapd /f average ;
: good-enough? ( num guess -- ? ) sq - abs 0.001 < ;
: sqrt-iter ( num guess -- guess ) 
  2dup good-enough? 
  [ ]
  [ swap dup swapd swap improve-guess sqrt-iter ] if ;
: sqrt ( num -- root ) 1.0 sqrt-iter ;

These are nice and fairly concise, but sqrt-iter seems pretty ugly. I checked back in with the good folks on #concatenative (who have been immensely helpful) and they agreed, saying “swap dup swapd swap is a code smell”. They pointed out the dupd word, which does the same thing. so a better version of sqrt-iter would be:

: sqrt-iter ( num guess -- guess )
   2dup good-enough? 
   [ ]
   [ dupd improve-guess sqrt-iter ] if ;

Which can be improved still further into:

: sqrt-iter ( num guess -- guess )
   2dup good-enough? 
   [ dupd improve-guess sqrt-iter ] unless ;

I’m sure there are ways this could be improved yet further. Leave me a comment with your ideas. I’ll try to post my Ruby version tomorrow and Erlang on Thursday.

Tuesday, October 09, 2007

Author Interview: Assaf Arkin and Jeremy McAnally

With the publication of the first four chapters of their new book, “Ruby In Practice”, through the Manning Early Access Program (MEAP). Assaf Arkin and Jeremy McAnally have been kind enough to answer some questions about the book, Ruby, and themselves. You’re welcome to join our discussion here, or you can buy the book and join the Manning Forum for Ruby in Practice and discuss the book there. As the more of the book is published through MEAP, Assaf, Jeremy, and I will take some more opportunities to talk, so if you have questions you’d like to ask, please let me know.

Hey guys, I just got the first MEAP release of your book and I’m loving it so far. Thanks for taking some time to chat with me about it. Let’s dive right in to some questions:

1) It’s obvious that you guys are taking a different approach to writing about Ruby than most people (no Ruby Tutorial, no ‘How do I install a gem’ section, etc.). Why did you choose to go this route?

Assaf There are books that teach you Ruby, I personally recommend the Pickaxe, I don’t think we need another one. For a lot of people, I happen to be one of them, the first obstacle is not learning the language itself, but learning to use the language to solve specific problems. It’s easier to learn Ruby and be productive when you’re seeing examples for real life problems, like generating a report, or parsing an XML document, or using a Web service, so that’s the approach we took with Ruby In Practice.

Jeremy It was really at RailsConf that I think we decided to pull a lot of the introductory stuff we had in there. We had a lot of “learning Rails” type stuff with some introductory Ruby coddling, but I was really struck at RailsConf how many Ruby books I saw at the book store at the conference and later at the mall. I usually keep pretty on top of the book market, and there were 3-4 that I’d never heard of. The market was finally robust, and so I saw no need to duplicate effort.

Even further, the original vision of this book was “I know Ruby, but now what?” We wanted to fill that gap. We also wanted to partially try to answer “Who cares?” also, but to a less extent. In a nutshell, we wanted to write a book that people could use right after they read Ruby For Rails or the Pickaxe or Learning Ruby or my book. I know a good number of programming languages fairly well, but I see no business sense in them. We want to instill that knowledge in our readers: “Yes, Ruby can be used for your problem, and here’s how.”

2) No book can cover everything. What are some Ruby things you wanted to talk about but just couldn’t fit into the book?

Jeremy We originally covered a lot more of the “why” for Ruby, but after reviews and actually reading what we wrote (haha! novel!) we decided that it didn’t fit. This is a manual designed mostly for developers, architects, or hybrids thereof, so we wanted to make sure that’s who we focused on.

I, personally, would also like to spend more time on the Ruby language, but this is a “practical” manual rather than a “language” manual so it didn’t really fit.

Assaf You can write an entire book on XML processing with Ruby, or Web services, or Ruports and PDF::Writer. The hard part is picking a handful of examples to show basic usage and more advance techniques, and fitting that into a single chapter. Besides covering all the different ways you can use a given library, there’s also a few things we won’t be able to fit into the book, but can’t list those until we’re done with the book.

3) In your first chapter you run through some of the Ruby idioms and features that really make the language shine. Where would you recommend readers go who feel that they need more information on these topics?

Assaf Have a look at other people’s code. When I started with Ruby, a lot of the concepts like writing a DSL or using method_missing were abstract. It was interesting to learn, but it only became practical when I looked at other people’s code and learned by example how, when and why to use them. And thankfully, Ruby has a lot of open source code you can look at, and your options range from Rails (a lot of good ideas in the code) to blogs that deal with one specific use case at a time.

Jeremy The Ruby Way and Ruby For Rails. Hal’s book is a given, but David’s chapter on the dynamic features of Ruby is top notch in my opinion. I still feel like there’s a gap in “advanced” Ruby knowledge to fill, and I hope to be involved in a project that fills it in the future (but we’ll see).

4) In Chapter 2, you guys provide the first coverage of RSpec and Heckle that I remember seeing in a Ruby book. Why did you choose to cover them alongside test::unit?

Assaf Testing is about specifying how the code should work, and then making sure it behaves that way. Rinse, repeat. You want to express tests in the most natural way, and RSpec does just that. But RSpec comes from the ability to have open classes and extend objects which works for Ruby; in languages like Java and C++ you don’t have that capability, so the best you can do is write assert statements. Assert statements are not the way to write tests, they’re just a compromise made by the limits of the language. Still a lot of people move between Ruby and other languages and already know the xUnit way of testing, so it makes sense to teach both at the same time.

Jeremy More and more I’m finding that people know Ruby, but don’t test. The paradigm doesn’t make sense to them: why am I asserting things about code that doesn’t exist yet? The BDD paradigm makes more sense: you’re defining behavior, discussing things that “should” happen, and so on. So, I think for those coming to the book with knowledge of Ruby but aren’t testing yet, covering RSpec might be a breath of fresh air.

As for Heckle, I’m finding that even in my own code, my tests are weak. Since I’ve been heckling, I start thinking a lot more carefully when testing. We included the section on heckle primarily because it’s such a darned useful tool for rooting out bad tests!

Assaf Heckle is testing our tests :-)

5) I also enjoyed Chapter 3’s discussion of integration. It seemed to have a lot less code than I would have expected, but I think it covered integration better because of that. What prompted you to write the chapter the way that you did? Will we see more of this kind of writing in future chapters?

Jeremy One reason was that a lot of these systems have a lot of code running in them (most of it code that can’t be released publicly…), but also we wanted to setup the rest of the book. The main thrust of the chapter is that you take ideas from it and then apply it to the technologies we teach you in the book. We give you some strategies you can enact combined with the practical content later on to solve some pretty big problems.

I think when/if we write an appendix on tighter integration with things like JRuby and IronRuby, you’ll see more code. If we don’t get to that, then it’ll be on the blog probably. :)

6) Chapter 4 continues to take a different perspective on things with it’s coverage of Rails. I really would have liked to see some coverage of Merb as an alternative to Rails … Any chance something like that might show up the book’s blog? What kinds of things do you plan on writing on the blog?

Jeremy We have a lot of stuff we cut out of the book that will likely end up on the blog. The “why” material discussed earlier, some unused Rails stuff, and, yes, some alternative web framework coverage (I believe we have a Camping section written and part of a Merb one that is rather out of date). Once the book it totally finished, we’ll start releasing that stuff. :)

Assaf Think 80/20. We can’t possibly cover everything in a single book, so some things are unfortunately left out, but hopefully we’ll give people enough taste of Ruby that they’ll go out and experiment with more Ruby libraries, beyond those we could cover.

7) Anything else that you guys would like to say to prospective readers?

Jeremy Enjoy. Enjoy life, enjoy Ruby, enjoy the book, and please enjoy giving us some feedback on the author forum so this book rocks that much harder when it comes out.

Oh, and write tests, Haskell, YAGNI, Agile, SCRUM, spec, Rails, Web 2.0. I just wanted to make sure that this answer at least had something to do with software development.

Assaf Write a lot of tests, have a look at RSpec and RBehave, they make test writing fun which is the most important feature in a testing framework. Learn not just the language, but the whole philosophy behind Ruby; you’ll get much more from keeping your code simple and DRY, avoiding premature abstractions and YAGNI, than any programming technique or feature. Don’t be afraid to scale out, and don’t be afraid to use the command line and mix languages.

Monday, October 08, 2007

Reading SICP 1.1.6

This time around, I’ve decided to toss the translations for Ruby, Factor, and Erlang into the same post instead of trying to juggle multiple posts and point them all at one another. So, without further ado …

Section 1.1.6

Let’s take a look at section 1.1.6, the goal of this section is to look at conditional expressions through implementing an absolute value procedure. the book iterates through a couple of versions, trimming away fat. In each of my examples below, I’ve only shown the final product.

In Ruby, the code should look something like this:

def abs(num)   
  if num < 0
    num = -num
  return num

In Factor it looks like this:

: abs ( n -- n ) dup 0 < [ -1 * ] [ ] if ;

And in Erlang it looks like this (I’ve left out the administrative bits from the top of the file):

abs(A) ->
    case ( A < 0) of
    true -> -1 * A;
    false -> A

Exercise 1.3

Esercise 1.3 asks the reader to write a procedure that takes three numbers and returns the sum of the squares of the largest two of them. In each case below, I rely on the previously defined square and sum-of-squares (sum_of_squares) procedures.

Ruby was pretty easy:

def sum_squares_of_larger(a, b, c)
  sorted_nums = [a, b, c].sort.reverse
  sum_of_squares(sorted_nums[0], sorted_nums[1])

Factor took me a while to figure out (mostly in trying to figure out how to build the array):

: top-two ( x,y,z -- x,y ) 3array natural-sort reverse first2 ;
: sum-squares-of-larger ( x,y,z -- x ) top-two sum-of-squares ;

I’m least sure of my Erlang code. I couldn’t find a good function for sorting the array, so I borrowed the qsort function from Programming Erlang. In any case, here’s my cut at it:

qsort([]) ->
qsort([Pivot|T]) ->
    qsort([X || X <- T, X < Pivot])
    ++ [Pivot] ++
    qsort([X || X <- T, X >= Pivot]).

last_two([H|T]) -> 

sum_of_squares_of_list(L) ->
    lists:sum([square(A) || A <- L]). 

sum_squares_of_larger(A, B, C) ->

What I learned

The biggest thing I’ve taken away from this exercise so far is that I really need a good Factor book that covers both the language and the vocabulary. Along similar lines, Programming Erlang is a good book, but it could have spent some more time on basic programming (especially covering the provided functions in something other than an appendix).

Factor has been the language that’s been hardest to wrap my mind around so far. At the same time, it’s the one that I’ve enjoyed the most—I also think the word definitions have a sort of terse beauty. I think Ruby is probably the one that most programmers could just pick up and maintain though.

Next up, Section 1.1.7 “Square Roots By Newton’s Method”.

Friday, October 05, 2007

Author Interview: Ola Bini

With Ola Bini’s JRuby book out, I thought that I should take some time to talk to him about it. Read on to see what Ola has to say about JRuby, JRuby books, and other languages.

You’ve written the first JRuby book. Obviously, it couldn’t cover everything, so what JRuby books are you hoping to see come out over the next year or so?

Ola Well, there are two different books that are needed. The first one would be a general JRuby book that covered most of the things people want to do with JRuby. Since my book was specifically focused on Rails, it doesn’t cover the full spectrum of interesting JRuby applications. So, a general guide – more or less an equivalent to Groovy in Action would be needed. (I know that at least one such book is in the works) Secondly, a JRuby cookbook would be very nice – showing people how to accomplish common and uncommon tasks with JRuby. Maybe a JRuby Recipes or the JRuby Way? =)

Books and language penetration are kind of a chicken and egg thing. What’s your impression of JRuby’s ‘real world’ use?

Ola This is a very hard question to answer. The interest in JRuby have picked up immensely the last few months though—after the 1.0 release more and more people have been streaming in to the community. Also, we’re seeing more companies that are working on applications using JRuby (both within ThoughtWorks and at other places).

How do you think your book will help?


I think it will make a fair improvement. As soon as a book on a subject comes out, the subject usually gains more penetration—so I’m positive.

Your book is mostly focused on Java users who will be picking up JRuby. How will it work for Rubyists going the other direction?

Ola Rubyists will be able to get going much quicker - since JRuby on Rails is Ruby on Rails this means that the initial hurdle is very small if you know Ruby and Rails. But there are still lots of things to learn for the Rubyist - including lots of things that are JRuby specific. Also, seeing the things you can accomplish by combining Ruby and Java will hopefully open the eyes of many Rubyists to exciting possibilities.

What do you wish you could have covered (or covered better) in your book?

Ola That’s a good question. I’m pretty happy about the current scope, but if I could have put some more information in about deployment that would have been good. There is popping up new ways of doing it all the time with JRuby, and the subject needs coverage. That said, I cover it fairly well, but there are always more things to say about a subject like that.

What Rubyisms are going to make the biggest positive difference in the Java world because of JRuby?

Ola Just getting the message out there about a more functional approach, making good use of internal iterators and closures would make much Java code better too. Also, just seeing that there are valid alternatives to the XML centric Java way of doing things is very important.

What Javaisms are going to make the biggest positive difference in the Ruby world because of JRuby?

Ola Depends on what you mean by Javaisms. I don’t think the Java language has much to teach Ruby. On the other hand, Ruby will benefit immensely from the rock solid virtual machine, many of the management features of Java, and lots and lots of different things that the Java ecosystem does correctly.

Outside of Java and (J)Ruby what three languages do you think programmers should learn to round out their programming knowledge?

Ola Three languages that rounds out your knowledge is kinda interesting. It doesn’t matter that much which languages you choose—the important thing is that they embody totally different paradigms. I would recommend learning Common Lisp (for the LISP way of doing things, functional programming, macros, and a totally different Object System (CLOS)). Prolog also deserves mention as a good language to learn. The declarative style of programming twists your mind totally differently than functional or imperative programming, and the declarative style is also seeing a resurgence in domain specific languages. The third language should be OCaML – to see what real static typing is about. Also gives insight into other domains of functional programming, some pattern matching and other nice features.

Thursday, October 04, 2007

Reading SICP in Factor: Section 1.1.4

Here’s my cut at SICP 1.1.4 in Factor. I’m a lot less sure of this than I am of the Ruby translation since I’m learning Factor as I go along. I’d appreciate comments from the Factor community as I go along, especially about Factor idioms.

In my Ruby translation, I failed to talk about some things, like procedures in SICP being methods in Ruby, and changing the method names to match the snake_case style favored by Rubyists. In the factor translation, procedures would be referred to as words, but I’ll be keeping the lispy-lowercase-divided-by-hyphens look.

There’s already a sq word in Factor, and I based my definition on that one.

> : square dup * ;
> 5 square .

The first line defines the word square and the second line tests it by excution. Lets see if I can explain the second line:

word or literal stack explanation
5 5 puts 5 on the stack
square 5 (I’ll explain this below)
dup 5 5 duplicates the top value on the stack
* 25 multiplies the top two values on the stack and replaces them with the result
. {} returns and removes prettyprints (and consumes) the top value on the stack

To create1 and execute the sum-of-squares word we can do the following:

> : sum-of-squares ( a b -- c ) square swap square + ;
> 3 4 sum-of-squares .

Again, my attempt at explaining the second line:

word or literal stack explanation
3 3 put 3 on the stack
4 3 4 puts 4 on the stack
sum-of-squares 3 4 (explained below)
square 3 16 squares the top value on the stack
swap 16 3 swaps the top two values on the stack
sqare 16 9 squares the top value on the stack
+ 25 adds the top two values on the stack and replaces them with the result
. {} returns and removes prettyprints (and consumes) the top value of the stack

(By the way, big thanks to Wilson Bilkovich for his editorial work on this post … he improved it immensely.)

1 In trying to create sum-of-squares, I ran into an initial problem understanding word definition. Thanks to gnomon in #concatenative for his help in straightening me out. Further updates are a result of the kind folks on #concatenative reading this and correcting me.

Wednesday, October 03, 2007

Reading SICP in Ruby: 1.1.4

Recently, I posted about reading and working through SICP in languages other than scheme. Today is the day that I start. I don’t know how quickly I’ll work through things, but we’ll see what I can do. In addition to Ruby, I’m also hoping to work with Factor and Erlang in parallel.

My first SICP post is nice and easy, I’m skipping up to Section 1.1.4 of SICP which covers compound procedures (procedures made up of other procedures). This is really the heart of concatenative programming (like forth and factor) and of the style of short method OO espoused be Martin Fowler in Refactoring.

Sussman starts out by defining a procedure to square a number, then another that uses the new square procedure to create a sum-of-squares procdure. In Ruby, this would look something like this:

def square(num)
  num * num
def sum_of_squares(num1, num2)
  square(num1) + square(num2)

If I type these definitions into irb and then try running them, I get the following:

 => 25
 => 25.0
 => 25.0
Just what you’d expect.

Next up, section 1.1.6 (Conditional Expressions and Predicates)