Check out the source:

http://www.mirah.org/

http://github.com/mirah/dubious

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はすばらしかった。

Things to revisit

• Archaeopteryx

• Rails 3

• Rack(1.1.0 in particular)

• Chef(looks better than the last time I poked at it)

• EventMachine

• Yard

New things(to me)

• RVM(rvm looks pretty handy, especially for cross vm library development)

• Ruby-Processing

• Hubris(this might be a neat way to get into Haskell development)

• Mucking about with the binary interfaces(because it is awesome.)

My lightning talk

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.

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.

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.

“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.

So, I give you this:

Me


Carrot Cake(Thanks Hyatt catering)

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

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

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?

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.

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.