Etikettarkiv: rails

Ruby on Rails

Lately I have been playing around with Ruby on Rails, mostly to learn a new technology and also to be inspired on what more modern development environments have to offer.

My main source of information is the excellent Ruby on Rails Tutorial by Michael Hartl, who incidentally have made some interesting work on why Pi is wrong, but that’s another topic.

Anyway, these are my reflections on Ruby on Rails…

My first thought is that Ruby on Rails is an example of where we have come quite far with standardized architectures for a domain that is somewhat large, but nevertheless specific.  Over the years there have been many attempts of creating a standardized environment for a specific type of system where the intention has been that developers should only focus on functionality and design, whereas the more technical and architectural issues are left to implementers of some sort of framework.  My latest post was about model-driven-development and this is one (or actually several) example of this kind of idea.  But mostly these attempts have fallen short in one of two ways.  Either the framework is not detailed enough so that any real applications cannot be created without significant framework tweaking/development which defeats the purpose.  Or the framework has been too specific which makes the sweet-spot for applications developed by it very small and therefore few systems benefit from it.  Of course one could argue that Ruby on Rails is an example of a very specific framework for a specific type of system, but that specific type of system (OLTP systems on the web) is indeed quite large in terms of number of applications currently being developed.

Secondly, Ruby on Rails have many variations on how specific things are done.  I guess that this is more a feature of the language Ruby more than the framework Rails.  This is both good and bad.  It is good because it allows for flexibility in development and also allows for a much larger focus on the readability of code.  But it is also bad because it makes the environment hard to understand for beginners.  If two things that look different are actually examples of how the same problem is solved, this could be quite hard to see and this makes the learning-curve steeper.

Third, on a more personal level, I have not quite yet gotten used to using a non-typed language such as Ruby.  Sometimes the old Java-developer in me have a hard time seeing the things that can, and should, be done by using the type-system more creatively.