Mad Marmot

Switching from mongrel to mod_rails.

Luke Ludwig — Sun, 13 Apr 2008 09:40:00 -0500

A mod_rails for Apache, also called Phusion Passenger, has been released. I switched this blogs deployment from using mongrel to using mod_rails in less than 20 minutes without any problems. The installation procedure is dead simple. I had to look up one thing in the user's guide, how to serve the rails app off a sub path of the domain (lukeludwig.com/blog), and I found it quickly. Overall I am extremely impressed and am curious how Passenger will do with higher traffic production sites.

Previously I was running this blog on a single mongrel instance, which is all that is needed due to the low traffic on this site. But lets just say that I wrote an article with great content and it got digged, causing traffic to spike like crazy for a few days. The single mongrel would quickly be overwhelmed and my site would be for the most part, unusuable, until I noticed and was able to start up a whole mongrel cluster of say a dozen mongrels. My server has 1 GB of RAM, most of which goes unused. Passenger is able to handle the number of rails instances in a much nicer manner. From a configuration perspective, I set the RailsMaxPoolSize to 12 and I'm done. Passenger will run as many rails instances as it needs depending on load, up to the max of 12. When traffic slows down, it kills the idle rails instances to conserve memory. Great stuff.

Use pagination to save memory when iterating over a lot of ActiveRecord objects.

Luke Ludwig — Sat, 16 Feb 2008 22:57:00 -0600

It is very easy to consume a ton of memory when using ActiveRecord's find(:all) method. When transitioning the Team Sport Tech rails app from using file column to attachment_fu I wrote a migration to convert all of the photos we had to the new database format and the new location on disk. Without thinking I wrote code like this:

    Photo.find(:all).each do |photo|
      # conversion commands
      .
      .
    end

I didn't notice any issues executing this on my laptop which has 2 GB of RAM, but when I went to run this migration on our staging server over at Engine Yard I had problems. Our staging server only has 640 MB of RAM. Our database has over 100,000 photos. That is an array with 100,000 ActiveRecord objects in memory all at once. As the migration executed on the staging server I could see that the rake task was using all available RAM and it was paging like crazy, utilizing 600 MB of virtual memory from disk. The cpu fluctuated between 0 and 1 percent of utilization due to the paging. If adequate memory was available this migration would take around 10 minutes and the cpu would be working like crazy. I did a few other things for awhile and came back to this migration 2 hours later. Still working and it probably had a long ways yet to go.

While the memory limitation on the staging server isn't that important, the real question was how the production server with 1024 MB of RAM would handle the migration since the live app has to be down for maintenance when we roll this out. Instead of wondering I decided to fix the real problem, which was the stupid code I wrote to load all of the photos in memory for iteration. I quickly realized that the problem was already solved for me in the form of pagination. Pagination is usually thought of as a way to display N number of items to the user on a web page and providing links to move to the "Next" or "Previous" pages. When doing this the pagination code smartly loads only the ActiveRecord objects that are needed for the current page in memory, which is exactly the behavior I needed.

We recently switched from using the classic rails pagination to the newer will_paginate plugin. Since I knew I would need to use will_paginate in this manner in other migrations, and possibly in actual application code, I wrote this iterator for reuse:

    def apply_to_all(klass, per_page)
      objects = klass.paginate :page => 1, :per_page => per_page
      num_pages = objects.page_count

total_entries = objects.total_entries

      for page in 1 .. num_pages
        objects = klass.paginate(:page => page, :per_page => per_page, :total_entries => total_entries)
        objects.each do |object|
          yield object
        end
      end
    end

So I changed my migration code to look like this:

    apply_to_all(Photo, 500) do |photo|
      # conversion commands
      .
      .
    end

A key thing to note is the use of total_entries. Each time the paginate method is called, 2 sql queries are performed. One to get the records, and one to count how many records there are in total. This counting query can be very expensive when there are a lot of records, and if you provide the total_entries option to the paginate method the counting query will be skipped. While I chose to reuse the will_paginate plugin here, it wouldn't be very difficult to rewrite the above code without it by using LIMIT with an offset, which is how the will_paginate plugin works. Additionally it may be useful to add a third parameter to the apply_to_all method called options, which is simply passed onto the paginate method allowing such things as conditions or includes to be execute in the paginate sql query.

