I instantly decided against hiring a DJ, because paying someone a bunch of money, telling him exactly which songs to play and which songs not to play didn’t sound worth it to me. I also decided against using an iPod, mostly because I don’t have one, but also because we allowed people to request songs on our wedding website, and we got a lot of requests for songs that we didn’t already own. Not wanting to buy all of those songs (some of which I would definitely NEVER listen to again), I decided my iPad would be our DJ and I would use a music streaming app.

Which to Choose?
My first plan was to make my playlists in Rdio, syncing them to my iPad so I wouldn’t have to worry about internet connectivity. All was well until I got requests for songs that Rdio doesn’t have. Rdio can match your local files, but it only adds the songs Rdio has; the rest get ignored. This is when I realized Rdio is the worst… except for everything else.

Spotify allows you to play your local files through their player so I bought a subscription and gave up on Rdio. After re-creating my playlists in Spotify, I downloaded their app on my iPad. At the time they didn’t have an iPad compatible app. (They released that about a week after my wedding. Seriously.) Their iPhone app looked funny on the iPad, but at least it would work. The only problem I had syncing local files to the mobile app was with the song She Moves In Her Own Way by The Kooks. Spotify has an acoustic version of the album, but not the original release. The album and all the songs are named the same, but the songs are different and even the song times are different, but that wasn’t enough. When I tried to sync the original release of the song to my iPad, Spotify kept giving me the acoustic version. I ended up renaming the song to get it to sync. Pretty annoying.

And then there’s crossfading. If there’s one feature on all music players that I rarely use, it’s crossfade. I don’t really care for it, but when you need it, you REALLY need it. If there is a second of silence on the dance floor, people will sit down. Well, guess what the Spotify app couldn’t do? (And yes, to answer the question you’re no doubt asking, the version they released a week later can do it. SERIOUSLY?!) The desktop version of Spotify had the crossfade feature though. It wasn’t looking very good for the iPad.

Bummer… Except Not Really
I begrudgingly came to the conclusion that my only remaining option was to give up on the iPad and use Spotify on a computer. Having to open it to change playlists would be annoying, but for better functionality, it would be necessary. But because I was already using my computer for our photo booth, it meant I had to borrow one. Fortunately, there was no shortage of MacBook Pros among my friends.

In the end, the music worked out great. I’d definitely recommend Spotify for DJ purposes, especially now that they’ve released their iPad-friendly app. And did I mention that it came out a week after my wedding? I did? Well… that really sucked.

grails.project.war.file="target/${appName}-${grails.util.Environment.current.name}-${appVersion}.war"

After getting the correct WAR file deployed, the next challenge is identifying the version of code running if/when bugs are found. Grails has a built-in mechanism for versioning which works well when I remember to actually use it. And unless you’re setting a new, unique version after each change, the version won’t tell you exactly what code is running. Fortunately, Git gives us an easy and automatic way to identify the code–commit hashes. The only trick is getting the hash into the app so it can be displayed. To accomplish this, we can hook into the Grails event model to ask Git for the current commit hash at compile time. Create a scripts/_Events.groovy file with the following contents:

eventCompileStart = { msg ->
  new File("grails-app/views/_git.gsp").text = ("git rev-parse HEAD".execute().text)
}

This will put the latest Git commit hash into a GSP template called _git.gsp which you can include on any page in your app. I’ll generally put this in the footer of the main layout, either visible or commented out, so it is on every page. You’ll want to add _git.gsp to your .gitignore file since it will change frequently.

Hopefully these two little tricks will make working with your Grails apps across different deployment environments a little bit easier.

• If it is expensive to read/create the data (reading across the network)
• If the data will be used more than once
• If multiple users need to access the data so you need to store it outside of a single user session

Here I will give you one example of how to use an in-memory cache. This can greatly improve performance but there are a couple of things you must keep in mind.

Scoped Services

One approach for storing the data is in an instance variable in a service. By default, Grails services are singletons, so only one instance of the service ever exists. Because of this, you could do something like this:

class MyService {
    private def cache

    public MyService() {
        //initialize the cache
    }

    public getValue(String key){
        //load value if it is not in cache
        //return value from cache
    }
}

Every request from a controller that accesses the service will be accessing the same instance, and therefore will be accessing the same “cache” variable.

Cache Considerations

This can be pretty powerful, and can help performance considerably, but there are some considerations you must think about.

1. Concurrency – Since all requests are going to be accessing the same instance, you must ensure that the “cache” variable is accessed in a thread-safe way or correctly handles concurrency
2. Memory Size – Since there will only ever be one instance, there should be a mechanism for removing old entries from the cache and/or limiting the size of the cache.

Google’s Guava Cache Library

A very good way to handle this is to use Google’s Guava cache library. Some of the key benefits are:

• It has built in concurrency handling
• You can expire contents of the cache automatically
• You can limit the size of the cache
• You can just call “get” on the cache and it will either return the object from the cache or load it if needed

To include the Guava libraries in your Grails project, you need to update your BuildConfig.groovy and add this line:

grails.project.dependency.resolution = {
    dependencies {
        compile "com.google.guava:guava:12.0"
    }
}

Then to setup your cache in your service you can do this:

public MyService() {
    //initialize the cache
    cache = CacheBuilder.newBuilder().
	expireAfterWrite(60, TimeUnit.MINUTES).
	maximumSize(500).
	build(new CacheLoader() {
		public MyExpensiveObject load(String key) {
		    return doExpensiveLoadOperation()
		}
        })
}

This cache (a LoadingCache object) will have a maximum of 500 entries and each entry will expire after 60 minutes. If the value is not already in the cache, the “load()” method will be called and the result (a MyExpensiveObject in this case) will be returned. There are other configurations to expire cache entries well explained in the documentation.

To use the cache then you would just do this:

def getValue(String key){
    return cache.get(key)
}

You do not need to check if the object is in the cache because if it is not it will automatically be loaded.

Conclusion

Using an instance variable on a singleton service can serve as an in-memory cache, and by using the Guava libraries you can overcome the most complicated issues surrounding caching.

References

• Scoped Services From Grails Documentation
• Google Guava Library – Caches Explained

Music is something most of us take quite seriously, but have you ever thought about the effect music has on the workplace? Think of what your day would be like without music in your office.

For over a year now I have been using the music app Rdio. I’m sure some of you are familiar with the service or others like it. Spotify is another popular example. Apps and services of these types are taking the phrase word of mouth and putting it at the fingertips of users enabling the rapid sharing of music. Like most things on the internet, its so quick to share and sharing creates engagement, which has had a very positive effect in the Refactr workplace.

Why we listen
Music is entertainment for our ears. It’s there for us no matter what mood we are in. It covers up the background noise that distracts us from focusing. People have playlists created with specific selections of music that they’ll listen to when they need to increase their productivity.

Music at Refactr
The music listening habits of the Refactr employees varies from day to day. There will be days when everyone is heads down listening to their own music. A good chunk of the employees here use Rdio, there are a few Spotify users and any others are either using Pandora or iTunes.

When we aren’t heads down in work or when someone decides to take the dj reigns we have a office Sonos player. The way we use the Sonos varies. Often someone just puts an album into the queue and it will get played through its entirety. There are other days where we collaborate with a theme in mind and a good majority of us will contribute to the music queue that way. This can be fun! Themes have varied from 90’s rock to 80’s rap and during a hack day not long ago we even collaborated on a remix playlist (listen below).

When turntable.fm hit the scene we all got really into it for a few weeks. Then we soon realized how distracting it can be. Turntable was great though, it got us all engaging with one another through this collaborative dj application, we’ve since gone back to taking turns with the Sonos.

Workplace benefits
Besides the obvious benefits of listening to music at work, there are also aspects of music listening that have brought the Refactr team closer.

Sharing music is one way we get more involved with one another. When we share, it creates engagement through conversations and conversations amongst employees is always a positive.

As a result of similar music tastes amongst employees in the office there’s been times where small groups of us have gone to concerts. Most recently you would have found several of us together at the Of Monsters and Men show at The Fine Line Music Cafe. We all know how important team building can be, but it doesn’t have to happen at the office. Spending time with coworkers outside of work can be quite beneficial! There’s a lot to learn about the people you spend day after day with, why not hang out with them outside of work? At Refactr we are big advocates of this!

We have all made the choice to be a Spotify, Rdio, Pandora, iTunes or other music user. That choice came with a lot of thought and reason. As tech enthusiasts we tend to judge an application or service more than the general public. There have been many debates and conversations over these various applications. We’ve talked about and compared the overall user experience and design of apps. Often we discuss certain features that an app should have or shouldn’t have. All these conversations surrounding our decisions for using a music service, or any app, are great and usually lead to more lengthy conversations that relate to the work we do here at Refactr.

Overall music at work just brings people together in a not so work specific way. If we are always engaging with our coworkers we will always be growing and becoming a better team.

Follow some of us and find out what we are listening to!
Refactr, Ben, Jesse, Hiromi, Dane, Kyle, Steve

Leave a comment and let Refactr know how music fits into your work day!

You’re free to download and run these manually yourself and install with Virtual PC, if you’re on a Windows machine. If you’re running Linux or OSX, however, you might want to instead try the following:

1. Install VirtualBox
2. Follow these instructions to automate the download and installation of the virtual machines.

…which gives you this (I wasn’t able to get IE6 working…maybe that’s for the best):

