When there’s no law, there’s no bread – Benjamin Franklin
I am not sure which way the causality goes in that statement. I fear that it is a self re-enforcing where a slip on either side causes a slip on the other. I fear that because we in the USA are already well on our way.
Today is my first on the job at ID Watchdog.
After the normal pleasantries of getting a desk, etc, i had the pleasure of over hearing a conversation of some ops people in the kitchen. Apparently, a not so nice person provided the police with the identity of one of our clients rather than his own. A fact which the ID Watchdog system detected. Now the ops team is working with law enforcement and the Judaical system to cleared up the confusion. A standard part of the service we provide, apparently.
I am psyched to be working at a place that helps people in such concrete ways.
If you are using a dynamic interpreted language please do not used use YAML1, or any other simple data serialization language, for configuration files.
Strictly speaking configuration is just data, of course, so you can use a data serialization language to represent your applications, or libraries, configuration. In some environments, like static compiled languages say, using a data serialization language for configuration makes a lot of sense. Creating your own custom configuration language from scratch is probably going to be more trouble that it is worth, unless you have a really complex configurations to express.
On the other hand, if you have an easily available, highly readable, Turing strength language why wouldn’t you use it? If the language that you application is written in supports eval you should probably use the app language to express the configuration. You will end up with a simpler and more power configuration system.
Lets look at a common configuration as an example. In Rails the database connection configuration looks like this.
development:
adapter: mysql
database: my_db_development
username: my_app
password:
test:
adapter: mysql
database: my_db_test
username: my_app
password:
production:
adapter: mysql
database: my_db_production
username: my_app
password:
host: db1.my_org.invalid
That is not horrible, but it does include a fair bit of repetition. This approach starts getting ugly when you need to have more dynamic configurations. For example, RPM type distros use /tmp/mysql.sock as the domain socket for the MySQL database. Debian type distros use /var/run/mysqld/mysqld.sock. So you end up with a config file that looks like this
development:
adapter: mysql
database: my_db_development
username: my_app
password:
socket: <%= File.exist?('var/run/mysqld/mysqld.sock') ?
'var/run/mysqld/mysqld.sock' : '/tmp/mysql.sock' %>
â‹®
You always end up needing non-declarative bits in your configuration. Everyone realizes this at some point. So much so that the most common pattern for YAML configuration files in Ruby is for them to support ERB as a way to embed Ruby.
Rather than implement multi-pass configuration file loading you could just have configuration files be pure Ruby but produce a hash structure like the YAML+ERB version does.
databases = {
:development => {
:adapter => :mysql,
:database => 'my_app_development',
:username => 'my_app',
:password => '',
:socket => File.exist?('var/run/mysqld/mysqld.sock') ?
'var/run/mysqld/mysqld.sock' : '/tmp/mysql.sock'
},
â‹®
}
That is nothing to write home about but it is dead simple to implement. Simpler even than the YAML+ERB approach. And it is superior to the YAML+ERB version because it is more powerful and extensible.
Rather than trying to map configurations onto a set of name value pairs, i prefer to create a small DSL for the configuration. The results of adapting the language to the configuration that needs to be expressed is significantly more pleasant and DRY than the hash oriented approaches. Consider the following
database {
adapter = mysql
database = 'my_db_#{RAILS_ENV}'
user_name = 'my_app'
password = ''
socket = File.exist?('/var/run/mysqld/mysqld.sock') ?
'/var/run/mysqld/mysqld.sock' : '/tmp/mysql.sock'
env('production') {
host = 'db1.my_org.invalid'
}
}
That is a lot clearer, simpler and less repetitive. In addition, users can do anything they need to because they have access to the full power of the host language. This DSL would be a little more difficult to implement that the hash oriented approach, but not much. For that additional bit of effort you get a huge improvement in usability and power. Your users are worth that effort.
I just received my unemployment insurance debit card, the default payment mechanism in Colorado. After dutifully reading the fee schedule i am appalled. If you are out of work it is quite likely that you need to make every penny count. But the debit card carries an obscene level of fees and usage charges.
Here are just a few of the most egregious ones.
I am ashamed that the Colorado Department of Labor willing subject unemployed workers to this sort of treatment. It is particularly shocking because the debit card is strongly preferred as a payment method for unemployment insurance. The only other option is direct deposit, but it really talked down in the sign-up process.
The debit card issuer obviously needs to be paid, but surely we can do better than allowing Chase Bank to nickel and dime claimants every time they use the money entitled to them. Since a simple check is not an option the least the Department of Labor could do to pay the card issuer directly for their services, rather transferring that cost to unemployed worker in the form of obscene usage fees.
I going to Mountain West RubyConf this weekend. I am very excited. Last year this was a great conference and the schedule looks great this year too. If you are going to be there too let me know. One of the great things about these conferences is all the great people you get to meet, so hopefully i’ll see you there.