stressfree - ruby

Developer paths beyond the Visual Studio juggernaut

David — Mon, 23 Feb 2009 06:33:02 +0000

I have just purchased a Mac laptop and am planning to partition it to run OSX and Ubuntu. Currently I use Microsoft Visual Studio on Windows for development projects. My concern is whether there is an equivalent to Visual Studio and the Microsoft Developer Network (MSDN) on OS X or Ubuntu?

Today I was asked this question, one which is very similar to others I have been asked and answered in the past. In Windows the decisions a developer must make prior to starting coding are relatively simple because it is an environment dominated by Visual Studio. When making the move to OSX or Linux the decisions facing the developer are more complicated because no single company dominates these platforms in the same way Microsoft does Windows.

Outside of this Microsoft’s sphere of influence is a large number of avenues to consider which can significantly influence the productivity and even success, of your software project. The short answer is there no direct equivalent to Visual Studio and MSDN for OSX or Ubuntu, but there are plenty of satisfactory alternatives. In making your decision consider what languages you use now, or are interested in learning in the future. Also identify what general platform you wish to develop for; be it the desktop, server, web or mobile. And always remember whilst none of these discussed paths are wrong, some are more right than others depending on the project.

Mono - The Cross-Platform Windows .Net Framework

For a developer used to Microsoft’s .Net framework and C# or Visual Basic, the easiest place to start is Mono. Mono is an open source implementation of the .Net Common Language Runtime (CLR) which can run on OSX and Linux. With Mono you program using the C# and Visual Basic syntax you are used to, but the compiled binary executes on OSX and Linux.

Unfortunately because the Mono team is a re-implementing an existing framework they are always one step behind what is available on Windows. For example the current 2.2 release supports the language features of version 2.0 of the .Net framework. Consequently you cannot take advantage of the new features in the .Net 3.0 until version 3.0 of Mono is released, which may take a while to materialise. Another thing to keep in mind is that many of the supporting libraries found in Windows .Net maybe different or unavailable in Mono. This is largely due to Mono's cross-platform nature and the fact .Net leverages many Windows-only libraries that will never be ported to other platforms.

Whilst the Mono runtime is very mature and compares well to its Windows equivalent, the development environment and community is not nearly as strong. Compared to Microsoft's Visual Studio the Mono Develop Integrated Development Environment (IDE) is significantly behind in terms of functionality and polish. In time this situation will improve, but for the foreseeable future those making the jump from Visual Studio to Mono Develop will be very disappointed. This is not to say that development in Mono Develop is impossible, it is just that nearly all of Visual Studio's handholding and helper tools are not yet present.

In terms of an online developer community, Mono's is small compared to alternative open source languages such as Java, Ruby, Python and PHP. However Mono developers can benefit from its .Net lineage by leveraging the wealth of MSDN documentation available for C#, Visual Basic and Windows Forms. When doing so it is important to keep in mind the practical differences between Mono and .Net, as whilst the syntax is generally the same, the tools and supporting libraries used may differ substantially.

Java - A Mature Cross-Platform Environment

When talking cross-platform development Java is the ten-thousand pound gorilla in the room. Whilst technically not the first cross-platform programming environment, Sun’s marketing department popularised the concept of "write once, run anywhere" during the 1990s. This was later referred to as “write once, debug everywhere” by Java’s detractors. Like C# and the .Net CLR, Java is both a language and a runtime environment, in fact Microsoft “borrowed” many of Java concepts when developing .Net. The major benefit of Java is that the environment and community around it is very large and mature. Unfortunately this is a double edged sword; on one hand this means there is a wealth of tools and support available, but on the other the options are so varied and complicated the learning curve can be extreme at times.

Like .Net, Java is an excellent environment to learn if you are unsure of what platform, be it desktop, web or mobile, you wish to write applications for. Whilst each platform has its own mannerisms and libraries to learn, many of the underlying concepts and tools can be universally applied. Again this has its own benefits and drawbacks. From a career perspective Java is ubiquitous and no matter what the problem space or context, it can almost certainly be put to use. Unfortunately this diversity has lead to a lot of coding inefficiencies when compared to a language dedicated to a certain problem space or context. The most prominent case of this in recent times has been the meteoric rise in popularity of Ruby on Rails amongst Java developers.

