In their announcement blog post, AppFog stated: “Cloud Foundry alone has no web interface, no pricing, no plans, no IaaS integration (no AWS, no S3), no support. That is where AppFog shines.”

True to their word, AppFog provides deployment to 4 different providers and offers 64 gigs of memory for a monthly rate of $29.99 (Gringo Dollars).

In this post, I’ll walk briefly over my first impressions deploying a Grails application on AppFog. Overall, it is a much richer and pleasant experience than Cloud Foundry and looks like we finally have a competitor to Heroku or Cloudbees.

Deployment

Since appfog has the same underlying structure as CloudFoundry, deploying a new application to it was the same as the traditional Cloud Foundry plugin.

One consideration is that you needed to specify the deployment target.

In grails-app/conf/Config.groovy, add the following lines

grails.plugin.cloudfoundry.username = "email@example.com"
grails.plugin.cloudfoundry.password = "mypassword"
grails.plugin.cloudfoundry.target = "http://api.aws.af.cm"

After building your application, you simply deploy it like a typical cloudfoundry application

grails prod cf-push

After deployment, you should see your application deployed correctly. Mine can be found at http://grails.aws.af.cm

Targets – Deploying to stuff besides VMware iron.

AppFog offers 4 different type of targets aside from the one offered by VMware:

• api.aws.af.cm – AppFog’s Amazon-based service
• api.rackspace.af.cm – AppFog’s Rackspace-based service
• api.hp.af.cm – AppFog’s HP Cloud-based service
• api.joyent.af.cm – AppFog’s Joyent-based service

However, it doesn’t seem that you are able to have further control over this, so it wasn’t very clear that you could specify that you wanted your Amazon servers to be based in Ireland, for example.

Services

Appfog offers support for MongoDB and MySQL.

By default, the cloud foundry plugin will ask if you want to provision a service for MySQL and Postgres. Selecting that you wanted to deploy a Postgres service broke the deploy script by returning a null.

Tunneling support to access services on AppFog is provided.

Admin UI

What makes AppFog really exciting compared to the VMware solution is the Admin UI that they offer for your application.

Your application appears on screen after you have logged in,

you can also view the services you have provisioned.

Clicking on your application takes you to a quick admin console.

Taking a page out of Heroku, you can quickly configure the number of instances of your application you want to run at the time. I was able to quickly and easily add another instance of my grails application with little hassle.

Appfog also provides the ability to map custom domains, something that CloudFoundry has promised for over 10 months and has done nothing about.

You can also easily modify your application settings and see the statistics. Overall, it is very nicely done for a preview version:

One of the niceties of Appfog is that you can create a github or dropbox based repo and it will automatically build this and deploy it for you. Unfortunately, this is not available for Java or Grails.

Pricing

Another element missing from Cloud Foundry since it’s introduction is pricing. Appfog seems to suggest that for $29 / month, you are able to get 64 gigs of memory. This might just be a placeholder value, but it’s nice to see that at least they are trying to attach a figure to hosting on their services.

Summary

Overall, I was very impressed with the AppFog Beta. It seem compatible with the grails plugin for Cloud Foundry and deployment seems to be fairly painless.

The lack of Grails / Java github support is disappointing. I would still probably use Heroku or Cloudbees for a git-based continous deployment approach.

As a long time Cloud Foundry user, it feels like a lot of holes in the VMware offering are plugged by Appfog. It is quite refreshing to see a company taking the Cloud Foundry project into the commercial sphere instead of just being an academic exercise. Appfog is what Cloud Foundry should have been when it launched.

You can request early beta access for appfog on their site here.

However, there seems to be quite a wait for this, as I remember requesting access when the service was first announced back in August.

In this post, I show how you can set up a separate webdriver profile for a subset of your spock/geb functional tests. 

In order to specify a separate driver profile ( we’re setting an iPhone user agent in our tests ), we needed a way to mark the new tests we’re creating to use this separate profile.

Marcin Erdman suggested in the Geb mailing list that it is possible to use the Geb Configuration mechanism to accomplish this, but you would end up creating a new driver for each test, which we wanted to avoid.

After a little bit of tweaking, we came up with the following base class for our tests to extend.

import geb.spock.GebSpec
import spock.lang.Shared
import org.openqa.selenium.firefox.FirefoxProfile
import org.openqa.selenium.firefox.FirefoxDriver

