leonardoborges.com

the not so usual geek stuff…

This week we started to test mod_rails in a couple of projects where I work on. One in production.

Of course it’s too early for any conclusions, but I just wanted to share a couple of problems you might find when the installer tries to compile the Apache module.

In our case, and I believe it is the case of many servers out there, we have a custom Apache installation, what makes the installer not find it and/or not find the Apache Portable Runtime (APR) sometimes.

The first one is easy and is documented here. You just seed to export the following environment variable, pointing to your apache installation:

export APXS2=/opt/apache2/bin/apxs

The second one is a bit tricky but it happened only when I tried to install passenger in another server that had CentOS. In this case, you will also need the following environment variable, pointing to your Apache APR config:

export APR_CONFIG=/usr/local/apache2/bin/apr-1-config

It took me a fair amount of time googling around to find this answer, so I hope it’ll be useful for someone.

As some of you know I went to the European Ruby Conf in Prague, this year.

The event was awesome and it’s good to know they finally made available the majority of the slides, here.

They also published Matz’s keynote, and more videos from the conference are being edited right now, so stay tuned to their home page!

Enjoy!

It’s been some time since my last post but here I am! Where? In Spain, of course! Having a great time, I must say.

I arrived last week in Madrid and the past 2 weeks before that I spent basically packing my stuff. There is still some paperwork going on but everything is flowing well.

Besides this little feedback, I was reading this week’s issue of the excellent series This Week In Ruby, from my friend Antonio Cangiano. I found something quite interesting, a plugin called HoboFields.

One of the things that bothers me in rails is the fact that by looking at your model classes, you can’t tell the fields you have there. Sure, you can look at the migration script. Yeah, you can also load the development environment and inspect the object. It’s a pain in the @zz! But this is the way ActiveRecord works…

Other ORM solutions like DataMapper, allows you to define the fields directly in the class. It’s a much cleaner and clear way to maintain your models. And you get to know what properties you have just by looking at your classes.

That’s exactly what HoboFields adds to ActiveRecord.

You define your properties and its types straight into your model class, and the plugin creates the migration scripts for you. Coming from a java world my self, I find it rather interesting, useful and it also reminds me of the way Hibernate works. You define your mappings with anotations in your class and hibernate just generate the schemas from there.

It’s worth a try.

Passenger(mod_rails) has been released.

The idea is to ease the pain on rails applications deployment. I tested myself and in less than five minutes I had my application working behind Apache!

I’m not going to say much here besides the fact that it seems like a really good option for rails deployment and people have been talking about it already, including DHH.

But I do recommend a read on the architecture overview document. Be sure to read it all, specially the part on handling concurrent requests.

To install, “it doesn’t get easier than” that.

Good job guys.

Update: Follow up link to this issue on JRuby’s Jira, here

As I told in my last post, it was time to give JRuby a serious try. So I took one of our rails projects at work and decided to migrate it to JRuby and see what happens.

We heavily use the XML capabilities of DB2 and this was a huge problem. Every query would work just fine through the activerecord-jdbc-adapter - part of the JRuby Extras . But every Xquery would gracefully fail!

After some debugging I got stuck and decided to get JRuby and activerecord-jdbc-adapter’s source to see what was happening.

As I could see, it has a bug -in my opinion - at the java part of the code. The jdbc-adapter is a bridge to allow Active Record to talk with databases through native JDBC drivers, so it’s normal that we do have a java part here. At this point, what the code does is to inspect the sql statement sent from ruby and decide if it’s a select, update or insert.

I fixed the problem and submitted a patch to rubyforge. I’m not sure if it’s the best solution or not, but now I got the xQueries working just fine.

I’d love to hear from people with similar environments whether this patch works for you or not. I’m sure I didn’t try every possibility.

If you wanna try it, just drop me a message (e-mail in the About page) and I can send the pre-compiled jar file - for activerecord-jdbc-0.8

You can also just check out the code and compile yourself.

Most of last QCon’s presentations are available for download here.

Highlights to Ola Bini’s on JRuby(pdf) and Randy Shoup’s on eBay’s architectural principles(pdf).

And while we’re talking about JRuby, it’s impressive how it’s becoming a recurrent and big subject. Fast. It had its own small space at big event like QCon and in the last Euruko in Prague, we had a presentation by the JRuby Core Developers Charles Nutter and Thomas Enebo.

Big companies are sponsoring JRuby’s development indirectly or directly, like Sun. And other big companies are endorsing its production ready state, like Oracle, which has a publicly available website developed with JRuby On Rails.

