I just registered for Ruby East, which is being hosted by Chariot Solutions a hop, skip, and jump from my house!  Hopefully it will be a good time!  They appear to have a number of good speakers lined up to talk about some interesting topics.

James Avery poses an interesting question in his "How long before ALT.NET becomes NOT.NET?" post.  I'm not really sure what it takes to get into the ALT.NET club, but from what I know I'm guessing I'd fit into the general "demographic".  Like James, I've also been wondering if and when more of the ALT.NET'ters will turn to Ruby on Rails (or alternates like Django).  I've thought about this a bit more lately since I've been spending a lot more time in Ruby and Rails.  In addition to wondering about other ALT.NET peeps, I've also thought a bit about where I want to go with my development efforts and whether I want to continue to focus on .NET as my primary means of making a living. At this point I don't see myself doing anything drastic.  Considering I only have 2 Rails projects under my belt and a heck of a lot more to learn about Ruby as well as Rails I think that's a pretty wise course to take.  I am going to continue on my path to learning Ruby as best I can, afterall it is my language for 2007.  I'm also going to continue to do projects with Rails, try and write a lot more Ruby and Rails related code from scratch (plugins make life way too easy), and evaluate if there is anything I've learned from Ruby and Rails that I can bring over into my .NET related work.  I'm also going to be keeping a close eye on IronRuby, and anxiously awaiting the day when they announce they can run Rails on top of it! 

At the end of the day, I believe learning Ruby, Rails, as well as many of the other things I'm looking into, will make me a better developer.  Whether or not I end up building the software I work on in .NET, Ruby, or Erlang doesn't matter much.  I think we all owe it to ourselves, as well as our customers, to question whether what we're using today is the best tool for the job.  We also owe it to ourselves to question whether we'd find more enjoyment in working with other languages and tools.  After all those questions are raised and answered we still need to make a decision based on where we are in life, what we have control over, and where we want to go in the future.

Perhaps before the migration to Rails starts, Microsoft will change its ways and learn a thing or two about what it takes to make ALT.NET developers happy.  Perhaps they'll realize that designers, wizards, and other magic isn't what where it's at.  Perhaps they'll realize that baking best practices into the platform is a good thing.  Perhaps they'll have a look at TextMate and realize it doesn't have any designers, yet Rails developers love it?!?!?  Perhaps they'll learn a thing or two from the success of Rails and stop the floodgates from opening.  What do you think?

As I've stated before, my programming language for the year is Ruby.  I actually planned on learning Python or Ruby last year, but things didn't pan out.  Over the last 6-8 months I've been doing a pretty good job of getting myself on the way to learning Ruby.  As with any language the best way to learn it is to write something using it.  As we all know Rails has done a tremendous job of bringing people to Ruby.  I'm no different.  Over the last 6 months I've worked on two Rails projects and in the last week put one of them into production (well almost).  Since I'm half way through the year I wanted to put some thoughts down here, mostly for myself, but also for others who might be interested in a .NET dudes impressions of Ruby and Rails.

Before writing a book myself, I bought a good number of books on technical topics that I found interesting.  After experiencing what goes into writing a book, I find that I'm much quicker to pull the trigger on books that I think I might find interesting.  The amount of work required to get a book out the door is mind boggling to me.  As such I've purchased, and read, the following books to help me learn Ruby.

• Programming Ruby: The Pragmatic Programmers' Guide, Second Edition
• Enterprise Integration with Ruby
• Everyday Scripting with Ruby: For Teams, Testers, and You
  
• Agile Web Development with Rails (Pragmatic Programmers)
• Rails Recipes (Pragmatic Programmers)
• The Ruby Way, Second Edition: Solutions and Techniques in Ruby Programming (2nd Edition) (Addison-Wesley Professional Ruby Series) (only skimmed so far)
• Advanced Rails Recipes: 72 New Ways to Build Stunning Rails Apps (not out yet)
  
• Beginning Google Maps Applications with Rails and Ajax: From Novice to Professional
• TextMate: Power Editing for the Mac (Pragmatic Programmers)

As you can see not all the books are strictly Ruby related.  Several are focused on Rails, one is focused on working with Google Maps with Rails, and one is to help me learn to work in my new favorite editor, Textmate.

In addition to reading the above, I've been checking out the source code for a couple of the more popular open source Rails applications as well as some of the more popular plugins.  While all of that has been very valuable, nothing is ever as good as actually writing code.  As such I've done several projects that I would have traditionally done in .NET in Rails instead.

