Archive for the ‘ruby’ Category

Mountain West Ruby Conf Rocked This Year

Monday, March 22nd, 2010

Mountain West Ruby Conf this year was awesome. I totally had a blast.

It was the third time I’ve gone to it. It was my first conference and still is my favorite. I got to meet Matz, I gave a lightning talk, I met all sorts of interesting people and I learned a bunch of new things. To quote Matz, MountainWest RubyConfはすばらしかった。

Matz & me

Things to revisit

  • Rack(1.1.0 in particular)
  • Chef(looks better than the last time I poked at it)

New things(to me)

  • RVM(rvm looks pretty handy, especially for cross vm library development)
  • Hubris(this might be a neat way to get into Haskell development)

My lightning talk

Usdo. Misspellings turn into gem-fu practice

Saturday, November 14th, 2009

Indian Paintbrush
A few weeks ago, during a period of frustration, I found myself repeatedly mistyping ‘sudo.’ So, in a fit of silliness I wrote a short script to insult me when I did it, and put it in the path.

Later, I packaged it as a gem, because a) I had never built a gem with an executable and b) gems are a great way to share things.

The end result?

http://github.com/baroquebobcat/usdo

It isn’t particularly smart, but I happen to find it funny. It also showed to me how far gem packaging has come. Gemcutter and Jeweler make building and distributing ruby gems freakishly easy. This is especially awesome in light of the recent announcement that gemcutter is going to be the default gems host(though at rubygems.org)

How I put it together

I ran jeweler to create the default directory structure and added a bin dir to it, for the files I wanted to end up in the path.

$ jeweler usdo
cd usdo
mkdir bin

I put my gist from before in the bin directory, and set up git.

Set up my gem info in my Rakefile

#...
Jeweler::Tasks.new do |gem|
  gem.name = "usdo"
  gem.summary = %Q{adds usdo command to ridicule mispellings of sudo}
  gem.description = %Q{...}
  gem.email = "ndh@baroquebobcat.com"
  gem.homepage = "http://github.com/baroquebobcat/usdo"
  gem.authors = ["Nick Howard"]
end

then did the jeweler gem initialization dance

rake version:write
rake gemspec
rake install

Testing it out:

$ usdo -l
----USDO----
    You mispelled sudo
    You can't do anything, you can't even spell sudo
    are you really sure you want to try running
    'sudo -l'????

Now that was working, to send it up for distribution.

Jeweler is awesome and now has gemcutter support. I followed the jeweler README‘s directions on uploading to gemcutter. Which makes pushing your gem as simple as

$ rake gemcutter:release

Awesome.

Check out my code if you want.

Scrubyt On A Server Workaround

Wednesday, November 4th, 2009

So you got some awesome scraper script and you want to deploy it to your server but you don’t want to have to install firewatir. Or, you don’t want to pull in the firewatir gem because you are not planning on using it. Whatever.

Problem: scrubyt
requires the firewatir gem

Hacky Solution: comment out the require

But where you ask?

/lib/scrubyt/core/navigation/agents/firewatir.rb line 1

This works on the current rubyforge version(0.4.1).
Recommended: Or, you could just use the version on github that is fixed(see commit)

grab the files via git or archive from github.com/scrubber/scrubyt

then

cd scrubyt-somehash
rake gem
gem install pkg/scrubyt-0.4.26.gem

Not as nice as using jeweler where you can just `rake install` it, but pretty nifty none the less.

OpenID Provider in Sinatra

Thursday, September 17th, 2009

As part of a personal project, I have been working on an OpenID Provider written in Sinatra.

The idea is to make it ridiculously easy to set up an openid provider within a rack middleware stack.

It’s just a single sinatra app without any tests using code I cribbed from the example rails implementation in ruby-openid. But, I intend on rewriting it once I get a better feel for how it should go.

The problem I face is a matter of interface, specifically application programming interface. I want it to be simple to use. But that is alittle complicated underneath.

Today I read The Little Manual of API Design(pdf), which made me think about my approach to building things in, I think, a good way. It talks about the goals of building a good API and boils it down to five things.

  • Easy to learn and memorize
  • Leads to readable code
  • Hard to misuse
  • Easy to extend
  • Complete

For my app, complete is pretty easy. I’ve boiled the interface down to two main things:

  • OpenID Store
  • User/Identity

First, for an openid app, you need an openid store to put all the associations, nonces etc.

