Ever since I saw Charlie Savage’s blog post about ruby-prof 0.4.0, I’ve been thinking about how great it was to see faster and better profiling tools (how cool are cross-referenced call graphs?). Now that I’m writing up my talk for RubyConf*MI , I’ve been looking a little bit deeper. For those of you not planning on being in Michigan on August 26th (your loss), here are three blog entries I’ve put together about ruby-prof and profiling in general: Profile and ruby-prof, ruby-prof and call graphs, and Profile and ruby-prof: getting specific.

I’m constantly amazed at how many tools are floating around out there for Ruby developers. What are your favorites?

First, there were the threads about rewriting Ruby apps in C, then I wrote a pair of follow up posts (here and here). These got picked up by an article over on InfoQ, which also pointed to How to Create a Ruby Extension in 5 Minutes. Finally, zenspider picked that up, tried it out, and wrote about his take on RubyInline and extensions: Writing C Extensions, Improved.

The traditional way meant creating a 5 line mkmf generator, 7 lines of C, running through the two step build process to end up with a dynamic library that can be required by ruby programs. With RubyInline, it took 8 lines of Ruby and C that live inside the Ruby program itself — the best part is that their now user run configure and compile cycle. they just run the Ruby program, and RubyInline does the work.

To quote zenspider, “It doesn’t get simpler than this… and really, it shouldn’t ever be more difficult than this.” Go take a look at the blog posts listed above, then go download RubyInline and make your life a whole lot easier.

You may have used the Active Record “acts_as” extensions that ship with Rails, such as acts_as_list, or those added by third-party plugins, such as acts_as_attachment. In this post I’m going to cover how to use a new plugin for Rails by Andrew Bruno, called acts_as_treemap.

What is a Treemap?

A Treemap is a diagram that allows you to easily visualize hierarchical information, or trees. The first treemap was used to visualize the directory structure of a filesystem; to make it very easy to identify the disk-hogs (files taking up a disproportionate amount of disk space) on a system with very limited resources. A more recent example of a treemap is one that Tim O’Reilly has posted on O’Reilly’s Radar that shows recent trends in programming language book sales.

The following treemap show two dimensions of information: Square size represents sales volume, and color represents rate of growth.

In order to represend your data with a treemap, your data must be modeled as a tree. The tree data model is much like that of an XML document, where there’s a root or parent node, and zero or more child nodes. Each subsequent node may have it’s own children, and so on.

In SQL, this structure is simple to set up. You create a field that serves a the primary key (in Rails that’s always “id”), and another field that stores the parent id of each record (e.g. “parent_id”). Note that the root node will have a parent_id of “NULL.” There can be more fields, of course, but these are all that are required to structure records as a tree.

The following diagram shows the relationship between data in a table (A), a tree structure (B), and a treemap(c).

I’ve posted a full how-to for Andrew’s acts_as_treemap Rails plugin over at Tupleshop.com. Please feel free to experiment with it and report back about your experience. Please visit: Using acts_as_treemap with Rails

FOSCon was amazing! Picture 100 Ruby geeks and Ruby geek wannabes gathered in a fairly small industrial building that’s been converted into something I heard described as “a frat house for geeks”. There were five talks (Lucas Carlson, Topher Cyll, Ryan Davis>, Geoffrey Grossenbach, Jim Weirich, and Amy Hoy) and a great deal of side room discussions. As good as OSCon is, FOSCon is even better, albeit in an anarchic sort of way.

The pdx.rb started FOSCon last year out of a desire to particpate in OSCon without needing to pay the conference fees. They invited a bunch of OSCon speakers and a couple of other folks to come out and present to an underground audience. This year, O’Reilly invited them into the fold, and FOSCon became a track unto itself — an all Ruby all the time track that came with pizza, drinks, and attitude.

So, other than making you jealous why am I writing all of his? Simple. I want you to be able to enjoy the same kind of experience — and you won’t have to come to Portland to get it. How’s that you say? Again, simple. All you need to do is work with you local Ruby Brigade (and maybe others in the region if you’re lucky enough to have them) and plan a regional Ruby Conference (and here and here). Pick a Saturday, find a location, invite a speaker or two from somewhere else, and put out a call for papers in your area. It’ll be great. Trust me.

I’ve admired James Gray for quite a while now and finally sat down to interview him by email. Most of us know him from the weekly RubyQuiz and the Pragmatic Programmers ‘Best of RubyQuiz’ book, but he’s made a lot more contributions to the Ruby community than just those. James always seems to have an answer to questions on ruby-talk (even the simplest), and his blog is a great read if you want to learn more about Ruby. Read on to learn a bit more about James and his place in the Ruby world.

