I then looked at rest_client’s documentation to see how best to manage the basic auth login, etc and decided to use RestClient::Resource, since it stores some of the config data for you., even though it makes things more complicatted due to needing two separate resources — one for api.twitter.com and one for twitter.com.
It took me ten minutes or so to put it together and test to make sure I didn’t make any stupid mistakes. Cool?
http://baroquebobcat.blogspot.com/ — my first blog ever, and definitely baroque in some of its sentence structures, stylings. It clearly didn’t last very long, unlike the baroque period, which lasted from the late 16th century through the early 18th(thank you wikipedia).
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.
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
I saw OK Go last night at the Canopy Club. The show was a blast. The songs were awesome, fucking loud; there was much kick assery to be had. My favorite moments though, were the silly ones.
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)
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.