Then, the meaty bit, the users and their identities. The stuff we are serving up. My current thought is to have one of the app’s parameters be a lambda or Proc that returns the current user, or nil when called with the request.env. So that using it would look somewhat like this.
It’s kind of ugly, but I like it better than some of my other options. One other way I could get the user to the app would be to use rack request hash. I could have users put the user object in the request env before the OpenID provider gets it and tell the provider where to look. But the problem with that is that I would need to add another middleware layer that added the user to the environment. That would look something like this:

Maybe that would be better.

Ultimately I just need to pick something and run with it.

The thing I wonder about though, is what is the most idomatic way of doing this. Using the most rubyish, most Rack like interface would make it easier to learn and memorize.

RubyNation: Preparing for 1.9

Thursday, June 25th, 2009

David A Black — Preparing for 1.9

“open a 1.8.6 [irb] and you’ll see all the stuff I’m showing you not work”

David showed us some of the differences between the 1.9 and 1.8.6 with live code demos.

generic to_a gone. I’d seen it in the docs for 1.8.6, but never used it. It doesn’t make sense for a number to know how to wrap itself in an array. Seeing it go makes me happy.

Strings

String no longer mixes in Enumerable. Instead of each, et al it has new each_* methods.

  • each_byte –again duh
  • each_char — duh
  • each_checkpoint — gives you the bits for the would be character regardless of encoding
  • each_line –duh
"string"[0]
# 1.9
#=> "s"
#1.8.6
#=> 115

str[0] returns a string of length one rather than a Fixnum representing the nth byte as 1.8.6 does. To get the same behavior in 1.8.6 you need to write str[0,1] which is not at all intuitive. I had run into that a few times and always thought it was odd for a language with such an awesome string manipulation toolkit to do.

case statements no longer have the optional ‘:’. when x: blah won’t work, it will have to be when x; blah

rubygems now part of core, so no need to require ‘rubygems’ before requiring a gem. Sweet.

{1,2,3,4} does not turn into {1=>2,3=>4} you always need the hashrockets(=>).

Also, hashes retain insertion order so you can now rely on what use to be coincidental. Cool. This also means that you can use position as well as key to refer to values…which confuses me because hashes can have numeric keys.ruby

Block local variables(let () anyone?). done like so

local_var = 'something to not overwrite'
do |a;local_var|
  local_var = cool_intermediate_method a
  some_method local_var
end
# local_var == 'something to not overwrite'

String encoding got some smarts. Ruby knows more about how to deal with string encoding in 1.9. David showed us some examples. If you change a string to ASCII and then try to add a Unicode character to it, the system will convert the string’s encoding to Unicode first.

Enumerators.
Like java iterators, only with more awesome. Apparently, these have been around for a while(1.8.7), but I hadn’t used them before. You can do cool stuff like:

e = (1..3).cycle
e.take 5
 #=> [1, 2, 3, 1, 2]
e2 = e.each_slice 2
e2.take 5
  #=> [[1, 2], [3, 1], [2, 3], [1, 2], [3, 1]]
e3 = e.each_cons(2)
e3.take 5
  #=> [[1, 2], [2, 3], [3, 1], [1, 2], [2, 3]]

Then there is the new BasicObject. It is like Jim Weirich’s BlankSlate, but baked in. Objects with no default methods are really handy for building DSLs, like builder.

a = BasicObject.new
p a
#=> NoMethodError: undefined method `inspect' for #

I want to talk about some of the other presentations from RubyNation, but I have been busier recently than I thought I would be. So, we will see what happens.

For David A. Black’s own stuff, check out his blog.

Also, according to my admin interface, this is my 100th post. Cool.

RubyNation Etc

Tuesday, June 16th, 2009

I am back from RubyNation and reapplying my nose to the grindstone, wheel to the asphalt and hands to the keyboard. I am still planning a big summary and commentary post based on my notes, but as I started working on that, I realized it might need more than one night to see to completion.

So, I give you this:

Me
Hyatt Ceiling Pastry and Me in My Hat

Carrot Cake(Thanks Hyatt catering)

Mmm Carrot Cake

And Lys, the cat who is strangely fond of white ceramics.

Lys, Sink and You

Tune in some indeterminate point in the future for a fuller update. Or, you could just read this guy’s take.

Sprinkle and Passenger Stack

Tuesday, April 21st, 2009

I started using sprinkle with the passenger-stack recently. So far, it has been easy to get started with and fairly intuitive. I chose it rather than puppet or some of the other declarative server configuration DSL because it doesn’t need to install anything extra on the server to work.

