On a current project we recently switched from Ferret to using Solr as our search engine. That switch was more than necessary, but that's material for a different blog post. Let's just say, the switch was more than worth it, and Solr just rocks our socks off.

The decent choice to turn to was of course acts_as_solr. Unfortunately I soon realized that there was no real active development, except for a couple of forks on the GitHubs. Luke Francl's was the most recent one at that time, so I forked it and started adding my own extensions and wrote a new unit test suite from scratch using Shoulda.

The project seemed to be missing an active maintainer, since Thiago stepped down a few months ago. Talking to Luke and the mailing list, a new plan was made, and without further ado I give you a fresh acts_as_solr mainline. I had weird feelings about picking up development, but I didn't want to let the plugin go to waste in the midst of a million forks. Of course Luke has commit rights to the repository as well.

Since the RubyForge project page is not up-to-date, I'll try to evolve most of the information and documentation on the project around the wiki. An rdoc documentation site will follow.

Drop by the mailing list, there'll surely be someone to answer your questions. I'm open to patches, so if you have something to contribute, feel free to drop me a patch or a pull request.

Tags: rails

It's true, I did write my diploma thesis using Vim. Old-school with LaTeX and C++. When I came to the Mac five years ago I was still using the now pretty much dead Carbon version of MacVim. And well, it just didn't feel right. I'm very comfortable on the command line, but on the Mac I wanted something that integrated well with the rest of that system, that behave like a real Mac application.

Of course, like a lot of people, I found TextMate. Who could resist the cool stuff as seen on the first Rails screencasts? I sure couldn't. I've been using it a good three and a half years now, and I still like it.

But recently the new Cocoa version of MacVim scratched my itch. It was Jamis Buck's blog entry that eventually pushed me over the edge, and had me trying out working with Vim for the last week or so. And holy crap, a lot has happened in the world of Vim since I left it for good. Omni completion, a really good Rails script package, and lots of other cool stuff.

So I gave it a go, and it was like Jamis said, it kinda felt like coming back home. I spent most of my university days with Vim, actually the first years using the old-school Solaris vi. So it basically felt like I never left.

I got pretty fluent with it pretty quickly, and started looking for a nice set of scripts that would fit my workflow. I found

It all felt pretty good in the beginning, especially rails.vim is an amazing package. But after using it for a week it made me realize one thing: That I haven't dived into the Rails bundles deep enough. There's a lot of things in rails.vim that the TextMate bundle also has. What is seriously cool in Vim is the completion, but I just don't use it that much, and it can be frickin slow if you're on a big project.

And that's mainly my main gripe, it all didn't feel very speedy. It took one to two seconds for a normal file to load, what with all the BufRead action going on for Ruby and Rails project files. I didn't mind it that much in the beginning, but it got really annoying. Plus, a lot of the plugins, like NERD tree, or taglist felt kinda bolted on.

So here I am working in TextMate, still loving Vim for it's flexibility and simple effectiveness, promising myself to delve deeper into what the bundles offer. It was a great week, and I'm glad that Vim gets the love it deserves.

One issue that drove me back to Vim was the fact that there's no news on what's happening in TextMate development, and what will be in 2.0. What the week in Vim made me realize were that TextMate could use stuff like split-screen editing, the ability to handle bigger files without hogging memory and CPU, and maybe some real good SCM integration.

My biggest gripe though was that file types didn't stick, switching from Rails to RSpec and Shoulda and back just seemed to confuse TextMate. I was made aware that there actually is a "fix" for that problem, but that just isn't a full solution. It helps right now, but I can only hope that TextMate 2 integrates something like TabMate, just maybe not with modlines but with metadata.

There's a lot of complaining, especially from people coming to Ruby from the Java world, about the lack of a language specification. And while a lot of effort is put into the RubySpec project to at least have a test-driven specification, the written word has been silently ignored for a long time. At least in terms of information technology.

There used to be a book called "Ruby in a Nutshell", written by Matz himself, but it mainly dealt with Ruby 1.6, and is therefore seriously outdated.

David Flanagan (author of several great books on JavaScript and Java) set out to fix that problem. With the help of Matz he dove deep into Ruby and wrote what I can only describe as its only valid written language specification. The result is "The Ruby Programming Language".

The book doesn't take any unusual path when it comes to its structure. It deals with the basic structure of a Ruby program, datatypes and objects, expressions, operators, control flow, methods, procs, lambdas, classes, modules and finally, reflection and metaprogramming.

Whatever you consider part of the Ruby language, you'll be sure to find it in one of those chapters. David manages to get the whole of the language into a mere 300 pages. Both a testament to the compactness of Ruby and David's skill to explain each part as simple as possible.

You'd expect something like a language specification to be boring (if you don't, you obviously haven't read the Java Language Specification or The C++ Programming Language), but I'm happy to report that is not the case. While you shouldn't expect an entertaining read, you can expect to learn all the little details you somehow have not yet grokked about Ruby. The book finally opened my eyes on the difference of proc and lambda. The book ends with a discussion of the core classes of Ruby, including API changes between 1.8 and 1.9.

It is up-to-date with Ruby 1.8, and includes most of the features of Ruby 1.9 including of course, fibers.

My verdict is simple: If you work with Ruby, buy this book. It's pretty much the most complete book on Ruby you'll find. While "The Ruby Way" is an excellent reference "The Ruby Programming Language" is meant as a guide through the language. You can read it once, and get back to it when you need to. And seriously: You should read it. There's very likely some parts of Ruby you haven't worked with in all detail yet. This book does a good job in helping you uncover them.

Disclaimer: O'Reilly provided me with a copy of the book for reviewing purposes. My excitement about it is real.

Tags: books, ruby