class MobileSpeck extends GebSpec {

@Shared def cachedDriver

def setupSpec(){
  // create a new firefox profile with an iPhone user agent and cache it

  FirefoxProfile profile = new FirefoxProfile();
  profile.setPreference("general.useragent.override", 'Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.1');
  cachedDriver = new FirefoxDriver( profile )
}

def setup(){
  // assign this as the default driver on the browser for each test
  browser.driver = cachedDriver
}

def cleanupSpec(){
  // after running the spec, kill the driver
  cachedDriver.quit()
}

}

( Note, this code is for 1.3.7, you might need to change GebSpec to use Specification if you are using grails 2.0. )

Basically, we create a new firefox driver with the desired profile and cache it in memory.

When a new spec is ran extending this speck ( we use the base class speck so that spock won’t try to run it as a test ), it will be assigned the new cachedDriver and use it instead of the default Geb driver.

After adding this Speck, we are able to specify a test by just extending the class. I.e,

class iPhoneUserLoginSpec extends MobileSpeck {

...

}

You can view the entire talk here.

After having a little think about it, I feel like there are a few other things that would be nice to have to make Grails a easier choice for developers:

1. A Payment / Transaction / Shipping API ( E-commerce plugins ) - Right now, it is fairly difficult to add a Payment Gateway or Merchant Account. Tools like Magento in the PHP world do a fantastic job in abstracting away the details of integrating a payment gateway and merchant account. It would be nice to have a common API extended by all the different payment plugins. This would make it easier to build ecommerce functionality without having to worry about whether you are using BrainTree, Authorize.net or Satan’s favorite Payment Gateway, Paypal.

2. Internationalization API – At the exchange, I mentioned that Globalizing a Grails application is still a bit complicated. There seems to be a few plugins that set out to help localize domains and message bundles, but what seems to be lacking is a plugin like resources where you can go – “oh, I need to support multiple languages, I need to install the Globalize plugin”.

Message bundles simply do not go far enough in this respect. There still doesn’t seem to be a straightforward way to add multiple language enabled domain classes, url mappings or do ad-hoc language switching very easily. This problem was very apparent 4 years ago when I was building sites in Canada, and it is still true today. 

3. Easier to customize scaffolding – The CRUD interfaces provided by Grails scaffolding are getting very nice. But it would be nicer if the scaffolding framework could be more extensible. If you look at the code of plugins like Flex Scaffold, there seems to be a lot of work being done for it to be similar to the default html scaffolding.

It would be nice if there was a common scaffolding interface that enabled adding rich client or mobile templates. It would also be nice if it was possible to add more template types, so instead of the typical ‘You can edit only one item at the time in separate screens’, scaffolding supported things like adding master-detail views, search and reporting templates and other types of alternative views that are automatically generated.

4. A/B Testing Framework - Working with frameworks like Google Website optimizer, it is pretty clear that a native grails A/B testing framework like ABingo or Vanity.

5. Member Services / Identity API – Working on a member’s only site for the last year has highlighted the need for a higher level framework for managing users. Nimble, Spring Security UI all provide a pretty good approach. But it would be nice if there was a common extensible core for this type of functionality.

6. Easier Reporting - on the business needs end of things, it would be nice if there was a slightly higher level page view tracking and reporting mechanism enabled. In our talk, we talked about how we built a simple engine that enabled us to store SQL / Groovy queries and render this out into reports. It would be nice to be able to easily generate summary reports and charts on domain classes, pageviews and similar mechanisms.

7. Content API / SEO - There doesn’t seem to be a lot of information about how to make Grails sites very SEO friendly. It would be nice if the URLMapping and Layout mechanism enabled easier customization of domain objects to inject specific fields like title, keywords and descriptions to domain objects. Also, having the ability to have sitemaps automatically provided and robots.txt templates provided would be very helpful.

Can you think of anything else?

The problem

At Secret Escapes, we have been struggling with the amount of time it takes to run functional tests. Our tests written in Geb and Spock has grown substantially and it takes up to 25 minutes to run completely.

During Luke Daley’s talk at the GGUG in London, he mentioned that one solution to speed up running functional tests was to set up multiple environments and run functional tests against each of them.

We wanted a way to do this in developer machines so they could run in parallel. After a few days of head scratching and ‘WTF doesn’t this work!’, we ( Donovan Frew, Michael Stogowski and me) came up with the script below.

The Script

Save this script in your scripts directory. The name we use for it is TestFunc.groovy

