Installing RadRails and getting error “Requested operation cannot be performed because it would invalidate the current configuration. See details for more information.”

Up until now, I’ve been using TextMate to create my Ruby on Rails code, but I’ve been missing stuff like autocompletion (I know, a bit more difficult when using dynamic languages, but I really miss it because I also do alot of C# development in Visual Studio).

So.. I decided to try out RadRails that is now named Aptana Studio and the Rails development package installed as a plugin.

After the download and the installation I then tried to install the Rails plugin, but got this strange error:

“Requested operation cannot be performed because it would invalidate the current configuration. See details for more information.” and “ Subclipse Mylar Integration (1.0.1) requires plug-in org.eclipse.mylar.tasks.core (0.9.2)”, or later version.”

After some searching I found the answer here. All you have to do is to un-select the Mylar integration. Although this might be a simple operation for experienced users of Aptana Studio, I was a bit puzzled about this. As someone who just wanted to try out the Rails environment (and I guess I’m not the only one), this seemed like an unnecessary complex installation (at the time I didn’t even now what Mylar was – now Mylyn)

Best of Ruby/Rails in 2007

Thanks to the great work of the Ruby & Rails communities, the year of 2007 saw many exciting new software releases. I have listed a few releases that I would like to point out in particular and expressively thank the developers for:

* Rails 2.0 – A great open-source framework got better in December 2007 with the v2.0 release. In particular I like the improvements in security, test fixtures, http support, performance, debugger and the non-beta addition of ActiveResource by default.

* JRuby 1.0 – By mid 2007 the first proper open-source release of JRuby arrived and it was able to run (most) Rails applications. Very impressive but a bit beta-like (many key API’s are still changing and there is little documentation in the download). Look out for an even better and faster JRuby 1.1 with JIT support in early 2008.

* Ruby 1.9 ( development release) – The proper development release of the next ruby programming language and implementation, version, 1.9, was released in open-source form on 25th December. Not suited for production but gives the community a chance to experiment with, and provide feedback for, many new Ruby features and implementation changes before Ruby 2.0 arrives. My favorite changes are string encodings (for f.x. unicode) and the new YARV virtual machine included in the Ruby 1.9 release.

* RubyGems 1.0.0 – First proper release of RubyGems in December 2007 as open-source. With RubyGems Ruby developers neatly avoids Java’s classpath-hell (*). Basic but cool stuff!

* Active Scaffold 1.1 (almost) – I was not sure if I was going to include this plugin on the list because it is not quite ready (it’s a release candidate last updated in December) and because the old version 1.0 had a bit too many limitations for my taste. However, this open-source Rails plugin is simply too great to leave out. It’s is basically a parallel to “ActiveRecord” but for the front end allowing the developer to implement visual, model-driven CRUD operations quite neatly. You should check it out.

* Commerical IDEs with real Ruby+Rails support arrives in plenty. Proper IDE releases in 2007 includes Netbeans, Aptana (RadRails), IntelliJ, 3rdRail, Ruby In Steel, Komodo IDE etc… At last some real competition to plain old emacs or textmate !

Nb) I use this term for a lack of a more neutral yet common description of the issues with installing jars and configuring classpaths in Java. Java is a great development platform – which I have used proficiently and happily for 10+ years – but classpath/package/module/jar/version management is not it’s strong point

Ruby on Rails’ footprint on Microsoft

This post could also be called how David (DHH) inspired Goliath (MS).

Lately Microsoft has release a number of products and new technologies on the .NET platform. Of course this could just be seen as the way of .NET framework. I mean.. 3.0 and 3.5 are just what comes after 2.0, right?!

