The Puerto Rican Rails Dude

It’s been an interesting week for me. I got a first-hand taste on upgrading a Rails 1.2.x application to Rails 2.0. To be honest, I was terrified when this task was presented upon me. I had never done this before, since virtually all the Rails 2.0 (and 2.1) apps I’ve worked with have started with that particular version, not an upgrade. Seeing that the application in question had been under development for a long time (hence still using Rails 1.2), I immediately though that an upgrade to Rails 2.0 would cause the app to break so bad, I would be having “NoMethodError” messages in my nightmares for a long time to time.

So with the thought of a long week of fixing trivial changes to make the application work correctly once again, I removed the frozen Rails 1.2 directory from the application and froze Rails 2.0 in its place. I started Mongrel, and… It worked. Like it really worked. Well, not 100%, but most of the application worked as it was before! I definitely couldn’t believe it. That was probably the easiest framework upgrade I’ve done in my entire life. Most of it had to do because of me doing a lot of refactoring for code that I had knew would be removed from the framework soon, but also kudos to the Rails Core team for making this pretty straightforward.

Like I said, it didn’t go 100% smoothly, so I thought I’d share some of the gotchas I encountered during the upgrade.

‘extract_options_from_args!’ method

The extract_options_from_args! method was apparently removed in Rails 2.0. Upon further inspection, there were many plugins using this method, but only one (nested_has_many_though) wasn’t properly handling it. All I had to do was update that particular plugin, and the error disappeared from the entire application. So my recommendation is to upgrade any currently existing plugins you have, although this is more tricky if you have old plugins that aren’t being currently maintained.

‘You are being redirected’ problem

In some places of the application, when an action used ‘redirect_to’ to send me somewhere else, a page would appear, simply saying ‘You are being redirected‘, with a link to where the app should’ve been redirected. The problem: there was a parameter named ’status’ that was used for the redirect. Changing the parameter name to ’state’ solved the problem. I’m guessing it’s because Rails uses the word ’status’ to set the HTTP code for a redirect, so it caused this hiccup.

‘Called id for nil’ error

I was also getting errors for nil variables where they didn’t exist before. The problem here was caused because some ‘form_for’ tags were using variables that weren’t initialized previously in the controller. Taking for example the following code: <% form_for @item, :url =>items_path do |f| %>. The instance variable ‘@item’ wasn’t declared in the controller (or the view, although if someone did that, I would hunt them down), yet in Rails 1.2 it would work properly. It was just a matter of adding @item = Item.new in the controller for the action, and it would work fine again. I guess this was just done to make sure things are coded correctly, which I really don’t mind.

Route Globbing and escaped slashes in URL

This one was an interesting one. Part of the application uses route globbing, where you can set a route to grab everything in a URL and set an array. The application in question was using this in one part of the application, to get a collection of IDs and process them for some other functionality. However, this was being done via a link generated using ‘link_to’, which promptly went to escape the slashes between the IDs (from ‘/’ to ‘%2F’, which the browser read well, but Rails 2.0 apparently doesn’t like), and the route globbing wouldn’t return the array as expected. For example, previously in Rails 1.2, if the URL ended like items/process/101/105/110, the route globbing would return an array of three elements: ["101", "105", "110"], which is what the app expected. In Rails 2.0, since the slashes were escaped thanks to ‘link_to’, it would return an array of one single element: ["101/105/110"]. This problem was already reported and seems like it’ll be fixed in Rails 2.1.1. But in the meantime I did a quick fix: take the element in the array and split it using Ruby’s split method to create the array as it should be before processing.

Besides these errors, the rest went smoothly. The app has been running for two days under moderate testing, and nothing else appears to be broken. So it all went well. Hope this post helps someone get through some problem upgrading their old, creaky Rails app.

This is obviously not my first time that I have shilled the PeepCode website. I truly think that for any Rails developer, this is one of the most invaluable tools for learning available anywhere. I’ve purchased many of their screencasts already, and once I get the opportunity, I’ll even spring for their PeepCode Unlimited subscription. I know I will fully get my money’s worth.