import groovy.sql.*
import org.codehaus.groovy.grails.test.*
import org.codehaus.groovy.grails.test.support.*
import org.codehaus.groovy.grails.test.event.*

includeTargets << grailsScript("TestApp")

target(main: "Runs functional tests in parallel in sets of bucketSize") {
	def reportsDir = 'reports'
	def numberOfServers = 5

	def sql = Sql.newInstance('jdbc:mysql://localhost:3306/', 'root', '', 'com.mysql.jdbc.Driver')

	def tests = new SpecFinder(binding).getTestClassNames()
	new File(reportsDir).mkdirs()
	def commands = []
	def threads = []
	def results = ''

	numberOfServers.times { id ->

		def reportsFile = new File(reportsDir + '/' + 'test' + id).absolutePath

		sql.execute( "DROP DATABASE IF EXISTS parallelDB${id};" )
		sql.execute( "CREATE DATABASE parallelDB${id};" )

		def pattern = ''

		tests.eachWithIndex { test, index ->

			if (index % numberOfServers == id)
			{
				pattern += " ${ tests.get(index) }"
			}

		}

		def command = "grails -Dgrails.project.test.reports.dir=${reportsFile} -Dserver.port=909${id} -Ddb.name=parallelDB${id} test-app functional:  ${pattern}"

		threads << Thread.start {

			println command
			ProcessBuilder builder = new ProcessBuilder(command.split(' '));

			builder.redirectErrorStream(true);
			Process process = builder.start();

			InputStream stdout = process.getInputStream();
			BufferedReader reader = new BufferedReader(new InputStreamReader(stdout));

			while ((line = reader.readLine()) != null)
			{
				if( !line.contains( 'buildtestdata.DomainInstanceBuilder' ) ){
					System.out.println("Server ${id}: " + line);
				}

				if( line.contains( 'Tests passed:' ) || line.contains( 'Tests failed:' ) ){
					results += "Server ${id}: " + line + '\n'
				}
			}

		}

	}

	threads.each {
		it.join()
	}

	println '------------------------------------'
	println 'Tests FINISHED'
	println '------------------------------------'
	println results

}

setDefaultTarget(main)

class SpecFinder extends GrailsTestTypeSupport {

	SpecFinder(binding) {
		super('name', 'functional')
		buildBinding = binding
	}

	int doPrepare() {
		0
	}

	GrailsTestTypeResult doRun(GrailsTestEventPublisher eventPublisher) {
		null
	}

	def getTestClassNames() {
		findSourceFiles(new GrailsTestTargetPattern('**.*Spec')).sort{ -it.length() }.collect{ sourceFileToClassName(it) }
	}
}

How it works:

This script only works with Geb Specs. If you need to use some other sort of functional testing, you will have to modify the way you identify your tests.

In order to have parallel environments, we needed to set up:

1. Different Databases
2. Different Report Directories so they wouldn’t get overwritten by each other
3. Different Ports to run functional tests against.

Notes about the script

• We use the ProcessBuilder instead of the standard Groovy .execute() method so we can bind the output of the script straight to the console while the script is running.
• Funtional specs are sorted by file size and executed via pattern matching. It could be more sophisticated but seems to work.

Application Changes needed for the Test environment

• To get this to work, we needed to change places in our Config.groovy that had a hard-coded reference to 8080. Instead, we specified a port name like so:

  grails.serverURL = "http://localhost:${ System.getProperty("server.port")?:'8080' }/${appName}"

• You also need to change the way your test environment loads it’s datasource so it can be overwritten by the command line. We changed ours to

  def dbName = System.getProperty("db.name") ?: 'flashsales_test'
  url = "jdbc:mysql://localhost:3306/$dbName?autoReconnect=true"
  

• This way, whenever db.name was specified in the command line, the test Datasource would use this.
• Change our functional tests so that there are no hard references to port 8080.
• We use mysql and the groovy sql mechanism to create new databases for these environments. You might choose a different poison.

Running the Script

• You can change the number of instance you want to run by changing the numberOfServers value. A quick modification to the script would be to make this value one that the script gets, but we haven’t gotten there yet.
• To run, just type grails test-func in your console.

Results

After getting this to work correctly, we noticed that in some cases, our test execution time went down from 26 minutes to 12 minutes. It is a definitive improvement.

Things to Do Next

• We would like to use the Grails pattern matching for test-app here, but haven’t had a chance to dig deeply into the code to do so.
• Number of servers, database names should all be configurable or read from Config.groovy.
• Not sure if running something like GPars would give us a performance gain over running scripts again.

