Mark Watson's opinions on Java, Ruby, Lisp, AI, and the Semantic Web

This is worth sharing: easy to follow instructions for installing Rails 3.0pre.

Thanks to Oscar Del Ben!

Yesterday I spent 90 minutes trying a fresh install of Ruby 1.9.1 and Rails 3.0pre with no luck, so thanks to Oscar for his writeup. BTW, I Used Ruby 1.8.7 when following Oscar's directions.

Labels: Ruby Rails

I saw today that the software for the Inoshi social networking web app was re-licensed from AGPL to MIT because the company decided stop trying to monetize this system. I have read the source code to many Rails applications (customer work and sometimes just to learn new techniques). Anyway, this source code base looks clean and well written and makes a good "read" if you are into studying other people's code.

Labels: open source, Ruby Rails

I have everything running under Ruby 1.9.1 on my development system that I need. I may upgrade/migrate my production servers to version 1.9.1 in a week or two if everything continues to go OK.

The last problem that I worked around was a problem in Rails/webrick in dealing with headers+bodies if the bodies contained binary data. I locally patched webrick (my Google groups post).

I can't get mongrel to build with Ruby 1.9.1 so that is an issue since I usually deploy using nginx + mongrel(s) + memcached.

Labels: Ruby, Ruby Rails

I have been converting (on my development system, not in production yet) my Rails applications to work with Ruby 1.9.1. I converted my non-Rails stuff (that I care about) to work with 1.9.x a while ago.

I still use ferret for single process (or single thread) web applications. I have wanted to switch to Sphinx and UltraSphinx for a while and since ferret is not compatible with Ruby 1.9.x because of changes for unicode (RString struct, specifically) I did that conversion late last night. I was pleasantly surprised how simple it was to switch to Sphinx and UltraSphinx: lots of little edits, but quick and easy.

A little more frustrating: the auto_complete Rails plugin does not seem to be Ruby 1.9.x compatible in one of my Rails web apps. I am going through the plugin code, adding debug output, and looking for the problem. The problem may just be specific to my application.

Because of the performance improvements of 1.9.x and because of the long term maintenance overhead of having (eventually) both ruby 1.8.x and ruby 1.9.x applications in deployment, I am willing to spend a lot of effort on the conversion. Another issue is that I expect to have a Ruby book published early summer of 2009 and I would like all the examples to be Ruby 1.9 compatible (and some JRuby specific code).

Labels: Ruby, Ruby Rails

I have some mixed feelings about the integration of Merb and Rails because Merb is a small "micro kernel" type framework that seems just about perfect for projects like light weight web services and web portals.

On the good side of this merger: if Rails becomes more modular and the resulting Rails 3.0 can also be tailored down to 'just what is needed', then this merge should end up being good for developers.

I have just signed a publishing contract for a new Ruby book that has one part on publishing information for consumption by both humans and software agents. After waiting a few months, I will grab early Rails 3.0 builds and write to Rails 3.0. A bit funny because before my holiday break I was deciding whether to use Merb or Rails for this book example.

Labels: Merb, Ruby, Ruby Rails

IntelliJ 8.0 was released yesterday and after installing the Ruby + Rails plugin, IntelliJ is very competitive with the NetBeans for Rails development.

One feature that I particularly like is the jump links in the editor that let you jump from a controller method to the corresponding view template. There are also links from a method to the super class method that is being overridden (if any). There is currently a small bug in the plugin: multiple identical jump links are shown; all work the same.

In some ways it is nice to have Java and Ruby support in one IDE, but there are "Java only" menus shown while working on Rails projects - that is one advantage of the new RubyMine IDE: basically IntelliJ with all Java support removed. At the current time, Rails support for IntelliJ 8.0 seems to be more stable than the prerelease version of RubyMine but it will be interesting to compare the two next year when RubyMine is released as a product.

Labels: IDEs, Ruby, Ruby Rails

First, 2.1 looks like a great update: I have not seen any compatibility problems with 2.0 that could not be instantly fixed. The named_scope (has_finder) changes look good for organizing database queries, and I especially like the way they nest. I have not tried using the new gems dependency functionality yet but this looks very useful when deploying applications to fresh servers.

The news about the large performance boost using MagLev looks interesting, but I will reserve my enthusiasm until the project is further along and I can try running it myself. I find myself reverting from coding in Ruby back to Common Lisp or Java to get around performance issues, so a much faster Ruby runtime environment sounds good. Ruby is such a slow language, that there is plenty of room for improvement.

Labels: Ruby, Ruby Rails

My Spanish4.us web portal is a simple 1 page fits all study center for a Spanish class that my wife and I are taking.

This is something that I love about Ruby on Rails: I had a simple idea and in less than 2 hours I had prototyped the application and deployed it to one of my leased servers. I will add more phrases to the popup translation tool and more general information over the next few weeks.

Labels: Ruby Rails