While I was interviewing Zed Shaw (you can read the interview here), he said a lot of good things about Luis Lavena, who’s been doing great work for Ruby on Win32 systems.

Since I don’t know much about Ruby on Windows (other than it often being seen as a second class citizen), and even less about Luis, I wanted to talk with him about what he’s doing and how it’s going to help Ruby. A short email exchange quickly grew into a great conversation that I wanted to share with you.

Zed Shaw is an up and coming programmer in the Ruby world. He’s the creator of the popular Mongrel webserver, and is building a reputation for fast, solid, secure code. In this interview, he discusses Mongrel, Ruby, and his path to better code.

How did you come to Ruby?

Zed I actually came to Ruby years back while developing the first version of a weird revision control tool I was playing with called FastCST. I tried Ruby out but didn’t quite see the point and so went back to using C. Then I read Curt Hibbs’ article and realized, “Hey, they do domain specific languages with that thing!” Right after that I started a Ruby version of FastCST and then became distracted with work and several other weird projects related to Ruby on Rails.

Ah, there’s the Rails link that most people expect when some says they use Ruby. How much of your work is in Ruby vs Ruby on Rails?

Zed I’d say the majority of my work with Mongrel is in Ruby in order to support Rails and the other frameworks that run with Mongrel, but I work with Rails at my day job.

Zed What I like about Ruby is how you can express statements succinctly but still clearly so that other people can read your code. It has warts but the speed that I code in Ruby is incredible. The language is just amazing for how it mixes domain specific language abilities with object oriented design to let me crank out fully functioning applications at prototyping speeds with production quality.

A lot of people are saying that Ruby and Rails aren’t ready for the enterprise. What’s your take on this?

Zed Before answering this I’ll have to clarify the term “enterprise” into something people can talk about. Right now “enterprise” seems to mean three general things:

• “Big and expensive for running real businesses.”
• “Scales and performs well enough to meet my service demands.”
• “Has legally enforceable commercial support options to cover potential losses.”

Okay, let’s talk about each of those concepts. Ruby and Rails are both free, how does this square with spending a lot of money?

Despite so many of the Ruby on Rails rock stars developing on the OS X platform there’s little documentation on the production deployment process on OS X Server.

Well, not any more. Luke Burton spells out the process for doing just that on MacDevCenter.

I was pleasantly surprised by the turnout (about twenty people) to the Toronto Rails Pub Nite. I had interesting discussions with people who noted that both the Ruby and the Rails communities are built on friendly shoulders: you don’t understand something, you ask a question and get a friendly answer. Someone else doesn’t understand something and asks a question, and you yourself are inclined to give a friendly answer now.

I’m looking forward to the next Pub Nite as a supplement to the regular Toronto Ruby User’s Group meetings on the first Sunday of every month. I’m not a Railser, but it’s good to see the community getting together this way.

I’m creating a CONSTANT value that I want my whole Rails app to see.