So now the migration code loads 500 Photo objects in memory at once. I ran this migration on the staging server and it barely used any RAM and executed in the expected 10 minutes. This short piece of code is a prime example of why I enjoy programming in ruby.

RMagick has memory problems. MiniMagick with Attachment_Fu is slowwww. Go ImageScience.

Luke Ludwig — Sat, 16 Feb 2008 18:35:00 -0600

Most Rails applications have to deal with resizing uploaded images for the creation of thumbnails. The main choices include RMagick, MiniMagick, or ImageScience, all of which come packaged as gems. Alternatively you can write your own which really isn't that difficult. So which one should you use? First I would recommend not writing your own, because it is really nice to take advantage of one of the very fine attachment plugins that are available. File column is the old standby rails attachment plugin, but it uses RMagick. Attachment_Fu is more flexible since you have the choice of using RMagick, MiniMagick, or ImageScience and can switch between them easily. At TeamSportTech where I work I recently transitioned our relatively large rails application from using file column and RMagick to using attachment_fu and ImageScience. Originally I was planning on using MiniMagick instead of ImageScience, but it turns out that MiniMagick is quite slow. The following timing results are on my Mac Book when running in development mode, and include uploading a single 3.4 MB jpeg which is resized down to 4 different sizes. MiniMagick consistently took 18 seconds to accomplish this, RMagick 7 seconds, and ImageScience 6 seconds. This doesn't accurately represent a production environment, but I do believe it is a fair comparison. Note that the time to upload is not a factor since this was done entirely on my local computer.

So why is MiniMagick with attachment_fu so slow? And why not use RMagick? RMagick and MiniMagick use the well known ImageMagick C libraries. RMagick works by providing API ruby bindings to the ImageMagick libraries, which means that RMagick operates within the ruby process. It is well documented that RMagick consumes a lot of memory and has memory leaks as well. See Craig Ambrose's article and a Mephisto article. It appears like RMagick2 provides better memory management.

Even if you have memory to spare, the more memory your Mongrels utilize the more garbage collection that will have to be done, which eventually will bog down the Mongrels. MiniMagick solves this memory problem by utilizing the shell commands provided by ImageMagick, which means all image manipulations are done in separate processes outside the ruby process' memory space. ImageScience is a different beast altogether since it uses the FreeImage library instead of ImageMagick, and it is more similar to RMagick in that it runs inside the ruby process. MiniMagick has extra overhead to start up a separate process for each ImageMagick command it executes. It also has extra disk overhead since it must operate on images on the filesystem instead of images loaded in memory.

I put a print out in the MiniMagick source to track all the ImageMagick commands that MiniMagick runs to accomplish this single upload with 4 resizing operations. Here is the output with timing in the order that they were executed:

1.421884 seconds:     identify "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"
0.594993 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"
0.592467 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"

0.602928 seconds:     identify "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-1"
0.594078 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-1"
0.584066 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-1"
1.444892 seconds:     mogrify -resize "240x240" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-1"
0.024799 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-1"
0.019388 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-1"

0.593593 seconds:     identify "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"
0.580201 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"
0.572714 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"
0.590181 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"
0.600532 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"
1.396459 seconds:     mogrify -shave "648x0" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"
0.973819 seconds:     mogrify -resize "75x75!" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"
0.016706 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"
0.016919 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-2"

0.594606 seconds:     identify "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-3"
0.690731 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-3"
0.592638 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-3"
1.513243 seconds:     mogrify -resize "550x550" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-3"
0.028199 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-3"
0.029103 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-3"

0.610143 seconds:     identify "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"
0.593422 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"
0.638836 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"
1.777569 seconds:     mogrify -resize "1024x1024" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"
0.089828 seconds:     identify -format "%w\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"
0.057866 seconds:     identify -format "%h\\n" "/var/folders/UE/UE7FB01vFkmqEPkTei2ABk+++TI/-Tmp-/minimagick15344-0"

