Thinking In Rails » Instructions

Ruby and Rails on Windows Finally Simple?

alan — Tue, 18 Jan 2011 17:36:06 +0000

Remember a bit ago when Wayne E. Seguin of RVM Fame (I think he should legally change his name to that BTW) was hired by Engine Yard to do, among other things, help get Rails working properly on Windows? Well, looks like in only weeks of work, there is now Ruby and Rails on Windows in a Single, Easy Install.

If this works as advertised (haven’t had a chance to test it yet), then this is huge in giving Ruby on Rails a big edge into the Windows world, and eliminates the need for such hacky (sorry Curtis) solutions like this, previously the “best” way to run Rails on Windows

Not only that, but this gives Rails on Windows almost the same advantage it has for development on Mac and Linux: stupidly low barrier to entry. Rails has always been easy to program in, but you had to get it up and running first. On Mac it’s been included in the OS for a few versions of Mac OS, on Linux it’s been as easy as “apt-get install rails” (or equivalent), and now on windows it’ll be as easy as “go to http://railsinstaller.org/, download and clicky clicky”.

Rails 3 Cheatsheets

alan — Sun, 02 Jan 2011 04:44:37 +0000

Awesome work by Envy Labs (of Rails for Zombies and EnvyCasts fame) creating Ruby on Rails 3 Cheat Sheets. They look great, are well laid out, and are great to throw in your Rails PDF folder to look at when needed.

Anatomy of A Ruby Gem

alan — Fri, 07 May 2010 03:01:22 +0000

If you’ve ever installed a Ruby gem off of gemcutter or github, you’ll know that you run the gem install command and when it’s completed you magically have access to use it through ‘require ’. If you’ve ever looked into the source you might want to have an idea of what goes where and how it all works.

First of all, I’m fairly new to this myself, so it’s very possible that I’ll miss something vital, please feel free to flame me in the comments, as long as you tell me where I messed up so I can fix it

Lets take a couple of examples. One is a gem for dissecting XML feeds that I just discovered, feedzirra, the other is a bit more complex, Cinch, the IRC micro-framework I was talking about a few days ago. Starting with feedzirra, here’s the listing of the files and directories in the root of the gem, I’ll take them one by one.

README.rdoc
README.textile
Rakefile
feedzirra.gemspec
lib/
spec/

README.*

The first two are pretty obvious, they are the README files with GitHub (and others) automatically parses out and displays when you hit the main project page. Here is a list of the README formats that github supports, as well the order that it will display them in. Here the author has included a README file as well as a README.textile (texttile is a simple markup language), and github displays the REAMDE.[something] first.

Rakefile

Rake, as you know is the ruby version of “make” the venerable Unix utility. Inside the Rakefile you find a formatted set of rules in the form of tasks and targets. Hit this tutorial for some more details. The short story is that there are targets (with prerequisite/dependency information) such as install, uninstall, and release, supporting functions if needed, and some boilerplate info (description, name, contact, etc). The targets can be anything it seems, for example Feedzirra has a task for releasing and uploading a new release, whereas cinch just has an ‘install’ task. Rake is used a lot to help the creation of gems, but I don’t think that it’s used in the actual installation.

[gemname].gemspec

Here is the meat of it all, the gemspec file consists of the control information for the entire gem. If you check out this tutorial you’ll see that it’s ruby code and can be created with a few utility scripts including Rake, and has some of the following information:

Gem name and information (homepage, description)
Author information (email, etc)
Version and Date
Other gem dependencies
One or more boolean flags (ie: is there documentation that needs to be generated)
A file list of what files need to be installed
A list of executables of files that will be put in the bin directory when they’re installed

lib/ And Other Files or Directories

Basically what’s left are directories of files that are going to be installed on your system. Of course, “lib” isn’t always going to be there, but for most gems that are adding a new class into your ruby environment, it will be. The gemspec file has the list of the files and directories that will actually be taken out of the gem and installed into your system. There are different ways to specify these files in gemspec, as you’ll see by comparing the s.files directive in the Cinch gemspec and the Feedzirra gemspec.

Inside the lib/ directory there will generally be one or two main files. In Cinch you have:

cinch/
cinch.rb

This is the module that is loaded when you do a ‘require “cinch”‘ and the cinch/ directory has the supporting files. The cinch.rb module file has a bunch of requires of “cinch/irc”, “cinch/rbase”, etc which are the sub-modules that it uses. More on Modules vs Classes in a later post.

spec/

This will be the specs that the author has put in his source tree and includes so that other developers can look and use their tests. Again, this isn’t going to always be there, but it seems to be very in vogue to do this whole “testing” thing, and including your spec or test directory is The Right Thing To Do.

File Locations

So when you run ‘gem install [foo]‘ where do the files go? Lets use Cinch again for this one as it’s fairly simple. Here’s a listing of the files that are in the source on github:

./LICENSE
./lib/cinch.rb
./lib/cinch/irc
./lib/cinch/irc/parser.rb
./lib/cinch/* [ more library module files ]
./examples/hello.rb
./examples/* [ more example files ]
./README.rdoc
./spec/irc/parser_spec.rb
./spec/* [ more specs ]
./Rakefile
./cinch.gemspec

(Note some of the directories are abbreviated).

When you do a gem install the files moved into the path defined in $GEM_HOME thusly:

cinch/lib           => $GEM_HOME/gems/cinch-0.2.6/lib
cinch/examples      => $GEM_HOME/gems/cinch-0.2.6/examples
[...]
cinch/README.rdoc   => $GEM_HOME/gems/cinch-0.2.6/README.rdoc
                    => $GEM_HOME/doc/cinch-0.2.6/ri/*
                    => $GEM_HOME/doc/cinch-0.2.6/rdoc/*

Nothing hugely interesting, files are basically just moved into your gem home directory under a directory named with the name and version of the gem you’re installing. Note that the doc/*/ri and doc/*/rdoc files are auto-created when the gem install runs, if you don’t pass the –no-ri or –no-rdoc flags of course. The internal magic in rubygems and ruby allow your programs to find the gems when they are ‘required’.

How to Examine A Gem

One of the nicest ways to play with these things, and what I did was to use RVM and then doing a gem install, as well as using git clone to pull down the source files from github. RVM, combined with it’s great gemset support, is a great tool and makes it really easy to add, remove, and play with no fear of mucking things up.

Conclusion

So that’s about it for the normal library gems that you’ll find on github. Hopefully you now understand a bit more about how a gem is structured and what happens when you install and use gems, and how they will interact with each other. I found lots of resources out there, including some great stuff on how to create your own gems, gemspec files, and so on, listed below.

Additional Reading

Evolving A Simple Twitter to Blog Ruby Program Part 1

alan — Wed, 05 May 2010 04:14:57 +0000

In a “quick” and dirty exercise I built a little ruby program to grab my twitter posts and colate them into a list for posting a “tweets of the week” type blog post. It was a lot more about figuring out how to do it than the actual output (I’d hope you just follow me on twitter than rely on me posting my tweets here). Tonight at the FV.rb meeting @dkubb helped me a lot in pointing out some glaring non-rubyisms and I thought that going through some of the changes might help others moving from “old school” programming (structured, functional, perl-y) to “new hotness” programming (object oriented, yeilds, and awesomeness).

I started out with this code in a gist. Nothing hugely bad, it pulls in either a URL or a file, parses the XML for the status updates, and for each one does some HTML replacement (@user, #hash, and URLs get auto-linked) and then spits out some HTML that can be copied and pasted into a blog entry.

Starting Off

The first step was figuring out how to parse the XML. A bit of googling found some possibilities. Hpricot, libxml-ruby, and Nokogiri. The first post I saw noted that libxml-ruby was the fastest, which makes sense as it’ll be pretty close to the bare metal C libraries, so I took a run with that. Not great success, the biggest challenge was figuring out how Ruby dealt with XML structure. There was a lot of mucking around in IRB.

ruby-1.8.7-p249 > require 'xml'
 => true
ruby-1.8.7-p249 > parser = XML::Parser.file('twitter.xml')
 => #
ruby-1.8.7-p249 > doc = parser.parse
# snip xml spew to STDOUT
ruby-1.8.7-p249 > doc.class
 => LibXML::XML::Document
# Hmm.... does find work?
ruby-1.8.7-p249 > s = doc.find('/status')
 => #
ruby-1.8.7-p249 > s.methods
# snip list of methods, and searching for what to do
ruby-1.8.7-p249 > s.each { |node| puts node.class }
 => nil
ruby-1.8.7-p249 > s.each { |node| puts node.inspect }
 => nil
# WTF? OK, so what now then?

It was a bit frustrating, though probably mostly because I just didn’t grok how the XML was being represented internally, and thinking of it more like a Perl hash-of-hashes than whatever libxml-ruby was using. So I moved on. (Ironically while re-doing some of this for this article I went back and was running the commands figuring now I would get it, and failed miserably

Next I looked at Hpricot, but the syntax in the readme and examples scared me away.

Starting Progress on the First Iteration

Someone at work suggested that Nokogiri was the way to go, and realizing that parsing a few kb of XML probably wasn’t going to run me into any performance issues, I took a run at it with this. I soon found that having a static XML file would be the easiest for testing, so I saved twitter.xml in the same directory as I was running IRB out of and played some more.

Much better. Then to find out to get a list of the statuses:

ruby-1.8.7-p249 > require 'nokogiri'
 => true
ruby-1.8.7-p249 > doc = Nokogiri::XML(File.new('twitter.xml'))
# snip
ruby-1.8.7-p249 > doc.class
 => Nokogiri::XML::Document
ruby-1.8.7-p249 > doc.xpath('/status')
 => []
ruby-1.8.7-p249 > doc.xpath('//status')
# snip lots more xml spew and more testing until...
ruby-1.8.7-p249 > doc.xpath('//status').each { |node| puts node.xpath(".//text").first.content }
# snip lovely output of each of the tweets in the xml file

Ok, so now I could run “.each()” on this, having discovered that the xpath() function basically allowed me to get a list of XML nodes with that path, and then I could get a list of node data from that, remembering to use the “start from current node” syntax (using the ‘.’ to represent the current location in the tree).

The next steps were (relatively) easy. Looping through each status, get some information (time, status ID, content, etc), format that into HTML, find and implement a couple of “convert @user to an HTML link” bits of code I found online, and voila, first iteration was completed and working.

Now With Some Expert Advice

So after reading the What I wish I had been told a year ago post, I figured the next stage was to convert it to a class, make it more ruby-y, and give it some tests. Dan Kubb of DataMapper fame thankfully answered my question to help and moved me on to this current version with some helpful advice.

I’ll continue this later on this week with Part 2, in which I iterate into more awesomeness!

Rails Authentication In a Gist

alan — Mon, 15 Mar 2010 18:09:35 +0000

I’ve been trying to get some more use onto my github account, and to this end I’ve copied my work on the rails authentication (a rip from Adian’s work, he gets full credit) over to this gist. Basically this is just exactly what Aidan did originally, but in a more cut-and-paste friendly format. I’ve also included a couple of minor fixes to it (ie: preventing the user password from being nuked on save and some other minor changes that were found in the comments on the original blogpost). I also haven’t included any of the tests (bad Alan, I know), but my thought is that you’re going to have your own test system, be it Rspec, Cucumber, or whatever) and putting in some tests there might be counter-productive if you’re already rocking with [insert your testing framework here].

The idea really is just that the next time I need to put in some authentication I don’t have to search as far, or go through as long a page, but can just grab the gist, copy and paste the needed chunks, and go.

The Challenge of Learning Ruby

alan — Sat, 09 May 2009 19:05:40 +0000

One of the biggest challenges I have as a Perl programmer is dealing with the change in the underlying language that Rails is written in, namely, Ruby. To help with this I’m working myself through Project Euler to do a couple of things

Force myself to work through problems in Ruby
After solving the problems, see how others did them

The last item is the most important. I generally start off in a very perl-ish, procedural way. When the answer arrives it’s a real eye opener to see how others solve the issues. For example, for one problem after solving it in what I thought was a fairly elegant way (a couple of short functions), seeing the first Ruby based solution in the forums the programmer had used a quick Monkey Patch (modification of the base Integer class in this case) to simply add a function that did what he wanted. I had never even thought of this! I knew the capabilities of Ruby to do this, but my brain just hadn’t triggered the idea that this was a good solution.

The pros and cons of Monkey Patching are a discussion for another day of course

I’m fairly proud of myself, I have worked through some of the problems and even just wrote the following line of code… on purpose!

(1..100).inject { |s,i| s*i }.to_s.split(//).inject(0) { |s,n| s + n.to_i }

I admit that my perl-ish nature of doing it all on one line came out a bit The actual solution that I came up with was a bit nicer of course!

The Ins and Outs of Serving Rails

alan — Sat, 02 May 2009 00:16:33 +0000

One of the biggest failures I found starting in Rails was the lack of a standard for hosting. In the mod_perl or php world, the standard apache distribution has everything needed built in to the standard distribution, and you’d be hard pressed to find a hosting system (of any size) that doesn’t have them.

Rails on the other hand, seemed to have a boatload of ways to serve itself. There doesn’t seem to be a “standard” webserver. You have mongrel, nginx, phusion passenger (mod_rails), lighttp… the list goes on. And it doesn’t seem that there’s an accepted “proper” way to do the webserving yet. Maybe it’s a case of different tools for different cases, maybe it’s just a symptom of a system that’s relatively young (compared to the apache/perl/php world).

Obviously the build in webserver (ruby script/server) will always be there, but if you’ve got your first app up and ready, and your hosting provider either doesn’t supply rails hosting as an option, or their setup isn’t up to the task I discovered an interesting (and most importantly, free) solution.

Check out Heroku. It’s a free, online hosting system with a fairly unique method of using git to allow you to simply run “git push” in your app directory and have any changes pushed up to their hosting cloud. Now granted, they are a commercial company and you only get the equivalent of the lowest level of hosting (a “Blossom” plan with 5mb of disk space), but this is perfectly adequate for a personal project or learning application. And again, it’s free

Dead Programmer Society has a nice write up on the whole deal.