While It’s Compiling: Skills Matter interviews Graeme Rocher


The Groovy & Grails eXchange 2014 (from left to right): Guillaume LaForge, Graeme Rocher, Russell Winder

After the success of the Groovy & Grails eXchange at Skills Matter, we spoke to the event’s second keynote speaker Graeme Rocher. Graeme is the project lead of Grails at Pivotal as well as CTO at G2One Inc, an open source services organisation providing training, consultancy, support and products around Groovy & Grails. He gave us some insights into what the new Grails framework is capable of, why contributions are so vital to the success and evolution of the Groovy language, and why he left London for Spain’s beautiful Basque Country.

Groovy & Grails eXchange 2015 tickets are on sale now – only £95! (for a very limited time)

You recently delivered a keynote talk at Skills Matter’s Groovy & Grails eXchange 2014 with a preview of the 3.0 rewrite of the Grails framework. Can you give us an overview of what the new version is capable of?

We’re previewing Grails 3, which is what we’ve been working on for the last six months or so now, which is a lot more flexible than Grails 2. You’re able to target multiple environments via the notion of profiles, so a Grails application could be potentially deployed in other targeted environments whether it be traditional Servlet, Netty or Batch. It’s also written to be built on top of Gradle, so the build system is completely new and more robust thanks to Gradle. And it has a completely rewritten code generation layer API which is now formalised, whilst before it was just a bunch of disconnected scripts. It is now much more robust. And it’s of course built on top of Spring Boot, which means that you can run your applications as a JAR file or you can write applications that are just little Groovy scripts, so you get much more flexibility in terms of how you create Grails applications.

With the core Groovy team being so small, how important are contributions to the success and evolution of the Groovy language, and do you need more people to get involved?

The contribution is essential to the survival of both projects and we’re constantly on the look out for new contributors. Groovy has done exceptionally well in this area, especially in the core with around 50% of contributions from the community, and it continues to operate very much as a community-run effort and that’s fantastic. Grails is a little bit more divided. We get massive contribution from the plugin community via plugins and that’s really buzzing and continuing to evolve, and that area of plugins in Grails is significant by itself. We get fewer contributions to the core, but they are still significant and we rely heavily on that. And of course we’re always on the look out for people to contribute.

You co-founded G2One – the Groovy/Grails Company – with Guillaume LaForge. How did it start, and did you ever expect it to become as successful as it did and ultimately attract the attention of SpringSource?

Well, you always have those hopes and dreams when you’re creating a startup so we went into it hoping to be very successful and in the end we were! But in terms of how it started, it was really around 2007 when I was presenting Grails at JavaOne and I got to meet Guillaume (LaForge) and the community and really get to know people, and we started spinning some ideas around and got in touch with some fantastic investors and the idea came to fruition to start a small startup. What we created was compelling enough for SpringSource to acquire and we still believe it is.

You co-authored ‘The Definitive Guide to Grails’ with Jeff Scott Brown, which explains the roles that Groovy and Grails are playing in the changing Web (amongst other things!). Can you summarise what roles these are and why they’re important?

The web is clearly evolving in terms of having much fatter clients and smaller services at the back end and these kind of Micro Service applications are definitely very well expressed in a concise language like Groovy. You can see that when you look at Spring Boot, how well Groovy fits into creating these types of small, focused applications that fit into Micro Service architectures where you have an essentially REST-based backend with Mobile and HTML frontends. Grails 3.0 with its profile support allows flexibility in creating small micro applications are what we like to call “Modular Monoliths”.

You’re based in Bergara in Spain’s Basque Country. What’s it like working there as a tech professional, and do you ever think about locating to a more tech-focused city such as London or Berlin?

Well, I lived near London for 12 years and London in itself was and is a fantastic hub for technology and innovation and a great place to be for creating a startup or for being in the tech industry in general. In terms of where I live at the moment, the Basque Country is a beautiful area, and it certainly has a tech community especially around the cities like Bilbao and Donostia. But it’s no where near the size of London. In terms of why I’m here, its mainly family reasons. My wife is from the area so its very much a family decision being here. But I’d certainly recommend London if anyone is really into the tech industry as a place to work and be

While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.


While It’s Compiling: Skills Matter interviews Martin Odersky


On the day the Scala eXchange welcomes more than 500 speakers and delegates to the Business Design Centre, Skills Matter catches up with keynote speaker Martin Odersky. The German computer scientist is the creator of Scala and the founder of Typesafe, a company to support and promote Scala. Currently a professor of programming methods at EPFL – the Swiss Federal Institute of Technology – in Lausanne, Switzerland, Martin Odersky told us about keeping Scala lean, which industries love Scala the most, and whether Scala can remain the essence of what Typesafe is and does.