It’s past the time to give it a serious try…

This is quite funny. A friend, Perl addicted, is now learning Ruby. He really enjoys the language but made a interesting observation: Ruby is a language for lazy programmers!

Well, I have to agree… You know, I love saving keystrokes and achieving more by writing less. And this is so true with Ruby.

Let me give a really simple example, comparing with java - don’t get me wrong… I love java, specially the platform, but it fits well here since I’ve always been a Java guy.

Imagine you have a Phone class with the attributes number and type, which can indicate whether the phone is a land line or a mobile phone. Then you got an array filled with phone classes and you want to narrow it by creating a new array only with mobile phones.

In Java, such a class could look very much like this:

public class Phone {
  private String number;
  private String type;

  public String getNumber() {
    return number;
  }
  public void setNumber(String number) {
    this.number = number;
  }
  public String getType() {
    return type;
  }
  public void setType(String type) {
    this.type = type;
  }
}

Quite simple, isn’t it? But we are telling the compiler many things we actually shouldn’t need to. This class is a java bean and as such, among other things, it needs a pair of getters and setters for each of its attributes.

Now, on with our example, the same class, in ruby, looks like this:

class Phone
  attr_accessor :number, :type
end

Yeah, I know the feeling. This class has exactly what we need: the two attributes with its own pairs of getters and setters each. But we didn’t need to inform it in the verbose way Java has teached us. Cleaner, period.

Now to the code that actually returns the new array containing only mobile numbers. In java, we can do it in two different ways.
Using an ArrayList:

//Create two phone objects, one land line and one mobile
...
// Add them to an array
ArrayList
 phones = new ArrayList
();
phones.add(land);
phones.add(mobile);

//Return an array only with mobile numbers:
private static ArrayList
 selectMobilePhones(ArrayList
 phones) {

  ArrayList<Phone> mobiles = new ArrayList<Phone>();

  for (Phone phone : phones) {
    if (phone.getType().equals("mobile")) {
      mobiles.add(phone);
    }
  }
  return mobiles;
}

Or using ordinary arrays:

// Assume the same phone objects here
...
//Add them to the array
Phone[] phones = new Phone[]{land, mobile};

//Return an array only with mobile numbers:
Phone[] mobiles = new Phone[a.length];

for (int i = 0; i < a.length; i++) {

  if (a[i].getType().equals("mobile")) {
    mobiles[i] = a[i];
  }
}

And you’re good to go. Actually this code with an ArrayList here only looks good thanks to generics. But this is another matter. Let’s take a look at the ruby code that accomplishes de same task:

//Create two phone objects, one land line and one mobile
...
//Add them to an array
phones = [land, mobile]

//Return an array only with mobile numbers:
mobiles = phones.select { |phone|
   phone.type == "mobile"
}

See the difference? Java is a great language but too verbose at times. This is a really simple example but if you take the same principle to a bigger app… yeah, you see where I’m going.

The bottom line… Ruby may be the language of the lazy programmer, as my friend pointed out. But I don’t mind being called lazy as long as I can type less and be more productive. Do you?

On friday I’ll be heading Prague for the European RubyConf.

Anyone is going?
Almost 300 attendees already registered for the event. And a few very interesting people will be speaking there like Matz and DHH (this one, through skype).

Besides that, the organization staff is scheduling 2 parties, friday and saturday, for the attendees.

Networking comes to mind, doesn’t it? I think it will be a great opportunity to meet interesting and bright people.

So, see u in Prague!

Today was the first day of the conference and it started with a tutorial about DSL’s with Martin Fowler, Neal Ford and Rebecca Parsons. We also had as attendants Ola Bini, core developer of JRuby, and others. My expectations were pretty high and the presentation didn’t let me down. I’ll try to put here toghether my impressions and some notes I took while I was there.

Marting Fowler started discussing what DSL’s are and giving some examples that many of us use in our day to day Job. Like the XML configuration files in the Java world. It is a kind of DSL, it has it’s own keywords and syntax in order to express some information that will be used , for instance, to configure an underlying framework.

The problem with XML is that it becomes hard to see the overall behavior behind it. It’s not very fluent to understand the purpose of an XML file just by looking at it for the first time. There is too much “noise”. Things that get into the way of the readability. - YAML files are an much more readable alternatives to XML.

The same happens with a standard framework api code. Let’s take for instance a sample API configuration code written in Java to tackle the domain of hotel reservations. A framework like this could have the following implementation:


HotelService hotelService = new HotelService();
PersonService personService = new HotelService();