When it comes to Java development tools there are plenty of good ones to choose from, for example Eclipse, NetBeans and IntelliJ. All three compare very favorably to Visual Studio in terms of features and developer community support. Personally I use NetBeans as it has a very good 'out of the box' experience and has excellent support for Java web development and languages such as Ruby and PHP. Eclipse is the most widely used Java IDE and has a vast number of third-party extensions that add a huge amount of functionality. However Eclipse's depth can be problematic as its default installation is minimal and its extensibility often poses more questions than it answers. As a result setting up your ideal development environment can take some time. IntelliJ, unlike Eclipse and Netbeans, is not open source and requires the purchase of a software license. This initial cost is outweighed in a commercial environment by its teamwork functionality and support provided. However in a single developer environment justifying this purchase when both Eclipse and NetBeans are free and so powerful is in my view much more difficult.

Other Languages on the Java VM

Whilst it has always been technically possible to run languages other than Java on the Java Virtual Machine (VM), it is only recently that this has become mainstream. Now a slew of modern, popular languages can be used within the Java VM such as JRuby (Ruby), Jython (Python), Rhino (Javascript), Groovy, Scala and Clojure. This rapid growth in JVM compatible languages has in turn been reflected in multiple language support within the Java IDEs. As a consequence some of the best IDEs for writing Ruby, Python and Javascript code are now Eclipse, Netbeans and IntelliJ.

In a similar way to .Net and Mono, the difference between the Java version of a language and its native equivalent (e.g. JRuby <=> Ruby) is its ability to leverage supporting libraries. Generally the majority of the language syntax is the same, but whilst Ruby can leverage a system’s C libraries, JRuby has access to those within the Java VM. In these cases this can lead to significant coding differences, but if you write an application using only core Ruby libraries there is a very strong chance it will run unmodified on both the Ruby and JRuby runtime environments.

Objective-C, Cocoa and Carbon

Writing cross-platform is a nice idea, but there are considerable benefits to be gained by targeting a specific platform. Objective-C is not an OSX specific language, but it has gained notoriety thanks to its close relationship to the OSX Cocoa framework and its associated user interface functionality.

Whilst the Cocoa framework is available on a variety of platforms, it is most well known for its OSX implementation where Apple has injected a considerable amount of additional functionality. Unfortunately much of this functionality relies on libraries present only within OSX, and as a result the cross-platform, open source implementation of Cocoa, GNUstep, is viewed by many as its poor cousin. For a good discussion of Cocoa, OSX and GNUstep checkout the interview with a couple of GNUstep developers on FLOSS Weekly.

The other significant development framework on OSX is Carbon, but this is primarily intended as a compatibility library between the "classic" MacOS and OSX. Any new development should be undertaken in Cocoa simply because this is where all the action is. Plus, if Apple stays true to form, support for Carbon will cease in the not too distant future.

As far as development environments go the OSX-only XCode from Apple is far and away the best IDE for developing in Objective-C and Cocoa. XCode and its accompanying tools are shipped free as part of OSX, plus there is a large developer community and Apple Developer Connection (ADC) to call on for support. Paid membership to ADC can be expensive depending on your needs, but like MSDN this grants you improved access to Apple’s internal development processes and pre-release software. Unfortunately on other platforms such as Ubuntu the tooling for Cocoa and Objective-C is not so strong. GNUstep has the ProjectCenter IDE, but this does not compare well to Visual Studio, Java IDEs or XCode in terms of its functionality or polish.

Life without an IDE - Text Editors and Command Lines

Whilst it may sound strange for someone used to operating within Visual Studio's padded walls, some of the best cross-platform development environments you can create yourself using a text editor and command line tools. Unlike C# and Java, languages such as Ruby and Python have grown to where they are now without significant support from complex IDEs. Learning a new language using these limited tools can also prove beneficial because you are not shielded from a language’s complexities by a "helpful" IDE. The end result is you gain a much better understanding of a language and its runtime environment than you would if you were to continually rely on an IDE’s wizards.

When using such an approach it is easy to move between different operating systems because each has an excellent suite of text editors. On OSX this choice ranges from the free TextWrangler through to the moderately expensive TextMate. As far as Linux goes it really depends on your operating environment (Gnome, KDE, etc) and preference for GUI or command line tools. Needless to say like most things open source, there are extensive and intense debates about the pros and cons of various text editors.

Version Control is the Key