I put it in config/environment.rb, down at the bottom, just like it tells me to.
(”# Include your application configuration below”)

But - I wanted to access that CONSTANT from config/routes.rb

No luck. Wouldn’t see it. Very confused.

I moved the definition of that CONSTANT up at the top - before the Rails::Initializer.run line

Now it works.

Henrik Mårtensson has posted a couple of blog entries about Ruby related patterns: Extract Mixin and Replace Mixin with Class. I’m more intrigued by Extract Mixin (I’m planning on applying it to some shared functionality in r43 and RWB.

Since Patterns have been a topic here, I thought these were worth pointing out. It makes me wonder though, are there other patterns that grow out of the Ruby Way, or are more visible/useful when seen through rose tinted glasses?

Bill Walton had some ‘issues’ following Curt Hibbs’ Rolling with Ruby on Rails as he tried to follow the tutorial using InstantRails, “a one-stop Rails runtime solution containing Ruby, Rails, Apache, and MySQL, all preconfigured and ready to run”.

Bill has written an update to Curt’s original, with Curt’s blessing, to “make it 100% keystroke-for-keystroke, window-for-window accurate for someone using this same tutorial for InstantRails”.

If you’ve banged your head against the tutorial using InstantRails here’s some healin’.

XML.com is featuring an article on getting started with Builder - an XML builder that was a part of Rails, but has become a full-blown project of its own.

I recently started writing an article about Domain Specific Languages (DSL’s) and Ruby. While conceptually I think I understand what a DSL is, I think a specific definition is elusive. After scrutinizing several articles and the Wikipedia, I can propose a limited definition of a DSL as a custom language designed to solve a specific problem.

Some examples of DSL’s listed are unix mini (or little) languages, such as sed, awk, troff, m4 or make. The list is quite long, and actually, could go on forever, since most any language, computer based or not, could be considered a DSL. But for now, I’ll limit this entry to languages used in the computer domain.

From my work, I see DSLs used for two main purposes. One, is as a friendly way to provide data (configuration or otherwise) to a program. The other is a friendly way to let users write business rules for a particular task. This is usually motivated by the desire to let the end user write code without realizing they are actually coding.

Except for very simple command lists, you see this second type less often because the complexity usually requires one to either build a real mini language or, if using a traditional general purpose language (GPL), the derived DSL is usually more cryptic or complex than just using the GPL itself.

When designing a DSL, the programmer has to weigh the options of taking the effort to build a full featured language (using the likes of YACC or Bison) or to make a simpler language that can usually be parsed with a hand built parser. It’s the choice between ’simple and now’ or ‘full featured and later’.

But the danger is that ’simple and now’ languages, if successful, tend to grow into ugly and complex later.

Consider make. I’m not intimately familar with the origin of this language, but here is my wild guess as to how it came about:

Programmer: Hmm, I’m tired of repeating these build steps over and over. I need to make a control file to do this for me. I also want to be able to take this with me to other platforms, so I’ll need to use a portable language. Hmm, I know C, I’ll use it.

Now lets see, I don’t want to go to the effort of writing a real language, I just need some simple features, so I’ll write my own parser.

I need a simple way to defined dependencies and a target, something like:

  target : dependencies

Yeah, the ‘:’ is good. You don’t see colons used much in filenames.
Now I need to define a list of actions. Hmm, how about:

  target : dependencies
  begin_actions
    action1
    action2
    ...
  end_actions

Wow, this is hard. These blocks are killing me. Hey, wait a minute, I can get rid of these blocks if I just make the user use a tab as the first character on an action line, kind of like Fortran, but more sinister since you can’t see the tab character (woohaahaaha). This way I can do a simple character test in C and don’t have to do any complex parsing. The user shouldn’t mind too much.

Having a critical syntax that depends upon an invisible character is just a horrible design — for the end user. For the programmer, it was pragmatic and reasonable.

Instead of writing a homegrown parser, another alternative is to create a grammar and use a tool like YACC and create a parser. This definitely falls on the complex side of the scale. For someone who doesn’t do this everyday, even simple tasks take a huge amount of brain power and one ends up focusing more on minutia of the DSL, and not on higher level usability issues.

Several years ago I needed to write a description file of geometrical stack. Several vendors had their own format, which were mostly line based, but a couple supported scoping inside a block. None, however, supported variables or constants. Their files were basically glorified configuration files.

I started to write my own using Racc. It was a great learning experience for me. We chose to write our own parser because we wanted to limit what could be done in the file (why, I don’t know). I spent about three weeks on the project and things were progessing nicely. It almost looked like Ruby. But, it was tedious, and other things got prioritized over the project before I could finish.

Later I revisited the project. This time I thought, hey, why should I write my own parser, XML/XSLT and xmlproc will do this for me. So, within a couple of days, I had done what took me three weeks previously. I thought it looked readable and the time and was able to partially convince a colleage that it was readable. About a week later, when I came back and revisited the file, I realized, XML is not readable. Sure, if your brain is in XML mode, then it can filter out the syntax noise. But when one is concentrating on getting a particular job accomplished and thier brain is forced to task switch between their problem domain and mentally parsing XML, overloaded synapses are a certainty.

The third time around, after the Ruby DSL hype had been going around for a while, I decided to use Ruby. This time, I was able to create the DSL in about five minutes. It was readable, and I was able to focus on the end users frame of reference.

The moral of this story is, don’t write a mini language if you don’t have too. And, don’t settle for a simple DSL when a full featured one is needed. Consider extending a GPL into a DSL. Particularly an expressive language that is good at creating a readable DSL — like Ruby.

Back to the original question of a what exactly is a DSL. One can either write a DSL from scratch or use a GPL with a few added functions to create a DSL. But if any GPL can be made into a DSL, doesn’t that make all languages DSLs?

Pop quiz, hot shot! What two topics are so high up the tech. meme ladder that they make geeks quiver at the mouth?

Right! Asterick & Rails. Now, put them together for mouth foaming madness in Hacking Asterisk and Rails with RAGI.

In this article, I’ll provide a quick overview of how Asterisk, the open source PBX, can be used as a general-purpose “telephony protocol server,” and can be connected to Ruby on Rails to create a rapid prototyping environment for creating next-generation VoIP applications and services.