As I recently joined Google’s developer advocacy team for Google Cloud Platform, I thought I could have a little bit of fun with combining my passion for Apache Groovy with some cool cloudy stuff from Google! Incidentally, Paolo Di Tommaso tweeted about his own experiments with using Groovy with Apache Spark, and shared his code on Github:

I thought that would be a nice fun first little project to try to use Groovy to run a Spark job on Google Cloud Dataproc! Dataproc manages Hadoop & Spark for you: it’s a service that provides managed Apache Hadoop, Apache Spark, Apache Pig and Apache Hive. You can easily process big datasets at low cost, control those costs by quickly creating managed clusters of any size and turning them off where you’re done. In addition, you can obviously use all the other Google Cloud Platform services and products from Dataproc (ie. store the big datasets in Google Cloud Storage, on HDFS, through BigQuery, etc.)

The cat is out the bag: I’m joining Google on June 6th, as a Developer Advocate for the Google Cloud Platform team!

My Groovy friends will likely remember when I launched Gaelyk, a lightweight toolkit for developing Groovy apps on Google App Engine? Since then, I’ve always been a big fan of the Google Cloud Platform (although it wasn’t called that way then) and followed the latest developments of the whole platform. And wohhh, so many new services and products have seen the light of day since my early experiments with App Engine! So there will be a lot to learn, a lot to do, and thus, a lot to advocate! 

At our disposal, we have so many ways to interact with an API: from a mobile on iOS or Android, from a web application, or from other services or microservices. And all of them have different needs: one wants only a shallow overview of the data, while the other desires a detailed view of a certain resource and all its sub-resources. It’s becoming difficult to design an API that caters to the needs of those varied consumers.

I had the pleasure of writing an article for Nordic APIs on Web API definition languages.

If you’re into the world of Web APIs, you’ve probably heard of formats like Swagger, RAML or API Blueprint. They allow developers to define the contract of the API, with its endpoints, its resources, its representations, allowed methods, the kind of payloads it understands, the status codes returned, and more.

With the contract of your Web API, you can generate code for your backend implementation or client kits, documentation for publishing the details of your API for your API consumers. This contract becomes a key element of your API strategy: a contract between the frontend team and backend team to be sure to work on the same ground, between your tech team implementing the public API of your company and all the API consumers that will interact with it.

The most common API definition languages we spot in the wild are Swagger / OpenAPI Spec, RAML and API Blueprint. All three let you define your endpoints, your resources, your query or path parameters, your headers, status codes, security schemes, and more.

In a nutshell, these definition languages define the structure of your API, and allow you to describe many elements. As standards in the API industry evolve, however, their purpose and design are under continuous scrutiny. Specifically, the extensibility of API specifications with additional elements and feature sets comes into question.

An interesting trend is emerging in the world of Web APIs, with various engineers and companies advocating for dedicated APIs for each consumer with particular needs. Imagine a world where your system needs to expose not only one API for iOS, one API for Android, one for the website, and one for the AngularJS app front end, but also APIs for various set-top boxes and exotic mobile platforms or for third-party companies that call your API. Beyond any ideal design of your API, reality strikes back with the concrete and differing concerns of varied API consumers. You might need to optimize your API accordingly.

Recently, I saw an interesting tweet, mentioning a JavaScript trick using default parameters to make a parameter mandatory.

In a language like Apache Groovy, when statically compiled, you’d get a compilation error if you forgot a parameter, because the signature couldn’t be found by the compiler. In dynamic mode, you’d get a runtime error though, with a MissingMethodException (and the error message should give you a hint as to which method you should actually call instead).

It’s literally the eve of SpringOne2GX, in Washington DC! I’m flying tomorrow, for 9+ hours above the Atlantic, to gather with the cool kids of the Groovy ecosystem. I’m impatient to see some of my fellow readers and Groovy users around there.

And let me wish the Griffon framework and its team a Groovy birthday!

Releases

• Ratpack 1.0-rc-2, a second release candidate
• Gradle 2.7-rc-2 released
• Grails 3.0.5 released with the new Web API profile
• Grails 3.0.6 released
• Spring Boot 1.3.0.M5 released

Articles

• Grails 3 Web profile vs the new Web API profile
• How to deploy a Grails 3 app to AWS Beanstalk and CloudFront CDN by Benoit Hédiard
• MrHaki’s Groovy Goodness
  • Removing elements from a collection
  • Inspect method returns nicely formatted object values
  • Operator overloading in reverse
• MrHaki’s Spocklight
  • Only run specs based on conditions
  • Undo MetaClass changes
• Philip Heath writes about Spock, the logical choice for testing
• Paul Gross’ team has migrated from Gradle to Bazel

Screencasts

• Screencast of NetBeans’ Gradle integration

Interviews

• An interview by JaxEnter of Dierk König in German, where he says that Groovy is a pioneer language where innovative changes help shape the future of Java and other languages

Mailing-list posts

• Griffon celebrates the 7th anniversary of the project!

Tweets

• The Mars rover has a state called “Solar Groovy” noticed Dierk König
• Marco Vermeulen is excited about the upcoming new website for SDKmanager (aka GVM), based off the Groovy website code and look
• Grails 3.0.5 available on GVM
• Grails 3.0.6 available on GVM
• Spring Boot 1.3.0.M5 available in GVM
• Gradle 2.7-rc-2 available through GVM
• Bertrand Goetzman working on a Groovy/Grails training is using a Groovy DSL with Grain to generate dynamic HTML documentation from Markdown documents
• The Gradle plugin for the Grain static site generator is available on the Gradle plugin portal
• Benoit Hédiard created a French-speaking channel in the Grails Slack community
• Roman Shaposhnik is reminded he loves Groovy when looking at how it can make the Apache BigTop project DSL easy to grok
• Matt Sheehan brings our attention to the new auto-generated Groovy DSL documentation for the Jenkins Job DSL

News

• Jacob Aae Mikkelsen’s Grails Diary week 36

Jobs

• SmartThings is hiring a cloud engineer with Ratpack experience
• Gilles Laborderie is recruiting for a Grails job in Paris

Books

• MrHaki’s Spocklight notebook updated

Events

• Only a few days left before the end of the Groovy/Grails eXchange call for paper
• Guillaume Laforge is a JavaOne featured speaker
• Guillaume Laforge relaunched the Paris Groovy Grails User Group introducing talks on the Grails 3 novelties and Groovy in a VoIP context

Is it really already September? Time flies so fast in the Groovy ecosystem, and although the northern hemisphere was taking some Summer vacation breaks (at least that’s what I did!) there was quite a bit of interesting content published!

Regarding events, after successful and busy Greach, GR8Conf US/EU conferences, we’re getting ready for September’s SpringOne2GX in Washington! There’s still time to register and join the Groovy ecosystem affictionados! And I’m really eager to seeing you there.

The not-so-weekly Groovy column is back for a summer edition on the shores of the Atlantic ocean (at least, that’s where I am now!) and there was a lot to catch up with in terms of news!

Ratpack is almost at 1.0, only a couple of weeks to go for the mythical release, whereas Gradle arrived in version 2.6, and some updates to the two main Grails lines were out too.