If you haven’t been following what they have been doing recently, they have also added PDF books to the mix. These books provide a lot of wealth, just like their screencasts, but only in text form, perfect for printing or, for the environmentally-conscious of you, just keeping in your flash drive and reading it whenever you need it. I just recently purchased two of their PDF books: Git Internals and ActiveMerchant.

I purchased the Git Internals book to satisfy my own curiosity. As many of you should know by now, Git is a distributed version control system (a la Subversion) that’s taking the software development world by storm. I’m slowly getting into Git, thanks to a PeepCode screencast on the basics of Git, and even decided to pay for an account on GitHub (which I will write about in the near future). But I’m usually not content to just know how to get my work done. I like exploring beyond that, knowing how it actually works in the inside. Most of the times, I fully understand its strengths (and weaknesses - nothing is perfect!), making me more efficient. This PDF book does exactly that. If you’re a curious being, and are using (or planning to use) Git, I wholly recommend this book.

The ActiveMerchant book, I actually bought out of necessity. The web application I’m working on has the ActiveMerchant Plugin installed, and some work with that plugin done. However, since the developers who implemented those features aren’t working for the company anymore, and some core functionality has changed since I’ve arrived, it needs to be changed. I didn’t want to start from scratch, so I bought this PDF book to see what should be the “right way” (as per the author, who undoubtedly has tons more experience with the plugin as I have). I really got into this book, because it’s really, really easy to understand (thanks to the plugin actually being easy to implement) and it explains everything you need to know about the entire payment process. This is a must-read for anyone who’s building Rails applications where money needs to get to you.

The guys over at PeepCode are doing an excellent job, so why don’t you head over to their site and check them out? If you’re a web developer, particularly using Ruby and Rails, you’ll definitely find something interesting, or even necessary.

Well, well, even a week after Zed Shaw’s infamous rant on the Ruby and Rails communities, all the talk generated by it continues. While it has died down enough, I feel that the repercussions of the rant are still going on. And I’ll be writing about one I’ve been disturbingly seen more and more in the past week.

One of Zed’s problems with Dave Thomas was due to his book, Programming Ruby (or “Pickaxe” - weird how some people know that book only by the Pickaxe name). Here’s one of the paragraphs he wrote about that particular book:

That’s right, take a look at the original topics and you’ll see that Dave’s book is nothing but a giant me-too book that seems to appeal to the average OOP coder of 2001. However, the average OOP coder using Java, C++, or C# wasn’t doing much meta-programming then, and what Dave presented was nothing more than a book that said, “Hey look, you can do all the stuff you’re doing now, and make NO money at it.”

He goes on to explain a lot of the shortcomings of the book, like the fact that the chapter about classes was demonstrated by designing some sort of Karaoke jukebox machine. I do agree with these specific points Zed makes. I remember reading the book for the first time, and just skimming the classes chapter because it felt awkward that these very important terms were being explained this way. It was also confusing as well. I just read the basics (how to create classes, inheritance, access control, etc.) and skipped most of it. Also, failing to include one of Ruby’s strong suits (which is the ease of meta-programming in this particular programming language) seems very weird.

However, this isn’t what I wanted to talk about. My issue is that after Zed pointed these things out in his rant, I’ve been seeing a lot of negative comments towards this book - something I hadn’t encountered before. In fact, I bought this book because everywhere I read on the Internet, it specified that this was the book to own on Ruby. In fact, let me show you a screenshot of the current reviews this book has on Amazon.com:

See anything interesting there? Yeah, there are only 52 reviews, but 43 of those reviewers - a whopping 82.6% - gave this book either four or five stars. To me, for a supposedly “shitty” book (as I’ve read a lot of people call this book in the past week), this is a rather high positive rating.

So, are these people honestly criticizing the book by their own will, or simply just want to “follow the leader” and bash Dave’s book without thinking for themselves? I find it extremely odd that a lot of criticism is aimed towards this book in such a short period of time - the past week since Zed’s rant. Were people scared or something of giving their honest take on this book for fear that the Ruby zealots would find out where he/she lived and crucify them or something? Something just doesn’t seem right.

