Tuesday, December 19, 2006

My Predictions for 2007

It's almost the end of the year and a fun thing to do at that time is to predict what will happen next year. Actually, I read this list of predictions and thought, I'll give it a shot as well. I will try to keep it "positive", i.e. not mention what I think will not make it in 2007. So here we go:
  • The uptake of RoR will continue. JRuby will make a diffenrence and will allow RoR to make its way into the enterprises. Similar frameworks in other dynamic languages will rather help RoR than take away from it (Django, Grails, etc) because they will only increase the overall interest in dynamic languages.
  • REST will become mainstream in the sense that it will not be considered the poor little relative of SOAP anymore, but a viable alternative even for the enterprisey guys.
  • Macs will continue to lead the pack in terms of innovation on the desktop.
  • Location-based services have a chance to grow a lot. I expect a technology mish-mash of GPS, RFID, bar code readers on camera phones, etc. Nothing will be ready for the very big stage but we will see some trials.
At the end of 2007 I will review this post to see if I got anything right...

Friday, November 24, 2006

Rails 1.2 RC1

Ahhh, good. Rails 1.2 RC1 is out and it supports Multibyte. That makes me happy:
'€2.99'.first # => '€'
truncate('€2.99', 2) # => '€2'

Even more so because DHH finally acknowledges the fact that this was a major pain:
it wasn’t as plug’n’play easy as you could have hoped (or perhaps even expected)

Wednesday, October 11, 2006

Great programmers answer questions

In this blog entry the author presents a answers to questions he sent to some great programmers. I found it interesting, especially
  • DHH considers writing HTML "programming" (well, sort of)
  • Peter Norvig (Research Director at Google) wants to learn Flash
Shame, that Roy Fielding (of REST fame) did not answer.

Wednesday, October 04, 2006

Enterprise Ruby?

Yikes! Just saw this article on Enterprise Ruby. Well, it's been said that you can program Fortran in any language. I'd like to ammend that with: you can re-create Java EE with any language.

IntelliJ and Rails

After I had seen this post where it was announced that the next version of IntelliJ (still a GREAT IDE for Java) will support Rails. Well, now it's been released and there's no word about it. A search on the JetBrains site gives no hits for "Rails" either (not even as a plugin). Very disapointing. Will have to stick with RADRails then. Or does any reader know if Rails for IntelliJ is still/already alive/available?

UPDATE: Dmitry has provided a link for the plugin (see comments). Thanks, Dmitry! Given JetBrain's history with IDEs I am very much looking forward to giving this a try.

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 rubyonrails.ch, 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

...as 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).

Friday, August 25, 2006

Great languages

Through this post I came across a couple of great new programming languages I did not know before:
  • COW (the instructions are all moos, only the capitalization varies)
  • Malbolge (named after the eighth circle of hell in Dante's Inferno, so difficult to understand when it arrived that it took two years for the first Malbolge program to appear)
  • Brainfuck (extreme minimalism)
All of them are adorable and certainly have the potential to kill Java and Ruby.

Tuesday, August 08, 2006


" Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something."

Kent Beck

Friday, August 04, 2006

Dynamically Add Methods to Classes Through their Objects in Ruby

Lucas Carlson has introduced this really neat Ruby hack to add a method to a class via an instance:
Technoblog: Dynamically Add Methods to Classes Through their Objects in Ruby

Bruce again

Oh my god, I thought, Bruce Tate (of "Bitter Java" fame) is at it again and bashing Java when I saw this on TSS. However, leaving aside the ramblings of the TSS crowd I just looked at his presentation (pdf) titled "10 Things Java Should Steal from Ruby". It's actually quite reasonable (i.e. Duck and Quack are not mentioned). And, yes, I also miss ActiveRecord in Java.

PS: 100.times {chalkboard.write "Java is not dead"}

Wednesday, August 02, 2006

Obsessed with productivity

One thing I like about the Ruby/Rails community is the obsession with productivity. Check out this post on rubyinside and notice the first comment by zenspider:
It should be noted that 5 minutes is glacial compared to what you can do with inline (and how much easier it is). The above example was done (and ran) in less than 30 seconds!
I'm impressed and delighted.
(btw: can I get the same in Java? Gotta have a look...)

Tuesday, August 01, 2006

Ruby books and jobs

O'Reilly reports they now sell more Ruby books than Perl. However, I would not overestimate such a fact (Perl has been around for a LONG while and it's gotten a bit dated). The graph in the article also shows the rise of JavaScript book sales.

The article also covers the job market. Ruby jobs are scarce but the only ones that are increasing (as compared to other languages):
The adjusted totals of jobs calling for programming skills (as a percentage of all jobs) is down across the board, except for Ruby.
Well, I live in Switzerland where the dominant job market is jobs.ch. Today, searching for "Ruby" reveal a meager 2 jobs.