Hotel hotel = hotelService.findById(1);
Person guest = personService.findById(10) ;

Reservation reservation = new Reservation() ;
reservation.setFrom(”2008-03-10″) ;
reservation.setTo(”2008-03-14″);
reservation.setGuests(new Person[]{guest});

hotelService.book(hotel, reservation);
Of course implementations of this simple example may vary but we can see here some of the readability problems. One approach we could use for that is to develop a Fluent Interface to wrap this API. This was one of the techniques explored during the tutorial and the actual fluent interface could now look somewhat similar with this:


new Hotel(1)
.book()
.forGuests({
person.find(10)
})
.rooms(1)
.from("2008-03-10")
.to("2008-03-10");


Much more readable, huh? One of the main benefits of using DSL’s they highlighted in the tutorial is the simplicity of code you can achieve. You can actually show this code to a business person and he can understand it. This is a kind of internal DSL.

But there is still a bit of noise in this code. The the parenthesis which are not always desirable, and the use of double quotes for dates. But, this is Java code, and Java doesn’t give too much room for you on the DSL subject. Here was when the speakers changed their focus a bit to Ruby. It’s dynamic nature and metaprogramming techniques provides a powerful flexibility that allows for a looser syntax.

So in ruby the previous interface could look like this now:


Hotel.find(1) .book(1.room).forGuests {
Person.find(10)
}.from(march.10.2008).to(march.10.2008)


We got rid of the double quotes and the code looks more fluent, like a normal english sentence. I doubt a business guy woudn’t understand what this code is doing. With this, we can get closer to the business guys, with a common vocabulary, and fill the gap between us.

This is just one of the ways we could have written this code and is not the actual example used in the tutorial. The syntax also really depends on how readable you wanna make your code. I’ll provide those later when they release the digital format of the presentation.

So one of the flows that the development of an internal DSL can get is to build a framework and define the DSL on top of it. But we should also keep in mind that DSL’s shouldn’t be general purpose programming languages. They should be created to tackle a specific kind of domain problem, so we would have a whole system made of small DSL’s.

Another interesting subject that was touched is testing. How do you test DSL’s?
The suggested approach, and that I think is quite reasonable, is to have separate tests for the underlying framework and another to test the DSL and its parser you can assure you have the expected behaviour of both parts.

This is really just a summary of my thoughts and of what happened there. I’m not going into too much details right now but if you found something too abstract - and it is! - feel free to ask details. I’ll be more than happy to help.

This is definetly an interesting subject and now I’ll head to play more with all that.
PS; This is not the whole presentation, just the best of it from my stand point. Other subjects include External DSL’s which can actually involve you coding Lexers, Parsers and Compilers. It’s usually not worth the hassle. And it’s too complicated anyway, that’s why I left it out from this post.

I think I’ve been really lucky lately. In my new job I’m getting to work with many interesting things and OpenID is just one of them.

We are investing high in Ruby on Rails and we have now a few internal applications in development stages. Our manager wanted the ability to let people log in to our rails applications(for now) using their OpenID accounts.

It was a funny task, as I knew very little about OpenID. The idea actually is really good. Instead of creating a new user account on each new service/site you’d like to subscribe to, you create a single user account in a OpenID provider - like MyOpenID - and use this identity to authenticate yourself in the services/sites that support this protocol.

What do we earn from that? Well, in my opinion, we can get a couple of benefits:

- You don’t need to memorize 723 logins and 723 passwords (if you really care about creating different passwords for all of your user accounts)

- You don’t authenticate yourself to the service you’re attempting to use. This service actually asks to your provider if your identity is valid, and you authenticate yourself there. Nowhere else.

I strongly recommend you visit the OpenID to understand more about it.

But, back to the problem, we needed to put it working in a rails app. And that’s when I found the ruby-openid library, provided by OpenID Enabled.

It is a complete library, really well documented that provides an abstraction layer both for consumer and server applications.

My first step was to develop the consumer. That’s what you need if you are going to provide your users with OpenID authentication in your web site. The ruby-openid library comes with several samples that really helped me out here. They were developed using Ruby On Rails and are a really good start point.

After this step, I was asked to evaluate the possibility of being a OpenID provider. At first I thought it would be a really complicated task, but again this ruby library had a great example of a simple provider. The drawback is that the samples were developed in an older version of Rails ( < 2.x ) . So I had to freeze the Rails version to 1.2.5 so I could run the provider sample code.

I am now working on porting this code to Rails 2.x, into one of our applications and it’s been flowing well so far. Just wanted to share this library for those of you trying something similar. It is really worth a look.