Now, while I’ve expressed before how much I enjoy the work of Dave Thomas and others who publish the Pragmatic Programmers books, do know that I’m not biased in any way, shape or form. I’m probably one of the most objective guys you’ll ever meet. If I think something sucks, I’ll gladly say so, as long as I can back my words up. But honestly, I don’t think the Pickaxe book sucks. Far from it. This book has helped many (myself included) find out about the awesome features of Ruby (well, most of them, at least). To ignore the fact that this book helped jump-start Ruby usage in the in the Western Hemisphere is really a disservice to it.

I think Programming Ruby is an awesome book and an excellent reference to the Ruby language. As a book to learn the language, I wouldn’t count on it to be the “be all to end all” Ruby book. To those who think there are programming books like this, you’re totally wrong. In my short programming career, I’ve come to know that one book for a specific language or technology isn’t enough. Obviously, that doesn’t mean you should buy all the books on a particular topic. But more than one, at most two or three books, should help you greatly. No two authors think alike, and there’s always some stuff missing from one book that another has, and vice versa.

So to all those newly-minted Pickaxe “haters”, I suggest you take an honest look at yourself and think if you’re really hating this book because you didn’t like it. If you didn’t like it from the get-go, good for you. I hope you find another book that helps you learn Ruby. But leave the rest of us who learned a great deal from this book alone. We don’t need a Zed-wannabe running around this joint.

UPDATE: After I posted this, I immediately E-Mailed David Heinemeier Hansson (yes, the creator of Rails), because I was curious on how he learned the Ruby language. I was surprised he responded in mere minutes, and his response was even more surprising:

I learned Ruby in large parts from the original Pickaxe and thought it was a great book. No, it didn't cover everything. And I picked up some metaprogramming tricks form The Ruby Way, especially Chapter 5, as well. But I was very happy to have it at the time.

Seems like David agrees with my thoughts on this subject. I bet that most of the big names in the Ruby world also learned the language from Dave’s book. I thank David for that quick and honest response.

Before I begin, I just want to wish everyone a Happy New Year! May 2008 bring happiness, peace and prosperity to all.

I’ve been keeping myself very busy lately with RSpec and Behavior-Driven Development, basically learning the ropes and how all the pieces fit together. For now, I’m totally enjoying it. But more on that in a future post.

Now, I know that everyone who read Zed Shaw’s rant towards most of the Ruby and Rails communities will have an opinion on this. But I’ll give my own thoughts on it. All I hope is that someone doesn’t read this and think “Who the hell is this guy to give an opinion?” I might not be a ’somebody’ in the Ruby or Rails communities at the moment, but I would really like to be part of those communities sometimes in the near future.

Upon first glance, Zed’s rant seems like a completely immature piece, just looking to damage the reputations of certainl people and companies. But if you read closely, ignoring the unprofessional language scattered throughout the text, there’s a whole lot of valid thoughts and reasoning to this entire rant.

Most of his attacks are aimed at two people: Kevin Clark and Dave Thomas. Kevin Clark has been a pretty big part of the Rails community, regularly contributing code and such, and Dave Thomas of course is the author of possibly the most well-known Ruby and Rails books in the market. His story on Kevin is that they possibly never got along and clashed multiple times, while the story on Dave is that supposedly Zed had a fix for a pretty serious bug in Ruby, yet Dave and others ‘threatened’ Zed to not release it. For what reason, it’s not clear in the rant. Now, about these allegations, I don’t know whether they’re true or not (there’s always two sides to a story). But from my own views, I think any environment has these types of problems all the time. My own workplace can be used as personal experience on these manners. There’s always someone who wants to be smarter and better than you, and for some unknown reason they go out of their way to make sure they come out looking better than you can. It’s stupid, but it’s just human nature, I guess. I bet almost any other open-source community is the same.

