Baroquebobcat

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
production:
  <<: *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.

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.