So as you can see, MiniMagick executed 30 separate shell commands. You can also see the temporary files on disk that it had to create to do these operations. To be fair, it is more correct to say that Attachment Fu executed 30 MiniMagick commands. I was curious why so many identify commands were needed. Each of the identify -format commands returns either the width (%w) or height (%h) of the image, which Attachment Fu stores in the database. This is very wasteful, because the initial identify command done for each resizing operation does include the width and height in the output, which should be parsed to save time. And for some reason notice that there are 10 identify commands to retrieve the width and 10 for the height, even though there are only 5 images involved (the original and 4 resized images). I don't know why this would be necessary and haven't checked the source to find out. Instead of pursuing these weird findings of how Attachment Fu uses MiniMagick, I decided to switch to Image Science. It is fast and is not a hog on memory.

Running ar_sendmail with monit

Luke Ludwig — Wed, 05 Dec 2007 19:35:00 -0600

Sending email from a web application, especially blast emails to a lot of people, can take a lot of time. Generally you don't want the user to wait until all the emails have been handed off to the smtp server. You also probably don't want to tie up an entire mongrel with sending mail. The ar_mailer gem solves this problem in excellent fashion, by saving pending emails to the database and having a separate ruby daemon process periodically check the database and send emails. I recently set up one of our rails apps at work to use ar_mailer. Configuring it to use ar_mailer was incredibly easy, but it was tricky to get the ar_sendmail ruby daemon process to run under monit. On our production servers which we have hosted at Engine Yard, we want every process that our application depends on to be monitored by monit.

The primary feature that ar_sendmail lacks to play nice with monit is the ability to leave a pid file after it starts up and to remove it when the process exits. This has already been pointed out on rubyforge as a feature request. Here is what I did to get ar_sendmail working under monit: (ar_mailer 1.3.1)

0) Find the file ar_sendmail.rb on your system and open it for editing.

For me this was at /usr/local/lib/ruby/gems/1.8/gems/ar_mailer-1.3.1/lib/action_mailer/. Another common location is /usr/lib/ruby/gems/1.8/gems/ar_mailer-1.3.1/lib/action_mailer/

1) Create a class variable to store the pid file path in and a method to remove the pid file.

I put this just below "attr_accessor :failed_auth_count"

  @@pid_file = nil

  def self.remove_pid_file
    FileUtils.rm(@@pid_file) if @@pid_file
  end

2) Modify the self.run method in ar_sendmail.rb to create a pid file, and to not start up if an ar_sendmail process is already running

    if options[:Daemon] then 
      require 'webrick/server'       
      @@pid_file = "#{options[:Chdir]}/log/ar_mailer.pid"            
      if File.exists? @@pid_file             
        # check to see if process is actually running
        pid = ''
        File.open(@@pid_file, 'r') {|f| pid = f.read.chomp }             
        if system("ps -p #{pid} | grep #{pid}") # returns true if process is running, o.w. false
          $stderr.puts "Warning: The pid file #{@@pid_file} exists and ar_sendmail is running. Shutting down."         
          exit
        else
          # not running, so remove existing pid file and continue
          self.remove_pid_file
          log "ar_sendmail is not running. Removing existing pid file and starting up..."          
        end
      end
      WEBrick::Daemon.start  
      File.open(@@pid_file, 'w') {|f| f.write("#{Process.pid}\n")}    
    end

If the pid file already exists, this code will check to see if the process is actually running. If it is then it will exit, otherwise it will remove the file and continue. This is useful for when the process dies ungracefully somehow (server crashes, killed with -9, .etc), in which case it will leave a pid file behind. Note that this differs from the code suggested on the rubyforge feature request, not only in that it checks the existence of the pid file, but it references options[:Chdir] instead of Dir.pwd in order to be compatible with the -c and --chdir ar_sendmail option.

3) Modify the do_exit method in ar_sendmail.rb to remove the pid file

  def do_exit
    log "caught signal, shutting down and removing pid file"
    self.remove_pid_file
    exit
  end

4) Create the monit file /etc/monit.d/ar_sendmail.teamsport.monitrc