He also goes on to write about Thoughtworks, a software consulting company that jumped on the Rails bandwagon a while back. Zed’s beef with them is the fact that they charge a shitload of cash while providing not-so-great work in return. Isn’t this is the case with almost all software consultancy places? I can name a few off the top of my head here in Puerto Rico. In fact, all you need to do is go to a website one of these ‘expert software consultants’ made, look at how the site is built, and anyone with an eye for software development standard practices can name a dozen things they would change immediately. This is no surprise here.

I do commend Zed for not making this a 100% negative jab towards Ruby and Rails. He included some people who he knows and have helped him out or were unlike those who he vilified before. Like I said, all communities have their share of bad apples, mostly people who want to be most widely known at your own expense. So the fact that he names some people who were cool to him shows that.

I’ve read a lot of other blogs where people are dismissing Zed for the way he expressed his views, that he burned his bridges and what not. But that’s what he apparently wanted. He said he’s not happy being part of the Rails community, so he wants out. This is his way of getting out. Now, I may not agree with the way he did this at all. You never know when you need to cross a bridge you burned in the past, after all. But being in the position he was, seeing and knowing a lot of things that went down, he has a valid opinion, and he’s simply entitled to it.

I think Zed partly wrote this rant not to bash everyone associated to Ruby or Rails, but to try and help out, in his own way. He knows a lot more about the community than most of us will probably ever know. So hopefully some good comes out of him exposing some dirty details on how the Ruby and Rails world is run. In the end, it simply boils down to this: It’s one man’s opinion. No matter how important he is (or rather, was) to the Rails world, one man isn’t enough to kill it, in my opinion.

Zed, if you miraculously read this, best of luck to you in the future, buddy. Hope the rant was worth it!

I was going to write a small post about Rails and its brand-spankin’ new release, known at version 2.0. But in the time it took to write this, the Rails community not only released Rails 2.0, but also Rails 2.0.1 (thanks to a small error in the original 2.0 release) and 2.0.2 (bug fixes and some nice changes included) were released in short order. That’s part of what I love about the entire Ruby and Rails community: You need to be on your toes and always up-to-date. It may be a pain at times, especially when there’s barely any time for one to do anything at all. But it’s just a blast, and I’m enjoying the ride.

I’ve been using the new Rails features for the past five months now, thanks to access to the Rails Edge code. I really like the direction the framework is taking. RESTful routing is now the norm, multiple views of the same chunk of data are now a breeze, huge security benefits straight out of the box… There’s just too many good things Rails 2.0 has brought out. And the upcoming release of Ruby 1.9 (and its promised speedups) have me anxiously awaiting its arrival. In fact, I’m thinking of porting my Puerto Rican Rails site, RailsPR.com, from the “obsolete” Rails 1.2.3 to benefit from all the changes made by DHH and the rest of the Rails core team. Excellent job, guys. Here’s looking towards the bright, bright future of Ruby and Rails. I’m excited to be part of it.

The past two weeks I’ve been totally separated from all of my learning and reading processes I’ve established to myself, and I felt terrible for doing that. It’s not like I’ve been totally disconnected from everything. I’ve still read all my favorite programming-related blogs, as usual. Still, I haven’t just sat down to absorb everything or practice.

These past two days I decided to get back on track. However, I found myself with the same problem I’ve had for a while now. Whenever I sit down to learn something, I want to learn everything. I don’t mean “learn everything of something“. It’s more like “learn something from everything“.

For the past months, I’ve had a hundred different interests. I’m interested in learning Adobe AIR. Microsoft Silverlight sounds like something I could use in the future. I was sold on Test-Driven Development and ever started to adopt its practices to my daily usage, yet recently I’m liking the sound of Behavior-Driven Development more and more and would like to test that road. I want to learn other web frameworks in different programming languages, like Django and CakePHP. And of course, I’m still totally into Ruby and Rails.

I know a lot of people who don’t mind knowing about everything. But the deal is that by learning (or having the desire to learn) about so many things, you don’t fully learn it all. You only learn a bit about each thing, but never a whole lot. There simply isn’t enough time in the world to do so, especially with a full-time schedule. So to say it’s frustrating is an understatement to me.