Anyway… We’ve had this WebForms framework for doing websites for years now, and MS never really strafed from this strategy even though the Model View Controller pattern has had alot of followers and proven itself on the Java platform. Why should we have an MVC stack when working with .NET?!? Well.. I for one find it really easy to understand. No more advanced event cycles and s… viewstate. No more postback and advanced control design… Well that’s just me. When that is said, I’ve worked almost exclusivly with WebForms since the .NET 1.0 beta was out… Of course there has been some alternatives. In the last post I linked to the MonoRails project. On the frontpage it even says that it is inspired by Ruby on Rails (just see the .rails file extension for the httphandler in all their examples).

As I wrote in the last post, Microsoft are now launching their own MVC stack… Hmmm… Why the sudden change? As with everything Microsoft goes into, they pretty much market it as something completely new and innovative. Just look at the MVC frenzy going on over at: ScottGu and Haacked.com (ok.. also alot of great examples… ).

So is this another MS MVC post… Well not really, I just wanted to sum up some recent stuff out of MS and then leave it up to you to decide if they are not (heavily) inspired by RoR:

MVC

As already discussed, the heart of RoR and a sudden shift from MS.

REST

While not invented by DHH, he spoke (and) … and the world listened. This completely suprised MS. “Does people actually need this silly rest thingy?!”. Well apparently MS is now REST’ing a but with the Astoria Project.

NRuby?

We currently have JRuby and MS recently launched their first dynamic language (IronPython) on the .NET platform. Furthermore there are job ads like this. There is also this open source project however.

O/R Mapping

While RoR uses Martin Fowler’s Active Record pattern for its o/r mapper, Microsoft finally has something they almost can call an o/r mapper. While MS has brought the dynamic expression i c# to the table with the LINQ technology, LINQ for Entities (and SQL) is really too little too late.. I’ve been using NHibernate for years now and with the LINQ for NHibernate I might just stay there :). And also remember that this is not the first o/r mapper MS tries to bring to the market. Who doesn’t remember ObjectSpaces.

While I don’t claim that MS has picked up on o/r mappers after RoR, they certainly comes in handy with their brand new lightweight MVC package.

So…

What do you think?! Is MS inspired by RoR?! I believe they are at least keeping a very big eye on it (Sauron style) but that’s just my to cents?

Shooting yourself in the leg with a bazooka

The colorful title reflects that this posting is about common mistakes done by good but relatively inexperienced software developers. Big mistakes that a developer actually need quite some skills to make. Mistakes that we unfortunately see all too often and we would rather not see much of again (hopefully this blog entry can aid a bit towards that goal):

1. Overly complicated design – Instead of a simple design for a simple project some developers insist on using a impracticable mix of all the newest, fanciest abstractions, design patterns, techniques and advanced language constructs that can possibly be combined in one software solution. All design elements have benefits and drawbacks. Great (experienced) developers know when a particular benefit of an abstraction, pattern, technique or feature outweighs the drawbacks. There is no silver bullet. No design element works well in all situations (just as no rules that you learned in “programming school” are in fact absolute). Developers that get way too eager ends up with one big unmaintainable design mess with the combined drawbacks of all decisions but few if any real benefits remaining…. Remember, a simple design is a beautiful design!
2. Writing too much code – Writing lengthily code with a high maintenance cost by hand when writing such code can be avoided. Much code can be avoided by choosing a more suitable design/architecture, using standard framework/library features (xml serialization is a common example), using techniques such as dynamic reflection or specialized code generation and aspect oriented tools (be careful though).
3. Reinventing the wheel – Some developers think they can write their own code much faster than learning to understand the underlying framework and available libraries. This might in some cases even be true, but when considering overall quality and maintainability (which developers seldom do) reinventing the wheel is almost always a bad idea.
4. Incorrect use of advanced concepts such as multithreading – Some developers use multithreading without the discipline and deep understanding that writing correct, safe multi-threaded code requires. Multithreading can improve the user experience immensely. It is also the answer to scalability nowadays. However, before even considering to use multithreading in your design, make sure to know the theory and features in your environment well. A vague recollection of mutexes and semaphores from school is not good enough. You should also realize that by deciding to use multithreading, you generally need to upgrade on testing, documentation, reviews and quality insurance.