Rocky Mountain Ruby 2011

Lightning Talk: Active Hash

Lightning Talk: Active Hash

by Jeff Dean

In this lightning talk presented at the Rocky Mountain Ruby 2011 event, Jeff Dean discusses the gem called Active Hash, aimed at facilitating the management of data in Ruby applications, particularly when dealing with changing project requirements and data complexity.

He begins by introducing the frequent challenges faced in application development, especially in enterprise projects, such as the management of various picklist tables in databases or as constants. He highlights that this becomes particularly problematic when needing to represent objects like countries that might have variable attributes such as tax codes, emphasizing the need for an efficient solution.

Jeff outlines the primary features of Active Hash, noting that it operates similarly to Active Record but leverages a hash as a data source instead of a database. The introduction of a companion adapter, Active File, permits the use of YAML, XML, or CSV files as quick read-on data sources, enhancing flexibility in data management.

Key points discussed include:

- Definition and Structure: Users define a class with specified fields and can easily create and access records, paralleling the convention used in Active Record.

- Query Methods: Active Hash supports familiar query methods (e.g., instrument.findbyname), allowing seamless interaction with data.

- Memory Considerations: As data are kept in memory, there's no need to manage seed data or worry about record existence, allowing for easier development and testing scenarios.

- Transition Capabilities: In scenarios where a project evolves, transitioning from Active Hash to Active Record can be done without a cumbersome data migration; only class creation and data population are required.

To illustrate the functionality of Active Hash, Jeff shares an example related to instrument records, where fetching and interacting with instances mirrors behavior akin to Active Record. He further encourages contributions to the project on GitHub and highlights a thorough README file available for reference.

The session concludes with an emphasis on the practicality and efficiency of Active Hash for development within Ruby applications, especially for those who might require dynamic references, such as dropdowns in forms utilizing XML or CSV files. Jeff invites any quick questions from the audience, solidifying the interactive nature of the discussion and promoting community engagement around the gem.

00:00:04.240 All right, what I'm going to be talking about is a gem called Active Hash.
00:00:05.240 We at Pivotal Labs work on a lot of applications, and we often find that people change their minds quite often, especially at the beginning of a project.
00:00:11.360 We also find that, especially on enterprise projects, there are a million picklist tables and databases that can be quite infuriating. I've seen them done in a number of different ways; sometimes they're actually in the database, and sometimes they're just lists of constants.
00:00:24.640 However, as soon as you have something like a list of countries but only work in three of them, you may want an object to represent that country and have behavior around it. For example, different countries may have different tax codes or country codes. You might create a class to encapsulate this.
00:00:39.320 When implementing these things repeatedly, common patterns emerge. One issue is that migrating to Active Record can be really painful. For instance, if you store country names as strings in your database and rely on conditional statements, you may end up with a mess if your application scales.
00:00:54.879 To address this, I developed Active Hash, which is a simple base class that resembles Active Record but uses a hash as a data source. There's also an adapter called Active File that lets you use YAML, XML, or CSV files as quick read-on data sources. Let me walk you through an example of Active Hash.
00:01:30.759 In a basic example of Active Hash, you define a class and specify fields, similar to how you would with a data mapper. For instance, your record has an ID and a name, and you create these records directly within the class. After that, calling instrument.all from any part of your codebase will return records that look and behave similarly to Active Record.
00:02:03.119 Using Active Hash allows you to access records in a way you might with Active Record; for example, instrument.id gives you the ID, and instrument.name will provide the name. You also have access to familiar Active Record query methods, such as instrument.find_by_name, which will return the ID corresponding to a given name.
00:02:39.159 Additionally, you can introduce an enumerator accessor, allowing you to access elements like constants. This is often the most common approach I've observed. The primary advantage of this method, compared to storing records in a database, is that you don't need to manage seed data or worry about the existence of records.
00:03:05.400 This method has some downsides since data is stored in memory, but it allows you to call methods like instrument.create from anywhere in your codebase. If a reference to a specific instrument changes, all instances using that reference will automatically reflect the change.
00:03:34.640 This presents a very specific use case where Active Hash can be quite beneficial. You can find it on GitHub, and I will share the link shortly. It features a comprehensive README file.
00:04:07.159 As for contributions, if you find a bug and provide a patch, I'll grant you commit rights, and you can help release the gem. Please note that my responses might be slower due to family and job commitments.
00:04:50.840 If you're dealing with XML or CSV files and someone needs to reference them in Rails forms or dropdown lists, this might be an excellent solution for you.
00:04:58.839 Any quick questions? One key point to mention is that when referencing a country in your database, you link by ID.
00:05:05.560 If you later decide to transition from using Active Hash to a full Active Record implementation, you wouldn't need to migrate data; you'd only need to create the class and populate it with the existing data. We've successfully performed a few migrations, and they go very quickly, illustrating the effectiveness of Active Hash.