Quick rubinius Post

It's stuff like this that keeps reminding me that I should run a tumbleblog. Evan Phoenix has just posted a rubinius style guide ... if you want to hack on rubinius like the rest of the cool kids, you should go read it.

Win a Book and Help rubinius

Want to help the rubinius team? Want another chance to win a book? Well then, this just might be the post for you!.

Every good open source project relies on good names and other cool stuff to keep it running, and rubinius is no exception. We've been trying to come up with a good name for our C API layer for a while now, but we're still stuck with 'RNI' and that's just not good enough.

Now, we're turning to you, intrepid reader — and we're offering a reward. Here's the deal, I'll take submissions for a better name for the C API until midnight (MST) on February 18th (Chinese New Year) then Evan will pick the best name from the batch. All you need to do to submit a book is to enter it in a comment below, you can submit as many names as you like (you're welcome to submit multiple names per comment). The person who's entry is chosen will win their choice of one of these three books:

• Code Craft
• Code Quality
• Code Reading

The (not so) Fine Print:

• In the event multiple people submit the same name, the first person to have submitted it will be considered the winner.
• I'm relying on Amazon's free super saver shipping to get the books to you — if it can't ship to where you live, I'm sorry.
• Pleas avoid names with previous committments, we really don't want to have to go through the hassle of renaming something after Microsoft sends us a Cease &l Desist letter.

Blogging Contest: February Challenge

Update: It's time to get going on the March contest.

---

Well, as we close up the January contest, it's time to get a new one started. Same rules, you enter by writing a blog post responding to the question below, and linking to it in the comments section. At the end of the February, Peter Cooper (the author of Beginning Ruby: From Novice to Professional, head of Ruby Inside, and this month's guest judge), Jason Gilmore (the Apress Editor), and I will take a week to pick our favorite and announce it. The winner will win three Apress books of their choice.

With that in mind, let's move right on to this month's question:

