Youngblog

The Phusion Passenger guys really dropped a bomb at their Railsconf presentation today, which unfortunately was poorly attended. Their successful copy-on-write improvements to Ruby (released as Ruby Enterprise Edition) and their improved queueing mechanisms in the Passenger Apache module make it currently the Rails deployment option with the fastest execution times and the lowest memory footprint, even when compared with nginx and thin servers in front of mongrel clusters.

On top of this, they announced that the mod_rails moniker has been abandoned, since it now supports Rack (which allows you to host things like Camping and Merb apps) and WSGI, which even lets it run things like Django (!)

I personally am really excited that Dreamhost has installed Passenger, which makes it so much easier for me to host my personal Rails apps.

I really enjoyed David Hansson’s keynote at RailsConf this year. He started out by discussing the surplus, or competitive advantage that Rails created, and how this surplus will eventually disappear, probably for one of three reasons:

• Other frameworks/languages will achieve what Rails has (unlikely)
• Another breakthrough technology will arrive
• Rails will become mainstream (good and bad)

My favorite part was near the end, where he admonished Rails developers to become better programmers by being more well-rounded. Among his suggestions for doing this were:

• Read more paper (reduce RSS feeds)
• Take up a hobby (examples: wood carving, banjo playing, pilot’s license)
• Get more sleep
• Reduce work time

On a side note, I have had a lot of people lament, along with me, that Confreaks wasn’t contracted to record RailsConf. Our services become especially useful at multi-track a conference like this, where you seem to always want to be watching more than one presentation at a time. While I wish we were recording it, it is also nice to be able to sit back and relax and just watch a conference for a change.

There is an interesting discussion on Slashdot about Moore's Law.

The gist of it is that even though Moore's predictions were originally based on a specific technology with physical limitations, companies have become so dependent on the revenues that come from the sale of faster systems and other add-ons that are based on these faster systems that they have a strong economic incentive to do the research and development necessary to maintain Moore's Law, even if the underlying technology on which it is based changes.

This really seems to be the year of personal finance apps. Wesabe was the first out of the gates but it looks like it will shortly gain additional competition from a number of interesting startups, including Mint, Jwaala and Geezeo--admittedly weird product names (except Mint, which I like for its elegance and simplicity), but potentially breakthrough applications.

Back in 2000 I was working on a personal PHP application that connected to my online bank accounts and automatically categorized my transactions, alerting me of any potential budget shortfalls. I even went so far as to write a fairly polished business plan for the idea. Unfortunately the application seems to have been in a nearly perpetual rewrite ever since I got it half working back then. The latest incarnation was going to be in Rails, but it looks like some of these folks might beat me to it. Faced with the fact that I probably won't be able to finish it in any reasonable time frame, I don't mind letting other people see my business plan anymore, if only to be able to say, "It was my idea first!" :-). I should add that the financials in the business plan were pretty much pulled out of a hat, and are the weakest part of it, but the concept and the market research is pretty solid, albeit out-of-date now.

In my opinion, one must-have feature for any online budgeting application is the ability to categorize my transactions and send me customized alerts without having to use an uploader on my own system or be connected to the internet. This is where Wesabe really falls short. I don't mind trusting a company with my online banking passwords, if they are really bringing all this added value. This kind of a system allows my personal finances to be almost on auto-pilot. Another important feature for me is sane budgeting. Most applications, including Money and Quicken, continue to reset your budget amounts every month, even if you overspend in some categories. I need to be able to have balances carry over from month to month, so that I can keep track of my overall performance, and I need to be able to view my budget over a year and not just a month. Here's hoping that one of these new offerings will see the light.

I'm really excited to announce that Confreaks will be recording RubyConf this year. We also have a number of enhancements we are planning for our work on the Hoedown, including searchable transcripts of every presentation.

Coby Randquist and I, as part of our Confreaks side business, went to the Ruby Hoedown in Raleigh, NC. We were contracted to record the entire conference and place the content online. The first video has been posted and can be found here. It was quite an adventure, and we hope to do a lot more of this in the coming months.

I recently spent a few enjoyable hours chatting with Fabio Akita about my involvement in the Ruby community and my thoughts about software development. Fabio is one of the developers I manage as part of my job at Surgeworks. He is a very skilled programmer and a great guy to work with.

It has been a long haul, but we finally finished our post-production work on the 2007 MountainWest Ruby Conference. During this process we developed a lot of scripts to make our future work easier and also learned which processes could benefit the most from better equipment. Hopefully we'll be able to use these skills in the future. Chad Fowler would like us to record this year's RubyConf and is seeking corporate sponsorship to help defray the costs. If your company is interested in supporting this effort, please contact me or Chad.

Confreaks is eager to assist with your next event. Please contact us for details.

One of my most common problems when developing migrations for a rails project happens when I make a mistake in my migration code that causes the migration to fail to complete successfully. When this happens, it is often the case that some of the commands in your migration executed successfully. This means that when you fix your bug and try to run the migration again, it will fail because it will attempt to run the previously successful commands but will complain that the changes they refer to are already there. There are some workarounds for this, such as using the :force => true option, but even then there are some situations that are hard to recover from. I often ended up having to manually drop my database and re-create it and then run the migration again—a real pain. So I finally decided to make a rake task that would make this a lot easier.

namespace :db do
  task :nuke => :environment do
    abcs = ActiveRecord::Base.configurations
    ["development", "test"].each do |db|
      case abcs[db]["adapter"]
        when "oci"
          ActiveRecord::Base.establish_connection(db.to_sym)
          conn = ActiveRecord::Base.connection
          conn.begin_db_transaction
          conn.tables.each do |table|
            indexes = conn.indexes(table)
            indexes.each do |ind|
              puts "Dropping index #{ind.name}"
              conn.execute("DROP INDEX #{ind.name}")
            end
            puts "Dropping table #{table}"
            conn.execute("DROP TABLE #{table}")
          end
          sql = "SELECT LOWER(sequence_name) FROM user_sequences"
          sequences = conn.select_all(sql).inject([]) do |seqs, s|
            seqs << s.to_a.first.last
          end
          sequences.each do |seq|
            puts "Dropping sequence #{seq}"
            conn.execute("DROP SEQUENCE #{seq}")
          end
          conn.commit_db_transaction
        when "mysql"
          ActiveRecord::Base.establish_connection(db.to_sym)
          conn = ActiveRecord::Base.connection
          conn.execute("DROP DATABASE #{abcs[db]["database"]}")
          conn.execute("CREATE DATABASE #{abcs[db]["database"]}")
          ActiveRecord::Base.establish_connection(db.to_sym)
        when "sqlite", "sqlite3"
          dbfile = abcs[db]["database"] || abcs[db]["dbfile"]
          File.delete(dbfile) if File.exist?(dbfile)
          ActiveRecord::Base.establish_connection(db.to_sym)
        else
          raise "Task not supported by '#{abcs[db]["adapter"]}'"
      end
      ENV['RAILS_ENV'] = db
      Rake::Task["db:migrate"].dup.invoke
      Rake::Task["db:fixtures:load"].dup.invoke
    end
  end
end

Save the text above into lib/tasks/db_nuke.rake. This task (run it using rake db:nuke) will completely drop your dev and test databases, run all migrations on them, and run rake db:fixtures:load on them. It works on mysql and sqlite. Adapting it for postgres or some other database is left as an exercise for the reader.

Update: I added a dependency on the environment, rather than trying to include the environment files manually. This is the "right" way to do it.

Update: I have added Oracle support.