Archive for October, 2010


Wednesday, October 20th, 2010

Mountain.rb At The Boulder Theater

My first local conference, right here in Boulder. I had a lot of fun. Thanks Marty for a great conf.

R2 Droid 2 Unboxing

Tuesday, October 19th, 2010

I got a new phone a couple weeks ago. w00t. Behold the unboxing photos!

The Box

Opening the box

Look At All The Wonderful Accessories

Behold the R2D2esque Back

It Even Comes With a Dock

Why Not YAML?

Sunday, October 17th, 2010

I enjoyed Joe O’Brien’s recent post Why Yml?. He asked why we use external config files when we have an dynamic language like Ruby. Yeah, Ruby is more expressive and it would be simpler to use only one language, but to me it makes sense to use YAML for config data. And I think YAML is used a lot because it can represent config data more clearly.

So, why would you store data outside of code when Ruby is so
freaking expressive?

  1. Interoperability — When you have applications in different languages that use the same configuration, then having a separate file makes a lot of sense. For example, when writing a JRuby on Rails app that  has bits of Java code (i.e. servlets w/ JDBC) that share the DB, you want to centralize your DB config to avoid having to do something nasty like generating properties files from database.yml.
  2. Security — Keeping config details, like DB login information out of the source is a good idea. It’s more secure because you often have a lot of sensitive information in your config files. The less places that information appears, the better. They should, ideally, not be checked into source control. For some reason, I feel more uncomfortable with the idea of not checking in source files than I do yaml files.
  3. Convention — Rail’s database.yml has a very stable structure. Keeping it as a YAML file encourages developers to not muck about with it. Why do this? There are times when having less expressivity is better because it’s harder to shoot yourself in the foot that way. It makes adding unnecessary behaviors more awkward. For database connections, this makes a lot of sense because they should not usually have a lot of logic around configuring them.

I generally agree with Joe on the ugly use of ERB in yml files, at least for things like data store configuration. When I see that or find myself doing it, I have a little a sense of “you’re doing it wrong!” Code smell, indeed.

I also think that the YAML vs XML vs JSON discussion is important here, because YAML as a language has some interesting properties that make it well suited to config type situations. In particular, I’m thinking of the ability to name chunks of the document and substitute them in other parts of the document in an override-able manner.

For example, in YAML, a set of configurations where one inherits from another might look like

development: &default
  adapter: foo_store
  port: 1337
  database: base_development
  <<: *default
  database: base_production

The equivalent in Ruby could be represented something like

#using 1.9 syntax, so it looks more yamlish
config_hash = {
  development: {
    adapter: 'foo_store',
    port: 1337,
    database: 'base_development'}
config_hash['production'] = config_hash['development'].merge(
                                                database: 'base_production'

Which I don’t think is quite as easy to scan.

I guess my point is that while Ruby is very expressive and powerful, sometimes a more constrained language can better express config information in a declarative manner.

Right Scale API gem

Sunday, October 10th, 2010

I was frustrated with the client libraries available for the RightScale API, so I wrote my own. It’s reasonably complete, but doesn’t currently have tests.

Mostly it arose out of a need to automate things and my desire to make something pretty clean.

I didn’t like the API’s of the existing libraries much, so I wrote my own.

It is fairly bare bones at this point, but I have been using it for a few months and it works for me.

Check it out:

Further reading/References(Others’ Right Scale API gems & libraries): — not a gem yet — little in the way of docs, feels pretty raw — pretty neat, activeresource based, have not tested though — uses httparty, missing most of the objects available — not gemified, not great — fuller implementation, but since it doesn’t use httparty, restclient, or activeresource, the source is really verbose


Thursday, October 7th, 2010

Today and tomorrow I’m going to be hanging out at the mountain.rb conference.

First up today is Jim Weirich doing a talk called To Infinity and Beyond. It should be fairly epic.

In other news I got a smart phone finally. It’s R2D2.