Last month Jarkko Laine asked "How has Ruby on Rails made you a better programmer?" This month I want to ask, "How has Ruby blown or stretched your mind?" Initially you might think the same answer applies as to Jarkko's question, but what I am specifically referring to are the things in Ruby that have made your brain race and go "wow!", even if you've never bothered to go on to use that feature much (if at all!)
Most Ruby programmers have come to the language from another. I came from Perl, which had already blown my mind with its development style, having previously come from the monolithic, strict worlds of Pascal and C. At each language transition, I have initially resisted and refused to look at the new programming language with an open mind, instead comparing it to my current language. Transitions are hard, especially when you're invested many years in your current techniques, but even though it can take a real effort to start on something new, especially a programming language, I've found that once those "Wow!" moments start coming along, you rapidly become a convert.
What were your "Wow!" moments with Ruby? Do you still get them? Are you just intellectually impressed when they come along, or do you actually become truly excited (keep it clean please)? What were the moments and the things that you saw that made you want to give your first-born to Matz and live in Ruby land happily ever after?
To kick things off, I will shortly be blogging my own answer to this question (although I won't be eligible for the contest, naturally!) but I look forward to getting to see what it is that's made you excited about Ruby, especially if I get to experience some new "Wow!" moments I haven't had before!

And while you head off to write you masterpiece, I'll be off reading through a stack of great entries from last week's contest.

Cardinal: A Behind the Curtains Look at Parrot

This week (and next), I'm taking some time away from the rubinius serial interview to let those guys get back to work. To keep everyone on their toes, I've got a couple of other bits lined up. This week, I asked Dan Sugalski, the original architect of Parrot, about a design decision that he made. Parrot might seem a bit far afield for a Ruby blog but there is the Cardinal project which is trying to build a Ruby front-end for it, so I don't think we're too far off the path.

Next week? You'll have to come back then and see.

---

In recent discussions in the Ruby world, the Parrot VM has taken some heat because of its register based design. I know you guys went through the trade-offs, but those discussions are lost in the mists of time. Could you fill everyone in?

Dan: There were a couple of reasons.

Firstly, I just like 'em. Yeah, I know, "taste" is a dodgy reason to do things, but when you're designing stuff like this, you need to do stuff that you're kinda fond of, and I was always comfortable working with register machines. Wrote more assembly than I care to think about for 6502 and 68000 family microprocessors. I liked them, was comfortable writing code for them by hand, so it was a good reason to design a register machine.

Second, there is a lot of literature out there for writing optimizers for register machines. All modern CPUs are register machines, and a lot of people have spent a lot of time figuring out how best to generate code for them. I knew that Parrot wouldn't be able to use it right away, but I was trying to plan for things in 2005, 2010, and 2020 when I started. (This was back in 2000)

Thirdly, register machines are generally more efficient than stack machines. Yeah you might see the bytecode look a little denser (which is certainly important) but there's an amazing amount of bookkeeping with a stack machine. There's an extra store for every opcode, which adds up. For example, storing 1 in register X is:

machine reg = regbase + x
store indirect 1

while a stack machine is:

machine reg = stackbase + 1
store indirect 1
store stackbase

Also on the efficiency front, stack operations are destructive, so something like:

x = x + 1
y = y + 1

requires putting that 1 on the stack twice — on a register machine you can reuse it, saving a full op. (This requires some intelligence on the part of the compiler, but it's actually a pretty simple optimization and easy for anyone past first year compiler construction to do.)

Fourthly, for JITting, we know we're targeting a register architecture — the CPU we're running on, which has registers. It's easy enough to do a naive stack VM -> native machine translation, but it's a stack transform, treating your register hardware as a stack machine, and that's inefficient. Doing a good JIT from a stack to register system is much tougher.

A register VM -> register machine translation is a lot easier. You can, of course, grab a register and use it as your 'vm register' base pointer, which is as naive as the stack transform above, but it's much simpler to get relatively efficient register machine code out of a register VM system, assuming some thought went into desinging the register VM. (Which it did.)

(The usual argument that "well, compilers build up a sort of stack-based intermediate representation before generating code" is interesting but bogus, since almost all the useful information in that intermediate representation is tossed away when the low-level stack ops are created.)

So that's basically it. One part taste, one part lots of free work to bootstrap on, and two parts efficiency.

Ruby Hacker Interview: Jens Kraemer

I recently completed an interview with Jens Kraemer, a german Ruby Hacker, and the author of several Ruby and Ruby on Rails tools. Read on to learn more about Jens and what he's doing.

---

To begin with, would you please introduce yourself to the readers?

Jens: I'm 28 years old and live in Dresden, Germany.

I work as a software developer at webit!, a mid-sized IT-consulting and software development company specializing on web-based applications. I also keep a blog.

I started studies in economics and engineering at the Technical University of Dresden in 1997. Though I always was fascinated by computers and especially by letting them do what I wanted, I choose not to study computer sciences because it seemed far too theoretical to me. Later in my studies I selected computer science courses wherever possible (picking the interesting topics, and leaving out the theoretical ones, of course ;-).

I started earning money with software development in 2000 when I joined webit! for what I thought would be a summer job developing an e-commerce portal. The project died the .com death, but I kept working at webit! while trying to finish my studies by the way. So it took some time, but in 2004 I finally finished my diploma thesis. I stayed at webit! without looking around too much for alternative jobs, just because it's a really great place to work, without too many rules and with lots of cool people around.

How did you discover Ruby?

Jens: I don't know for sure, but I think the first time I heard about Ruby was in a conversation with Steffen Gemkow, an IT consultant from Dresden. Must have been 2002 or 2003, I think.

I then had a look at it, but at first underestimated it's power. I liked it more than Perl because of the cleaner syntax, and so I used Ruby for what I would have done with Perl otherwise - small scripting and screen scraping tasks, and some data import/export/conversion jobs.

I was a Java guy at this time and I didn't think too much about using Ruby (or any other scripting language) for 'serious' web apps.

Later I discovered an early version of Rails while looking for some ORM layer to simplify a database migration job I planned to do with Ruby.

I found quite interesting what I saw, tried it out in a small side project, and fell in love with it right away. I think the real secret to Rails' success is the Ruby language, at least that's why I prefer it to all the other newish Rails-like web frameworks written in other languages.

Are you using Ruby professionally?

Jens: Yes, we already did several Rails projects at webit!, some for customers, some for internal use. Right now I'm working on an ecommerce solution implemented in Rails for a publishing company here in Saxony. It allows customers to subscribe to online and printed versions of several official publications concerning saxon law and administration. Ferret-powered full text search is available to registered users, too. The site is located at www.sachsen-gesetze.de.

As time permits, I also do some Ruby/Rails freelance work.

What other languages are you using?

Jens: Recently I was involved in C# and Perl projects. Before that I've built J2EE web apps for several years.

What is the Ruby community like in Germany?

Jens: As far as I can tell - quite small ;-) But it seems to be growing. I really can't say much about this, there's not much activity Ruby-wise in or around Dresden. In other areas (Berlin, Hamburg, Frankfurt) there seems to be more movement, though. There's a quite low traffic german rails mailing list.

But Ruby seems to get momentum, recently a potential client explicitly asked for Ruby experience ;-)

What projects are you working on with Ruby?

Jens: Besides building web applications with Rails at webit!, I currently maintain two Ruby-related open source projects:

• RDig is a full text indexer for web sites and file systems written in Ruby
• acts_as_ferret is a Rails plugin for easy full text search across model data.

