something fancy with coding

Just when I started to get a feel for Scala I got the news: my team will be joined each year by a young fellow from the states who participates in my companies fast-track program. Each assignment will be for 6 month. I was told I can expect talented IT individuals, but more or less fresh from college and most likely no developers. The expectation is to put them to good work, but also to teach them, maybe give them a new perspective - of course I'll get them to develop! While most will probably have done some programming class in college, developing on the job is slightly different. I also hope to give them a feel for what's necessary for quality software (and that quality software is indeed possible!), something that a lot of the older folks in my company seem to have lost faith in.

That said, I looked at the Scala code I just wrote and asked myself if I wanted to teach THAT. Short answer: nope. Still half-way through Scala for the impatient, barely time on the horizon to tackle Programming Scala. So, quick decision, back to Go!

Now nearly 6 month later and the first assignment over I'm really really happy with my choice. Not only was Go a good teaching language, I came to really like it over time. Some random thoughts:

first language where TDD just worked for me

http://peter.bourgon.org/go-in-production/ is a must-read

still not using any big frameworks, everything I built is small enough so net/http is just fine

https://github.com/kohsuke/winsw for services

accepting that Go needs more vertical space is vital, the benefit is super-great readability. Haven't encountered a 3rd party packet yet where I could easily just browse through the code and understand what's going on without too much head-scratching.

Due to a job switch I didn't have enough time to play enough with Scala and it's frameworks, so when I needed to whip up a quick proof of concept over the weekend I went back to Grails.

Using the new 2.3 version for the first time I quickly noticed that breakpoints would be ignored. This is because Grails started using forked exection, so a new JVM is spawned for the app itself - IDEA connects to the wrong VM!

Fixing is easy: either disable forked execution all together or enable forked debug and connect via remote debugging to the session.

The first is described in the docs, to disable forking for the run command go to BuildConfig.groovy file and change grails.project.fork.run to false:

grails.project.fork = [ run: false ]

To enable forked debug either use the command-line switch debug-fork or enable debug by setting it to true in the grails.project.fork.run map:

grails.project.fork = [ run: [maxMemory: 768, minMemory: 64, debug: true, maxPerm: 256] ]

The title might not make that much sense, but that’s what I’ve been doing for the past few weeks (in addition to an amazing trip to Chicago) - trying to figure out what web framework to use in the future.

Up until now

I have been using Grails since version 1.1 and have been pretty happy so far. It met the requirements I had for a web framework in the environment I work in. Those were mostly:

must run on Tomcat 5.0 / Java 1.5

development speed > runtime speed

I’ve been using a JSF/Spring combo before that and I really didn’t like the approach JSF uses. Several things changed since then from my perspective including my personal requirements.

Current situation

From my perspective Grails has been losing steam over the last month and never gained the amount of traction I hoped it would get. The plugin ecosystem might be okay-ish, but it’s by far not on Ruby on Rails-levels. In addition to that Burt Beckwith, author of quite a few plugins and formerly author of the weekly “this week in grails” blog went silent in July. I haven’t checked if he continued to work on plugins, but this still prompted me to finally take the time to look around and assess my options.

My requirements

active community

must on Windows Server (no NGINX for me :<)

container-less deployment is sexy (I never used any Tomcat-specific configuration anyway) but not a must

if Java then Java 1.7 / Tomcat7

static language, if possible

good IDE support, if possible

Changed web development approach

The rise of the MVC JavaScript client frameworks! Finally web development made sense for me. Not this weird mixing server & client together in one mushy package but a clean separation of back- and front-end. Since I’m not developing public internet apps that need SEO or have low latency requirements I didn’t see any reason why I shouldn’t embrace that approach.

So the main thing the new server web framework needs to do is provide a nice REST interface.

Assessment

Ruling out stuff

Ruby got ruled out because the deployment on Windows seems to be not-that-mature - or my Google-fu failed me

the techempower benchmarks ruled out Python (and Ruby for that matter). I might not need the speed, but if I choose new technology it shouldn’t be that slow

Node.js is still a bit too “fresh” and it is JavaScript-based - okay-ish language, but not my favourite

same goes for vert.x, but I’ll definitely keep an eye on it

Long story short

I narrowed it down everything to a few options:

Grails: it works, I know it, it’s reasonably fast and Groovy recently picked up pace according to some language rankings

DropWizard: tailor-made to provide great REST-interfaces, sounds like the perfect fit

Go: great little language, and really really fast

Scala: the new go-to language for enterprise development? Both Scalatra and Play! looked nice and seem to have a lot of traction

Results

DropWizard

I implemented a small proof of concept in DropWizard and I really liked the package the yammer guys put together. However, it’s Java. Coding in Groovy for that long made me forget what a verbose pain Java can be. Still the language with the best IDE support!

Grails