No matter what language or development approach you choose the most important to setup and use is some form of version control. Systems like Subversion or Git make it easy for developers to move between OSX, Linux and Windows without having to worry about shared filesystems. There some very good GUI tools for version control management, for example the tools built into Java IDEs and standalone applications such as Versions (OSX only) and RapidSVN.

Version control is especially important in cross-platform development because no matter how hard you try, chances are you will inadvertently introduce a bug that affects one or more of your target platforms. When this happens it is important that you can quickly find out what was changed, or what changed on your target platform, and work up a patch. This may involve reverting to a previous version of your code, or creating a platform specific branch.

Conclusion

Unlike the .Net/Visual Studio dominated world of Windows the choices available to a developer on OSX and Linux are many and varied. There is certainly no right answer, but more often than not there is one language that fits the problem space or context you are working in better than others. Personally I prefer the breadth and depth of the Java development world. Not only is arguably the most cross-platform, but it also has a strong developer community and tooling that is on par with, and at times better than, Visual Studio.

Unfortunately if it is a desktop application you wish to develop, Java is in a state of flux until JavaFX gains more adoption and is released on platforms other than Windows. With this in mind the functionality offered from Mono and its WinForms implementation is hard to pass by, even if the tooling support available in Mono Develop is immature at present.

Perhaps the most difficult development decisions arise if you wish to develop for mobile devices. In terms of a lucrative market the iPhone with its Cocoa framework is hard to ignore. However a version of Java, be it Micro Edition or Dalvik, is available on most other mobile devices. Fortunately I am not a developer in this space, but if I were I would probably take the iPhone route given its proven market. This being said I would keep a close eye on the growth of Android as its openness may prove the winner in the long-term.

Interesting moves on the JavaVM front

David — Sat, 20 May 2006 07:22:38 +0000

Java One is turning out to be quite interesting this year. Not only has the Java license been changed to allow for easier distribution in Linux channels, but there is also a lot of buzz about coding in different languages for the JavaVM. The most tantalizing from a business perspective is Sun's commitment to get Visual Basic running within the JavaVM. Whilst it will not be practical to get Visual Basic applications written specifically for Windows frameworks running, (that is what Mono is for) it still will be interesting to see whether this significantly grows the Java (as a concept rather than a language) developer community. Even though Visual Basic may be ported across the fact it won't be tightly integrated into Windows like traditional Visual Basic it will more than likely not encourage a mass-migration of low-end, practical developers as some would hope. Still it will be nice to be able to get basic software written in by someone who only knows Visual Basic and have it able to run on any platform that supports the JavaVM.

More interesting from my perspective was the progress the JRuby project has made in getting the Ruby language ported to the JavaVM. Not only in the Ruby language over but even the Rails framework is beginning to run under Java. Admittedly it is a lot slower than the C version but from a deployment perspective it is very interesting as it would permit Ruby and Java applications to run and scale within the same JavaVM application engine.

java
ruby

Thomas Fuchs AJAX presentation & Google's AJAX API

David — Wed, 17 May 2006 20:42:22 +0000

Thomas Fuchs, the guy behind script.aculo.us recently did a presentation in San Francisco about AJAX that looked pretty interesting. He has is slide show online in PDF format here. Associated notes made during the presentation have been put online by the guys at Ajaxian.

Probably the coolest piece of information I did not know about was the link to a very cool window library for Prototype/script.aculo.us enhanced window objects.

At about the same time Google was announcing the immediate availability of their Google AJAX Toolkit for Java. It is interesting in that rather than acting as a HTML embedded AJAX library like Prototype/script.aculo.us is with Ruby on Rails this API seems targetted at Java coders used to writing Swing/AWT (desktop) application interfaces. This does not appeal to me much, I prefer the HTML/controller level coding of Ruby on Rails than writing a completely abstracted user interface in Java. Still the toolset provides a means by which a great many traditional desktop application programmers can start writing for the Internet using a toolset that is very similar to those available on the desktop.

Intel OSX is all go

David — Sun, 29 Jan 2006 09:26:55 +0000

Over the weekend I finished the transition from my PowerBook to the Intel based iMac as my primary development platform. Rather than use the PowerPC only Flock or stick with Safari I have started using an unofficical Intel compiled version of Firefox. Performance is excellent and there are no issues with reliability, Java or Flash.