check process ar_sendmail_teamsport
  with pidfile /data/teamsport/current/log/ar_mailer.pid
  start program = "/usr/bin/ar_sendmail -d -e production -c /data/teamsport/current/" as uid teamsport and gid teamsport
  stop program = "/usr/local/bin/stop_ar_sendmail" as uid teamsport and gid teamsport
  if totalmem is greater than 65.0 MB for 2 cycles then restart      # eating up memory?
  if loadavg(5min) greater than 10 for 8 cycles then restart          # bad, bad, bad
  if 20 restarts within 20 cycles then timeout                        # something is wrong, call the sys-admin
  group ar_sendmail

Note that I am using a simple shell script script called stop_ar_sendmail to stop the ar_sendmail process. ar_sendmail has signal handlers for SIGINT and SIGTERM so we should use these signals to kill it, which will cause the do_exit method to be triggered. The stop_ar_sendmail script looks like this:

#!/bin/bash
kill -2 `cat /data/teamsport/current/log/ar_mailer.pid`

Originally I tried putting the contents of this shell script in the .montrc file like this:

stop program = "/bin/kill -2 `cat /data/teamsport/current/log/ar_mailer.pid`" as uid teamsport and gid teamsport

This however does not work, since apparently monit doesn't know what to do with the backticks. Alternatively you could use some sort of grep and kill script, such as pkill, to stop the ar_sendmail process. Ideally in the future, ar_sendmail will support some sort of stop command in the same manner as mongrel so that you could run "ar_sendmail stop" to stop it.

Once you have this all setup you can control ar_sendmail via monit. When creating the ar_sendmail.teamsport.monitrc file, make sure you change "teamsport" to the user that you want to run the process as. Then do a "sudo monit reload" and monit should see that ar_sendmail is not running and will start it for you. To make sure everything is working correctly try "sudo monit stop ar_sendmail_teamsport" and "sudo monit start ar_sendmail_teamsport" (replacing "teamsport" with the appropriate user name).

Other than not working well with monit out of the box, the only other issue I have with ar_sendmail is the memory footprint, which is dependent to some degree on your rails app. The ar_sendmail process for my app runs at around 50 MB, and just to send mail! I assume this is due to the fact that ar_sendmail loads the rails app's environment.rb file. The environment.rb file runs the boot.rb file, which bootstraps and initializes the entire rails app. Additionally, our environment.rb has several other plugins required inside of it. I think the environment.rb file is loaded primarily just to get at the ActiveMailer smtp_settings, which is a slick way to allow for easy integration of ar_mailer with minimal changes to your existing rails app. Many people wouldn't think twice about 50 MB, but rails hosts charge quite a bit for RAM. I can definitely envision a slimmed down ar_sendmail that doesn't load the rails app's environment.rb file, but it seems almost impossible to do this without making integration with existing rails apps more difficult.

How to add a new column to Rails' sessions

Luke Ludwig — Mon, 26 Nov 2007 17:59:00 -0600

For a rails app at work we store user access privileges in the session. This is done as an optimization to avoid an extra sql query that would need to be done for every page view to determine if the user has edit privileges. Security-minded people may see this as a security hole. For this application I don't see this as a big deal. Its not like our rails app is controlling the launch of nuclear missiles.

The problem is that when an admin goes to modify the user access privileges for someone, the changes won't take affect until the user next logs in since the user access privileges are stored in the session. So if the user is already logged in this is a problem. They will have to log out and log back in for the changes to take affect. The solution to this problem is to modify the session of the user who's access privileges were modified.

To do this we need to add a user_id column to the sessions table. This can be done like any other migration. The tricky part is accessing the user_id column. We will want to set the user_id of the session when someone logs in. This of course will not work:

session.user_id = @user.id

The session we are so familiar with is not like other ActiveRecord objects. If you are using ActiveRecordStore for your session storage (the rails built-in database session storage mechanism), this is easy. For ActiveRecordStore, the session has a model attribute allowing you to access the ActiveRecord session object. First you need to make a session model class which extends ActiveRecord. Mine looked lke this:

class Session < ActiveRecord::Base

end

Then inside your "login" action you can do:

session.model.user_id = @user.id

Then just rely on the automatic session saving built into rails to save the user_id to the database.