One technique I’m finding useful to juggle these interests is to create a necessary project in your mind to learn along the way. This should keep your interests level high during the learning process, while making you stay focused with one or two things at a time. For example, my next project is a web application, where I’ll strictly try to use the practices of Behavior-Driven Development while learning to use RSpec. This way, I’ll be learning a lot of different, yet related, subjects at the same time. After this project is done, I’ll see where Adobe AIR has headed, since it’s still in Beta. If it still piques my interest, I’ll create a new project for one of my current needs, and learn from there.

Being in this world of programming and technology, where it seems like time is always on fast-forward, it can be tough to keep up with what you like. But at the same time, it’s just fun. Even though I get frustrated at times, I’m having a ball learning these things. I guess it all boils down to that for now.

Note: Unfortunately, I had to take this site offline, due to its inactivity, and due to the fact that I have moved to New York City. I had plans for this site to be a starting point for me to start my own Ruby and Rails User Group in Puerto Rico, but I obviously can’t do that now. Hopefully someone in the near future in Puerto Rico will want to do something similar.

Although I finished this project a while back, I hadn’t announced it anywhere, so here it is. I just finished RailsPR.com, a site which I hope generates some much needed attention to the Ruby programming language and Rails framework here in my native land of Puerto Rico.

The main reason I started this site is because the IT industry in Puerto Rico is currently just centered on Microsoft products. I’ve said in a previous post that I really don’t mind Microsoft, and I think some of their products are great. However, with so many stable and useful open-source alternatives in the market, from operating systems to programming languages, I don’t see why it should be this way.

I’ve been learning and using Ruby for most of this current year, along with Rails. And it still baffled me whenever I talk to other programmers, they don’t even know what Ruby is. They’re still stuck with the same Visual Basic teachings they had in college. There are even some still using COBOL.

So my mission with this site is to create a community where interested programmers from Puerto Rico can be together in one place, sharing their knowledge and experiences, which is really what open-source is all about. It would make me proud to have my site be one of the main reasons people got into Rails.

Note: This site has changed a lot over the last year. I’m not using Rails anymore on the site, so there’s no place where I’m currently using the Digg API. However, I’ll leave this post intact, as it might help others with something similar.

If any of you readers have come in through my main site lately, you should notice that I added a little something on the sidebar. One of my favorite time-wasting activities of the day is browsing Digg. I tell you, there should be some sort of “Diggers Anonymous” for us simple-minded folk who can’t stop from visiting the site for stories many times a day!

Anyway, they recently announced the release of the Digg API, to allow any user to access the stories on the site in any way, shape or form we desire. Now, I must say that I have no real use for this. Of course, being the geek I am, I just wanted to try it out and see how I could use a simple API using Ruby, for use on my Rails site (this one). This is also made in case anyone else wants to do the same. One note, however: I’m only a Ruby / Rails beginner. I’m sure there are much better and efficient ways to do this. Since I haven’t dabbled in this too much, and “it works on my machine“, I’ll leave it as it is for now.

Just for the record, the testing and development for this code was made on my computer running Ubuntu 7.04, along with Ruby 1.8.6 (compiled by myself, not downloaded from the Ubuntu repos), RubyGems 0.9.2 and Rails 1.2.3. It should work correctly with any fairly recent version of the software mentioned above.

The Digg API is rather simplistic right now. All you need is a simple request using a URL like this:

http://services.digg.com/stories?appkey=http%3A%2F%2Fdennmart.com&type=xml&count=5

In the example above, the API is called to the ‘http://services.digg.com’ server. The parameters afterwards (in this case, ‘/stories‘) is the request. You can add more parameters for a finer-grained search.

Once the request URL is complete, you need some additional actions to add as well. The ‘appkey‘ is required, but can be anything for now. Digg isn’t generating application keys (a la eBay or other external API’s), but an appkey is required for ’statistical purposes’, according to the documentation. The ‘type‘ is how the data is going to be returned to the app, and it can be either XML, Javascript, JSON or PHP. I use good ol’ XML for now, until I can actually play around further with the other response types. Finally, the ‘count’ action is to limit how many stories are returned. I’m only going over these options quickly, as the API documentation has much more information.

