After using it for about a
I thought it’s time to actually put up Pressevent on
Github So anybody in need of
monitoring a WordPress install for updates can either just host it themself on
heroku or sign up.
Rails apps use a secret token to keep user information save, so the more entropy the better. This means using the same secret token on heroku and locally is not ideal, and quite easy to fix.
First make the
secret_token.rb set the token from an
MyApp::Application.config.secret_key_base = ENV['SECRET_KEY_BASE'] || "sometoken"
And now create the token in the heroku config
heroku config:set SECRET_KEY_BASE=`rake secret`
That’s it, enjoy!
Rails migrations are the ugly stepchild of most projects, even though
actually making them work correctly saves so much time. Even though they seem
like one-off scripts, and also are most of the time when you do need to run them
more than once you are already in a bad place, so be sure that the migration you
wrote, when there was time is not making it worse.
At least doing a quick testing of the rollback is worth your time, in all cases!
So just run
$ rake db:migrate && rake db:rollback && rake db:migrate
When creating a new migration, thank you, you are awesome :).
Relying on rake task to do some repetitive work is a really common way in most
rails apps. Testing those tasks seems to not be as common so.
Personally I think this is mainly due to just not being present in the default
tests stack, so as a developer I assume they are not worth testing because nobody
else is. But actually I think a task which is essential to your application
should be tested never the less, so to ease my journey towards better test
coverage for rake tasks in my own apps I decided to create a little helper to
setup just the basic environment and about as important, be there as a reminder
that I should test those tasks.
Personally I come to like minitest to test rails apps, so the
gist is based on
minitest, but can easily be adapted for any other framework. Looking through the
code you’ll find some conventions I personally like to be enforced in my rake
so here we go, enjoy!
When I extracted
from an active project is was a pretty quick thing, but since then I found, since
it is just so barebones easy, that uses pop up outside of the initial
Currently I am in the process of moving it towards a more stable release,
just a couple more things are left to do, but for now at version 0.0.9 is here
with a slimmed down interface and better docs. Find and read the
Rails generators are often known to be a one way street. Often people new to
rails think if they generate the wrong thing they are stuck. Not true! So here
we go, happens to me all the time:
$ rails g controller ReportsController index ... app/controllers/reports_controller_controller.rb ...
Oh right generate just takes the name without the extension. No need to hunt
down the generated files:
$ rails d controller ReportsController index ... $ rails g controller Reports index ... app/controllers/reports_controller.rb ...
Just run d for destroy and generate again. Just thought to point this out!
Travis CI is great way to get continuous integration into a project.
So just to get started here is a quick walkthrough, through the setup for a
project of mine. Basically it’s a 3 step process:
This is easy, and probably already happens anyway! Just to check
My own .travis.yml for
ActiverecordTranslatable looks like this:
Set the ruby version to 1.9.3
Setup the database for the tests
Now to complete the setup setup the hook for travis under the Settings → Service Hooks on Github.
So now quick, learn more checkout TravisCI docs it’s
Sometimes it comes in handy to render a template from another place than a
controller in Rails. For example using
WickedPdf to generated some pdfs
inside a model comes in quite handy. Normally you need to setup a lot of stuff
for WickedPdf but since everything is already done when calling the build in
render, we can just reuse this.
So to call render from somewhere besides a controller, well we need a
controller and we can just call render from there, what pops out is the
actually rendered template as a string (that’s why we call render_to_string of
course), which we can now ship of to wherever we need it.
UPDATE: As Fladam Orin points out in the comments this falls flat if you use helpers like url_for since the controller lacks a request object. This is a problem which can be solved by using an ActionView and loading the helpers.
Getting started to debug a problem within the rails lib itself it is nice to be
able to just run a single test. Doing this is pretty straight forward, still it
took me some minutes to get the command right since I found a lot of non working
ways online first. So here it is (as an example I run the test_label test in
$ cd actionpack $ bundle exec ruby -I"lib:test" test/template/form_helper_test.rb -n test_label
Look at this post as
well for further details about test running in rails.