Both projects are built on top of David Balmain's great Ferret library.

In addition to that, I'm involved in the soon-to-go-live project led by Benjamin Krause, that David talked about in his interview ;-)

What can you say about this project?

Jens: OK, time for some planned leakage ;-)

The project is called Open Media Database or short, OMDB. As the name says, it's a database about media. Our goal is to provide objective, correct and structured information about media of any kind, be it books, movies or music. To reach this goal we combine full text information with structured, domain specific data. For now, the scope of the platform is limited to movies.

Basically all data will be open for editing by the public, just like Wikipedia. To ensure the correctness of the structured data, it is possible for a team of editors to freeze never-changing relationships like 'George Lucas has made Star Wars' to a non-editable state after they have been confirmed as correct.

All information will be published under a free license. we're currently looking into the CC and GNU license versions. Of course we plan to provide APIs for easy access to the database.

At the moment we're busy getting ready for a public beta. A team of film students and journalists is entering content into the site as we don't want to go live with an empty database.

You can have a look at our current development version here.

It's our testing server, so expect the occasional hiccup ;-). As we're mainly german natives, most of the content already entered is in german, too. But we plan to go live at least with english as an additional language. Most of the user interface already is translated.

We also have a blog.

Can you give some examples of how Ruby makes Rails better?

Jens: In general Ruby tends to not surprise it's user - most of the time even a novice developer can guess how to do something. That makes it very easy to get started with Rails for people coming from other languages.

From a more technical point of view, I think one of the important Ruby features that make Rails what it is is objects and classes being open to extension from the outside after their declaration. That enables the little goodies like '3.weeks.ago' as well as custom methods in Active Record relationships and plugins that build complex stuff such as versioning right into the framework.

Another example of using Ruby's power in Rails is when you create your own DSL for use in your integration test sessions - telling user stories with statements like 'joe.buys_a_book' makes testing really fun.

Another point is that in a standard Ruby installation, you have almost everything you need, in terms of functionality. So, any special needs aside, you have Ruby, Rails, and maybe the ruby-mysql bindungs, but that's it. You can start hacking away on your project and chances are you don't need any other libraries. Depends on the project, of course, but it makes installation and maintenance in general much easier if you have less external libraries to watch.

Compare that to Perl, where even object orientation is implemented in external modules. A project like Catalyst has to depend on so many external modules (not talking about the project itself being split into another huge set of modules), that it really can be a hard job to get everything installed in the right versions. Imho, you have to be a hard core Perl hacker to get a successful start with Catalyst. I don't want to say the way Perl does handle this is plain wrong, but it makes it harder to get up to speed with a new project, especially for people who are new to the framework and the language.

What problems have you seen with Rails?

Jens: Deployment could be really hard in the beginning (say before Mongrel was there). Zed Shaw is really doing a great job with Mongrel, and it became my preferred deployment platform right from the start.

Otherwise, I'm really happy with Rails :-)

Have you looked at JRuby at all for bridging the Ruby/RoR and Java worlds?

Jens: I did a short look at it, but at the time (I guess somewhere in between 2004 and 2005) it was still quite inactive and I decided to not try using it in production code. Maybe I would have taken a second look after JRuby got up to speed recently, but I didn't do any Java projects since then.

That said, a working .NET integration would be what I need now ;-) I've been watching the Gardens Point Ruby.NET Compiler project for a while now, but I think it will take at least a year until we can talk about using Ruby e.g. in an ASP.net web app.

I'm not an RDig user, can you tell me a bit more about it? Do you know how many people/projects are using it?

Jens: RDig mainly does three things:

• crawl for documents
• extract content from those documents
• index that content with Ferret

The crawling can take place in the file system, or on the web.

For content extraction there are pluggable content extractors for various formats (pdf using xpdf-utils, doc using the wv utility, and html - here you have the choice between a Rubyful Soup based extractor, and one based on the hpricot lib). The hpricot content extractor was the great news of the latest version of RDig, since it's way faster than Rubyful Soup.

In theory, the indexing backend could support other indexing libs, too, but I didn't feel the need to implement one yet.

There's also a CLI for querying the ferret index created by RDig, but that's more for testing purposes. You're supposed to write your own frontend for your index, think of the search in your intranet, or for a site search on a public web site. RDig however has some code to make accessing the index easy, there's no need to learn the Ferret API.

For the numbers, they're quite small. There have been 25/31 gem/tgz downloads of the last version in 2 months. However I have mails from several people successfully using it for tasks like intranet search. Some even send me patches - so I guess it's a useful tool for some people.

At webit! we use RDig for a client who has a web site that in large parts is built by a CMS that publishes static HTML pages. RDig crawls the site via HTTP every night and so rebuilds the index that is used for the site wide search (which is implemented in Rails).