Scala was first born in 2003. Has there been a lot of pressure to keep adding features? And have you always been convinced about the need to keep it lean?

There’s always pressure to add features. Users always want new features. So we tried for a long time to keep the feature set down to a reasonable size and…hopefully we’ll be able to make it even smaller.

You have described Scala as a fusion. Can you explain this in a little more detail?

The idea underlying Scala is that object-oriented programming and functional programming are not opposites but two sides of the same coin, and that one gains a lot by merging them. That’s not an amalgamation, taking all these features from functional programming and adding all these features from object-oriented programming – that way you would get a fairly large language. It’s really a fusion…So for example, the functions in Scala themselves are actually objects. Functions and objects are, in Scala, very much the same thing. And the same holds (true) for a lot of other things. Unlike many other languages that have classes and functions as types separately and then algebraic data types separately, we have one concept which is essentially classes forming a hierarchy. They serve as a framework for doing pattern matching as well, which in other languages requires an algebraic data type. So in that sense, Scala tries to have only a few concepts but very generally composable ones.

Are there particular organisations or industry sectors in which Scala has proven particularly successful?

We’ve got quite a few. I think its used everywhere there’s a JVM and nowadays it’s starting to be used on the client with Javascript as well. But there are a few verticals where Scala particularly common: It’s very much established by now in Big Data and machine learning. There, Scala is probably the number two language behind Python. Another big vertical is e-commerce – think of Walmart Canada, and many others. Another one is the finance industry – the most prevalent in London – so in the banks and the hedge funds Scala is also very common.

What have the main criticisms of Scala been and how have they been remedied?

Some of the difficulties comes from the user community, because now you have Java programmers and Haskell programmers that form part of the same community and that has proven to be a much tougher challenge than the technology. Sometimes these communities don’t get along very well, sometimes its very hard to read somebody else’s Scala code because there are different ways to write the same thing. We try to help by establishing simplicity as a criterion for a middle ground.

What was your vision when you set up Typesafe and have you been surprised by its success?

Scala already was a success and we had just run the first Scala Days..there was a lot of excitement and also a lot of people from industry – a lot of companies like LinkedIn, people from Swiss banks, Foursquare etc were talking about it. And that’s when it dawned on us that it really had bypassed the capabilities of just a research lab at my university. It was becoming too much work to continue to support it and also, we could see the opportunity. So we joined with the Akka team in 2011 to form Typesafe, and Typesafe now is I think still very much true to these roots…but it has also developed the reactive space starting with Akka, with middleware that is more application oriented and less language oriented.

A question about the direction Typesafe is going and its ongoing support of Scala, given its development of other products such as Akka and Play for Java developers. Will Scala always remain at the core of Typesafe?

Yes, I do think so. Scala is very much the essence of what Typesafe is. Internally everybody does Scala and everybody loves the Scala APIs. That’s not to say we don’t also do Java and Java 8 for the bigger market – that’s very sensible and we have to do that. But at its roots, it’s a Scala company and it will stay one.

You were a student of Niklaus Wirth in Zurich. How did that experience influence you?

When I was young, I was sort of a compiler hacker…and Modula 2 was a new language at the time and for me a very exciting language, so I wrote a Modula 2 compiler. I was actually on the cusp of joining Borland, at the time the big programming language and software company, but I decided to wait and finish my masters thesis. And then I realised that I had fun doing research so that’s when I decided not to go to Borland but to go to Niklaus Wirth – the inventor of Modula 2. At the end of my studies in Zurich (with Niklaus Wirth), I decided that functional programming was really cool and that I wanted to do more, so that’s why after Zurich I ended up doing much more functional programming.

You have had a long, varied and impressive career. What has your motivation and objective been throughout?

In Zurich with Niklaus Wirth (I was working with) very practical languages, which were also quite efficient, which functional programming wasn’t at the time. Towards the end of my PhD I discovered that functional programming could be very elegant and theoretically well founded, and that appealed to my sense of elegance and rigour. After that, I always wanted to bring the two together – to do something that’s really practical but that has the elegance and rigour of functional programming. So that led me to the work to combine functional and object oriented programming, first with Pizza, then with GJ, afterwards with Funnel and Scala.   The central question was always whether we can take the proven mainstream – object oriented programming – and the more academic notion of functional programming and combine the two harmoniously, keeping the good parts of both? That has driven me for most of my professional career.

While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.


While It’s Compiling: Skills Matter interviews Rebecca Grenier

