As I mentioned in a previous post, I have been working with Ruby and Rails to broaden my skills. While books are a great way to learn a new language, for Ruby and Rails, there are plenty of online tutorials to help you get started. Here's a partial list of Ruby and Ruby on Rails tutorials
Ruby
Why's (Poignant) Guide to Ruby: While I'm a .Net guy, I do know that every Ruby developer needs to read Why's (Poignant) Guide to Ruby. Its pretty close to a law. I hear your Ruby code won't run unless you answer some Microprose-esque like questions about Why's Guide to Ruby. In all seriousness, it is an excellent read and very informative, if not somewhat unconventional in the realm of Computer Language books.
Ruby in 20 Minutes: This is from the official Ruby website, and as one would expect, is an excellent introduction into Ruby. While I didn't time myself, the lesson did move pretty quickly and was easy to understand.
Ruby from Other Languages: Again, this comes from the official Ruby website and offers a comprehensive look at how Ruby compares with other languages.
Learning Ruby:If you are looking for a more classical training in the Ruby language, then Learning Ruby from a University of Maryland website is the closest I've found online.
Ruby on Rails
Setting up Rails on Windows: While I haven't gone through the tutorial myself, this seems to be a pretty comprehensive tutorial on setting up Ruby on Rails for a Windows development environment.
Getting Started: This comes from the official Ruby on Rails website, and while it explains a great deal about the Ruby on Rails methodology, it also requires a working database setup and provides little guidance for the user if things go wrong.
Tutorials Point: This sites starts at the beginning of Ruby development and introduces the reader to concepts that the reader will use, but may take for granted. In all, this is one of the better tutorials on Rails.
Rad Rails Tutorial: This tutorial is geared towards the users who use Aptana's Rad Rails plugin for Eclipse and Subversion. While I prefer Mercurial, I was still able to do this tutorial by skipping over the portions regarding Subversion.
Ruby on Rails Tutorial (book): This is a fairly comprehensive book regarding Rails that is still being edited. As such, there may be mistakes. But, the book covers many more advanced topics then any other tutorial on this list.
While these tutorials will not turn anyone into a Ruby or Ruby on Rails guru over night, they do provide a starting point for the Developer. Ruby is a new technology, but like any new technology, time and effort must be put in to understand how to use.
Thursday, May 13, 2010
Tuesday, May 11, 2010
Setting up Ubuntu 10.4 for Ruby on Rails Development
In late July last year, I tried the impossible, setting up a Windows machine for Ruby on Rails Development. I spent an entire weekend on the project, and while everything seemed to work at first, once I started writing a simple application, I would receive random errors that I could never make much sense of. Part of the problem may have been with my system, which had Aptana Studio installed previously, but I had removed it after I realized it was just Eclipse with some fancy plug-ins (which could be installed on a standard Eclipse install anyway).
Most of my aggravation lied in getting the database setup. In the end, I was faced with numerous database errors that would crash the Ruby interpreter, and numerous other issues that made me vow to never try to develop a Ruby on Rails application again on Windows.
But, I've recently installed Linux on another machine, and with a few web site ideas bouncing around in my head, I thought it would be best to attempt to learn Ruby on Rails again. In the process of setting this machine up, I ran across this tutorial for installing Ruby on Rails on a Windows machine. While it sounds promising, I have a better alternative (Linux) on hand and won't torment myself with Ruby on Windows again.
(Note: This is not a definitive guide, but just the steps and errors I encountered while setting the machine up.) To setup Ubuntu 10.4 for Rails development, I first fired up Synaptic Package Manager and selected Eclipse, Ruby, Rails, and their corresponding decencies for installation.
Once these have all been installed, I navigated to Radrails.org and went to the Download page and followed the instructions for updating Eclipse. For Eclipse Galileo, navigate to Help > Install New Software. On the dialog that appears, I clicked the link "Available Software Sites", clicked "Add", then provided the URL provided on the Downloads page. Click 'Ok' on this screen and the previous one, returning to the 'Install' screen. In the drop down box at top, select the URL you just provided and once it loads, select the plug-in it lists below.
After the install is done, Eclipse will need to reboot. After it is reloaded, go to Window > Perspectives > Open Perspective.. and select the Rad Rails Perspective. Once this perspective opens, it will display a list of Ruby gems that need to be installed. Select OK to install the Gems.
I received numerous errors at this point, but I'm at a lost on how to fix it. I did copy the errors to examine another day.
Afterwards, I created a new Rails project, but I received an error stating that it could not install the latest version of Rails. But, I installed Rails in the first step, so as the instructions told me, I modified the config/environment.rb file to comment out the RAILS_GEM_VERSION variable, and re-ran the project. The starting project loaded, but as I was running through this tutorial, I ran into a couple of issues.
First, I received the following error:
To fix this error, I modified the Config/routes.rb file to recognize the new controller 'Say'.
Unfortunately I made the fix and started receiving this error:
To fix this, I followed the instructions at http://www.hackido.com/2009/03/quick-tip-solve-uninitialized-constant.html, which solved the issue.
Despite a few issues I've ran into so far, my experience of Ruby on Rails on Linux is MUCH better then my experience on Windows.
Most of my aggravation lied in getting the database setup. In the end, I was faced with numerous database errors that would crash the Ruby interpreter, and numerous other issues that made me vow to never try to develop a Ruby on Rails application again on Windows.
But, I've recently installed Linux on another machine, and with a few web site ideas bouncing around in my head, I thought it would be best to attempt to learn Ruby on Rails again. In the process of setting this machine up, I ran across this tutorial for installing Ruby on Rails on a Windows machine. While it sounds promising, I have a better alternative (Linux) on hand and won't torment myself with Ruby on Windows again.
(Note: This is not a definitive guide, but just the steps and errors I encountered while setting the machine up.) To setup Ubuntu 10.4 for Rails development, I first fired up Synaptic Package Manager and selected Eclipse, Ruby, Rails, and their corresponding decencies for installation.
Once these have all been installed, I navigated to Radrails.org and went to the Download page and followed the instructions for updating Eclipse. For Eclipse Galileo, navigate to Help > Install New Software. On the dialog that appears, I clicked the link "Available Software Sites", clicked "Add", then provided the URL provided on the Downloads page. Click 'Ok' on this screen and the previous one, returning to the 'Install' screen. In the drop down box at top, select the URL you just provided and once it loads, select the plug-in it lists below.
After the install is done, Eclipse will need to reboot. After it is reloaded, go to Window > Perspectives > Open Perspective.. and select the Rad Rails Perspective. Once this perspective opens, it will display a list of Ruby gems that need to be installed. Select OK to install the Gems.
I received numerous errors at this point, but I'm at a lost on how to fix it. I did copy the errors to examine another day.
Afterwards, I created a new Rails project, but I received an error stating that it could not install the latest version of Rails. But, I installed Rails in the first step, so as the instructions told me, I modified the config/environment.rb file to comment out the RAILS_GEM_VERSION variable, and re-ran the project. The starting project loaded, but as I was running through this tutorial, I ran into a couple of issues.
First, I received the following error:
Routing Error
No route matches "/say/hello" with {:method=>:get}To fix this error, I modified the Config/routes.rb file to recognize the new controller 'Say'.
Unfortunately I made the fix and started receiving this error:
uninitialized constant ApplicationController
To fix this, I followed the instructions at http://www.hackido.com/2009/03/quick-tip-solve-uninitialized-constant.html, which solved the issue.
Despite a few issues I've ran into so far, my experience of Ruby on Rails on Linux is MUCH better then my experience on Windows.
Thursday, May 6, 2010
Running Mercurial with Subversion
On the project I'm currently assigned to, we use Subversion as our version control system. Subversion is a great tool and is certainly a step up from the alternatives that we have used in the past. However, after reading a fair bit about Distributed Version Control systems (hginit), such as Mercurial, I've been wanting to play around with one of these systems in a real project. Code version control is not something that should be changed on a whim, so there's little hope for me to get Mercurial adopted department wide. But, the very nature of Distributed Version Control systems offer a way to utilize the system without forcing it upon others.
Distributed Version control systems offer 2 main benefits. First, they allow a user to keep a local repository of changes without having to pollute the central repository with changes that may break the build or unit tests. For those coding large components that take weeks to finish or those who are doing exploratory coding, checking code into a central repository is not feasible.
Another, less obvious benefit comes from how Distributed systems record revisions and perform merges. Whenever the code is checked into a local or central repository, a diff of the changes between the last revision and the new revision are stored. When a merge is performed, the code can replay the diffs to create a merged file. This will not solve every merge conflict, but it goes along way to make merges less painful.
Thanks to a Python package called hgsvn, I was able to download our project's code from the Subversion repository and place it in a local Mercurial repository in one easy step. The package hgsvn contains 3 scripts. The first, hgimportsvn, takes the URL to the SVN repository and then will download the code from the central into the current directory. After the code has been downloaded, it is then checked into a new Mercurial repository. This last part is done en masse and can cause problems if you have a very large code base and/or a very large file in that code base (as I would have very good reason to know).
If you run into this problem as well, 1 solution to try is to call hgimportsvn on the various sub-folders of the central project. In some instances, this can be made to work, but not in others and I can't find a rhyme or reason behind it.
The second script in the package is hgpullsvn, and it pulls the latest code from Subversion for the current directory and places it into the Mercurial Repository. Each revision in Subversion gets its own corresponding revision in Mercurial, and hgsvn keeps track of what Subversion revisions have been brought over to keep everything in sync. Unfortunately, it seems to overwrite in local changes that have not been committed into Mercurial, so ensure that Mercurial is up-to-date before running this.
The last script is hgpushsvn, and it commits any code you've checked into Mercurial into Subversion. While you can certainly use this tool, I've found it just as easy to use TortoiseHG to check the changes into Mercurial, and then use TortoiseSVN to commit those changes into Subversion when I'm ready.
Using Mercurial locally, Subversion on a central server, and hgsvn to synchronize the two, one can get a large benefit of using a Distributed Version Control System, without forcing the system upon others.
Distributed Version control systems offer 2 main benefits. First, they allow a user to keep a local repository of changes without having to pollute the central repository with changes that may break the build or unit tests. For those coding large components that take weeks to finish or those who are doing exploratory coding, checking code into a central repository is not feasible.
Another, less obvious benefit comes from how Distributed systems record revisions and perform merges. Whenever the code is checked into a local or central repository, a diff of the changes between the last revision and the new revision are stored. When a merge is performed, the code can replay the diffs to create a merged file. This will not solve every merge conflict, but it goes along way to make merges less painful.
Thanks to a Python package called hgsvn, I was able to download our project's code from the Subversion repository and place it in a local Mercurial repository in one easy step. The package hgsvn contains 3 scripts. The first, hgimportsvn, takes the URL to the SVN repository and then will download the code from the central into the current directory. After the code has been downloaded, it is then checked into a new Mercurial repository. This last part is done en masse and can cause problems if you have a very large code base and/or a very large file in that code base (as I would have very good reason to know).
If you run into this problem as well, 1 solution to try is to call hgimportsvn on the various sub-folders of the central project. In some instances, this can be made to work, but not in others and I can't find a rhyme or reason behind it.
The second script in the package is hgpullsvn, and it pulls the latest code from Subversion for the current directory and places it into the Mercurial Repository. Each revision in Subversion gets its own corresponding revision in Mercurial, and hgsvn keeps track of what Subversion revisions have been brought over to keep everything in sync. Unfortunately, it seems to overwrite in local changes that have not been committed into Mercurial, so ensure that Mercurial is up-to-date before running this.
The last script is hgpushsvn, and it commits any code you've checked into Mercurial into Subversion. While you can certainly use this tool, I've found it just as easy to use TortoiseHG to check the changes into Mercurial, and then use TortoiseSVN to commit those changes into Subversion when I'm ready.
Using Mercurial locally, Subversion on a central server, and hgsvn to synchronize the two, one can get a large benefit of using a Distributed Version Control System, without forcing the system upon others.
Tuesday, May 4, 2010
Challenges in Installing Mythbuntu 10.4
While I'm a .Net guy, I've been known to tinker with Linux now and again. I've built/rebuilt many machines using Red Hat 7.3, 9, Fedora Core 2, Fedora Core 4, and most recently, Mythdora (a Fedora Core release with MythTV bundled with it).
But, I've heard a lot of good things about Ubuntu, and there has been a lot of hype ahead of the Ubuntu 10.4. So when it came out last Thursday, I downloaded a flavor of it, Mythbuntu.
The installation of Mythbuntu had a couple of hiccups along the way however. On the first attempt, I realized that the system did not detect my main hard drive. After changing the pins on the Hard Drive to 'Master', I re-attempted the install, with the machine on its side. Here I ran into my first problem, before the install started, I received the error "Unable to find a medium containing a live file system".
Many posts suggest testing the CD, but as I already had reached the installation wizard, I was fairly certain that the CD was fine. After numerous attempts, I eventually re-arranged my Hard Drives and stood the tower up instead of having it on its side. This time the installation proceeded without an error.
There were only two other minor hiccups. First, I had an external hard drive which contained my entire Music library, plus a couple recordings that I saved. On XCFE, the windowing system that Mythdora installs by default, I could not get the Hard Drive to connect.
Each time, I've tried to install Linux in the past, I've always installed KDE and Gnome side by side. And each time I try to use Gnome, or some other windowing system, I find myself running back to KDE. While KDE is not always the most stable of the options (see below), it has access to all of the System Tools that I need in a nice Graphical interface. While any of the Administrative tasks could be accomplished in the terminal with commands and configuration files, I prefer the more Dummy-proof Graphical interface because when it comes to Linux, I am a dummy.
KDE, in this case, was the solution I was looking for. After I installed KDE and loaded KDE up, I was able to get the Hard Drive to connect by simply plugging in the drive.
The last glitch I encountered in the process was a minor nuisance. While copying the music files over, the Window Manager for KDE, Dolphin, crashed. While I don't know exactly what caused the error, I suspect that the total size of the files was the cause, as I was able to copy a smaller subset of the files.
In the end however, I am quite impressed with the changes that I see in the latest versions of the Linux kernel, KDE, MythTV, and with Ubuntu in general. The issues I encountered were minor enough that I could work around them. I'm not certain if Ubuntu 10.4 will upset the balance of the Desktop operating systems, but it is a step in the right direction.
But, I've heard a lot of good things about Ubuntu, and there has been a lot of hype ahead of the Ubuntu 10.4. So when it came out last Thursday, I downloaded a flavor of it, Mythbuntu.
The installation of Mythbuntu had a couple of hiccups along the way however. On the first attempt, I realized that the system did not detect my main hard drive. After changing the pins on the Hard Drive to 'Master', I re-attempted the install, with the machine on its side. Here I ran into my first problem, before the install started, I received the error "Unable to find a medium containing a live file system".
Many posts suggest testing the CD, but as I already had reached the installation wizard, I was fairly certain that the CD was fine. After numerous attempts, I eventually re-arranged my Hard Drives and stood the tower up instead of having it on its side. This time the installation proceeded without an error.
There were only two other minor hiccups. First, I had an external hard drive which contained my entire Music library, plus a couple recordings that I saved. On XCFE, the windowing system that Mythdora installs by default, I could not get the Hard Drive to connect.
Each time, I've tried to install Linux in the past, I've always installed KDE and Gnome side by side. And each time I try to use Gnome, or some other windowing system, I find myself running back to KDE. While KDE is not always the most stable of the options (see below), it has access to all of the System Tools that I need in a nice Graphical interface. While any of the Administrative tasks could be accomplished in the terminal with commands and configuration files, I prefer the more Dummy-proof Graphical interface because when it comes to Linux, I am a dummy.
KDE, in this case, was the solution I was looking for. After I installed KDE and loaded KDE up, I was able to get the Hard Drive to connect by simply plugging in the drive.
The last glitch I encountered in the process was a minor nuisance. While copying the music files over, the Window Manager for KDE, Dolphin, crashed. While I don't know exactly what caused the error, I suspect that the total size of the files was the cause, as I was able to copy a smaller subset of the files.
In the end however, I am quite impressed with the changes that I see in the latest versions of the Linux kernel, KDE, MythTV, and with Ubuntu in general. The issues I encountered were minor enough that I could work around them. I'm not certain if Ubuntu 10.4 will upset the balance of the Desktop operating systems, but it is a step in the right direction.
Subscribe to:
Posts (Atom)