Bruno Pinto

Rails 4 precompile assets

2013-05-18 00:00:00 +0000

Adding config.assets.precompile to your config/environments/production.rb file is not working on rails 4. This bug has been raised on sprocket-rails and as a temporary fix, move this setting to config/application.rb

class Application < Rails::Application
  ...

  # Precompile additional assets.
  # application.js, application.css, and all non-JS/CSS in app/assets folder are already added.
  config.assets.precompile += %w( head.js )
end

Hatmaker - An alfred workflow manager

2013-04-24 00:00:00 +0000

It’s hard for me to use a computer without Alfred nowadays – it’s one of the first apps I install when bootstrapping my computer. And with its recent release – version 2 – where they have introduced workflows, it has gotten even better.

There is one problem though and this is what I’m trying to solve with Hatmaker: Workflows are made by the community and the official place to release them is a forum, as you can imagine, keeping your workflows up-to-date is a madness.

There are some unofficial attempts to provide a solution for this problem but still they all miss some important features. Hatmaker goal is not to re-invent the wheels but to unify these solutions in order to provide an easy workflow manager.

Hatmaker version 1.3 has been released and with the help of the community, new features are being added continuously. Great features are to be added on the next release versions, make sure you follow it on github and on this blog.

Running mocha tests on subdirectories

2013-03-11 00:00:00 +0000

Over the weekend I started a node.js app and decided to give mocha a try. Despite all google I did and all github issues I read, I couldn’t find an easy way to run tests that are on subdirectories.

But why should it be easy? :P

Mocha advices you to use Makefiles to setup which tests it should run, IMHO this is over-engineering – maybe one day you will need it. The solution I propose is quite easy, and I just needed to look at the mocha binary file and see the possible arguments it accepts.

.option('-r, --require <name>', 'require the given module')
.option('-R, --reporter <name>', 'specify the reporter to use', 'dot')
.option('-u, --ui <name>', 'specify user-interface (bdd|tdd|exports)', 'bdd')
.option('-g, --grep <pattern>', 'only run tests matching <pattern>')
.option('-i, --invert', 'inverts --grep matches')
.option('-t, --timeout <ms>', 'set test-case timeout in milliseconds [2000]')
.option('-s, --slow <ms>', '"slow" test threshold in milliseconds [75]')
.option('-w, --watch', 'watch files for changes')
.option('-c, --colors', 'force enabling of colors')
.option('-C, --no-colors', 'force disabling of colors')
.option('-G, --growl', 'enable growl notification support')
.option('-d, --debug', "enable node's debugger, synonym for node --debug")
.option('-b, --bail', "bail after first test failure")
.option('-A, --async-only', "force all tests to take a callback (async)")
.option('--recursive', 'include sub directories')
.option('--debug-brk', "enable node's debugger breaking on the first line")
.option('--globals <names>', 'allow the given comma-delimited global [names]', list, [])
.option('--ignore-leaks', 'ignore global variable leaks')
.option('--interfaces', 'display available interfaces')
.option('--reporters', 'display available reporters')
.option('--compilers <ext>:<module>,...', 'use the given module(s) to compile files', list, [])

The --recursive option does what we need. So, one just needs to run mocha using this option and mocha will find all files under the test directory.

➜ mocha --recursive

In order to set this as a default argument, configure this on your test/mocha.opts file.

➜  cat test/mocha.opts
--recursive

This also works when running npm test, as long as your package.json is configured properly:

"scripts": {
  "test": "mocha"
}

Janky - The forgotten tool

2013-01-17 00:00:00 +0000

Where I work we use GitHub as our Git central repository, and we have Yoda, our Hubot, helping us on our day to day tasks. We had to setup a Continuous Integration server for our project and after looking at all the CI options out there, we had to decide between Travis-ci or Jenkins. Both are well-known continuous integration servers but they were not exactly what we needed at the moment. Travis is $150 per month and Jenkins has to be manually installed and configured, plus it has an awkward interface.

