Getting Ruxit to work with Play

At Accolade, we’ve been playing around with the Ruxit platform. But one of the first issues you may hit is how to make it identify your Play application correctly. There’s this treatise on how to use an environment variable, but what does it MEAN? Thankfully, I am here to help.

You simply have to set your RUXIT_CLUSTER_ID before running your application. The easiest way to do this is right on the command line!

RUXIT_CLUSTER_ID=<my-awesome-name> ./<play-application-run-file>

This also works with screen:

RUXIT_CLUSTER_ID=<my-awesome-name> screen -d -m ./<play-application-run-file>

Getting code coverage in the Play Framework using Jacoco

QUICKLINK: I don’t care about your stupid life story, just show me how to make it work

We’ve been using the Play framework lately at KonciergeMD to build our application. One thing that’s always good to have on your application is good test coverage, and there’s no shortage of tools to measure that.

To get the reports on code coverage, we decided to give JaCoCo a shot, and specifically try to use the sbt-jacoco plugin to do it.

Trying to use it right out of the box, however, proved useless. Running jacoco:cover from sbt or play would not work, and instead run no tests while not giving any error messages, and making you feel like a fool for trying.

After staring at the problem for a while, @seantbrady and I finally came across the solution. The main and simple issue with it is that sbt runs tests in parallel by default, and this is what the sbt-jacoco plugin inherits. You can see this by doing the following in the play console:

[webapp] $ jacoco:parallel-execution
[info] true

Play, however, has this set to false. The simple solution, then, is to set this to false for jacoco also.

How to make it work

UPDATE: We originally had the settings in a separate build.sbt file in the root directory to make this work. A quick email from Peter Hausel at Typesafe showed us how we can do it in the Build.scala file present in the project directory.

Some of this is covered in the sbt-jacoco wiki, but I’m going to put it all here for completeness.

1 libraryDependencies ++= Seq(
2 	"org.jacoco" % "org.jacoco.core" % "0.5.7.201204190339" artifacts(Artifact("org.jacoco.core", "jar", "jar")),
3 	"org.jacoco" % "org.jacoco.report" % "0.5.7.201204190339" artifacts(Artifact("org.jacoco.report", "jar", "jar")))
4 
5 addSbtPlugin("de.johoop" % "jacoco4sbt" % "1.2.2")
 1 import de.johoop.jacoco4sbt.JacocoPlugin._
 2 
 3 
 4 object ApplicationBuild extends Build {
 5 
 6 	val appName         = "webapp"
 7 	val appVersion      = "1.0-SNAPSHOT"
 8 
 9 	lazy val s = Defaults.defaultSettings ++ Seq(jacoco.settings:_*)
10 
11 	val appDependencies = Seq(
12 		// Add your project dependencies here,
13 	)
14 	
15 	val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA, settings = s).settings(
16 		// Add your own project settings here
17 		parallelExecution in jacoco.Config := false
18 	)
19 }

I’ll highlight some of the more important parts of this file.

First is this line:

lazy val s = Defaults.defaultSettings ++ Seq(jacoco.settings:_*)

This adds the jacoco settings to the variable s.

Next is this line:

val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA, settings = s).settings(

You’ll notice settings = s is added to the PlayProject. This adds the default and jacoco settings to the PlayProject.

Finally this line:

parallelExecution in jacoco.Config := false

Will make sure that parallelExecution is off during test execution.

Now you can run jacoco:cover to produce your beautiful coverage report! You can see your report at target/scala-2.9.1/jacoco/html.

Delete files from Campfire Rooms

I wanted to take a stab at doing some Ruby, so I whipped up this little utility delete all the files in one or all of your campfire rooms for a given URL.

You can get it on my github.

Running the program

To run, the command is as follows:

$ ./campfireremovefiles.rb -s server -t apitoken

where server is the name of your campfire server (in the form of name.campfirenow.com) and apitoken is the token given to you. You can get this token by going under the “My Info” link on your campfire page.

The script will print out a list of rooms, and give you a choice of which one to delete from (or all). You can ignore the “peer certificate” warning, it just means that you’re not verifying the cert from campfirenow. We’ll assume the server is correct.

Here’s what a sample run will look like:

warning: peer certificate won't be verified in this SSL session
Choose the room you want to delete the files from: 
1: Test
2: Test 1
3: Test 2
4: All
? 2
This will delete all files in the room Test 1!!  Are you sure? (y/n)
? y
Deleting test2.txt
Deleting test1.txt

Again, since this is my first ever Ruby program, it’s probably in pretty crappy shape. Deriding comments about the exact level of crappiness are always welcome.

Sleepwords is released!

I finally got around to releasing my silly little app for Android. It’s called “Sleepwords”, and it floats the name of random objects in front of you, to help you sleep, meditate, or give your conscience mind a distraction to help your subconscious mind flow free. Best of all, IT’S FREE. So you really have no excuse not to at least try it.

You can find it on the market here. I’m planning on making the source code available soon.

UPDATE

I’ve just released sleepwords as open source! You can get the code on github here.

Google Music "could not identify your computer" in ubuntu

When I was trying to get Google Music working on my Ubuntu install, I was getting the following error:

Thanks, helpful, Google

On my motherboard, I have two ethernet ports. Doing an ifconfig, I saw something weird with my MAC addresses.

Two bits if you can see what's weird

I’m only using eth1, but you can see that both of the ethernet ports are reporting the same MAC address of aa:00:04:00:0a:04. I found this post detailing that the DECNet tools is what causes the MAC address to be the same. To remove them, run the following:

$ sudo apt-get remove dnet-common libdnet

Reboot, and running ifconfig will show your ethernet ports mapped to their correct MAC address. Now you should not have any problems running Google Music!