Moving back to Grails I was instantly annoyed by the dynamic nature of the language. IntelliJ IDEA is really good with Groovy, but still I missed the type safety from the other languages (I had played around with Scala and Go in the meantime as well). Great job, increased incentive to find “the new thing” quickly.

Go

I think Go is THE future language for PaaS or cloud stuff in general. It’s resource usage is amazing, the deployment is more or less “copy single binary & run”. I think my simple web app uses something like 6mb memory. The language seems to be the opposite of Scala, very lean, only the bare minimum features built in but excellent concurreny support. The Go code you write usually does exactly what you expect it to do. To top that off the compiler is amazingly fast, again the opposite Scala.

However, the eco system is quite young:

the only Oracle driver I could find hasn’t been updated in ages

same with an LDAP library

no mature web frameworks yet (BUT the standard net/http package is quite amazing on it’s own)

In addition to that, the missing generics and sparse collection library make the code sometimes a bit verbose (nothing like Java, mind you). The whole dependency management thing (from my limited perspective a solved thing in the Java eco-system) is ignored, go get always pulls the latest MASTER. Urgh.

I used GoSublime for development and was quite happy with it.

Scala

Scala drove me nuts at first. The ability to use nearly any symbol as a method name in addition to the functional part of the language made it really difficult to read code in the beginning. The language feels like every available language feature available got crammed in. This combined with functional programming style seemed to promote “elegant, one-line but unreadable” code.

That said, after I finally figured out some of the functional parts of the language it started to not only make sense, but it was also fun to implement stuff. The collection API, the Option type, immutability - things started to fall in place. Also, the language has access to the vast ecosystem of 3rd party Java libraries.

The language support in IntelliJ IDEA is improving but still nowhere near Groovy level. It’s still very usable from my perspective.

Conclusion

I think I finally settled on Scala. Go is a close second and I will try to keep up with what’s happening, I really liked developing in it and when I’ll ever need to use a PaaS like Heroku etc I will definitely try to use Go there.

Yay, no more MAMP, grunt server all the way!

I started using dropwizard as a basis for my RESTful services and needed some basic authentication roles support. This is the first, basic result - simple, but works.

However, I found this interesting post: http://www.odi.ch/weblog/posting.php?posting=658

Another post described mod_proxy_ajp as more buggy than the http submodule.

While being a little too bloated for the task, Grails makes it very easy to create JSON backends for those shiny new HTML5 MVC JavaScript web apps.

I tried putting the HTML5 app in the Grails application itself, but I disliked it for various reasons. I ended up serving the HTML5 app with MAMP, using mod_proxy_ajp to link to my Tomcat, appending the following lines to /Applications/MAMP/conf/apache/httpd.conf:

ProxyPass /TempTracker ajp://localhost:8009/TempTracker

UPDATE: I used ProxyPassReverse here, which is not necessary for mod_proxy_ajp.

For debugging it makes sense to link to Grails run-app directly. To do that, you need to attach a script to the Tomcat events as described here.

My _Events.groovy script looks like this:

Since Java6 we have integrated http authentication: http://docs.oracle.com/javase/6/docs/technotes/guides/net/http-auth.html

So before initiating a connection to SharePoint I did the following:

Authenticator.setDefault(new Authenticator() { @Override public PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(user, password.toCharArray()); } })

From OSX, you get an error message but otherwise things work just fine.

Here is the post method I used:

String post(String url, String action, String content) { def soapUrl = new URL(url) HttpURLConnection connection = soapUrl.openConnection() as HttpURLConnection connection.setRequestMethod("POST") connection.setRequestProperty("Content-Type", "text/xml") connection.setRequestProperty("SOAPAction", action) connection.doOutput = true Writer writer = new OutputStreamWriter(connection.outputStream) writer.write(content) writer.flush() writer.close() connection.connect() return connection.content.text }

When deploying the application to our Windows servers I ran into issues - SharePoint would respond, with with an item count of 0. After a lot of head-scratching and searching in the wrong places I finally found out (aka read the documentation again) that Java's integrated authenticator tries to determine the authentication details from the system first:

On Microsoft Windows platforms, NTLM authentication attempts to acquire the user credentials from the system without prompting the user's authenticator object. If these credentials are not accepted by the server then the user's authenticator will be called.

Finally figured out how to mock / stub the groovy Sql object, my Google skills failed this time (or there are no posts ^_^). Too obvious in hindsight:

def sqlStub = new StubFor(Sql) sqlStub.demand.newInstance { return new Sql() }

The Sql() constructor is private, so the stub can use it. It’s easy from there, for example when checking if the proper SQL gets executed:

when: String executedStatement sqlStub.demand.execute { st -> executedStatement = st } sqlStub.use { Sql sql = Sql.newInstance() // do stuff with sql } then: executedStatement == 'foo'