Regardless of how you choose to do this, the download time is pretty painful (probably several hours).  The payoff is pretty nice, however:  fast Internet Explorer testing at your fingertips.

When using relational databases, we sometimes take for granted certain operations that appear to be missing in “NoSQL” databases like MongoDB, such as the ability to group data and run aggregate functions in SQL, like sum, max, etc. These things can still be accomplished in MongoDB with MapReduce, of course, it just requires a different approach than in a relational database due to design choices that favor huge, sharded datasets.

The concept of MapReduce itself was nothing new at the time to functional language aficionados, but Google took the algorithm and applied it in a distributed computing context in their popular 2004 paper on the subject. MongoDB’s approach is fairly similar.

A Simple Blog App

Let’s walk through a simple blog example using the MongoMapper gem. The source code of this example is available here.

We’ll start with 2 simple models, shown below: User and Post

class User
  include MongoMapper::Document
  safe

  many :posts
  key :username, String
  timestamps!
end

class Post
  include MongoMapper::Document
  safe

  belongs_to :user

  key :content, String
  key :tags, Array
  timestamps!
end

Now, let’s generate some sample data:

pete = User.create username: 'pete'
sally = User.create username: 'tony'
joe = User.create username: 'sally'

Post.create user: pete, content: "Blog post content", tags: ["t1", "t2", "t3"]
Post.create user: pete, content: "Blog post content", tags: ["t2", "t3", "t4"]
Post.create user: pete, content: "Blog post content", tags: ["t2", "t3", "t4", "t5"]
Post.create user: sally, content: "Blog post content", tags: ["t2", "t3", "t4", "t5", "t6"]
Post.create user: joe, content: "Blog post content", tags: ["t2", "t3"]

Enter MapReduce

Based on this simple structure and sample data, we might decide that we want to know which users have been using the most tags. With MongoMapper, we could do the following:

class UserTags
  include MongoMapper::Document

  key :value, Integer

  def self.map
    <<-MAP
      function() {
        var post = this;
        this.tags.forEach(function(tag) {
          emit(post.user_id, 1);
        });
      }
    MAP
  end

  def self.reduce
    <<-REDUCE
      function(key, values) {
        var sum = 0;
        values.forEach(function(value) {
          sum += value;
        });
        return sum;
      }
    REDUCE
  end

  def self.build
    Post.collection.map_reduce(map, reduce, { out: "user_tags" })
  end
end

# Run the MapReduce job, store the results
UserTags.build

# Get the user who used the most tags on their posts
UserTags.sort(:value.desc).first

Some explanation…

In the MapReduce operation, we first emit a user_id key with a value of 1 for every tag that exists in the system. Since the key in the emit is used for grouping, when we get to the reduce step, it will receive an array of the emitted values for each key to combine in some way (I chose to sum them). We choose an output collection (out: “user_tags”), into which the results are dumped for later retrieval (it could potentially be a time consuming operation if the dataset is very large). Then a simple sort by this sum value will give you the highest user/tag-count combo in the database.

Note that even though MongoDB lacks the transactional semantics that are usually available to relational databases, this operation is nonetheless atomic. While the MapReduce operation is running, it is being output to a temporary collection which is only renamed to “user_tags” (which backs the UserTags model) once the MapReduce is complete, meaning that running this job shouldn’t cause the collection to become unavailable.

Additionally, if you decide to shard your data, the MapReduce operation can run concurrently on every shard.

In this example, I will use the GPS data from my watch to create a heat map that shows where the common areas are that I run:

Get Data

To get the data, I exported all of the history from my GPS-enabled watch software. The only trick here was converting GPX data to CSV. If you want to do this, you can use the Groovy script at the bottom of this post, or there are a number of sites online that will convert many different GPS formats for you (this one for example)

There are also a number of apps for iPhone and Android that will let you export your GPS data.

Create The Heat Map

Once you have your data in CSV, you are ready to follow these simple steps to create your heat map.

1. In Google Docs, choose to Create > Table. Note: this is currently in Beta
2. Upload your data on the Import step.
3. You now need to tell Google to use the columns Latitude and Longitude as “location” columns.
   1. Edit > Modify Columns
   2. Select the first column (either Latitude or Longitude)
   3. Change the type to “Location”
   4. Check the “Two column Location” box and make sure the Latitude and Longitude are assigned correctly
      
4. Now check out the map:
   1. Visualize > Map
   2. Check the “Display as heat map” checkbox near the top

Groovy Script

Here is a simple Groovy script to convert GPX to a CSV list of longitude and latitude:

//get all the GPS points
def gpx = new File('running.gpx')
def gpxData = new XmlSlurper().parseText(gpx.text)
def allPoints = gpxData.depthFirst().findAll{it.name() == 'trkpt'}

