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.