Helping ruby developers to use the best tools for each job so they can solve hard problems, with less bugs and have more free time.
Some time ago I missed one of the cool features from the time I worked with JavaEE, that was a request scope for some variables.
I know the instance variables on controllers do a great job simulating it, but I needed to access context in a completely different part of the application, that wasn’t always called from controllers, variables that should be scoped to that request.
So I thought, I could create something like that for my rails app.
This is a very opinionated post, with some performance tips from someone that uses sidekiq for more than two years now, as as such I have already did some mistakes and learnt some tricks. My current opinion is that sidekiq is the best backend job engine for ruby/rails applications. And of course to use it…
After you spend some time working in the same Rails project, being this project whatever project you are working for some time now, you probably use the Rails console a lot, many reasons: Testing code Seting up data Using “binding.pry” to “debug” some controller or model Put whatever you are doing in “rails c” now…
When you look at the logs of your application in development, they may appear clear and concise to you (probably not thou), but when you are looking at the production logs and there are many simultaneous requests, sometimes it is difficult to know exactly what like of the log is the next entry, or what…
Rails is a really cool framework to work with, but it is not fall proof, and it will not prevent you from doing stupid things, having that said, even with the best tools available, putting a new software in production, or doing a significant upgrade to a software that is already in production is always…