Mattenoble.com - Articles

Ruby Blocks, Illustrated.

Mon, 24 Aug 2009 23:54:41 +0000

Blocks are sort of tricky when you first come to Ruby; I decided to make a quick little illustrated guide to using them.

buy_car accepts a block, denoted by the ampersand before the parameter &block. yield car passes the newly created car object to the block. The block then sets the color of that car object. Finally buy_car sets person.car to that newly colored car.

This is obviously a hugely simplified example, but hopefully it’ll help someone understand blocks a little better.

Send Your Database With Your Commits.

Fri, 14 Aug 2009 03:29:06 +0000

Let me start off by saying, I like to have my development database full of data while working on a project. It lets me visualize the end result a lot easier. Whether that’s good practice or not is another story.

I’m working on a project that has some pretty text heavy data. It became a huge pain in the ass to replicate the data I had on each machine I work on. So I came up with a super simple solution. I use Git and MySQL, so I combined the 2 into easy shell commands.

Add these to ~/.bash_profile:

  1   function gg() {
  2     mysqldump -u user --skip-extended-insert database_name > ./sql/database_name.sql
  3     git commit -v -a -m "$*"
  4   }

Usage: gg message of the commit. First it dumps out the contents of your database into a file, ./sql/database_name.sql then, assuming database_name.sql is already in your Git index, it will commit everything, database contents and all.

The next part of this is the component on the opposite end, the git pull part:

  1   function gl() {
  2     git pull
  3     mysql -u user database_name < ./sql/database_name.sql
  4   }

Now you can call gl and it will first pull down any new stuff from your upstream Git repo, then apply the database_name.sql to your database.

This is a very dirty way of doing it, but it works pretty well for me.

Speccer: Bootstrapped Continuous Integration

Wed, 11 Mar 2009 04:47:05 +0000

Continuous Integration is pretty awesome and there’s a few options out there in the Ruby world. Most of them are more than what I want for my personal projects though, so I decided to hack together my own. I mainly use RSpec and all I wanted was something that would run my spec every time I save it or it’s corresponding class/module. Enter, Speccer.

Speccer really has two parts, a TextMate command that replaces the normal Apple + S shortcut and the command line script that “receives” these saves. Set up your TextMate command like the image above, making sure to duplicate the settings exactly. Then copy in the code below.

  1   #!/usr/bin/ruby
  2   require 'fileutils'
  3   require 'ftools'
  4   
  5   logpath = File.expand_path( "~/log" )
  6   
  7   unless File.directory?( logpath )
  8       FileUtils.mkdir( logpath )
  9   end
 10  
 11  log = File.open( File.join( logpath, "/spec.log" ), "w" )
 12  log.write "#{ Time.now }\n"
 13  log.write "#{ ENV['TM_FILEPATH'] }\n"
 14  log.write ENV['TM_PROJECT_DIRECTORY']
 15  log.close

Basically all this does is creates _/log if it doesn’t exist, opens /log/spec.log and writes the time, file saved and the project directory to it, every time you hit Apple + S. This acts as a sort of Queue, but in reality the file only ever has one record in it at a time. This is how we let the script in the next part know about when we saved the file.

Create /usr/local/bin/speccer (or in whichever bin you want) and add the following:

  1   #!/usr/bin/ruby
  2   require 'ftools'
  3   
  4   log = File.open( File.expand_path( "~/log/spec.log"), "r" )
  5   
  6   loop do
  7   
  8       trap("INT") { |this| puts ""; exit this }
  9   
 10      last_time = @time
 11  
 12      log.seek(0)	
 13      record = log.read.split("\n")
 14  
 15      @time         = record.first
 16      @saved_file  = record[1]
 17      @proj_path  = record.last
 18  
 19      begin
 20  	   
 21          unless @saved_file.include?( "_spec.rb" )
 22              saved_file_array = @saved_file.split( "/" )
 23              lib_position       = saved_file_array.index( "lib" ) 
 24              spec_filename   = File.basename( @saved_file, ".rb" ) << "_spec.rb"
 25              spec_dir            = saved_file_array[ lib_position+1..saved_file_array.length-2 ].join( "/" )     
 26              @spec               = "#{@proj_path}/spec/#{spec_dir}/#{spec_filename}"
 27          else
 28              @spec = @saved_file
 29          end
 30  
 31          if last_time != @time
 32              system("clear")
 33              puts @time
 34              system("spec #{@spec} -c -f specdoc")
 35          end
 36  	
 37      rescue
 38      end
 39  
 40      sleep 1
 41  	
 42  end