//create the new CSV
def csv = new File('running.csv')
allPoints.each{csv << "${it.@lat.text()},${it.@lon.text()}\n"}

Note: this script converted over 5000 data points in just over 1 second.

Adam will be jumping into a Grails project leveraging several social APIs. One of his recent projects he’s proud of involved implementing a document management system, centralizing and migrating over 150,000 files that were distributed across many locations  that can be replicated globally.  One of biggest challenges was building a tool to migrate the large amounts of metadata associated with each file without losing any information. The project was a huge success!

Welcome Adam!

There are multiple language alternatives to Java on the JVM, like Groovy, Clojure, Scala, Jython, etc. But with the popularity of Ruby on Rails and JRuby, there’s another bloat free option to Java with all the scalability, tuning, and tools that come with the JVM. On top of that sweetness, you have one deployment option: the JVM.

With all the great work that the JRuby team has done to make Ruby work on the JVM, it’s a no brainer to deploy Rails-based products on the JVM.  We hope to catch up with the local Ruby developers at JRubyConf.

Why Switch?

Why should you use STS? Since STS is built on Eclipse, you get a number of nice features built in. Here are just a couple of my favorites:

Outline View:

Content-assist / Autocomplete:

Automatic refactoring tools (like renaming all instances of a variable):

And many more:

• Support for groovy, gsps, java, css, javascript, and many more
• Auto formatting of files including fixing indents and spacing
• Highly configurable workspace (tabbed editing, split-pane editing, task lists, etc)
• Huge Plugin community (source control, other languages, etc)

Installation

Assuming you are already doing grails development, installation is very straight-forward. Follow the instructions on the grails.org site here: http://grails.org/STS+Integration

If you are starting from scratch, you will have to install Java and probably specific versions of Grails before you can install STS.

Out of the box, STS is geared towards Spring development. Since Grails runs on top of Spring, after you install STS you have to install a couple plugins for Groovy and Grails. It is all detailed in the grails.org post. Assuming you already have Grails installed on your computer, you do not need to install the Grails language extension. You will just need the Grails and Groovy “tooling extensions.”

Initial Setup

Once STS is installed and open, here are a couple of things to get started.

First, setup your Grails installations if you did not do that during the installation. Go to the Preferences (MacOS: SpringSource Tool Suite > Preferences, Windows/Linux: Window > Preferences) and then navigate to Groovy > Grails. Just browse to your grails directory and STS will fill in all the details for you. You can do this for as many versions of Grails as you want. The default will be used for new projects, but you can always specify which version to use for a specific project.

Next, switch to the Grails perspective and you are ready to go.

Importing Existing Project

To pull your existing Grails project into STS, just follow these steps

1. File > New… > Grails Project
2. Under Contents, change it to “Use External Location” and Browse to your existing Grails project

There are a couple things that may now happen, depending on which version of Groovy and Grails you are using.

First, you could get a “Incompatible Groovy Compiler Version” warning

In my case I was importing a Grails 1.3.7 project and my Groovy version was 1.8.6, which is more recent than Grails 1.3.7 uses. Most of the time I just ignore this message because I do not have any problems with using so-called “incompatible” versions. However, you can easily switch to a different version of Groovy if needed. Go to the Preferences > Groovy > Compiler. In here is a button to switch versions of Groovy and a link with more details.

Second, you could get a “Grails version mismatch detected” warning

In my case, the default Grails in STS was 2.0.3 and my project was 1.3.7. If you say “Yes” it will run “grails upgrade” on your project. If you say “No” it will configure you project to use the correct version, 1.3.7 in my case. You can see what version of Grails is configured for a project by right-clicking (control-click on a Mac) on the project name and choosing Properties then Grails.

Third, you could get a “Grails version x.x.x not installed” warning

As you can guess, this means the version of Grails specified by your project is not installed in Grails. You can either upgrade your project through STS (clicking Yes) or go back and configure STS to use that version of Grails.

Features of STS with Grails

Project Explorer:
Since Grails uses “convention over configuration”, STS can easily identify your domain, controller, view, service, etc classes and will group them accordingly:

Running Grails Commands:
Built into STS is the ability to run any Grails command, just like you would from the command line. Some are tightly integrated and others not so much. For example, you can do File > New > Domain Class (or Controller, or Service, etc) which will run “grails create-domain-class MyDomain” automatically.

You can also run any other Grails command with the “Grails Command” button in the toolbar:

This will bring up a prompt and you can enter any command:

If you enter run-app like I did, it will bring up a server within STS and you can click on the URL in the console view. That said, I typically still run the application from the command line out of habit.

You can still run commands from the command line. Just remember to refresh your project in STS if you are creating any new files.

Note on Source Control

Using STS will create a new target-eclipse directory in your project and may put some items in the .settings directory. You will probably want to exclude these from your source control (using .gitignore or similiar)