Turning off Rails’ annoying “secret_key_base”

One of the most frustrating things with Rails is how they force shit down your throat when you don’t need or want it. Enter Rails “credentials” and their “securing” thereof. Where I work, we have no use for it. We don’t use Heroku or AWS. So why force me to set up a bunch of files or environment variables for something which I don’t want???

And setting “config.require_master_key = false” does not resolve the issue.

Well, here’s how I killed that filthy bitch:

In the file “/config/application.rb” add the following method:

    def secret_key_base
      'SOD OFF'
    end

There – now Rails can take their stupid “security” and shove it up their asses.

And now WP is annoying me. Awesome.

Alternative to Ruby’s const_defined? method

Today I wrote a bit of code in a base class which checks to see if a constant named “EXPORT_MAPPING” was defined. I’m not a Ruby expert, so off to Professor Google I go, and all the references I could find say to use the “const_defined?” method, thus resulting in the following implementation:

self.class.const_defined?(:EXPORT_MAPPING)

Now, since the intention here is to facilitate multiple levels of inheritance, I have a subclass called “ImageSlideshowComponent”, and a subclass of that “NivoSlideshowComponent”. ImageSlideshowComponent contains the EXPORT_MAPPING definition, with the intention of NivoSlideshowComponent simply inheriting it. Which is sort of does. We correctly see if it we do this:

NiveSlideshowComponent::EXPORT_MAPPING

However, invoking the following gives us “false”:

NiveSlideshowComponent.const_defined?(:EXPORT_MAPPING)

Clearly I’ve misunderstood the intention of the “const_defined?” method. It seems to only indicate if the class in question itself has defined the constant.

Here is the revised code block from the superclass which works correctly:

self.class.constants.include?('EXPORT_MAPPING')