Travis could certainly be our solution in a future moment but, for now, we decided to try Jenkins out. As a solution for the issues raised, we decided to use Janky, “(…) a continuous integration server built on top of Jenkins, controlled by Hubot, and designed for GitHub”.

When I first read Janky’s readme, I thought it would be an easy setup… Well, I couldn’t be more wrong. It’s hard to know which values should be set for each of the required environment variables, and the gem is outdated forcing you to build it from git directly…

Anyway, one can always fork and submit pull requests, right? So, let’s focus on the setup process.

Installing Jenkins

Janky recommends Jenkins version 1.427, but as I installed a newer version (1.498) you should be fine with newer versions. Installing Jenkins guide is easy to follow and will help you on installing a Jenkins server if you don’t have one yet.

Installing Janky

Janky’s guide on the other hand will guide you to failure ~~since the beginning as the [Gist][] you use to install is outdated and lacks the *JANKY_BRANCH* variable definition.~~. Apparently the gist has been updated, so you can almost run the commands as they say:

➜ git clone git://gist.github.com/1497335 janky
➜ cd janky
➜ heroku create --stack cedar

At this point, I suggest to not use the latest released gem version (0.9.13) – as its outdated – and bundle the gem directly from the repository by changing the following lines in the Gemfile.

gem "janky"

to:

gem "janky", :git => "git://github.com/github/janky.git"

And now we can proceed with the installation guide:

➜ bundle install
➜ git add Gemfile.lock
➜ git commit Gemfile.lock -m "lock bundle"
➜ git push heroku master

Configuring Janky

All variables are defined with the following syntax:

➜ heroku config:add VARIABLE=value

Define janky’s URL on heroku with a trailing slash:

JANKY_BASE_URL: http://JANKY_APP_NAME.herokuapp.com/

Our server has Jenkins’ Matrix-based security enabled, so only registered users can access Jenkins. In order to authorize Janky, you need to create an account for it and specify both the username and its api token that can be found on the user configuration page: http://jenkins.example.com/user/JENKINS_USER_NAME/configure on the URL.

JANKY_BUILDER_DEFAULT: http://USER:API_TOKEN@jenkins.example.com/

Define the configuration dir (default):

JANKY_CONFIG_DIR: /app/config

Hubot’s user and password are the same passwords you will use when configuring Janky’s hubot script. Create your own secure user/password here.

JANKY_HUBOT_USER: Login used to protect the Hubot API.
JANKY_HUBOT_PASSWORD: Password for the Hubot API.

You have to create a github account (or use your own) to allow janky to connect to github and set up service hooks for you.

JANKY_GITHUB_USER: Login of the GitHub user. Requires Administrative privileges to set up service hooks.
JANKY_GITHUB_PASSWORD: Password for the GitHub user.

There are two variables that apparently should be configured with the same value, and the token value is obtained by using the one that comes in the following curl command response:

➜ curl -u USERNAME:PASSWORD -d '{ "scopes": [ "repo:status" ], "note": "janky" }' \
https://api.github.com/authorizations

JANKY_GITHUB_HOOK_SECRET: Secret used to sign hook requests from GitHub.
JANKY_GITHUB_STATUS_TOKEN: To update pull requests with the build status.

You should also specifiy the default chat room, but I don’t know whether this is the room name or number on campfire. It should not be a problem as long as you specify the room for each project.

JANKY_CHAT_DEFAULT_ROOM: Chat room where notifications are sent by default.

Migrating the database

Now you can run the database migration.

➜ heroku run rake db:migrate

Configuring hubot

Configuring hubot is pretty easy, all you have to do is enable its script on hubot-scripts.json:

["janky.coffee"]

and define an environment variable on hubot’s server (not janky’s). Don’t forget to append _hubot/ to the URL:

HUBOT_JANKY_URL: http://JANKY_HUBOT_USER:JANKY_HUBOT_PASSWORD@JANKY_APP_NAME.herokuapp.com/_hubot/

Troubleshooting

After all heroku commands you might need to specify the app on which you want to run the command using the argument −−app.

➜ heroku run rake db:migrate --app MY_APP_NAME

Fish and RVM

2012-07-29 00:00:00 +0000

Decided to move from bash/zsh/etc to fish shell? Developing in ruby? So, you probably use rvm.

If you are lucky, you found this step-by-step tutorial that integrates rvm with fish. After using fish for a while, you noticed that your cd function is missing some features… WTF!?

Why would the cd function lose features if “RVM just manipulates environment variables”? Rvm is not just manipulating environment variables, it also overrides shell commands like cd.

➜ set -l GITHUB https://raw.github.com/lunks/fish-nuggets/master/functions
➜ curl --create-dirs -o ~/.config/fish/functions/rvm.fish $GITHUB/rvm.fish
➜ curl -o ~/.config/fish/functions/cd.fish $GITHUB/cd.fish

As you can see, the third step from the tutorial is actually redefining the cd function.

Fish has a philosophy different than most of the shells: “Many other shells have a large library of builtin commands. Most of these commands are also available as standalone commands, but have been implemented in the shell anyway for whatever reason. To avoid code duplication, and to avoid the confusion of subtly differing versions of the same command, fish only implements builtins for actions which cannot be performed by a regular command.”

While you have the builtin command cd you also have the regular command defined in fish. The latter adds more features to the cd function.

Functions in fish are lazy loaded, and ones priority depends on the directory that it was defined. When following the step-by-step guide, the cd function is copied to a user specific directory which has a higher priority than the default fish functions directory. Thus, the regular cd command is never loaded.

One of the features your cd command loses is being able to cd into your previous path:

➜ cd -
cd: The directory '-' does not exist

Currently, fish has no support for replacing functions without losing its functionality, and as I was using rvm at that time I decided to create such behaviour. This functionality was added to Oh My Fish and its rvm plugin already fixes this issue.

Oh My Fish

2012-07-25 00:00:00 +0000

I’ve been using Zsh as my default shell for a long time, it has many builtin functions that I use on my day-to-day work. I also use some plugins that come with Oh My Zsh and others that I did; This is my current plugin list: autojump, brew, bundler, fast_rake, git, mkv, rails3, rake, rvm, wifi .

Time has passed and I started noticing that my shell is really slow. It’s certainly related to the amount of functions and plugins that I use, so I looked for a solution and found Fish.

Fish is a incredible fast shell which “uses a cutting-edge technology known as ‘threads,’ so it doesn’t stutter even on sluggish filesystems”. It has a different approach then Bash and Zsh which might not meet your needs (and maybe not mine) but I’m willing to try it.

At this moment, I’m adding these plugins to Oh My Fish (a framework for Fish that I’m developing) and in the future I intend to add support for more tools. Wanna help me and the Fish community? Fork it!

Another blog attempt

2012-05-12 00:00:00 +0000

I tried blogging a few times in the past but the result was always the same: The blog was abandoned after a while. From these attempts, I think I’ve learned what I believe is essential to go beyond the huge amount of 3 posts per blog:

Write about anything
Engage with your blog’s readers (if any)
Invest on the environment

Investing on the environment

There are several ways one could invest on his blog environment, e.g., using a good blog platform, using a good blog layout, etc.

I’m using Jekyll - a static site generator - as my blog platform, it improves my limited blogging capacity. Mixing it with the joy of building my first blog layout… I can only preview a wonderful blog ahead!

Jekyll has many Plugins one could use in order to improve their blog and it also seems easy to develop new ones if necessary. With this in mind, I believe I will start thinking about the blog not only as a way to learn & share but also as a way to do what I most enjoy – developing.

Lastly, but not least, I’m using github as a remote repository and to host the blog.