One of the issues we are running into with Groovy’s execute() method and its online examples is that the output from the process is not available until the process is finished.

When running Grails functional tests, we want to see the results right away in the console to debug things that are going wrong.

The solution we found was to use the Java ProcessBuilder task instead.

So instead of

myCommand.execute()

in Groovy, use the following wall of code:

ProcessBuilder builder = new ProcessBuilder( myCommand.split(' ') )

builder.redirectErrorStream(true)

Process process = builder.start()

InputStream stdout = process.getInputStream ()
BufferedReader reader = new BufferedReader (new InputStreamReader(stdout))

while ((line = reader.readLine ()) != null) {
   System.out.println ("Stdout: " + line)
}

You could probably change this so that it replaces the groovy metaclass methods, but it’s a start.

The executor plugin allows you to move tasks that might be long running into the background of your application.

In this post, I will show you how to unit test spock interactions wrapped inside the runAsync methods provided by the plugin.

A typical block of code within executor would look like this:


myServiceMethod() {
... non Async code ...
runAsync{
someOtherService.asyncMethod( var1 )
}
}


We ran into a peculiar problem while moving our code into the executor plugin today.

We normally mock interactions in spock within our unit tests to make sure that certain methods are called.

our tests run something like this:


when:
service.serviceMethod()
then:
1 * someOtherService.asyncMethod( _ )


This works fine when you have no code within the runAsync block, but if you move code into the runAsync closure, the method call don’t get detected by Spock anymore.

It meant that moving our code to make it asynchronous also broke our unit specs. All our interactions would seem to disappear as they were now being ran in another thread.

The way we were able to solve this problem is to just rewrite the runAsync method in the service metaclass within our tests, so we added:


given:
service.metaClass.runAsync = { it() }
when:
service.serviceMethod()
then:
1 * someOtherService.asyncMethod( _ )


The first line basically says ‘take the code within the runAsync closure, and just execute it’.

After adding this, all our unit specs pass again.

Groovy is the heart of Grails, but it is surprising how easy it is to get by writing code the Java way.

I think it was four months after I started writing code in Grails that I started looking at the Groovy books, and they definitively helped me improve the code I was writing tremendously.

• Venkat Subramaniam’s Programming Groovy – Good chapters on metaprogramming.
• Dierk Koenig’s Groovy In Action, 2nd Edition, MEAP – Excellent for understanding newer concepts like AST transformations.

2. Consume videos, podcasts and blogs

There is no lack of new content being published on the web about Grails and Groovy. The following are my favorite resources:

• Burt Beckwith publishes a weekly summary of the things going on in the Grails ecosystem in This Week In Grails.
• The Grails Podcast, GoovyMag and Groovy Tweets are really good ways to keep track of new ideas in the Grails ecosystem.
• Messages from Mr. Haki and Peter Ledbrook’s posts on the SpringSource blog are vital references for the Grails developer.
• SkillsMatter publishes all the videos for the Grails Exchange in London for free every year. The collection of presentations is pretty impressive. (2010 | 2009 )

3. Answer one question on the grails-user mailing list every week.

One of the things I like to do is to challenge myself to answer one question in the grails-user mailing list every week. Answering just one question forces me to sift through all the new questions coming through and seeing if I can find a quick and easy solution to a real world question.

Instead of answering something I already know, I try to pick a question that might take 5-10 minutes to answer. More often than not, the questions will force me dig into the code of a plugin or try to do something different within the grails console.

For me, this is the easiest way to come up with a guided exploration of ideas and concepts within Grails. I highly recommend it.

4. Read plugin source code and samples.

Something I found myself doing a lot is digging into the source of plugins like Geb or App-info and seeing how everything connects together. Other times, I find myself digging into smaller plugins like Taggable to understand how other people implement certain things.

I found exploring other people’s code allows me to add to my groovy manna that I can then use when writing my own code and plugins.

Another useful exploration is to expand the source code of the tag libraries within the Grails documentation by clicking Show Source. One of the better surprises for me recently is seeing how elegant the scopes within the g:set tag were implemented.

A final useful tool is to see and read the code that other people have written for the groovy web console.

5. Talk at / attend a conference or user group meeting. 

One of the more interesting experiences of my programmer life has come from talking at Grails conferences and user groups. There is just something about condensing the stuff you have learned and talking about it for an hour in a way that doesn’t put your audience to sleep. It forces you to spread out your thoughts and carefully examine the work you do. I highly recommend it.