Installing Rails and ImageMagick turned out to be very straightforward thanks to DarwinPorts, the Rails on OSX wiki and the ImageMagick on OSX howto. Currently there is no Intel compiled DarwinPorts binary but fortunately it compiled from source without issue (once the Apple Developer Tools were installed).
In the process I found a nice Eclipse plugin for Ruby on Rails named RadRails.

The only non-Intel development specific applications I am waiting for are Transmit (FTP/SFTP) and NaviCat (MySQL manager). Apparently a Universal Transmit should ship soon whilst NaviCat maybe a long way away. Fortunately both applications run okay through Rosetta.

A name picked and prototype development begins

David — Tue, 17 Jan 2006 10:52:02 +0000

After coming back from the Christmas/New Years break I have started putting together the prototype system for use in the revised BBsC303 Digital Craft course. The paper I am writing for the CAADRIA conference will be describing the methodology and once that is complete (this Friday) I will be putting a more in depth breakdown of the proposed concept online. In the meantime I have picked a name to call the system by: Reasonate

Its a play on resonate and reason because the two ideas are fairly closely tied to my concept. 'Resonate' in the sense that there is a continual reverberation of ideas within a project until some harmony is reached and 'reason' because at the end of the day it is hoped people will turn to the system to understand why decisions were made (pretty clever eh). I have bought the reasonate.co.nz domain name but unfortunately someone has 'parked' the reasonate.com address space (damn GoDaddy and their $1.99 domain name reservations). There is no logo yet but at least there is a moniker to refer to it by.

An early prototype of Reasonate (click to enlarge)

For the BBsC303 prototype I have invented two imaginary design firms that the students will be working under, Red Light Designs and Black & Blue Architecture (which gives us a red team and a blue team sort of like Survivor). I am writing the application in Ruby on Rails which is a bit of a learning experience as its my first real Rails app. I must say it is a whole lot better than writing in Java, even after a week I have made two or three times as much progress as what it would have taken in Java. I will be using Java a little for the document indexing side of things (using LUIS, a Lucence front-end API) but apart from that everything will be in Rails with a number of snappy AJAX/CSS tricks to get things looking really slick.

37signals: Basecamp

David — Sat, 14 Jan 2006 03:14:48 +0000

I had heard the name 37signals before as they are a leading Ruby on Rails development house but I had never really thought of checking out what they were up to until this week. It turns out their Basecamp product is a very tidy project management tool with a rather large following. Feature-wise it is fairly simple and is completely centralised around the 37signals server farm (no local Intranet version). Rather than focus on email processes 37signals picks up on the blog model of posts and comments with a central (unversioned?) file repository. It appears their target audience is distributed Web developers who need a simple way to manage the comings and goings of a small group of workers.

Basecamp from 37signals (click to enlarge)

Installing RMagic for Ruby on Rails on OSX Tiger

David — Fri, 13 Jan 2006 23:53:49 +0000

Installing RMagic for Ruby on OSX can be a little tricky especially considering running 'gem install RMagic' usually results in a bunch of error messages. There is a couple of ways to get this installed without too much fuss. One way is to follow the how-to on the RMagic site.

This how-to is a little long and requires installation of many Darwin ports. Fortunately however there is a self contained installer for OSX available called Locomotive. It bundles Ruby, Rails, RMagic and a bunch of other tools into an easy installer.

If you are like me and like the ability to track and update your packages you may prefer using Fink.

After installing Fink (and probably FinkCommander) compile and install imagemagick-nox and imagemagick-nox-dev plus all their dependencies from source (to get the latest versions). Choosing the -nox packages gets around a few RMagic compile errors related to X image functions tied into Xorg.

Once imagemagick-nox is compiled and installed download the source tar for RMagick.
Uncompress the source to a location, change into that directory and run:

LDFLAGS=-L/sw/lib ./configure (enter)
[where /sw/lib is the path to your fink library directory]

make (enter)

make install (enter)

If everything goes to plan you should have a working Ruby/RMagic implementation ready to use in your Rails' applications.

Getting Rails up and Running with Apache2 on SUSE

David — Wed, 09 Nov 2005 05:23:04 +0000

After some Googl'ing, reading and playing about I have got Ruby on Rails running on my SuSE 9.2 server. The process was made difficult by the need to compile quite a few different pieces of software from source and configure mod_fastcgi (which has not been worked on for a while). If you are stuck on this subject take a look at the tutorial here:

