I am not sure how well it comes across in my blog posts, but joining ThoughtWorks have been the best move of my life. I can’t really describe what a wonderful place this is to be (for me at least). I sometimes try – in person, after a few beers – but I always end up not being able to capture the real feeling of working for a company that is more than a company.

I’m happy at being with ThoughtWorks. It’s as simple as that – I feel like I’ve found my home.

So imagine how happy I am to tell you that ThoughtWorks is exploring opportunities for an office in Sweden!

Now, I am one of the persons involved in this effort, and we have been talking about it for a while (actually, we started talking about it for real not long after I joined). But now it’s reality. The first trips to Sweden will be in January. ThoughtWorks will be sponsoring JFokus (which is shaping up to be a really good conference, by the way. I’m happy to have been presenting there the first year). We will have a few representatives at JFokus, of course. I will be there, for example. =)

Of course, exploring Sweden is not the same thing as saying that an office will actually happen. But we think there are good reasons to at least consider it. I personally think it would be a perfect fit, but I am a bit biased about it.

So what are we doing for exploration? Well, of course we have started to look into business opportunities and possible clients. We are looking at partnerships and collaboration. We are looking at potential recruits. But really, the most important thing at this stage is to talk to people, get a feeling for the lay of the land, get to know interesting folks that can give us advice and so on. And that is what our travels in January will be about.

So. Do you feel you might fit any of the categories of people above? We’d love to meet you and talk – very informally. So get in touch.

This is exciting times for us!

3 Comments | By Ola Bini | In: Uncategorized | tags: jfokus, sweden, thoughtworks. | #

The title says it all. The only reason you haven’t noticed, is that you probably aren’t working on a large enough application, or have enough tests. But the fact is, Test::Unit leaks memory. Of course, that’s to be expected if it is going to be able to report results. But that leak should be more or less linear.

That is not the case. So. To make this concrete, lets take a look at a test that exhibits the problem:

class LargeTest < Test::Unit::TestCase
def setup
  @large1 = ["foobar"] * 1000
  @large2 = ["fruxy"] * 1000
end

1000_000.times do |n|
  define_method :"test_abc#{n}" do
    assert true
  end
end
end

This is obviously fabricated. The important details are these: the setup method will create two semi large objects and assign them to instance variables. This is a common pattern in many test suites – you want to have the same objects created, so you assign them to instance variables. In most cases there is some tear down associated, but I rarely see teardown that includes assigning nil to the instance variables. Now, this will run one million tests, with one million setup calls. Not only that – the way Test::Unit works, it will actually create one million LargeTest instances. Each of those instances will have those two instance variables defined. Now, if you take a look at your test suites, you probably have less than one million tests all over. You also probably don’t have that large objects all over the place. But remember, it’s the object graph that counts. If you have a small object that refers to something else, the whole referral chain will be stopped from garbage collection.

… Or God forbid – if you have a closure somewhere inside of that stuff. Closures are a good way to leak lots of memory, if they aren’t collected. The way the structures work, they refer to many things all over the place. Leaking closures will kill your application.

What’s the solution? Well, the good one would be for test unit to change it’s implementation of TestCase.run to remove all instance variables after teardown. Lacking that, something like this will do it:

class Test::Unit::TestCase
 NEEDED_INSTANCE_VARIABLES = %w(@loaded_fixtures @_assertion_wrapped @fixture_cache @test_passed @method_name)

 def teardown_instance_variables
   teardown_real
   instance_variables.each do |name|
     unless NEEDED_INSTANCE_VARIABLES.include?(name)
       instance_variable_set name, nil
     end
   end
 end

 def teardown_real; end
 alias teardown teardown_instance_variables

 def self.method_added(name)
   if name == :teardown && !@__inside
     alias_method :teardown_real, :teardown
     @__inside = true
     alias_method :teardown, :teardown_instance_variables
     @__inside = false
   end
 end
end

This code will make sure that all instance variables except for those that Test::Unit needs will be removed at teardown time. That means the instances will still be there, but no memory will be leaked for the things you’re using. Much better, but at the end of the day, I feel that the approach Test::Unit uses is dangerous. At some point, this probably needs to be fixed for real.

7 Comments | By Ola Bini | In: Uncategorized | tags: test test/unit ruby memory leak. | #

I spent a few hours this weekend converting RubyTime in JRuby to use Joda Time instead of Calendar or Date. That was a very nice experience actually. I’m incredibly impressed by Joda, and overall I think it was worth adding a new dependency to JRuby for this. The API is very nice, and immutability in these classes make things so much easier.

There were a few things I got a bit annoyed at though. First, that Joda is ISO 8601 compliant is a really good thing, but I missed the functionality to tune a few things. Stuff like saying which weekday a week should start on, for the calculation of current week would be very nice. As it is right now, that functionality has to use Calendar. It might be in Joda, but I couldn’t find it.