For an insight into December’s Scala eXchange brought to you by Skills Matter, we caught up with Rebecca Grenier, who’ll be speaking about Slick – a relational database mapping tool that brings Scala’s features to database interactions. Until recently a Software Developer for EatingWell Magazine in Vermont where she used Slick to transition from a PHP website to Scala, Rebecca is now working her magic on the University of Vermont’s websites. She told us about the hunt for experienced Scala programmers in Vermont, eating well at EatingWell, and her efforts to make the image of women programmers a more normal one.

Becky And The Hackettes

‘The Hackettes’: left to right – Megan Brown, Rebecca Grenier, Buffy Miller, and Sarah Lindberg.


Only 2 days left – Book your ticket now!

What are the coolest things about (the relational database mapping tool) Slick?

Slick is a great showcase for Scala itself, using some of Scala’s best features to improve how programs can work with relational databases. These features include static type checking, the functional collection methods, and for expressions.

What have been the main challenges faced during EatingWell’s transition from a PHP website to Scala?

Here in Vermont the biggest challenge has been lack of any experienced Scala programmers to hire. I hear they are hard to find everywhere but here they do not exist (in our experience so far).  Every single new hire needs to not only learn our specific systems but also the Scala programming language and often the whole functional programming paradigm as well.  Recently we have found some expert Scala consulting companies located in the larger cities who are helping a lot.

What did you love most about working as a software developer for EatingWell Magazine?

I loved working with the EatingWell editors and food writers as I am a wanna-be healthy eater and home chef myself and their recipes and articles are hands-down the best anywhere.  It was challenging working for a company who was so focused on print-media rather than digital, being in a support role and not a member of the core business.

You’ve taken a one-year term position at the University of Vermont to work on the Department websites. Do you see a dearth of females students focusing on tech-related subjects?

Well, my work at the Communications Department hasn’t led to a lot of involvement with the student body yet, but all the statistics I hear about women entering into STEM fields are not great.  I believe the key is getting younger girls involved with programming and computers.

Tell me about Becky and The Hackettes?

Becky and the Hackettes was a dream I had ever since I first heard of the Vermont Hackathon.  I wanted to see an all-women’s team compete.  The first year I participated (which was the second year of the Vermont Hackathon), I did not know any other women programmers who could participate, so I joined a men’s team just to see what it was all about.  It was fun but I was dismayed to see the low percentage of women, which only dropped further as the night got later and later.  The next year I had met some other women programmers who were willing to join me and four of us competed as “Becky and the Hackettes”.  Despite the fact that almost none of us used the same programming languages (if you want an all-women’s team you have to take what you can get), we worked together well, created a great application and took home second place.

Any other initiatives you’re involved in to encourage women to get involved in tech and coding?

I have also been very involved with GirlDevelopIt, which is an initiative that offers low-cost introductory tech classes to women to try and get more of them into the field.  I have been a Teacher Assistant to many classes, taught a few, and created a totally new class on “How to get your first job in tech”, which actually did lead to at least one person getting their first job in the tech world. I also frequently am asked to serve on panels that want to ask questions to programmers, which I try to do whenever possible to hopefully make the image of women programmers a more normal one.

You’ve been a web programmer in Vermont for more than decade – why there, rather than a tech centre like San Francisco or New York?

I stay in Vermont because this is where my family is and because I love it here. I love the seasons, I love our brave and independent politics, our Senator (the only Independent in congress) Bernie Sanders.  I love our rural rednecks and “city” hipsters, and that they are only a 30-minute drive from each other. One of these winters I’m going to take up skiing, too.

While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.


While It’s Compiling: Skills Matter interviews Brendan McAdams

brendan mcadams LARGEFor the next in our series of Scala eXchange speaker interviews, Skills Matter caught up with  polyglot programmer and international speaker Brendan McAdams. Previously at Typesafe, Brendan now works at Netflix and will be using his talk at Scala to speak about the architecture Netflix is using for their next generation device metadata APIs. He told us about the beauty of simplicity in code, the importance when building software of keeping users at the forefront of your mind, and why walking and drinking local beer is the very best way to discover new cities.


Only 4 days left – Book your ticket now!

What makes REST API’s beautiful?

I’ve always been a big fan of elegance and simplicity in code. Having done a lot of messaging systems in the past, with everything from Fixed Field over TCP/IP to SOAP, XML/JSON-RPC, and more, I’ve burnt myself out on the complexity and insanity of these formats. Why do we, as developers, insist on building such inscrutable messes and then selling them as an improvement? With REST, you can choose whatever data interchange format you want, whether JSON, XML, or even the abomination that is IBM’s JSONx, while maintaining a consistently simple transport protocol. You can declare a set of common endpoints that any language can consume without big nasty client libraries–frontend & backend devs alike can get useful things done. Ultimately, REST’s transport protocol is just HTTP, which most modern developers understand intuitively. It ends up being mostly self-describing, and that is a beautiful thing. Simplicity in code has an elegance and beauty all of its own, and I absolutely love that.