If you are using SqlSessionStore, you don't have access to the model attribute. Instead you can do this to set the user_id:

my_session = Session.find_by_session_id(session.session_id)
my_session.update_attribute(:user_id, current_user.id)

Now presumably at some point in your application you will need to access and make use of the user_id column. For me this is when the user access privileges are modified. Since we created a session.rb model class, we can use the built in rails find method to find all sessions for the user.

sessions = Session.find(:all, :conditions => "user_id = #{user.id}", :select => "session_id")

To take advantage of the built-in session data marshaling in rails, we need to access the session like this:

user_session = CGI::Session::ActiveRecordStore::Session.find_by_session_id(sess.session_id)

Then we can set a session value using the data attribute and save the session off. Here is the full code for updating the sessions:

        sessions.each do |sess|
        user_session = CGI::Session::ActiveRecordStore::Session.find_by_session_id(sess.session_id)
        user_session.data[:access_privileges] = new_access_privileges
        user_session.save
        end

A Virus the World Needs : How to Topple the Reign of Internet Explorer

Luke Ludwig — Sat, 20 Oct 2007 17:39:00 -0500

For my first project at my new job, a Ruby on Rails position with Team Sport Technologies, I implemented a table builder, which allows a user to create simple tables using their browser without writing HTML or any other special markup. My JavaScript was a bit rusty, so it took a few days before I had the table builder complete. I was working with a brand new Mac Pro without Parallels installed, and so I had yet to try the table builder in Internet Explorer, but it worked perfectly in Firefox, Safari, and Opera. I soon found out that it failed miserably in Internet Explorer. I was assuming it would be a quick fix, but it turned out that Microsoft's implementation of the DOM Event model is so messed up that I had to redo the entire implementation using a different approach.

Internet Explorer is a source of constant frustration and wasted hours of web developers across the world. All other web browsers follow standards set by the W3C World Wide Web Consortium describing how web browsers should interpret Cascading Style Sheets, JavaScript, and the Document Object Model. Books on these subjects dedicate dozens of pages to detailing the crazy hacks that programmers need to use to get their web sites to operate in Internet Explorer. Microsoft breaks many of these standards intentionally, and can get away with it simply due to having a majority of the browser market.

Wikipedia has an interesting chart on web browser usage which shows that in 2004 Internet Explorer had 95% of the market. According to OneStat.com, in June of 2007 approximately 85% of people browsing the web worldwide use Internet Explorer. In recent years Firefox has been gaining users from Internet Explorer, but I don't think we can expect this trend to continue. The typical non-technical person wants a simple and familiar web browser. Isn't Firefox simple? Of course, but it is not familiar. The refresh button looks different. Everything looks different. Most people dislike learning how to use new software. It doesn't matter if the unfamiliar product is clearly superior.

So this leaves us web developers in a disgruntled state, forced to ensure our code works with a crappy piece of software that everyone uses. We can expect this as long as Microsoft and Windows dominates the world of computers. Windows only ships with Internet Explorer and people just don't want to download and install a new browser, no matter how easy it is. So what can we do to topple the reign of Internet Explorer? I can imagine a program which automatically installs Firefox, pre-loaded with an Internet Explorer theme so it feels familiar to people. This program could even relink the Internet Explorer shortcuts to point to Firefox, and then disable Internet Explorer by assigning an invalid proxy server. And while unethical, wouldn't it be nice if this program was released as a virus to spread across the world? Sure would be interesting. The word virus has such a negative rap. It would probably go over better if we called it a security patch and actually asked the user if they would like to install it. After all, Internet Explorer is known to have quite a few security holes.

Previously I thought JavaScript was a crappy language and I was annoyed that it is essentially the only choice for a client-side browser programming language. Over the last two weeks my opinion has changed. JavaScript is a decent language, especially with the addition of excellent libraries such as Prototype and Scriptaculous. JavaScript even has closures, an advanced programming language feature made popular by Lisp and not found in many other languages such as Java. But writing JavaScript code is still frustrating and will be as long as we have to play by the rules of Internet Explorer. It would make little difference if a Ruby interpreter came built-in to all web browsers. Internet Explorer would still fail to implement the Document Object Model correctly and web development would remain what it is today: An exciting fast paced industry pursued by a little devil with an eery cackle and a sharp pitchfork --> Microsoft.