Once you figure out which request you want to make (using Mozilla Firefox can help greatly, as the XML response is nicely formatted), it’s a matter of getting that data into your Ruby or Rails app. Going back to the ol’ trusty Pickaxe book, I found a nice little module integrated in Ruby called open-uri. This module allows the Ruby application to open a URL (either http, https or ftp) and get the returned contents. To use this module, a simple line of code is needed:

require 'open-uri'

That should load your module correctly. Now it’s just a matter of having Ruby open the API connection and store its XML response in a variable:

response = open('http://services.digg.com/stories/popular?appkey=http%3A%2F%2Fdennmart.com&type=xml&count=5').read

The ‘open‘ function, well, opens the connection to the API, while the ‘read‘ method gets the data that’s returned from the URL. Like I said, rather simple.

However, I was getting timeout errors when calling the ‘open’ function. Strangely enough, the function worked fine when using any other URL. Upon further reading of the API documentation, I found this little tidbit:

“All API requests must include a User-Agent HTTP Header. A request without this header will receive no response.”

So, after that small mistake, I edited the request like so:

response = open('http://services.digg.com/stories/popular?appkey=http%3A%2F%2Fdennmart.com&type=xml&count=5', 'User-Agent' => 'Ruby/1.8.6').read

The ‘User-Agent‘ parameter can be anything. I just decided to use the Ruby version I have. Once I added that, I had my nice XML with the five most recent Digg stories that have been promoted to the front page.

After that, I needed to parse that XML. I searched around the Internet, and found a great little module called ‘XmlSimple‘. This module reads and writes XML, and formats it according to whatever’s needed. In my case, I needed to read the XML response. Just like the ‘open-url’ module previously, you need to load the ‘XmlSimple’ module as well, once installed (”gem install xml-simple“):

require 'xmlsimple'

I did run into some minor problems when loading this module. The Ruby interpreter cried out loud, saying it couldn’t load the module. How come? I verified that the gem was installed correctly, and it was. Then I realized that since this is a gem, I need to have ‘RubyGems‘ loaded before loading ‘xmlsimple’:

require 'rubygems'

I believe that Rails already loads the module for you. But if you’re testing this out on Ruby and not on Rails, you’ll need it.

Okay, once I did that, I was able to load the ‘xmlsimple’ module. Now I need it to parse the XML response that I stored in the aptly-named ‘response‘ variable. A simple line of code can convert the XML into a hash:

XmlSimple.xml_in(response)

That takes the entire XML string and puts it into a neatly organized hash. I really don’t need everything in the hash, just the story title, link and how many diggs the story has. So I just access those particular keys:

digg_hash = XmlSimple.xml_in(response)
story_title = digg_hash['story'][0]['title']
story_link = digg_hash['story'][0]['link']
story_diggs = digg_hash['story'][0]['diggs']

In the example above, the ‘story_title‘ variable has the most recent story title, the ‘story_link‘ is the link that takes you directly to the story, and the ‘story_diggs‘ has the current amount of diggs that story has. The number zero used in the array is the story number. If you want to get more than one, you’ll need to loop through the array and get the other stories.

The code I’m using on the main site right now is the following:

<%
  require 'open-uri'
  require 'rubygems'
  require 'xmlsimple'

  response = open('http://services.digg.com/stories/popular?appkey=http%3A%2F%2Fdennmart.com&type=xml&count=5', 'User-Agent' => 'Ruby/1.8.6').read
  articles = 0
  while articles < 5
%>
<%= XmlSimple.xml_in(response)['story'][articles]['title'] %>
(Dugg <%= XmlSimple.xml_in(response)['story'][articles]['diggs'] %> times)


<%
  articles += 1
  end
%>

In all, this was rather simple, and I’m sure there will be a much more creative use for the Digg API soon. But for those who want to learn how to use it, or those who need a very simple approach, this works just fine. I’m interested in listening on how other people have put this to use. Hope this helps someone!