What is it about the toolsets of Scala (Scalatra, Swagger, and Akka) that allow you to do this particularly well? What makes them different?

Swagger solves the problem of “how do I effectively document my UI in a way that stays up to date with my code and makes sense to API users?”. It is just a fantastic tool for doing this, as you describe your API with it as you write your server API. Ultimately, Swagger really helps with a belief I hold that Code is (or should be) communication. Scalatra makes things simple: minimal configuration and convention. With Scalatra, your code is generally your configuration and it integrates cleanly with Swagger to extend that to your API Docs. As for Akka, I could write an entire book on how wonderful it is as a product. Specifically with Scalatra though, I’ve found it incredibly powerful for handling background tasks that need to happen behind the scenes while the rest of a request completes. In particular, I’ve used it to defer long running invocations to external systems without blocking up the rest of a HTTP request thread.

What other architectural considerations do you need to make when building REST APIs?

Consistency is important: there aren’t 100% perfect, immutable standards for REST APIs but rather a general set of loose guidelines. As such, it ends up being really important to decide on what your standards are and communicate them effectively to your team, and get everyone to agree. Good, well disseminated internal standards prevent the inevitable hammering a square peg into a round hole syndrome. It is all well and good to decide you are going to use a particular set of HTTP response codes, but do the people using your API understand what it means when you do? Do you consistently communicate errors in a meaningful way? Finally, how do you document all of this? I’ve found that self documenting code – especially with a tool like Swagger – makes everyone involved happy because your code quickly reflects reality from a documentation standpoint.

You moved to Netflix earlier this year. What were you able to bring to your new job as a result of having worked at Typesafe previously?

Between my consulting and training work at Typesafe, and MongoDB before that, I gained a lot of perspective as a software engineer. I had previously spent most of my career in a cubicle with my head down, coding. I hadn’t spoken at conferences or even attended many. When I started speaking at the NY Scala User’s Group, my life and career took a pretty big left turn into that world. Speaking publicly, and especially consulting, changed my point of view heavily in my career. I now think much more strongly in terms of who my users are – and the idea that your customers/users might be people inside of your own company. Customer interaction has become much more important to my viewpoint, as a result. At the end of the day, if you aren’t building software with your users in mind you are wasting everyone’s time and a lot of their money. So I’ve found that while working at Netflix I spend a lot more time making sure that my code communicates more effectively with its users. Clear error messages, consistent behavior, and sanity are much bigger parts of what I do in my code than they were prior to my Typesafe and MongoDB days.

Since working at Netflix, have you made any exciting discoveries outside of the SCALA ecosystem?

There are a wealth of tools that Netflix has both internally and as part of the Netflix Open Source projects which have really opened my eyes to better ways of doing things. RxJava, in particular, the focus on immutable deployments makes it much more likely that I can reproduce a server issue because nobody has changed things out from under me.

We do a lot at Netflix with stability and fault tolerance, to the point of having a “Simian Army” whose job it is to create trouble and chaos within deployed systems to ensure what we build is capable of resilience in the face of adversity. There are also very interesting things coming out from the Open Source world in general around these kinds of flexible infrastructure concepts such as Docker, which intrigue me. I simply wish I had more time to play with them! Within the Scala ecosystem, I’ve recently started playing with Scalaz which is a haskell-inspired functional programming library to extend and complete Scala’s stock toolkit. It has turned out to be a fascinating and powerful tool for improving my code.

You’re a very prolific public speaker! What do you love most about speaking at conferences, whether at home or internationally?

I love getting a chance to show people what I’m thinking and what I’m excited about at a given time – and forcing them to sit down for an hour or two and listen to me ramble about it! It is a fantastic opportunity to show off cool things that people might not have known about before, and it is a very rewarding feeling. As for the fringe benefits of being a speaker, I think I’ve always found the “hallway track” – the part of the conference between talks where you get to talk to people – the best part. There’s always amazing perspectives that I wouldn’t find anywhere else, and I learn so much about what is going on in the industry. I’ve made a lot of lasting friendships over drinks and conversation at these events that I wouldn’t trade for anything. Finally, I’ve always loved walking around new cities and trying the local beers. There’s no better way to learn about a new place than a comfortable pair of shoes and a healthy liver. Since I started at MongoDB in 2010 I’ve worn out the soles of at least two pairs of Doc Martens walking around half of Europe!

While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.