Heroku has a convenient new way to share add-ons between apps. Since their postgres service is one such add-on, it becomes extremely easy to get two apps to talk to the same database.
When an object should not change during the execution of a program, you make it a constant:
Good forever, right? Well, not really. More accurately, perhaps, not at all. First, there is the case of a simple reassignment:
Ruby issues a warning, but the constant still gets reassigned. This is perhaps unfortunate, but at least it’s clear what happened. In other cases, the change of a constant can take place by less obvious means and, to boot, without raising any warnings.
On the face of it, Hash’s
fetch instance method is a pretty handy and fail-safe way of
retrieving keys from a hash. It allows one to specify a default value to be
returned if a key does not exist.
Null Object is a well-known software design pattern that allows one to take advantage of duck-typing encouraged by Ruby. Plenty of articles offer good descriptions of this pattern and provide basic usage examples, which has prompted me to attempt integrating it into my Rails apps several times. Unfortunately, null objects always seemed to fall short of being able to fully replace nil checks and other conditionals. Luckily, Sandi Metz took a terriffic in-depth look at this pattern in a recent talk. Inspired by this presentation, I returned to the Null Object pattern and finally implemented it in a way that unlocks its full potential while leaving the code base clean and compartmentalized.
While building a simple API in Rails, I had the following method in my User model that needed to be tested:
The method uses Devise’s
friendly_token method to generate an authentication token for a new user record. After calling the method once, the loop checks whether a user record with the same auth token already exists. If the answer is positive, the method goes for a second try; otherwise it breaks out of the loop, mission accomplished.