Jan 23
It’s funny how every Rails application I - and possibly you - work on ends up needing some sort of per-environment global constants.
Examples may include the application url - It might be used in account activation emails and thus should be different between the development and production environments.
Or perhaps your application depends on external services that, depending on the environment, are available in different URIs.
There are a couple solutions out there but my needs were simple and straightforward, thus I developed a small rails plugin that is the simplest thing that could possibly work: AppConstants.
It’s been useful for my current project and I hope it can be useful to someone else too


Hmmm, this seems exactly like confirmation. Maybe you should check it out.
Confirmation? I think you meant Configatron, right?
If so, it is similar although I did not find a way to specify environment specific attributes in configatron without putting if statements in the code. With this plugin, the constants are defined in an external file, divided by environment. That made the code simpler.
Yeah that is what I meant. And wouldn’t you just use the environment files to specify your configs?
That’s what I wanted to avoid: configuring the constants in the environment files. I don’t think it’s the best place for them to be. We end up mixing Rails and Application specific configurations.
Configatron does allow you to load constants from yaml files, but then, you’d have to replicate all constants for the different environments you might have, since configatron expects a full set.
Whereas the way I’ve done it, you just use normal inheritance in yaml files, and the environment files remain clean.
Both solve essentially the same problem. I just chose what for me looks like a cleaner approach.
Ah okay, got ya.
The only thing that I would say, is that maybe you should have extended configatron, to allow environment specific loading. Because the nice thing about that is that it allows you to have scoped constants. So not just
Configatron.constant
But
Configatron.scope1.scope2.scope3.constant
But looking at the code that you wrote, I wouldn’t think that it would be hard to reproduce this behaviour. Also thinking about it, I do agree that having all the constants in one place is a lot neater and cleaner.
One of the reasons I didn’t exntend Configatron is that I didn’t remember it existed until right after I finished my plugin
And yeah, scoped constant shouldn’t be hard to add. I might do that in the futurre. I just didn’t need it yet.
[...] in January I announced a small but useful plugin called AppConstants, that basically provides a central place where you [...]