This is great for the kinds of things I have been working on, because they are fairly small, and don’t need many servers.
I think if I were managing more things, I might choose puppet, because the overhead would be justified.

One of the things I like about sprinkle, is the DSL is pretty straight forward, eg the package definition for passenger looks like this:

package :passenger, :provides => :appserver do
  description 'Phusion Passenger (mod_rails)'
  version '2.1.3'
  gem 'passenger' do
    post :install, 'echo -en "\n\n\n\n" | sudo passenger-install-apache2-module'

    # Create the passenger conf file
    post :install, 'mkdir -p /etc/apache2/extras'
    post :install, 'touch /etc/apache2/extras/passenger.conf'
    post :install, 'echo "Include /etc/apache2/extras/passenger.conf"|sudo tee -a /etc/apache2/apache2.conf'

    [%Q(LoadModule passenger_module /usr/local/ruby-enterprise/lib/ruby/gems/1.8/gems/passenger-#{version}/ext/apache2/mod_passenger.so),
    %Q(PassengerRoot /usr/local/ruby-enterprise/lib/ruby/gems/1.8/gems/passenger-#{version}),
    %q(PassengerRuby /usr/local/bin/ruby),
    %q(RailsEnv production)].each do |line|
      post :install, "echo '#{line}' |sudo tee -a /etc/apache2/extras/passenger.conf"
    end

    # Restart apache to note changes
    post :install, '/etc/init.d/apache2 restart'
  end

I had some problems, like the version of passenger in the passenger-stack master branch on github is a point release behind the phusion’s, which is annoying because when passenger updates itself to 2.2.0, the configs are not updated and apache tells you it can’t find the mod_passenger.so file.

Also, it puts the passenger config in a slightly unusual place(/etc/apache/extras), for an apache module, as well as appending stuff to /etc/apache2/apache2.conf. This prevents it from idempotency, because if you run it twice, it will add additional lines to the config files. So, in the vein of scratching my own itch and what have you–you know, that open source thing–I rewrote it.

package :passenger, :provides => :appserver do
  description 'Phusion Passenger (mod_rails)'
  version '2.2.0'
  gem 'passenger' do
    post :install, 'echo -en "\n\n\n\n" | sudo passenger-install-apache2-module'

    # Create the passenger conf file
    loading = %Q(LoadModule passenger_module /usr/local/ruby-enterprise/lib/ruby/gems/1.8/gems/passenger-#{version}/ext/apache2/mod_passenger.so)
    conf = %Q(PassengerRoot /usr/local/ruby-enterprise/lib/ruby/gems/1.8/gems/passenger-#{version}
PassengerRuby /usr/local/bin/ruby
RailsEnv production)

    post :install, "echo '#{conf}' >> /etc/apache2/mods-available/passenger.conf"
    post :install, "echo '#{loading}' >> /etc/apache2/mods-available/passenger.load"
    post :install, 'a2enmod passenger'
    # Restart apache to note changes
    post :install, '/etc/init.d/apache2 restart'
  end

  verify do
    has_file "/etc/apache2/mods-enabled/passenger.load"
    has_file "/usr/local/ruby-enterprise/lib/ruby/gems/1.8/gems/passenger-#{version}/ext/apache2/mod_passenger.so"
    has_directory "/usr/local/ruby-enterprise/lib/ruby/gems/1.8/gems/passenger-#{version}"
  end

  requires :apache, :apache2_prefork_dev, :ruby_enterprise
end

Now, it takes advantage of the debian convention of keeping module loading and configuration files go in /etc/apache2/mods-available that are symlinked into /etc/apache2/mods-enabled by the a2enmod utility. This is immediately obviously awesome to anyone who has contemplated the horror of trying to parse the apache main config to see if the stuff they want to add is already there and needs updating.

I also added some verifiers so that it won’t rerun if there were no errors. Pretty cool, no?

Ruby is awesome–lazy scripting

Monday, April 20th, 2009

Sometimes I find myself doing tedious things like trying to grab the dollar amounts from text copied from the web. More and more often I turn to irb for these sort of things. For example, a few minutes ago, when I wanted to analyze my spending habits I copied the data into a file and manipulated it.

I grabbed the lines from the file

irb(main):001:0> lines = File.readlines 'transactions'


And selected those with dollar signs (with a little effort–sometimes I forget whether it is =~ or ~=).

irb(main):002:0> monies = lines.select {|l| l ~=  /\$(.*)/}
SyntaxError: compile error
(irb):2: syntax error, unexpected '='
monies = lines.select {|l| l ~=  /\$(.*)/}
                               ^
	from (irb):2
	from :0
irb(main):003:0> monies = lines.select {|l| l =~  /\$(.*)/}

Then I grabbed the numbers using map.

irb(main):008:0> nums =monies.map {|m| m.sub( /\$(.*)/,$1).to_f}

From there, I could do all sorts of things.

I could sum numbers.

 total =nums.inject(0){|sum,i|sum+i}

I could get the average.

total/nums.length

I could even see how much of the total was due to transactions under $20.

nums.reject {|i|i>20}.inject{|s,i|s+i}

In short, I like ruby.

Ruby in Practice is Good

Thursday, April 16th, 2009

I have been reading Ruby in Practice over the past week or so as you know. Currently, I am on page 114 which talks about using active resource to consume RESTful webservices( you could use RESTClient, but thats another story) and has a box about the ever awesome BlankSlate class.

I haven’t really learned many “whoah, ruby does what?? Sweet” things from it, most of those are behind me. Now, I get more “Whoah, X project really abstracts that annoying thing into a nice interface.” kind of feelings, which are more satisfying in some ways and less in others. I guess what I am saying is that I have grown to know ruby much better over the past six months or so using it at work every day, than the past, uh, five? years. Which is sweet.

But back to the book( I ramble when I feel braindead):

The things I have learned from reading this book remind me of ruby itself. It has glued together various bits of ruby that I know, in the same way you can use ruby to glue together other technologies. Most of my ruby smarts have been picked up through hacking at things and reading blog posts by knowledgeable people, but that sometimes leaves some gaps in my knowledge. This book has helped me to tie some of the things I have learned together(w00t Hebbian Learning).

For instance, spec tasks

While I know that rspec has a set of extensions for rake, I had not used them outside rails, in fact in the project I was working on I just wrote the following.

task :spec do
  sh "spec --colour --reverse #{FileList['spec/**/*_spec.rb']}"
end

The problem with this is that when any of the specs fail, I get a huge trace from the ran shell script that I have to scroll past before I can see the failed specs.

But, if I included the spec tasks I could do stuff more like this.

require 'spec/rake/spectask'
Spec::Rake::SpecTask.new('spec') do |task|
  task.spec_files =FileList['spec/**/*_spec.rb']
  task.spec_opts = ['--colour','--reverse']
end

Now things work like they do when you generate the tasks from within rails. I had read the lib/tasks/rspec.rake file when I was looking over the generated code in one of my rails apps, but it was a little too complicated to grok easily.

The other things I am looking for are cool projects that I should be more aware of. Sometimes, they are only mentioned but that doesn’t mean they are not awesome. Some that I would like to play with include:

  • Chronic a date string parser that tries to be able to handle stuff like: “next tuesday” and “summer”
  • FasterCSV I saw this at Mountain West Ruby Conf and made a mental note to read it at some point(so much for mental notes)
  • Heckle runs tests. Breaks your code. Sees if the tests fail like they should.

Later.

Merb in Action: Ch 1 Thoughts

Wednesday, April 8th, 2009

Last night I read the first chapter of what will become Rails 3 in Action. So far, I really am enjoying it.

One of the things that frustrates me the most in my own projects is this feeling that things need to be big and get abstracted before they can be useful. I guess it might be a hold over from being a student and wanting to over achieve, or maybe just the classic problem of the hobbyist who tinkers but never manages to really build anything.

It is a gumption trap, to use a Zen and the Art of Motorcycle Maintenance-ism; a thought that sort of stalls my work on a project.

“How will this be useful to anybody?”

“How can I get this to a usable state?”

I think I am getting better at this problem, but sometimes I feel like I have this irresistible urge to over-architect things that gets me into trouble.

What this has to do with Merb in Action?

Well, the thing I thought was really cool was where the authors linked to the pastie that started it all, clocking in at ~120 lines.

I look at that and I think two things.

  1. I usually over think things
  2. I can do this.

The beginning of merb is completely grokable. It reminds me that something doesn’t need to be fully designed. It just needs to be useful enough.

or you could just say:

YAGNI

You Ain’t Gonna Need It.

YAGNI is part of the reason why I have been trying to use BDD in a more disciplined way. By using the Feature->Spec->Implementation workflow, there is less temptation to add neat features on the backend that are never used. I have worked on a number of projects where I ended up writing more code than I needed, than was used.

Writing from the outside in helps to manage that some. After all “no code is faster than no code.”