Erlang - The Next Great Programming Language?

Luke Ludwig — Thu, 04 Oct 2007 08:13:00 -0500

Erlang - The Next Great Programming Language? I don't think so. I probably shouldn't be doing this. At least not yet. I just don't know enough about Erlang to make any predictions. I haven't written any Erlang code myself. This will change shortly, as the book is on its way. I guess I am impatient. And curious to see if my opinion will change.

All signs seem to point to Erlang being the next great programming language. It has momentum, it has hype, it even has the Pragmatic Programmers on its side. And like Ruby, it has a killer app -- parallel processing. Ruby's killer app is Rails of course, which greatly eases the burden in developing web applications. Ruby is the latest great programming language. For the past 3-4 years Ruby (and Rails) is the language that everyone has been talking about, the language that all the talented programmers want to learn in their spare time. Before Ruby, Python may have stood for a short time on the latest great programming language podium. Python never quite had the killer app that Ruby does with Rails, but it still shocked the world (well, the world of nerds anyway) with its pseudocode look and its use of whitespace. Before Python there was Java, and before Java C++, and before C++ there was C. I wasn't programming at the time, but yes people I believe if you could travel back in time there was a point where C was the latest cool programming language that all the cool kids (aka major nerds) had to try out.

And now Erlang? Certainly it seems like all the cool kids are sneaking off to become Erlang experts during their lunch break. Which is the beginning of how the next great programming language comes to be. Due to its killer app, parallel processing, Erlang is impossible to ignore. Multi-core computers are now a reality, with more cores coming out every year. Intel could have 32 cores by 2010. The tides have turned and the software world now lags behind the hardware world. In the past we always had software programs that would consume the available processor time or eat up all the RAM. But now, with 32 cores just around the corner, very few software programs will be able to take advantage of this. Unless Erlang becomes the next great programming language, and quickly.

Parallel-processing comes built-in to Erlang. Whereas conventional programming languages use a concurrency-model with shared state, Erlang uses a message-passing concurrency model where the only way for "threads" to exchange state is via asynchronous messages. The shared state concurrency model causes a host of problems, most of which fall under two categories: race conditions and deadlocks. These problems are extremely frustrating to fix and it can be very difficult to prove their absence. Edward A. Lee has written an excellent paper on The Problem With Threads, where he basically says that the dominant shared state concurrency model in use today is not the way to go. He argues that "Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed". I don't know if Erlang is quite what Edward A. Lee was envisioning, but right now it is the best we have. Along with Erlang's asynchronous message-passing concurrency model, it automatically distributes the multiple "threads" (which are really processes) across cores, which essentially means an Erlang program running on a 32 core machine can run 32 times faster than on a single core, assuming there are no other bottlenecks such as disk to slow it down.

Why don't I think Erlang will be the next great programming language? It is too radically different. It is too functional. No real variables? No mutable state? My simple-minded brain understands the importance of no-shared state between "threads", but with Erlang I can't even change the value of foo? And has a functional programming language ever become popular with the masses? Everyone knows that Lisp is more powerful than other languages, but no one cares.

Erlang is simply too different. In C++ - The Forgotten Trojan Horse, Eric Johnson reminds us how C++ took over the world. C++ extended C in a manner that allowed developers to gradually transist into the world of C++. Eric Johnson writes that "Too often we developers think of great change as requiring discrete, atomic, massive events that stand out as a fork in the road". In reality, great change in the programming world is gradual, not all at once. Scott Berkun in his The Myths of Innovation, points out that Compatibility is one of the main factors in how quickly innovations spread. Scott writes "How much effort is required to transition from the current thing to the innovation? If this cost is greater than the relative advantage, most people won't try the innovation".