The other thing I had a problem with – and this actually made me a bit annoyed – was how Joda handles GMT and UTC. Now, it says clearly in the documentation that Joda works with the UTC concept, and that GMT is not exactly the same thing. So why is it this code passes (if assertNotEquals is assumed):

    public void testJodaStrangeNess() {
       assertEquals(DateTimeZone.UTC, DateTimeZone.forID("UTC"));
       assertEquals(DateTimeZone.UTC, DateTimeZone.forID("GMT"));
       assertEquals(DateTimeZone.UTC, DateTimeZone.forOffsetHours(0));
       assertNotEquals(DateTimeZone.UTC, DateTimeZone.forID("Etc/GMT"));
       assertNotEquals(DateTimeZone.forID("GMT"), DateTimeZone.forID("Etc/GMT"));
   }

Yeah, you’re reading it right – UTC and GMT is the same time zone. +00:00 is the same as UTC too. But Etc/GMT is not the same as UTC or GMT or +00:00. Isn’t that a bit strange?

4 Comments | By Ola Bini | In: Uncategorized | tags: joda, jruby, time. | #

Earlier today I attended the last sessions for this years JavaPolis. This was the first time I attended, and I’ve been incredibly impressed by it. The whole conference have been very good.

I arrived on Monday, sneaking in on Brian Leonard and Charlies JRuby tutorial. I didn’t see much of it though, and after that me and Charles had to prepare our session a bit, so no BOFs.

Tuesday I slept late (being sick and all), and then saw Jim Weavers JavaFX tutorial, which was very adept. I feel I have a fairly good grasp of the capabilities of Java FX Script now, at least. There were a few BOFs I wanted to go to that evening, but since the speaker dinner/open bar was that night, I obviously choose that. Cue getting to bed at 3am, after getting home to the hotel from… uhm. somewhere in or around Antwerpen.

On Wednesday, the real conference started. My first session was the Groovy Update. I always enjoy seeing presentations of other language implementations, partly because I’m a language geek, but also because everyone has a very different presentation style that I like to contrast with each other. One thing I noticed about the Groovy presentation was that much of it was spent comparing Groovy to “other” languages.

Right, after that I saw two quickies – the first one about IntelliJ’s new support for JRuby. And yes, this is support for JRuby, not just Ruby. You can use IntelliJ to navigate from Ruby code to Java code, where you have used that Java code in your Ruby. It looks really promising actually, and I spent some time showing the presenter a few things more that could be included. I don’t know of any IDE that supports JRuby specific things like that, actually.

After that I saw Dick Wall’s presentation on GWT. Since I have actually managed to avoid any knowledge about GWT, it was kinda interesting.

The next sessions didn’t seem too interesting, so I worked a bit more on my presentation, and walked around talking to people.

Charles and my presentation went quite well, even though I managed to tank all the demonstrations quite heavily. For some reason I actually locked JIRB in comment mode, and couldn’t get out of it, and then I fell upon the block coercion bug that happens when you call a Java method that is overloaded so that one takes no arguments and another overload takes the interface you want to coerce into. Charles didn’t stop me until afterwards… =)

But yes, it went well. Lots of people in the audience, and lots of interest.

The final session of the day was the future of computing panel, with Gosling, Bloch, Gafter and Odersky. To be honest, I found it boring – Quinn was moderator, but didn’t really manage to get the panel as enthused about anything.

After that, it was BOF time, I sat in on the Adobe one to pass the time, but didn’t learn anything spectacular. The Groovy BOF was nice – it’s always fun to see lots of code.

I started Thursday with the Scala presentation. Now, I didn’t learn anything I didn’t know here, but it was still a very good presentation. And oh, I found out that there is a Scala book on the way. (It’s actually available as a Rough Cut from Artima. Very nice.)

The next session was supposed to be Blochs Effective Java, but he used to spot to rant about the BGGA closures proposal instead. Of course, Joshua Bloch always rants in a very entertaining way, and he had chosen insidiously good examples for his point of view – but I’m still not convinced.

The Java Posse live show was good fun. After that I managed to see Bob Lee’s Web Beans presentation, and then the one on JAX-RS. Doesn’t really have much to say about those two. Except… am I the only one who starts getting bored by annotations all over the place?

The day was nearly over, and then it was time for BOF’s. The main difference being that it was time for the JRuby BOF. All went well, except that Charles didn’t show up, I didn’t have a projector the first half of the BOF, Tom introduced a bug on Wednesday that made all my examples fail, and so on. A huge thanks to Damian Steer who saved me by keeping the audience entertained while I fixed the bug in front of everyone.

I sat through Chet Haase’s talk about Update N, but didn’t pay that much attention since I was hacking on JRuby.

