Sooner or later you want to pages to your Rails application that are not created dynamically, but rather contain either some marketing information, legal info like imprint or terms, or even feature some sales copy you call your homepage.
When rendering your
ActiveRecord models in your controller as JSON you often wanna include more than just the default attributes that calling
#to_json on the model gives you. There are various hacks described on Stackoverflow, like overriding the
#serializable_hash methods, two of which I can even find in my current (legacy) project.
Today I wanna show you the OOP way how to do this. Spoiler: We'll create a class.
In all of my projects, I have some data that my tests heavily rely on: things like a list of currencies, shipping methods, a pre-defined list of roles, and other things that never change or very infrequently.
When writing tests, I do not want to create the same record from my factories over and over again for each and every test, but instead just have it available. How do you do that?
Having recently upgraded a legacy Rails project from 3.x to 4.2.x, one of the biggest benefits is that I can finally use some nice additions to
ActiveRecord. One of my favorites is
#distinct, which, as the name says, will return
DISTINCT records for...
I was recently called for help to update a gem in a Rails application I wrote a couple of months ago. It was important to only update a single gem (which had a known security vulnerability) and not touch any others, as this would have triggered a complete...
Recently I’ve been working on a new project where I’m using omniauth and omniauth-identity instead of devise to manage login and password for users. That’s mainly because I wanted to have a separation between user and authentication data (but that...
This time I wanna share with you something rather small, but really helpful: my default Heroku deploy script. It will push new code to your Heroku application and run migrations, if necessary.
In part 1 of this series we've looked on the basics of the interactor pattern, created an interactor dealing with the Mailgun API and refactored it to use a
Result class to signalize success and failure.
In this part, we want to add some method sugar to our solution, so that we don't have to deal with the setup process too much.
The other day I was working on a Rails application that did some communication with the Mailgun API. I already started with a light version of the interactor pattern but soon discovered that I wanted to have not only the hard work of calling the API done in my interactor pattern, but also make the decision if the call was successful or not.
The presenter pattern is one possible way to move logic from your views into a place where it's not only better suited, but can also be reused. Maybe that's the reason it's an essential part of the MVP pattern in other web frameworks. In this article, I want to offer a lightweight implementation that both explains some specialties when used with Rails helpers and doesn't need any external dependencies.