https://www.stress-free.co.nz/node/163/59/

Rails, Apache2 and SUSE

David — Wed, 09 Nov 2005 05:14:43 +0000

Getting Rails up and running on Apache2 on SUSE is takes a little work as at the moment Rails is not part of the the SUSE software updates network. This means you must build Rails (and Ruby if using SuSE < 9.3) and the FastCGI development kit from source.

1. First off it you need Ruby 1.8.2 (or greater) to run Rails. If you have a version less than this you will need to compile and install Ruby from source.
Install GCC, make, the C devel, zlib and zlib-devel packages using Yast.
Download the latest version of Ruby from http://www.ruby-lang.org/
Untar the source file to /usr/local/src, compile and install (as root or sudo):

tar -xzf ruby-1.8.3.tar.gz
cd ruby-1.8.3
./configure
make
make test
make install

Once completed this will set Ruby up on your system (by default into /usr/local/bin). Create a link in /usr/bin to ruby.

ln -s /usr/local/bin/ruby /usr/bin/ruby

2. Install gems (a ruby package manager). Download gems from http://rubyforge.org/projects/rubygems/
Untar the source code into /usr/local/src, compile and install (as root or sudo):

tar -xzf rubygems-0.8.11.tgz
cd rubygems-0.8.11
./configure
make
make install

This will install gems into /usr/local/bin. Create a link in /usr/bin

ln -s /usr/local/bin/gem /usr/bin/gem

3. With ruby and gems installed install Rails:

gem install rails --include-dependencies

4. With Rails installed create a test project and test the Rails WebBrick server.

5. Using Yast install the mod_fastcgi package for integrating Rails into Apache2.

6. From http://www.fastcgi.com/ download the FastCGI development package. Untar the source into /usr/local/src and compile:

tar -xzf fcgi-2.4.0.tar.gz
cd fcgi-2.4.0
./configure
make install

7. Now install the fcgi component for ruby using gem.

gem install fcgi -- --with-fcgi-dir=/usr/local/

8. Edit /etc/sysconfig/apache2 and in the modules section add fastcgi to the list of modules loaded by Apache when it starts.

9. Create a new virtualhost in Apache for your Rails application. Use the following template as an example:

<VirtualHost *:80>
        ServerName rails.test.domain
        AddHandler fastcgi-script .fcgi
        AddHandler cgi-script .cgi
        DocumentRoot /srv/www/rails/RailsTestProject/public
        <Directory /srv/www/rails/RailsTestProject/public>
                RewriteEngine On
                RewriteRule ^$ index.html [QSA]
                RewriteRule ^([^.]+)$ $1.html [QSA]
                RewriteCond %{REQUEST_FILENAME} !-f
                RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
                ErrorDocument 500 "<h2>Application error</h2>Rails application failed to start properly"
                Options ExecCGI FollowSymLinks
                AllowOverride all
                Allow from all
           Order allow,deny
        </Directory>
</VirtualHost>

10. Restart Apache and test the virtual host. Hopefully fastcgi should be working with Rails to display your new application.

Ruby on Rails in OSX Tiger

David — Thu, 03 Nov 2005 10:26:06 +0000

At the moment I am learning Ruby on Rails (I must say it is very impressive). Unfortunately getting it setup in OSX Tiger was not as straightforward as one would hope.
Although Apple have included Ruby with Tiger there are a few things that do not work right.
For my own future reference (and for anyone else that is interested) this is how I got it working with MySQL correctly on OSX Tiger and MySQL's own OSX binaries.

Follow the install intructions found here:
Rolling with Ruby on Rails on Mac OS X Tiger

Once installed open a Terminal window and enter the following:

sudo sh
(enter the admin password)

curl -O rufy.com/fix-ruby-tiger.sh; sh fix-ruby-tiger.sh

gem install mysql -- --with-mysql-lib=/usr/local/lib/mysql --with-mysql-include=/usr/local/include

exit

This should fix any Ruby issues and compile a fully functional Ruby MySQL driver ready for you to use.

Ruby on Rails 15 minute Intro video

David — Mon, 10 Oct 2005 11:33:15 +0000

This introduction video for Ruby on Rails is very impressive. Even if you don't know anything about programming it comes across as being very easy. If you are used to programming in Java like me watching this made me very, very jealous....

Ruby on Rails 15 minute introduction video