The first application that I got started with (and which I'm still working on) is an application that helps geographically visualize key individuals within a social network.  The data for the individuals in the social network, as well as the data for the connections between individuals, is stored in flat files so I got my first chance to play around with the CSV parsing capabilities of Ruby.  I found the FasterCSV library very useful, and got off to a pretty good start with my first attempt at parsing the CSV files and getting them into my MySql database using my ActiveRecord model objects.  After the file parsing was done, I got a chance to build several administrative pages for the site using Rails, as well as the chance to experiment with some very useful plugins such as:

• FasterCSV
  
• Geokit
• Gruff
• Ym4r_gm

My second application involved setting up a site with paid membership.  The site has several administrative functions for the owner of the site, as well as a handful of features for those who sign up to be members such as exclusive downloads, advertising opportunities, and a members only forum.  In addition to be able to gain a lot more experience with the inner workings of Rails this project also led me to gain experience with:

• mocha
• Beast
• active_merchant
• attachement_fu
• ssl_requirement
• acts_as_authenticated

So given all of the above, if your still reading, I'm guessing your wondering what I think.  In short, I'm becoming a pretty big fan of Ruby as well as Rails.  While Rails isn't perfect it does a lot of things very well.  Rails Migrations are the best solution that I've come across for migrating the schema of a database.  I can see why large teams run into some trouble with them, but for the projects I've been working on migrations have worked wonderfully.  While I'm a big fan of DDD, I also really like ActiveRecord in the right situations.  Being able to create a migration, run rake db:migrate, and have the column automatically available in my model without having to do anything makes developing with Rails and ActiveRecord very enjoyable.  Rather than dealing with the mundane tasks of writing scripts for adding columns, and then updating the associated data access and model classes, I can focus on the stuff that matters.  In addition to migrations and ActiveRecord I'm also fond of ActionMailer and the way that it allows you to create and send email, its far better than what's available in .NET land.  Next up, is the MVC structure that Rails uses for building the pages that make up the application/site.  I'm a huge fan of MVC/MVP for building UI's so it should be no surprise that I'm also a big fan of Rails implementation of MVC.  I really like having a single controller per model object, and having a nice organization to the views used by the controller.  I also really like the validation story for Rails.

As I learn new technologies I often times hack my way around until I get a good feel for what I'm doing and how things are supposed to work and be put together.  This led to me not writing as many unit tests for certain parts of the applications I was working on.  I did test drive most (if not all) of the logic I put into my model objects, but I slacked off a bit when it came to testing the controllers.  This is partly due to the fact that I was using scaffolding, and partly due to the fact that I was pushing almost everything into my model objects rather than allowing my controllers to get "fat".  As part of the test driving of my model objects I used the built in testing infrastructure, although I still want to checkout rspec.  On my latest project I also began experimenting with mocha which really helps with the testing of objects that have dependencies. 

So given all my recent exposure to Ruby and Rails one has to wonder how I rate it against my native "tongue", .NET.  I have to say I've had a lot of fun working with Ruby and Rails.  This is in part because its something unfamiliar and I really enjoy learning, but its also because both Ruby and Rails have a way of making developing with them very enjoyable.   I haven't enjoyed some of the deployments and such that I've had to deal with, but since I was learning a bit about how to deploy Rails applications on Linux it wasn't as bad as I expected.  I'm nowhere near hanging up my .NET toolbelt, but I am going to continue to do a lot of the work that I would have previously done in .NET in Ruby and/or Rails.

Glenn Vanderburg's "The Beauty of Ruby" JAOO presentation was recently published on InfoQ.com.  Glenn talks about some of "the subtle beauty that experienced Rubyists have come to know and love".  Over the last couple of months I've come across a lot of great content on InfoQ's Ruby section that has helped me to learn some of the subtle gems that exist within the Ruby programming language.  While reading books, and writing Ruby code are great ways to learn Ruby, its also tremendously valuable to hear experienced Rubyists talk about what they love about the language.  Below are a couple of my favorite Ruby presentations available on InfoQ.

• The Beauty of Ruby
• Rich Kilmer on the Power of Ruby
• Agile DSL Development in Ruby

The self proclaimed ninja's over at ActiveReload have unveiled Warehouse, a "web based subversion browser that doesn't suck".  Warehouse is a Rails app that allows you to view a subversion repository with a very slick web interface.  Rick and Justin spent the weekend when they weren't at RailsConf getting Warehouse started, and now a couple months later they've released it to the world. 

I'm in the process of deploying a Rails app, and up until a few minutes ago I was having problems getting acts_as_attachement and attachment_fu to work.  I originally started development with acts_as_attachement since I was naive and didn't know there was something better.  After looking for a fix for the issue I was seeing, I came across attachment_fu and came to see that it was superior and would undoubtedly solve my issue.  It didn't....however, the upgrade process was painless and I got some extra goodies so all was good.  For those interested, the extra goodies include pluggable image processors (RMagick, MiniMagick, and ImageScience) as well as an option to store files with Amazon S3.

With attachment_fu installed, I was sure my problem would be resolved.  I suspected the issue I was having was related to RMagick image resizing since I'm deploying to a shared hosting account on TextDrive, and RMagick has quite a reputation for hogging up lots of memory and causing havoc on shared accounts.  After switching over to attachment_fu and to MiniMagick as my image processor I was still seeing my issue, so I realized it had to be something else.

Before going onto the solution, let me explain the problem that was occuring.  When I was submitting a form for an attachment_fu model I was immediately being redirected back to the index page.  Every once in a while the form would appear to be submitting, hang, and eventually hose the lighttpd process.  As I mentioned above, I first suspected the problem was related to image resizing being done by RMagick but I was able to reproduce the problem on a non image attachment_fu model object.  After digging around on the web and coming up empty, I ended up checking out the Rails log file to see if I could figure out what was going on.  Examining the production.log showed that I was going from the :new action, directly to the :index action.  Since I was submitting a form, I should have seen a hit on the :create action for my controller.  This led me to search google for a slightly better phrase which eventually landed me at this "Form doesn't trigger create in production" forum post, as well as this related post on Ruby Forum.

It turns out the problem is due to the way that attachment_fu stores the files uploaded on the file system.  attachment_fu stores the files in a folder with the same name as the model within the public folder.  This causes issues since the url for the controller, as well as the directory for storing files have the same URL.  Fortunately the fix is as simple as adding the following to your application.rb file.

def default_url_options(options)
{ :trailing_slash => true }
end

Deployment is such fun, isn't it! :)

The validation infrastructure within Rails is another one of the niceties that it provides.  By decorating model classes with validation helpers you can quickly define a pretty thorough set of validations for a model.  As an example of the types of validations that can be added to Rails models lets take a look at a user model created by the acts_as_authenticated Rails plugin.

class User < ActiveRecord::Base
  # Virtual attribute for the unencrypted password
  attr_accessor :password

  validates_presence_of     :login, :email
  validates_presence_of     :password,                   :if => :password_required?
  validates_presence_of     :password_confirmation,      :if => :password_required?
  validates_length_of         :password, :within => 4..40, :if => :password_required?
  validates_confirmation_of :password,                   :if => :password_required?
  validates_length_of       :login,    :within => 3..40
  validates_length_of       :email,    :within => 3..100
  validates_uniqueness_of   :login, :email, :case_sensitive => false

  #other stuff
end

By using validates_presence_of, validates_length_of, validates_confirmation_of, and validates_uniqueness_of we're able to put together a detailed set of validation rules for our User model.  Additionally, we can enable and disable certain validations by defining an :if parameter on our validations.  With all these things in place Rails provides a nice default set of functionality for ensuring the validity of models.  One of the things that's been on my mind since I started working with some of these validations is how they might scale, and how well they'd support a model object with complex validation rules.  While it seems as though what's provided out of the box by Rails could be bent in order to meet most requirements I came across something today that looks very promising.

The ActiveSpec project aims to provide domain driven design (DDD) style specificiations to the Ruby world.  While Rails is getting all the attention, ActiveSharp isn't limiting itself to Rails, but instead makes itself available to all of Ruby.  On my train ride home tonight I read through the Introduction to ActiveSpec and was pretty excited about the direction it's headed.  It's pretty early in the game so the current bits may not be ready for prime time, however, that doesn't make them any less promising.  In addition to providing the ability to create simple specifications, composite specifications, ActiveSpec also provides a base ActiveSpec class with macros to help make the process of creating complex specifications more straight-forward.  I've included some sample code snippets below, but to get a full run down of ActiveSpec checkout the Introduction.

# Composite Specifications
spec = CompositeSpecification.new
spec.add_specification(SizeSpecification.new(6, :username))
spec.add_specification(CollectionSpecification.new(18..30, :age))
spec.add_specification(ConfirmationSpecification.new(:password))
spec.satisfied_by?(User.new)
#=> false

# Custom Specification Class
class UserSpecification < ActiveSpec::Base
    requires_presence_of :username, :password
    requires_size 6, :password
    requires_confirmation_of :password
    requires_inclusion_in 18..30, :age
end

UserSpecification.satisfied_by?(some_user)

# pure ruby selection
User.find_by_specification(SomeAdvancedUserSpecification)

# specifications for SQL queries?
User.find(:all, :conditions => SomeAdvancedUserSpecification.to_sql)

I must say I'm growing more fond of Rails the more I use it. It seems like it was actually designed by someone writing real applications for a living, and designed to make the common things that we have to do in most applications straightforward and easy.  Tonight I needed to add some logic to send out emails so I read through the ActionMailer chapter in Agile Web Development with Rails.  For those interested, sending out emails in Rails requires that a mailer class be created that inherits from ActionMailer.  The easiest way to do this is to run the mailer generator like so:

script/generate mailer OrderEmail confirm_order

The generator creates a mailer object in the models folder of your Rails application that looks like so:

class OrderEmailer < ActionMailer::Base
  def confirm_order(sent_at = Time.now)
    @subject    = 'OrderEmailer#confirm_order'
    @body       = {}
    @recipients = ''
    @from       = ''
    @sent_on    = sent_at
    @headers    = {}
  end
end

Which we may modify to have the necessary settings, and accept the necessary order parameter like so:

class OrderEmailer < ActionMailer::Base
  def confirm_order(order)
    @subject    = 'Thank you for your Order'
    @body       = {:order => order}
    @recipients = order.customer.email
    @from       = 'steve@sellscoolstuff.com'
    @sent_on    = Time.now
    @headers    = {}
  end
end

The generator also creates a rhtml template for the email in the views/order_mailer folder that can be used to construct the email message.  To send the email is simply a matter of calling the deliver_confirm_order method on OrderMailer.  Take notice that we call deliver_confirm_order and not just confirm_order.  Rails supports either sending emails out by using the deliver_ prefix, or allows the emails to be created by prefixing the mailer method with create_. What's really nice is that the Mailer uses a rhtml template within the views directory for the mailer (views/order_mailer in the example above) to generate the email.  This allows you to create emails using the same mechanisms used to create dynamic pages within Rails.  Plain text emails can be created, or the mailer methods and views can be updated to pass along parameters, which we do above with the order parameter.  The only difference between a mailer template and a template for a controller is that the mailer view is being used to create a text email rather than an HTML page that will be rendered to the browser.

With my mailer in place I had everything I needed to send out the necessary emails.  There was only one problem, on my MacBook Pro the emails I was generating weren't sending.  Luckily I was able to find this page on how to get OS X setup to send emails via SMTP.  After following these steps I updated my /config/environments/development.rb file to have the following settings for ActionMailer and all was good!

config.action_mailer.server_settings = {
  :address => "127.0.0.1",
  :port => 25
}

As I stated a couple days ago, I was planning on learning MonoRail for a very small project that I'm working on.  Due to various circumstances, I'm not going to be using MonoRail, and will instead be learning a little more Ruby on Rails.  The primary issue is that I've been having a lot of problems as well as frustrations with Parallels lately.  The  biggest frustration is that I can't seem to get going within VS.NET due to OS X having all my common keyboard shortcuts mapped to other things.  I know I could remap them, but when I'm in OS X I want them to be mapped to the things they're supposed to.  The other issue is that VS.NET is repeatedly hanging, left and right.  I'm not sure if its a Parallels issue, or a problem with having both Orcas and VS 2005 installed or something else.  What I do know is that it makes trying to get anything done very difficult.  The final issue, which may be much more my own fault than anyone elses, is that getting going with Castle proved to take longer than I anticipated.  My primary issue was in trying to get everything built from the trunk with the VS.NET wizards and such setup.  I'm still getting a compile error that's related to AL.exe which may be related to having Orcas installed side by side with 2005.

Anyway, I've decided to go with Ruby on Rails instead.  Below are some things that I think are going to be of value:

• Serving Static Content with Rails
• ActiveMerchant (with this PlugNPay Gateway patch)
• Beast (integrating with another application)
  

By the time this project is over I should have a pretty good overall feel for Rails, and will be posting my thoughts on it in comparison to my primary development platform (.NET/C#). I'm going to continue to look into getting everything going with Castle and MonoRail as well, since my initial reactions to it after going through some of the getting started material and documentation was very positive.

Regarding the Parallels issue, I think I'm going to clean things up in my virtual machine, copy them over to someplace safe on the network and go back to using BootCamp.  While Coherence and such is nice, I simply can't be productive when running the applications that are important to me (VS.NET) within Parallels.  Since Parallels supports BootCamp, perhaps I'll still use Parallels from time to time to quickly switch between XP and OS X, but for the most part I think I'll be ditching Parallels.  Heck, maybe I'll just give up Windows all together, and become a Rails developer. :)

Tonight I found out the hard way that prior to version 5, MySQL don't support using an aggregate in an ORDER BY clause.  Unfortunetly my web host is currently on 4.1.21-standard of MySQL while my development machine is running 5.0.27-standard.  The end result is that some pages within the Rails app that I'm working on are not working so well on my staging box at Site5 :(

I tried to find details online about when ordering by aggregates was added, however, I didn't have any luck so all I know is that it works in the version on my dev machine, but not on the version that my web host is running.

Update: For those interested the work around is to include the aggregate in the select list with an alias, and then order by the alias.  So instead of including the aggregate in the order by like so:

SELECT Column1, Column2, etc FROM MyTable LEFT OUTER JOIN MyJoinedTable on MyTable.Id = MyJoinedTable.OtherId ORDER BY COUNT(*)

You instead need to do something along the lines of:

SELECT Column1, Column2, etc, COUNT(*) Cnt FROM MyTable LEFT OUTER JOIN MyJoinedTable on MyTable.Id = MyJoinedTable.OtherId ORDER BY Cnt

And yes, I know the SQL here is completely contrived and might not be showing why the order by count is needed but that's not the point.  And for those wondering, as far as I can tell Rails doesn't exactly make it easy for  me to do what I need to do.  I can write all the SQL myself, but I was using find along with an :include to pull in an association, which means the necessary SQL isn't something I want to write if I don't have to.

As I've mentioned serveral times lately I'm currently working on a Rails application.  Overall, I've really enjoyed the experience and I'm glad that I took the plunge into unknown territory.  For the most part I've been creating everything within my Rails application as resources.  For those who don't know, using resources within Rails is how cool people build Rails apps these days.  Creating a Rails app as a set of resources makes it so your app automagically has a set of RESTful services that can be consumed by the likes of ActiveResource. Up until know I've had things setup pretty simply, and as such have only had standalone resources.  Tonight I needed to add a nested resources and found this post on the topic very helpful. 

Back in February I posted about when the right time for a new technology is.  As some likely guessed after seeing my review of Everyday Scripting with Ruby and the list of books that were on my next up list I decided to go with Rails as my new technology for one of the projects.  In a future post I'll detail how I've found the experience, and how it compares to .NET land but that's for another day.  Today, I'd like to point out the fact that nobody writes anything cool in .NET.  At least nobody writes any of the cool stuff that I need in .NET.  Ok, perhaps I'm exagerating a bit....in actuality the fact is that nobody writes social network visualization libraries in .NET. :)  The project that I'm working on that's using Rails involves social networks.  One of the things that I'll be getting to shortly is the actual visualization part of the project.  What I'd really love is if someone would write something as cool as this, in Silverlight.   That way I could have my Rails application call .NET code.  What could be better to piss off the Rails purists?  Afterall, I'm supposed to have given up all things .NET by now and truelly converted to Rails, right?  Ok, moving on....who wants to write prefuse in Silverlight?  It'd be a killer demo application to show off the capabilities of Silverlight and would undoubtedly make it so the only RIA platform anyone chooses is Silverlight.  Flash who?  Java FX what?  Flex...I think not.  With prefuse.NET, Silverlight is guaranteed instant mass approval.  Or maybe it'll just make me happy that I get to write .NET code that will access a RESTful Rails service for data that lives inside a rhtml page.  Either way you win, right?

In all seriousness I think Silverlight would be a great technology for building web based network visualization software.  While there's no way I'll have time to write something as fully functional as I'll need, I think I'll apply the learn a new technology even if it will take longer rule and give getting a basic network visualization demo in Silverlight working.  Luckily, I think some of the Silverlight samples (such as this one) might get me moving in the right direction.  If anyone cares to lend a hand, give me a shout!  Instance fame and fortune is within your grasp!

Over the last week or so I've been following a thread of blog posts that outline some of the issues that Twitter is experiencing.  For those of unfamiliar, Twitter is a "microblogging" site written in Ruby on Rails.  Over the last month or so they've seen some very serious growth.  They're supposedly seeing over 11,000 request/sec which is putting a hurting on their servers.  In this interview, Alex Payne points out some limitations in Rails, most notably it's lack of built in support for talking to multiple databases, that are making it particularly hard for them to handle the increased load.  As a result, several individual have put together plugins to make working with multiple read only slave databases possible.

• Magic Multi-Connections: A “facility in Rails to talk to more than one database at a time”
• ActsAsReadonlyable

Along with checking out the plugins mentioned above you may want to checkout the following posts that go into more detail on the problems.

• Twitter trouble
• Twitter, Ruby, and Scaling
• Rails and Scaling with Multiple Databases

What I find particularly interesting in the series of posts that talk about the scaling problems that Twitter is experiencing is that most of their problems are arising due to the database server getting nailed.  They've been able to scale out their web tier but that doesn't help their poor database server in the least.  I've been thinking about writing a series (or maybe just one) post on some of the things we've been thinking about regarding scaling our application.  It's not written in Rails, and it doesn't need to handle 11,000 req/sec but it does need to handle large sets of data and be "hot ass fast". We're currently positioned well to handle scaling out our services tier quite easily, but we need to do some more work to figure out how best to scale out our data tier.  We've had many discussions about how scaling out our services may not help since it will only increase the pressure on the database server.  Anyway, hopefully I'll get a chance to post more about the things that we're thinking about in a future post.

Jumping back to the Twitter/Rails scaling problems...I'll be interested to see how things end up with Twitter, and Rails.  I have a feeling that Rails will be better off when all is said and done, but will it be because of Twitter, or in spite of it?

Simple, use the acts_as_enterprisey plugin!  It doesn't get any easier than that does it?

Let’s face it, we all want the big bucks. And we all know Consultancy Law No. 1:

    Your Rates Are Proportional To Your App's Enterpriseyness

Or, as Shakespeare would have said:

    Enterprisey Apps Invite, Nay Demand, Enterprisey Rates.  Verily, Sunshine.

Rails make life easy for us but — and it’s a big but — we don’t want it to look easy. acts_as_enterprisey is your friend.

How does acts_as_enterprisey make webapp development look hard? Well, the only way your client can judge your app is by playing around with it. What better gives the feeling of heavy weights being lifted behind the scenes than slow response times? Exactly. That’s what acts_as_enterprisey does.

So while your client clicks, …waits…, and then gets the page, you can blather on heroically about wrestling with clustered indexes, cache expiration strategies, n log n seek times, etc ad nauseam.

http://agilewebdevelopment.com/plugins/acts_as_enterprisey

On a more serious note, the http://agilewebdevelopment.com/ site has a lot of good information on Rails plugins.

As you may have noticed, I spend my mornings and evenings going to and from work on a train.  I usually use this time to read, unless I have a pounding headache in which case I stare out into space until I hear the call for my stop.  Anywho, I recently finished Everyday Scripting with Ruby: For Teams, Testers, and You by Brian Marick. 

A while back when I was learning about Ruby on Rails Migrations I got a chance to learn a bit of Ruby.  This was mostly due to the fact that the SQL Server adapters for Rails Migrations wasn't exactly up to snuff, and in order to get a proof of concept going Aaron and I needed to write some Ruby code.  The experience gave me a pretty good understanding of Ruby as a language. 

Fast forward a year, and all the sudden there I am forgetting everything that I learned.  That is...until Everyday Scripting with Ruby.  Brian has put together a really nice introduction to the Ruby language that should be approachable for programmers, testers, and anyone else who likes to dabble in scripting.  I don't think I fit exactly within the target audience, but I still found the book a worthwhile read and would recommend it to anyone who would like to learn Ruby.  Along with Programming Ruby you should have all you need to master the Ruby language.  Brian does a good job introducing the Ruby language, as well as offering valuable insight into his world and how he goes about writing scripts.

In summary, Everyday Scripting with Ruby is a great edition to your bookshelf if your interested in learning Ruby.  Those with many years of experience in the industry will likely find parts of it "skippable" or "skimmable", but no matter how much experience you have your bound to find a couple nuggets of wisdom that make it worth the twenty (or so) bucks you'll plop down for it.

I'm not sure what's up next but I just made a mass purchase of books from Amazon.  One of the following will make it into my work "briefcase" shortly.

Anyone care to guess what I've decided about the right time for a new technology? :)

While installing Rails and friends using something like MacPorts may prove to be a little less time consuming and less error prone, I think installing from source is the way to go.  Dan Benjamin, over on Hivelogic, has an excellent tutorial that steps you through all the steps to pull down and compile the source for Ruby, Rails, MySQL, Subversion, and Mongrel.  Over the last couple hours, in between a bunch of other things I've been doing, I walked through Dan's install guide and I'm happy to report everything went very smooth!  If you do decide to go the MacPorts route, I've been told, that James Duncan Davidson's tutorial is where to go.

On the train ride to and from work today I read RESTful Rails Development.  I've already done a fair bit of reading on REST and I've worked with several RESTful APIs lately (Amazon, Flickr), however, I found the RESTful Rails Development article a good introduction to what is at the heart of REST API's.  Namely, the idea of resources, and more specifically URI addressable resources.  The support for REST within Rails 1.2 adds a lot of nice features, and looks like a great way to support multiple output formats (html, xml, javascript, rss/atom, etc.) for applications that are oriented around resources.  Anyway, if your interested in REST or Rails, it's worth a read.

I've been thinking recently that I need to learn something new. Whether it be a new technology on the .NET side of the house, or a new language, or a new web framework. I'm not sure what, but, I definitely feel like I need something new that will cause me to stretch my mind a bit.

I've had the itch to dive into WPF for a while, but don't have a whole lot of time at the moment to do anything on that front.  While I do have several ideas for little WPF apps I'd like to see built for myself I have concerns it'd be a wasted effort since my design/UI skills have diminished over the years, and what sense is building a WPF app if you can make it look slick as all get out? 

I've also been thinking a bit about trying my hand with a new language.  The top contenders would be Ruby, via Rails, or Python (with IronPython).  I'm leaning more towards the Ruby/Rails track since it would involve me stepping almost completely out of my comfort zone. 

I have a few things on my plate that I could choose to do using non .NET technologies.  Of course the problem is that I could undoubtedly do them much faster using my bread and butter technologies.  The benefit of the .NET appraoch would be that I could get more things done and perhaps have extra spending money due to being able to do more of the little projects I've been asked by peeps to lend a hand on.  The downside is that I'd still feel like I need to learn something new, and stretch my brain a bit.  I've run into this same scenario many many times in the past, and always went with the approach that would get things done the fastest since I never seem to have enough time available for anything else.  The problem, of course, is one of the main reasons for doing little side projects outside of work is to stretch yourself in ways that you might not be able to otherwise.

When confronted with such dilema's how do you choose?  Do you go safe, and stick with what you know, or do go with the more difficult, and potentially more rewarding path of trying something completely new?

One of the things that draws me to Ruby on Rails is the passion that I see from those who use it day in and day out.  Ryan McMinn from Unspace, falls squarely in the passionate for Rails camp. He recently gave a short talk about the approach that Unspace uses to build software.  They don't do specs, they don't do contracts, and they don't "conform".

John Rusk left a comment on my Developers ditching Microsoft for Rails post and brought to light the fact that developers might not be leaving because of what Rails is doing right, but instead because of what .NET is doing wrong.  I definitely agree that many of the reasons people leave the .NET world for technologies like Rails is because working in .NET isn't as smooth as it should be.  One of the things that makes Rails so successful is its focus, and the embracing of constraints.  Rather then trying to be everything to everybody, Rails is focused on a specific vision.  As I've said in the past, Rails is opinionated software.

For those looking for Rails-ish frameworks in the .NET world you might want to checkout SubSonic and Castle's ActiveRecord and MonoRail projects.  I just had De-ja-vu.

I've been reading a lot of stories lately about developers leaving the friendly confines of .NET Land for Rails and other non-Microsoft technologies.  Perhaps the most notable being Mike Gunderloy of  The Daily Grind fame.  You can read more about Mike's journey over on his A Fresh Cup - Notes from a recovering Microsoft addict blog.  Also of interest is the Forums on the softiesonrails.com site. 

I actually thought about switching my blog engine over to Mephisto to get a little taste of Rails, however, since I'm hosting this on a Windows box the thought was short lived.