• RVM Readline Error
  Way around fixing that annoying problem with readline and rvm when loading certain gems
  (tags: readline rubyonrails rvm)

No tags

I’m quite excited to announce the release of jasmine-runner 0.2.1 0.2.9. In case you didn’t know, this is a commandline tool I wrote awhile back to basically re-create the jasmine gem as a node.js npm package. The reason for this was gem just wasn’t part of my workflow while node.js is. This runner runs client side specs while the next release will have support for running specs on different environments such as node.js itself and rhino.

For those unfamiliar with it, it is installed via npm by typing

npm -g install jasmine-runner

Which provides a locally executable jasmine command that allows the capability to run specs, initialize a project structure with example specs, and even run specs in an autospec like mode that monitors files for changes.

This release completes an overhaul that makes it work on the latest version of node.js and includes several contributions. One of the most interesting contributions is that it works with coffeescript out of the box with all files ending in coffee being compiled down to javascript and served up to the browser. Just to quickly whet your appetite here’s an example spec:

And the actual implementation (using Eulcid’s formula of using the prime number sequence to find perfect numbers):

There’s still a few oddities to resolve. For example, if your coffeescript doesn’t compile correctly the client side won’t get anything (which may result in passing specs). Feel free to file issues with any problems you have and I’ll try my hardest to get them fixed.

I’d like to give a special thanks to amaierhofer (Added the awesome coffeescript feature),MichaelXavier, and peterbraden for their contributions that have made this release possible.

No tags

Along the lines of my previous post, here’s how to set up grails for a multi-user environment to store plugins and artifacts in a common location versus in each user’s home dir.

export GRAILS_OPTS="-Dgrails.work.dir=/usr/local/share/grails -Divy.default.ivy.user.dir=/usr/local/share/ivy"

You could also set the ivy.default.ivy.user.dir to the same directory that gradle caches it’s artifacts as well.

No tags

I’ll just skip straight to how to accomplish this.

export GRADLE_USER_HOME=/usr/local/share/gradle

The windows variant is just doing something similar. Define a environment property named GRADLE_USER_HOME and point it to something like c:\gradle-user-home or something.

Set this up to be exported for all users and they’ll now be able to re-use artifacts that have already been cached by others who have used the machine. This is handy for my workplace as different people log into the machines daily as pairs swap and rotate around on the team.

No tags