Finally, it was time for the BOF on other new language features in Java, with Gafter and Bloch. This was actually very interesting stuff. It ended up being almost 2 hours. But I think most people got their fill of new language syntax in it. The question is, which parts are good? I particularly didn’t like method extensions. All the proposals seems to lose the runtime component of it, and in that case it just stops being interesting. I would much rather see the language add real categories or something like that.

Friday was a lazy day. I sat in on the OGIi presentation and the TDD one, but nothing really exciting there either.

So that’s my JavaPolis week. It’s been a good time. And now I think it’s time to have some more beers with JRuby people before moving out from here.

2 Comments | By Ola Bini | In: Uncategorized | tags: conferences, javapolis, jruby. | #

It would really be time for JDBC to add support for database agnostic DDL. This is still one of the more gross areas of many database libraries (just look at dialects in Hibernate). Most of it is actually caused by DDL. But at the end of the day, most of the operations supported are actually exactly the same. Am I the only one who thinks it would be nice to have programmatic access to DDL operations?

3 Comments | By Ola Bini | In: Uncategorized | tags: ddl, jdbc. | #

Tomorrow I’m going to JavaPolis – me and Charles are presenting on JRuby on Rails on Wednesday. We’ll be there the whole week so if you wanna get in touch, don’t hesitate. We’re aiming to taste many nice Belgian beers.

Except for that, it’s actually quite quiet right now. There are some things in the works which will soon be announced, though.

3 Comments | By Ola Bini | In: Uncategorized | tags: beer, belgium, javapolis, jruby. | #

This is one of those idea-posts. There is no implementation and no code. But if someone wants to take the idea and do something with it, go ahead.

The gist of it is this: what if you could implement the actions for AspectJ in Ruby? You could define an on-load pointcut that matches everything and dispatches to Ruby. From there on you could do basically anything from the Ruby side – including dynamically changing the stuff happening. Of course, there would be a performance cost, but it could be incredibly useful for debugging, when you don’t really want to restart your application and recompile every time you want to change the implementation of the aspect code.

3 Comments | By Ola Bini | In: Uncategorized | tags: aspectj, jruby, ruby. | #

Friends! ThoughtWorks is hiring Ruby developers all over the world, but right now San Francisco is the hottest place to be. So if you’re located in the Bay Area and want to work with Ruby and Rails, don’t hesitate to make contact.

The time since I joined ThoughtWorks about 6 months ago have been the best of my life, and of all our offices around the world, I like the San Francisco one best. ThoughtWorks is really the home for people passionate about development and people who love Ruby.

If you have been following my blog, you know about Oracle Mix and other interesting things we have been doing out of the SF office. And there’s more to come – exciting times!

Could ThoughtWorks in San Francisco be your home? Take contact with recruiting here: http://www.thoughtworks.com/work-for-us/apply-online.html, or email me directly and I’ll see to it that your information gets to the right place!

1 Comment | By Ola Bini | In: Uncategorized | tags: ruby, thoughtworks. | #

This is a glorious day! Joni (Marcin’s incredible Java port of the Oniguruma regexp engine) has been merged to JRuby trunk. It seems to work really well right now.

I did some initial testing, and the Petstore numbers are more or less the same as before, actually. This is explained by the fact that I did the integration quite quick and tried to get stuff working without concern for performance. We will go through the implementations and tune them for Joni soon, and this will absolutely give JRuby a valuable boost.

Marcin is also continuing to improve Joni performance, so over all this is a very nice approach.

Happy merge day!

1 Comment | By Ola Bini | In: Uncategorized | tags: joni, jruby, oniguruma, regular expressions. | #

It’s been some time since I wrote about what’s happening in JRuby trunk right now, and what we’re working on. The reason is I’ve been really boring. All my time I’ve spent on Regular Expressions and the REJ implementation. Well, that’s ended now. After Marcin got the Oniguruma port close enough, we are both focusing on that instead. REJ’s implementation had some fundamental problems that would make it really hard to get better performance. In this regard, Joni is a better implementation. Also, Marcin is incredible at optimization so if everything goes as planned, we’re looking at better general Regular Expression performance, better compatibility and a much more competent implementation.

And boy am I bored by this now. =) I’d really like to get back to fixing bugs and get JRuby ready for the next release. That might happen soon, though – I’ve spent the weekend getting Joni integrated with JRuby inside a branch and today reached the goal of getting everything to compile. Also, easier programs run, like jirb. Our test suite fails, though, so there are still things to do. But getting everything compiling and ditching JRegex is a major point on the way of replacing JRegex in JRuby core. It shouldn’t be too far off, and I think it will be fair to say we will have Joni in JRuby 1.1. Actually, 1.1 is really going to be an awesome release.

1 Comment | By Ola Bini | In: Uncategorized | tags: joni, jruby, oniguruma, regular expressions. | #