If you rather just listen, there are a bunch of User Group Meetings.

A few conferences are also coming up to learn more about Grails, including SpringOne2GX, Groovy and Grails Exchange, Greach and the GR8Conf. I highly recommend attending those.

6. Work on a real project.

Of course, there is no better way to learn Grails than to interact with a real team of developers and work on a real project from start to finish. I’ve often found that the work we do day-to-day helps guide a lot of the blog posts and plugins I end up writing.

Many of my recent plugins like CDN-resources, Website Optimizer and Inviter have come from requirements in our projects. I find that by pairing and working with other people, the way in which I write code just gets better by leaps and bounds.

There seems to be a lot of opportunities popping up, you can always check Grails Jobs for the latest listings.

Shameless plug

Finally, if you’re in London and would like to learn more about Grails, why not consider working with Secret Escapes. We are looking for talented Grails developers, so get in touch.

Many of the posts on the web ( like this one, or this one )describe how to get started with the Resources plugin from scratch. However, chances are that your project already uses UI-performance. How easy is it to migrate an existing project to use Resources?

In this post, I would like to document the steps we took to migrate our Grails project from the UI-performance plugin to the new resources plugin.

Steps

1. Uninstall UI-performance

You do this by grails uninstall-plugin ui-performance

2. Install resources plugin

Grails install-plugin resources.

You might be tempted to install all the other related plugins at this point, but I would recommend just sticking with vanilla versions of the plugin.

3. Replace all references to ui-performance tags with new resources tags.

For this, I wrote a simple tag library that simply maps the UI-performance tags to resources tags

package com.flashsales.utils

// maps UI Performance tags to resources plugin tags
class ConvertUiPerformanceTagLib {

	static namespace = 'p'

	def css = { attrs ->
		attrs.uri = "/css/${ attrs.remove( 'name' ) }.css"
		attrs.type = 'css'
		out << r.external( attrs ) 	} 	def image = { attrs ->
		attrs.uri = '/images' + attrs.remove( 'src' )
		out << r.img( attrs ) 	} 	def javascript = { attrs ->
		attrs.uri = "/js/${ attrs.remove( 'src' ) }.js"
		attrs.type = 'js'
		out << r.external( attrs )
	}

	//  TODO: imageLink, favicon, inputImage, sprite, dependantJavascript and addJavaScript

}

UI-performance assumes certain defaults for directories, which resources does not. Using a tag library makes it easy to switch back and forth between the two plugins.

One thing that is important for these tags is that you can’t use relative paths in your file references. So if your tag is <p:image src=”myfolder/image1.jpg”/>, you need to change it to <p:image src=”/myfolder/image1.jpg” />

In our application, we don’t use sprites or the dependantJavascript tag, but you could write similar taglib code to override this.

4. [Optional] Add tags to your layouts to include the tags used by resources plugin to provide ‘ESP‘

At this point, you will want to change your layouts to include JavaScript resources in your application’s head and body.

Go through each of your layout files and add a <r:layoutResources/> tag in your head and body sections. This step is useful if you wish to leverage other features of the resources plugin in the future, but is not necessary for translating uiperf to resources.

5. Run your application and make sure everything renders correctly.

Try your application with both grails run-app and grails run-war to see that it works in the way you want it to work.

6. [Optional] Define modules.

One of the more powerful features of the resources plugin is the ability to define  modules that encapsulate a series of resources. One of the main benefits of this approach is that it guarantees that all your javascript and css files get included correctly, and they appear on the right place in your page. It also makes the inclusion of resources less verbose, as you can bundle several js files and css files together.

On the other hand, changing resources to modules is also tedious and error prone if you already have a bunch of resources defined with the Ui-performance plugin. You have to go through each page of your site that has a <p:whatever/> tag and refactor these to use the new <r:require> tags.

If you choose to declare modules, you will have to introduce a new file called ApplicationResources.groovy and follow the instructions in the plugin user guide.

7. [Optional] Change your tags from r:external to r:require.

If you have defined a module in the previous step, you will wish to change the parts in your code that reference the old css and javascripts, and replace them with the new, simpler <r:require tags/> for the modules. It really depends on why you want to switch from one plugin to the other.

8. Add additional support plugins and make sure that everything works correctly.

