 All right. What I'm going to be talking about is a gem called ActiveHash. We work on a lot of apps at Pivotal Labs. We often find that people change their minds quite often, especially in the beginning of a project. And we also find that, especially on enterprise projects, there are a million sort of pick list tables in databases, and they infuriate me. And I've seen them done a number of different ways. Sometimes they're actually in the database. Sometimes they're just lists of constants. But as soon as you have something like maybe a list of countries, but you only work in three countries, and you're probably only ever going to work in three countries. But those countries have maybe different tax codes, or they have different country codes or prefixes for orders. You might want some objectors to represent that country and to have a little bit of behavior around it. So you might maybe make a class for it. And what I've found is that when you implement these things over and over and over again, they fall into a couple of common patterns. One is the migration to ActiveRecord can be really painful. So if you just have strings, and you say, I'm going to use the countries as strings in my database and have some if statements here and there, and then you want to all of a sudden you get bought by some big company, you add 60 different countries to your database, life is pretty bad. So I developed ActiveHash, which is a simple base class that just sort of looks like ActiveRecord but can use a hash as a data source. There's also an adapter called ActiveFile, which can let you use YAML files, XML files or CSV files to just sort of act as a quick read-only data source. And so I'll walk you through what that looks like. This is a very, let's see, another, this is a pretty basic example of ActiveHash. You make your class, you define a field, a little bit like a data map, and you say, well, my record is a name, you have an ID and the name, you sort of create these records directly in the class. And after you do that, if you say instrument.all from any of your code base, you're going to get two records that look and behave a lot like ActiveRecord in the sense that you can say instrument.id, you'll get one, instrument.name, you also get a lot of very similar ActiveRecord finders, like you could say instrument.findbyname, and if you gave a trumpet, you'd get back ID number one. Similarly, you can add an enumerator, accessor, and by doing that, you basically get to access it like a constant, and this is actually what I end up doing more often than not. And this is the pattern that I saw repeated multiple times. The benefit of this over, say, using something in the database is that you don't have seed data to deal with. You don't have the potential that maybe that trumpet record might not be there. You don't have the performance overhead of constantly pulling back the same data, which you probably would end up putting in memcache or something like that anyway. There are a couple of really big downfalls to this. It's in memory, but it lets you, that create method, you could call that from anywhere, you could call instrument.create from anywhere in your code base, or if anywhere in your code base you had a reference to that one instrument and you changed the name, anything in that process is going to have the name changed. So it's definitely, it's got one very specific use case, and if you use that, it might be pretty slick. You can see it on GitHub, it's a, I'll show the link in a second, and it's got a pretty comprehensive readme. My patch policy is if you find a bug with it and you patch it, I'll give you commit rights and I'll let you release the gem. I can be a little bit slow at responding to things with family life and a job. And if you have an XML file, you have a CSV file and someone says, hey, we need to reference this in Rails forms, drop down lists and what not, you might want to take a look at this. The link for that is, any quick questions? I should mention too that the reason for this is that you, in your database, if you referenced country, you would reference it by ID one. So your database would still have the ID. So if you ever decided you're going to make instrument into a full active record class, you wouldn't have to migrate any data outside of just creating the class and populating it with this data here. We've actually done a couple of these migrations and they go very, very, very quickly. So that's active hash.