My most recent DevX article has just been published. This was fun material to write about because after some experimentation I feel like I have my Ruby on Rails development environment and server deployment strategy just right, at least for my needs. I should mention that although I have been professionally writing Ruby on Rails applications for a few years, I have not yet written an application that will not run nicely on a single server using nginx, memcache, and a few mongrels. I set my development.rb environment for my MacBook and my production.rb environment for the Linux server I am deploying to, and svn is the glue that holds everything together. If you are interested in deploying very large scale applications, my article will not be very useful to you.

Labels: NetBeans, Ruby, Ruby Rails

I had to set up a customer's Rails application to run using SSL+HTTPS this morning. Based on a few positive web blog articles I decided to try Igor Sysoev's nginx web server. If you first build and install OpenSSL and the Perl regular expression library, then build nginx with

--with-http_ssl_module
--with-openssl=/OPENSSL_SOURCE_DIR
--with-pcre=/PCRE_SOURCE_DIR

you should be all set to use HTTPS. Clustering mongrel is also simple; I used this nginx.conf file from Brainspl.at as an example and I was set up and running very quickly. Good stuff!

Labels: HTTPS, Mongrel, nginx, Ruby Rails, SSL

I have been using the fine Dojo Javascript library in a web app written in Common Lisp and this morning added Dojo to the code base for a current Rails project. The easiest way to get started using Dojo and Rails is to simply install the developer's version (non-compacted) of dojo.js and the src directory directly in your Rail project's public/javascripts directory, so it looks like this:

public/
  javascripts/
    dojo.js
    src/

Again, the "src" directory contains the dojo source files (besides the dojo.js loader). Dojo will complain about rendered Rails web pages withot HTML and HEAD tags, so I added the following HTML with Dojo setup to the view for my main application controller:

<html>
 <head>
  <title>KBSportal KnowledgeManagement</title>
  <script type="text/javascript">
  djConfig = {isDebug: true}; 
 </script>
 <script src="/javascripts/dojo.js" type="text/javascript"></script>
 <script type="text/javascript">
  dojo.require("dojo.io.*");
  dojo.require("dojo.event.*");
  dojo.require("dojo.widget.TabContainer");
  dojo.require("dojo.widget.LinkPane");
  dojo.require("dojo.widget.ContentPane");
  dojo.require("dojo.widget.LayoutContainer");
  dojo.require("dojo.widget.Checkbox");
 </script>
 <style type="text/css">
  body {
   font-family : sans-serif;
  }
  .dojoTabPaneWrapper {
     padding : 10px 10px 10px 10px;
  }
 </style>
</head>

Dojo is definitely "heavier weight" than the prototype.js Javascript library that is provided with Rails so you may not want to use Dojo for very high traffic sites.

Labels: AJAX, Javascript, Lisp, Ruby Rails

There has been a lot of buzz over Sun hiring Charles Oliver Nutter and Thomas Enebo (two core JRuby developers). Certainly a fine thing for people who use both Java and Ruby. My hope is that they do a lot of work on Tomcat/WEBrick/Rails integration for hybrid JSP/Rails web apps.

I have been using both Ruby and Rails a lot in the last year, and have not missed Java too much. That said, an efficient Rails platform on top of a Hotspot JVM sounds good. My quick experiments with JRuby have not been totally without problems, but with Sun's obvious motivation to get a first rate Ruby environment running on the JVM, I expect things to get better. The smooth integration of Java classes in an interactive Ruby IRB shell environment is fun.

Labels: Ruby, Ruby Rails

While Apache has the advantage of coming pre-installed on leased servers and virtual servers, I am way more enthusiastic about using lighttpd as the front end for Rails applications. For one thing, all you need to do is install the Perl Compatible Regular Expression and then lighttpd, and then Rails will automatically and painlessly use lighttpd in development mode. Installing lighttpd and Rails in production mode is also easier than dealing with Apache (here are good directions).

Although what I am going to say next goes against common Rails wisdom, I would also like to add that it sometimes makes sense to deploy in production mode with WEBrick. Here are a few application specific details that might make you decide, at least for a long while, to just use WEBrick:

• You need your web application to run in a very low memory environment (like a virtual server with a very small amount of allocated memory)
• You expect a small number of concurrent users
• Most content is dynamically generated

If I run a small web application in production mode on WEBrick + Rails it takes about 22MB. If I run the same web application using lighttpd + Rails (using two FCGI processes), I use a total of about 60 MB, but obviously with better performance. (This is a moot point for me because I lease two virtual servers with 192MB and 224 MB of allocated physical memory.)

For a lot of reasons I like to not use a shared server (i.e., share Apache, get a unique port for Rails, etc.): ability to customize the OS, what services to run, choose lighttpd instead of Apache, secondary uses like backup and subversion services, etc. It has been my experience that I get better service (automated backups, restarts after hardware replacements, etc.) using Xen based virtual servers rather than cheap leased servers. You can also usually buy just what you need and reconfigure as needed; one scenario is setting up a low volume web portal using WEBrick + Rails and an inexpensive low memory virtual server. If necessary for either reducing server latency or handling many more concurrent users, just order more allocated memory and switch to using lighttpd + Rails with very little trouble.

I have not tried SwitchTower yet, but the documentation looks good and I am looking forward to trying it out.

Labels: Ruby Rails