This actual speccer script first opens the log file then just continuously checks to see if the Date is the same as the previous run through. If it is, it won’t do anything, but if it’s new it’ll run the spec. The if-statement in the middle just figures out which spec is associated with the Class/Module file being saved by breaking apart the file’s path and reconstructing it within the spec/ folder. Speccer assumes you set up your spec/ directory in the same structure as your lib/ folder and name your specs classname_spec.rb. Save the script and chmod 755 speccer and you’re set.

Now just run speccer then go writing your tests/specs and the file needed to make them pass. Every time you save one of them it’ll automatically run. Quick and easy continuous integration for the solo developer.

Be Your Own User

Tue, 03 Mar 2009 19:40:04 +0000

I constantly have ideas floating around in my head for cool and useful web-services or products, the problem is that they’d never be useful to me. Most of them would be great for homeowners, teachers, etc. but I’d probably never use them after launch. This is why I think a lot of web-based business fail so often, they aren’t their own users.

Chris Wanstrath gave a great keynote at Startup Riot where he told his tale of FamSpam and GitHub, which illustrates my point perfectly. He talks about a ton of other great things as well; check it out. In the end GitHub was what he loved to develop and use, which made it better for everyone. For an idea to be successful (in any form of the word) it needs to be brilliant. I don’t mean brilliant like having the most ridiculous algorithm in the world (although sometimes that does work) or having all PhD’s working for you. I mean a product that is 100% useful to it’s audience and continues to be a great experience for them.

Your high school teacher who told you that if you do what you love, you’ll never work a day in your life, was so right. I forked that quote and changed it: if you create what you love, you’ll always have a user. What I mean by this is, create something that is useful to yourself and in the end it’ll be a better product because of it. GitHub is what it is today because Chris and PJ use it themselves, everyday. You need to take it a step past just believing in what you’re doing, you need to use what you are doing.

Being your own user gives you a front row seat to see what could make it a better product. You can be selfish; develop features and fix bugs that bother you, as a user. You’ll be making it better for yourself, but at the same time all your other users. From a user-experience point of view, it’s easier to put yourself in the shoes of your customers, if you are one (obviously). You don’t have to pretend to be part of them or try to speak their language, you naturally will and other users will appreciate that.

Rock Your Own Dynamic Methods In Rails

Wed, 25 Feb 2009 01:50:11 +0000

method_missing is a piece of Ruby’s meta-programming arsenal that’s pretty powerful in my opinion. It allows you to call methods that don’t actually exist, but still do something useful with it.

I’m trying to keep this short and sweet, so imagine you have a blog like this one. You have Article, Comment and Category models and you want a way to find all Articles/Comments/Categories by calling find_all_( articles | comments | categories). So instead of create a find_all_* method for each resource, we’ll let method_missing do the work for us:

  1   class ApplicationController < ActionController::Base
  2       
  3       private
  4       def method_missing(method, *args)
  5           resource = method.to_s.split("_").last
  6           if method.to_s.match /^find_all_/
  7               resource.singularize.camelize.constantize.find(:all)
  8           end
  9       end
 10  
 11  end

This is a very simple example of what method_missing can accomplish but it’s a relevant one at least. method_missing takes two main arguments, the name of the method the user tried to call and the arguments passed through to that non-existent method.

If you follow a find_all_( model ) naming convention the last word will always be the Model. In my example, first thing we do is set resource to that String representation of the Model (the last word of the find_all_* method). Next, we make sure the call is actually to a find_all_* method. The long “-ize” method chain makes the String singular ( “comments”.singularize #=> “comment” ), uppercases the first letter ( “comment”.camelize #=> “Comment” ), constantizes it ( “Comment”.constantize #=> Comment ) and finally calls a normal old find(:all) on it and returns the result. Now you can do this in your controllers:

  1   # CommentsController.rb
  2   @comments = find_all_comments
  3   
  4   # ArticlesController.rb
  5   @articles = find_all_articles
  6   
  7   # CategoriesController.rb
  8   @categories = find_all_categories

My example only shows one “magic method” and is only a bit more readable, but you could extend it to check for find_recent_ or maybe find_10_ pretty easily.