Baroquebobcat

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.

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.

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.

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

I just ordered Ruby in Practice and Rails 3 in Action from Manning(they had a one day only 45% off promo).

The Rails 3 book won’t actually be coming out for a while, but in what I think is an ingenious publishing move, people who preorder can look at drafts of chapters as the book is worked on. It reminds me a little of how Lawrence Lessig is doing the next edition of his books. Except of course totally different.

The thing that makes them similar is the added participation of future readers. It isn’t that this is a new idea. People have been soliciting comments on publications for as long as they have been around. Technology just changes the timescale and the scale of the projects.

Anyway, cool.

Right now, I have Ruby in Practice and through the fourth chapter of Merb–Rails 3 in Action. More later.

Sweet.

After yesterday, I have a lot of grokking to do. And, some projects to start.

The talks, like the day before were great. And having the opportunity to talk with so many people about what they do with ruby was enlightening.

I wanted to write up my thoughts about yesterday, but they haven’t really congealed yet.

Short summary:

• Ruby is awesome.(of course)
• I need to be more aware of my metaworkflow
• Rhodes looks really slick.
• Adhearsion would be fun to build something with(eg a podcast engine)
• Destroy is a funny word to users(rails)
• Of the bicycle gears of software development,cucumber is the outmost one
• Suite.add(test) if test.value > test.cost
• be extremely pedantic when you first start trying to use a new methodology–even if it sucks(in the ‘man, why all this typing’ sort of suckage you know makes you want to be lazy).
• don’t confuse concise with terse.
• maybe I should try to make a theramin sim with the wiimote
• energy not time is the most precious resource