But Erlang has the momentum and the hype and in the next few years I am sure most of the cool kids will bring it around the block for a spin to see what it can do. The best hackers have probably done this already and most likely they realized that Erlang is too different. What the world needs now is a language like Erlang with its asynchronous message-passing concurrency model and its automatic parallelization across cores, but without its functional nature and without its lack of real variables. People can only take so much change at a time, and switching from a shared-state to a message-passing concurrency model is a rather large change by itself. I expect that before long a new language will appear to steal the glory. Or maybe an existing language (Ruby anyone?) will be extended to include the more important concepts underlying Erlang. As Scott Berkun points out in The Myths of Innovation, the best ideas do not always win.

There is more to life than code.

Luke Ludwig — Tue, 02 Oct 2007 22:34:00 -0500

Many skilled programmers are good, in part, because it is all they do. At work they code and they can't wait to get home so they can code on their own project. The world of programming is a large turbulent pool of knowledge, ideas, and skillsets too vast and changing for any one human mind to conquer. For many people this world of code is their primary passion in life. Programmers get sucked into an hour-gobbling vortex that leaves little time for other activities. Tired of sitting at your desk all day? Followed by sitting in your car as you commute home, and further by sitting in front of the tv or computer at home? Sit, sit sit, its what Americans do, especially lazy but passionate-about-code programmers. I think it is important for the health of the human psyche to have at least one hobby or activity, unrelated to work, that gets you excited, and why not make it a physical activity since the majority of your life is spent sitting on your bottom?

Physical activity? Most people are turned off just by the thought of it. Physical activity is usually set aside as one of those healthy things you should be doing, but never have time for. Like flossing your teeth. Occasionally inspiration hits and you'll go for a run every other day or hit the weight room. But if you are like most people, this usually lasts for only a week or two before you are back on the couch. You wouldn't want to miss an episode of Heroes. The problem is that very few people actually enjoy running or lifting weights. What you need is a physical hobby which excites you as much as the latest cool programming language. If you are passionate about excelling at a physical hobby, then your own self-motivation will drive you to stay in great shape, just as it drives you to stay on top of the latest programming trends.

There are many physical hobbies to choose from, such as road biking, mountain biking, whitewater kayaking, sea kayaking, geo caching, backpacking, and various forms of martial arts. Find one which you are excited about and get started! If you need help choosing, then let me convince you to take up lightweight backpacking. Especially if you sort of like nature, or at least you don't hate it and could maybe grow to enjoy it. The lightweight backpacking movement shares several similarities with the agile programming movement. Both are about constantly improving and excelling at their respective topics. Both embrace simplicity. Agile practices are often described as lightweight since they attempt to eliminate complexity and unnecessary waste in the software development process. One of the well-known agile methodologies is actually known as Lean Software Development. A lightweight backpacker similarly eliminates waste by only bringing essential items.

Just as the best programmers are agile, the best backpackers go lightweight. The amount of weight one carries while backpacking plays a huge role in your comfort and enjoyment while on the trail. A traditional backpacker typically carries between 35 and 60 pounds, travels between 4 and 8 miles a day, and honestly dreads time on the trail. A lightweight backpacker typically carries between 15 and 25 pounds, travels between 8 and 30 miles a day, and thoroughly enjoys their time on the trail. Whereas the goal of agile programming, produce better software on time and within budget to maximize value, is simply about becoming better at software development, the goal of the lightweight backpacker varies from person to person. Many lightweight backpackers enjoy perfecting the art of wilderness travel and strive to cover as many miles per day as they can. For others, backpacking lightweight may allow them to carry other gear such as photography equipment, enabling them to get shots that normal outdoor photographers dream about. And some lightweight backpackers simply want to enjoy their time in nature, and instead of pushing themselves to cover miles they travel in a more relaxed manner without the burden of a heavy pack.

Backpacking can be a challenging hobby. Their are many skills to refine, including orienteering, regulating body temperature, staying dry in bad weather, wilderness first aid, physical fitness, hanging your food pack, and caring for your feet. Many of these skills relate to using your gear, and gear research and selection prior to trips is a large part of the lightweight backpacking hobby. Lightweight backpackers keep gear lists, which have every piece of gear they bring on trips along with their weight. Example Excel templates can be found at BackpackingLight, one of the best resources for lightweight backpacking. You'll find a healthy online community of lightweight backpackers at this site to answer your questions and to sell you their used gear for cheap. Backpacking lightweight does not have to be expensive, and the best way to learn is to jump right in and try it.