For our application, we’re adding the cached-resources, cdn-resources, less-resources and zipped-resources plugins. For this step, we install each plugin individually and make sure that they work correctly. Refer for each plugin documentation for additional steps. For the CDN-resources plugin, for example, I had to go ahead and set up a CDN location for my application.

9. Test and Deploy.

Discussion

If the UI-performance plugin works well for you, there is really no reason to migrate to the new resources plugin mechanism.

For us, there were two things that we are currently doing that made us want to switch to Resources:

1. we started using LESS and it felt that this is slightly better supported by the resources plugin than by UI-performance.
2. We wanted to use a CDN. Although we got UI performance to work with a CDN, the version of the plugin that included the patch ( 1.2.2. trunk ) had some issues dealing with images in css files. At the end of the day, it felt safer to write a simple mapper to enable CDN support.
3. Cached-resources is more efficient than the current way in which UI-performance handles versioning.

   In UI-performance, a new CSS, image and JS file gets created and downloaded by the client whenever a new War is pushed.

   Given that we follow principles of continous deployment, it meant our clients kept downloading the same images over and over again. Using Cached resources means that we are able to reduce the number of files being downloaded by our clients.

4. We like the notion of modules and feel that this is something we would like to refactor our code to use.

Hopefully, you would agree that the process of transitioning an existing project that uses the ui-performance plugin into resources plugin is fairly seamless and pain free.

However, I always found it difficult to present this to job applicants. Our initial job postings where hastily copied from other job postings and failed to present our culture of sharing and collaboration.

We recently had an opening for a Junior Grails Developer, and I thought it would be interesting to have the team help me come up with a new job spec that would reflect the company they would be working with.

After a couple of hours, we came up with a new job description that we think presented our development team much better.

In the old spec, we focused a lot on the technology side of things. For developers working in the Java world, having the ability to play with Grails and Groovy is certainly very appealing. But this alone would not convince me to send my CV over to a new company. We tried to make it very clear about the type of people we wanted and the type of team we are.

What makes us different?

The new spec now has a section that asks, ‘what is it like working with us?’.

What is interesting about this section is that it really reflected our development vision and culture.

The other developers and I are big fans of not just writing code, but crafting it and making sure that it not only works, but that it is easy to maintain and fully tested.

When reading other job specs, it was very hard to figure out what these other companies were like. By sitting down with my development team and asking them: ‘so, what makes working with us that is different than some big stuffy bank?’, we were able to come up with a better description of how we work.

This is what we came up with:

Why work with us? Our developers say:

• We’re open to exploring and improving the ways in which we build software. We’re a team that embraces change and want to work with the best tools, processes and people.
• We continuously rotate our tasks while supporting and learning from each other.
• We are a young multi-cultural team.
• We socialize as a team. From team lunches on Thursdays to GGUG meetings, we have fun.
• We work closely with the business. We sit in the same space with the key stake holders. You get to see the impact of your work right away and get immediate feedback.
• We believe in working with open source, blog furiously and have released many plugins into the Grails ecosystem.

Who are we looking for?

One of the things that we discussed at a recent retrospective was getting the team more involved in the hiring process. This lead to a quick discussion about the characteristics of new people we want to bring into our team. Writing the job spec allowed to define the characteristics about this person that was not about technical skills, but also about how they approached writing and building applications.

This is how it looks like:

Who are we looking for?

• You are willing to explore new ideas and try out new tools.

• You treat programming like a craft, code cleanly, and want to get better at it each day.

• You appreciate that your code supports a business and care about how it will be used.

• You like the idea of dynamic languages, and want to work with world-class Groovy and Grails developers with lots of experience. This is a role where you can get great mentorship.

• You embrace agile principles like Test and Behaviour-driven-development,

• Pair-programming and Continous Deployment.

• You believe that great software is built through communication and collaboration.

• You want to be proud describing the types of web applications you are working on.

• You think staying in hotels is fun.

Conclusion

For reference, this is how our old job spec looked like – Click here.

And this is how the new position looks like – Click here.

After this exercise, it became very clear to me that job specs should always be written together by the team that is hiring.

Before, writing a job spec felt like a task that I wanted to get over with as soon as possible. By making it a collaborative task, it becomes enjoyable again because it forces us to really evaluate the must-haves about potential candidates and gets the whole team to agree on the qualities of the new candidate.

Shameless plug: we are hiring a new Junior Grails Developer in London. So please apply. We will also be at the Silicon Milkroundabout on October 30, so stop by and have a chat.

tl;dr – write job specs with your development team, because it’ll help you sync your brains