Wednesday, July 26, 2006

AppFuse and Seam

Hmm, I really liked what I saw in Seam, especially the fact that there are so few files in an app :) Basically, I have the view that one big advantage of Rails is that it controls the whole application stack and that is kind of what Seam tried to do as well. So that's the good part.

The bad part is that the application scaffolding does not work as advertised. OK, it's beta, so that's forgivable. But if you look into the Seam forum you find that many people have problems even with the scaffolding example when they try to use their own db's. There is help given in the forum but overall I was a bit put off at this point.

Back to AppFuse I was again shocked just how much code is there already in an essentially empty starter application. So I had to get over that, adjust my mindset not to think about Rails and off I went. I was not very productive, but I got my stuff done in the end (Matt has really done a great job with AppFuse IMO). I guess Spring, Hibernate, etc can be considered outdated, but they work and there is plenty of material, help and tutorials around. And that helped my productivity quite a bit as well.

In case you should try to follow the Seam application scaffolding example take this hint: the Hibernate reverse engineering tool when applied to a medium sized Oracle db is so slow that you will assume it has crashed. Chances are that it has not. In my setup it took around 20 mins to come up with a list of tables. Apart from this abysmal performance on Oracle I like the tool, actually.

Tuesday, July 25, 2006

Java productivity and the Rails community

I need to write a Java-based web app (it has to be Java because of i18n and scalability issues my employer has with Rails) and I am looking at tools that increase my mileage. Under consideration where Seam and AppFuse, but what made me give Seam a shot is this video: http://www.jboss.com/products/seam/SeamHBTools.html
While I do not need to write a CRUD app this nicely shows how to actually get started without all the plumbing one usually has to do in Java EE (and even then there's some left). Anyway, I'll keep you posted on Seam.

Related to my research on this I came across a thread on the Rails mailing list. For christ's sake! It seems that the converted Java-guys are now Ruby-zealots that now find their pleasure in bashing Java EE. That's a shame because the Ruby community was so well-recognized for being friendly.

PS: if you also need to make up your mind about AppFuse and Seam I found Matt Raible's comments helpful (Matt is the project lead of AppFuse)

Wednesday, July 19, 2006

Ruby's classes are dynamic

One way cool feature of Ruby is that classes can be modified dynamically. I got a chance to use this feature today when I needed to change the output format of the Logger class in Rails (the default format is suboptimal IMHO). I simply had to append to environment.rb:

require 'logger'
class Logger
def format_message(severity, timestamp, msg, progname)
"#{severity} #{timestamp} #{msg}\n"

and, voila, the method 'format_message' was modified.

As a sidenote: By the time I write this the example for changing the log format given in the Rails wiki does not work. And what's worse, if you put non-working code into your environment.rb WebBrick will, of course, not come up.

Ruby, Java and rewriting everything

Here's (http://rewrite.rickbradley.com/pages/moving_to_rails/) a nice article on the pros and cons of Ruby as compared to Java development. While it seems to be a bit too biased for my taste it still gives a nice overview and I agree with the points the author has collected.

On the other hand I asked myself if the guy who wrote this really wants to rewrite a large Java-based system in Ruby. If so, that kind of venture reminds me of the efforts to rewrite office suites in Java back in 98 (remember Corel?). It's like "hey, I've got this shiny new tool, now let's re-implement everything". Well, when you've got a hammer everything looks like a nail.

I remember Sun's campaign for "100% pure Java" and really don't think we need need a new dogma "100% pure Ruby". I go for "100% the right tool for the job".

Monday, July 17, 2006

Ruby on Rails, Unicode and Oracle

I was kind of in love with Ruby on Rails but now our relationship has hit the first bump: the infamous UTF-8 issue. In short, Ruby does not support UTF-8 (that's more or less the situation). So Rails does not either. However, my task at hand basically involves CRUD operations on a legacy (yet, UTF-8 enabled) Oracle db including German texts. Well, here's how to do that:

The first stop for Unicode in general is the wiki page on Unicode and Rails: http://wiki.rubyonrails.org/rails/pages/HowToUseUnicodeStrings

The problem with that page is that it covers the setup of Postgres and MySql-based applications, but not Oracle. In order to get that done I left my database.yml as before, but added a line to config/environment.rb:


This sets an environment variable (it also works if you set the variable for your Rails server process externally). I had to figure out the value of this variable by querying the database:

select * from nls_database_parameters;

For the line in environment.rb use the parameters as: (NLS_LANGUAGE)_(NLS_TERRITORY).(NLS_CHARACTERSET)

OK, I'm happy with my Rails again.