So stop sitting on your butt all day! Find something to do outside which you are excited about and start doing it, because there is more to life than code.

Inspiration While Kayaking

Luke Ludwig — Thu, 03 May 2007 19:23:00 -0500

One Thursday afternoon in early May, I decided to leave work early at 3:30 and go kayaking. Adios manager Chris. After a boring hour commute home to lovely Woodbury, Minnesota, I tossed my kayak on top of my truck, drove to nearby St. Croix Bluffs Regional Park, launched, and was on the water by 5:00. My kayak is a yellow 17 foot long Current Designs Caribou and is designed for "seas" as it is a sea kayak. I paddled across the wide St. Croix river to the Wisconsin side and headed downriver along the shore. Out for exercise, I was planning to paddle about 8 miles in a moderately strenuous manner. The planned 4-mile turn around point is where the St. Croix joins with the Mississippi.

I soon got in a rhythm and began thinking about, what else -> backpacking. If you were to just meet me and ask what I do I would say "I backpack, paddle, and write code" [1]. Certainly you were expecting an answer more like, "I work as a Simulation Engineer at BAE Systems in Fridley. We make the biggest guns in the world, aka howitzers, for the army." Backpacking, paddling kayaks and canoes, and writing code are my three main... passions or hobbies? If I just call them passions then I have to make the standard disclaimer about my wife Becca being my first passion. How about passion-hobbies.

So I was thinking about backpacking. Specifically the 2 week, solo, 240 mile trip I was planning for late summer in the Cascades. I don't just backpack, I backpack light. Similar to not being a traditional backpacker, I am not a conventional programmer. I am an agile programmer. Both lightweight backpacking and agile programming are movements in their respective worlds that have been expanding in popularity in the last 5 years or so. While expanding, agile programmers and lightweight backpackers are certainly still minorities. My inspiration, while out kayaking, is that the guts behind each of the movements are incredibly similar. What was I to do about it? Write of course. There are lots of websites about backpacking and even more about programming, but hopefully I will have the first ever website on both backpacking and programming. Does this make sense? I don't know. But I will be sharing similarities between the two and how ideas from both of them can be brought into everyday life. Maybe I'll be able to convince a few programmers to take up lightweight backpacking. Somehow I doubt I'll be able to convince any backpackers to take up programming!

I turned around shortly before reaching the junction with the Mississippi and headed back up river and into the wind. I concentrated on using my torso instead of just my arms to propel my body and kayak through the water. The river being straight here, I spotted on the distant horizon what I thought was the take out. As I neared it I realized I was mistaken and was only half-way back. Since I was paddling hard this was a bit disheartening. No matter. A short time later I was observing a bald eagle being harried by a smaller bird a few hundred feet overhead. While under attack, the bald eagle suddently dropped its feet, opened its large talons and dove down to the water. I was expecting a big splash in the water, but wow, this baldy barely got its toe-nails wet. Its prize was a small sunfish, wiggling in the eagles death grip.

As I neared the real take out I noticed a big fishing boat towing an even larger fishing boat back to the public launch. As a kayaker this makes me smile. Simplicity is one of the primary properties underlying lightweight backpacking, agile programming, and kayaking. Kayaking is one of the simplest ways to enjoy being on the water. There is no outboard motor to fail and leave you stranded. You travel via your own power. I need to remember to always bring my tow rope with me. If I had, and the other fishing boat wasn't around, I literally would have towed this boat, family and all, back to the launch[2]. This would have brought an even bigger smile to my face.

[1] This concept of answering "What do you do?" by describing what I'm passionate about instead of what I do for a job deserves a reference, since I saw it on a short film last week about a guy who skis (he works as a waiter in case you are wondering) while watching the 2007 Banff Film Festival at Midwest Mountaineering's Spring Outdoor Adventure Expo. Not much of a reference since I can't remember the guys name.

[2] Skeptical about a kayaker towing a boat? Don't be. It has certainly happened before. I'm not saying it wouldn't be a lot of work, but it is more doable than it sounds. Once you get momentum going I imagine it would only be strenuous work (as opposed to completely exhausting).