Friday, September 29, 2006

Swiss Ruby/Rails Group

Yesterday, the Swiss rails group was founded in the Reithalle in Zurich. I was there and had quite some fun talking to other Rails and Ruby devotees. Check out, where we start to get things going.

UPDATE: some pics of the meeting on Flickr

Tuesday, September 26, 2006

Unicode again / I start spreading FUD

I, like many others, have been plagued by the lack of Unicode support in Ruby and consequently in Rails. While I did not follow the discussion around it in great detail I stumbled over it again in an article on InfoQ. In here, DHH gets quoted as saying Morten Christensen pointed out; shouldn’t 5 or more plugins for internationalization indicate quite clearly that the Rails community craves unified support implemented in the core?

No, DHH answered, from the Core Team’s point of view, this means that people want to support and implement internationalization in a lot of different ways, and that there is no universal solution that will make everybody happy. Even inside the Core Team people can’t agree how it should be done. Although, DHH added, I can’t rule out that the 37signals needs internationalization, is the day that Rails get it.

Quite frankly, this arrogance drives me up the wall. And more important, it proves that the people who argue that RoR is proprietary have a point. It might be OSS, but its evolution seems to depend largely on one man's opinions (aka the good tyrant). This might be good (see Linux, Spring), but it imposes risks on you if you rely on the evolution of RoR in some way. In know, this sounds like spreading FUD, but DHH needs to listen more me thinks.

Friday, September 22, 2006

On DSLs and design patterns

Through an article on InfoQ I have come across a number of blog posts about DSLs (domain specific languages). It all starts with Joel (by now famous for his opinions on Ruby performance ;) ) who explains the rationale behind creating Wasabi, a DSL for his company's bug tracker. This software apparently has to run on VB and PHP.

InfoQ also refers to the blog "discipline and punish" (what a name) in which the author argues that DSLs are flawed due to their (or rather their creator's) inability to adapt to change - well, that's what I gather from it at least.

Personally, I am currently working for a company that has created its own DSL for describing user interfaces on mobile devices (we're not talking about simple XML, but rather a real language). These UIs need to run cross-platform (Symbian, MS Mobile, Java, etc) so the DSL really has to abstract the platform differences. So in essence, I really buy into Joel's argument that DSLs are about abstraction (I do NOT buy into his argument that Wasabi is a good idea for the reasons he describes or that creating a DSL would be not a lot of effort).

One thing that had not been covered on the DSL discussion as mentioned by InfoQ is the tools issue. If you create a DSL you either have to develop without tools (-> inefficient) or create your own tools (-> effort). For me, this is one of the reasons why I do think twice about creating a DSL and then think about it again.

And now to something completely different.

In this blog entry Mark Dominus argues that design patterns are a sign for a weakness in the language. Thought about it. Found it a brilliant observation. Agree. (and I'm sure Erich Gamma will not be happy ; )

Maybe there will always be design patterns because the mainstream general purpose languages changes so slowly (i.e. our change from one to the other). So we stick with them for a while (like a decade) until we learned enough to convert to a new general purpose language (think C, C++, Java).

Along these lines I remembered that the decorator pattern can be implemented really easily in Ruby. But still, it has to be implemented. So, maybe Ruby is not the great next thing after Java (it's just nice - which is good enough for me ;) ).

Thursday, September 14, 2006

Agile Manifesto

I signed the Agile Manifesto today because I believe that the directions given by the manifesto's principles are are necessary further advancement in our understanding how software development should work.

Here's the principles:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Sounds good, no?

And my disclaimer to all this: Agile is not for every project I think. But even if you need to do e.g. RUP for whatever reason you should have look at Agile methods and maybe adapt parts of it.

Wednesday, September 13, 2006

Joel and Ruby performance

Joel of Joel on Software fame has bashed Ruby performance on his blog. The outcry caused by this flamebait has been large as expected. Yet, out of the gut (without any benchmarks to back up my feelings) I thought he was probably right that Ruby is small.

However, I found an interesting comment on the Smallthought blog: the author points out that Ruby's performance is slowed down by a naive implementation of the interpreter and points to a Smalltalk interpreter just OSSed by Sun. Now, if we combine this and Sun hiring the JRuny guys there is cause for hope to get a better Ruby interpreter in a short while.

Tuesday, September 12, 2006

Sun hires the JRuby developers

InfoQ has an article on Sun hiring the JRuby developers and the implications of this step for Groovy/Grails. They quote Graeme Rocher, a lead developer of Grails, who (not too surprisingly) says that it will not have much impact. I beg to differ and here's why.

When I became interested in latest enchilada of RAD tools like Rails, Grails, Trails and so on the two I had a real hard look at where Rails and Grails. What drew me to Grails was the fact that it was close to Java so that I could use the myriads of existing libraries out there and that I could deploy it in Tomcat. But the more feasible it becomes to deploy a Rails application on JRuby the less valid these two arguments will be. So why would anyone go for Grails these days? In Graeme Rocher's Blog he quotes the tight integration with Spring, Hibernate, etc. and that they lokk at integrating EJBs. This might be of interest to some developers, but for me this misses the point of why I became interested in Rails in the first place: a very efficient and maintainable way to build db-driven web sites. If it is built on Spring or not does not really matter to me (at least for the use cases I am looking at right now).