I recently came across this blog post, where someone compared various implementations of Ruby, specifically to check the speed of each. When I read this post, I wasn’t surprised at the results. I was totally surprised at how many different Ruby implementations there are. I hadn’t realized how many there were.

Now, my question is, why are there so many different implementations that run Ruby code? I haven’t read about the others, such as Rubinius or Cardinal, so I still don’t know. I would imagine that there’s different needs for each (such as Gardens Point Ruby .NET, as the name suggests). But unless there’s a reason to have all these different ports, I wonder why there are so many.

Why don’t these developers focus on the original Ruby language and strive to make it better, instead of forking off to a different road and possibly confusing new users? Like I said, I haven’t read about these other implementations, so there may be something behind this. I’ll take the afternoon to read about the other implementations, and try to find out why there’s so much interest in making different Ruby implementations instead of focusing on the original.

I remember when I first started using Linux back in the day - “back in the day” referring to about the year 2000 - it was a total pain to work with. From not-so-great hardware detection, to installation and partitioning pains, to the ever-lasting fight against making a Winmodem work, it surely wasn’t for the weak-minded. However, something I sort of enjoyed during that period was downloading and compiling the programs myself. Well, I didn’t enjoy it much when dependency problems arose. But just the fact that I was taking this free and accessible source code, compiling it myself, then having fully functional software made me have a sense of accomplishment.

Nowadays most people have it easy. With friendly and easy-to-use Linux distributions, such as Ubuntu and OpenSUSE, all you need is to just click on a checkmark in a GUI interface and your programs, along with all dependencies, are immediately installed. Nowadays no one even has to use the command-line at all if they wish to do so. So as Linux gets easier to use, less and less people learn how to really use the operating system to its fullest.

Unfortunately, I too have fallen into that trap as well. I remember I used to compile the kernel every single time a new one was announced. Now, I barely do it. If the operating system I’m using at the time doesn’t have a current update, I don’t install it. Every time I see a new program I was to try out, I check first if there are already pre-compiled binaries for my distribution, and only compile the source code if all else fails. It’s kinda sad how much I’ve lost during these past few years.

That will probably change from now on. Last night, I took a spare computer in my apartment (1.0 GHz Athlon with 768 MB of RAM and a 20 GB hard drive) and decided to put it to good use. Seeing that I’m trying to learn Ruby and Rails, I wanted to install an easy-to-use distribution to save me some time with installation and configuration duties. So I chose Ubuntu, and it all installed just fine, until it came time to install Ruby and Rails afterwards. With Ubuntu, installing Ruby is just as easy as doing this:

sudo apt-get install ruby

Ubuntu did its magic, even though I didn’t have a good feeling when I saw it was installing version 1.8.4 (Ruby is now at 1.8.5). Oh well, I thought. It was just a minor revision, no big deal. I then went on to install RubyGems, and it installed okay, until I started getting some warnings. Since it finished the installation, I just kept on going. When it came time to install Rails, This time one of the gems didn’t install (I believe is was Action Web Service). I had installed Rails in other distributions without warnings, even on Windows. Since I had a couple of spare minutes at night, I decided to go the long route, and install everything from scratch, and make sure it’s up-to-date.

I’ll skip the entire process, as I’ll probably cover it in another, more formal, post. But I grabbed the source code of Ruby and after uninstalling all the mess the Ubuntu binaries caused, I compiled everything and I had absolutely no errors at all! I was even able to install the Mongrel gem without any problems.

So, that taught me a lesson as far as relying on pre-compiled binaries goes. Besides the obvious reasons why you should try to compile your own software (if the code is available), such as optimizing the compiled binary for your system and making sure you have the latest versions, you can avoid problems from the beginning, even if package managers such as Ubuntu’s apt are supposed to help you there. Also, it brought back that sense of accomplishment I used to previously have. So from now on, as long as time and skill allows me, I’ll be compiling my own code.

Time to pay a visit to the Linux Kernel Archives. Long time I haven’t been there.