The interviewee we are proud to present today is Guillaume Laforge, Project Lead of the Groovy programming language and Product Lead at Restlet. In this interview, he talks about what he dreamt about as a junior developer, how he got involved in Groovy, and why he is not fond of hackathons.
Guillaume, it has been 15 years since you started your career as a Junior Software Engineer in 2000. Do you remember yourself as a beginner? How different was your professional comprehension? What did you dream of at that time? Did you manage to accomplish as much as you expected to?
Before diving more into APIs, I essentially focused on development, design, architecture, Java-based systems, and the Groovy programming language. But when I started working, my eyes were still full of stars admiring famous design patterns, and like many juniors, I was perhaps trying to put all possible design patterns a bit everywhere! Fortunately, with great colleagues, with lots of curiosity for the Java ecosystem, and with a strong implication in Open Source, I managed to improve my coding and design abilities.
Compared to when I was a junior developer, I’m probably a bit more down to earth, more pragmatic, if not more cynical about the politics in companies that prevent them to be more efficient! But I guess with maturity and experience, that’s probably the same for everybody!
Now, what I was dreaming of then, I think I wanted to become a good developer, producing quality code, able to move towards more high-level positions involving design and architecture of IT systems. That’s indeed what happened in the first half of my career. The second part has so far been more into the direction of product development, with the Groovy programming language, but also the various products and projects of Restlet. And I really love thinking, dreaming, brainstorming about hypothetical project or product ideas too! That’s probably my creative side of the brain that always thinks about potential exciting projects!
You have been involved in the Groovy programming language project since 2003. Could you tell us a bit about it?
Back in the day when I started working on the Groovy programming language, I was working for a small software vendor that was building a kind of application generation engine that would transform a description of your app (a so-called meta-model) into a running application. Customizing widgets, components and behavior in that engine would always trigger complex redeployments impacting all users of the service, even if that little change was just for one of them. So I was in search for a tool or language that would allow me to dynamically create and deploy new components, live. And Groovy was the language I was looking for to serve that purpose.
I quickly got involved in that project, through my Open Source contributions, and later on took the lead of the project. In 2007, I even co-founded a startup around the project, that got acquired by SpringSource (now part of Pivotal).
Now Groovy is in the Apache foundation incubator, to further strengthen the maturity of the project and also to encourage even more contributors to help us move the project forward.
Like in my first job as a junior software developer, I believe that Groovy can be an awesome glue to enrich and combine APIs together. That’s why companies like Alcatel-Lucent with its PaaS or PayPal use Groovy to orchestrate their APIs and services!
The Summer of APIs is in its zenith. How did the idea to organize such a hackathon appear? Have you participated in any hackathon yourself?
At Restlet, we were looking for a way to promote our platform to encourage users to share and develop ideas around the theme of Open Data. Although our free tier is very generous, we’ve lifted the limitations so competitors with high traffic APIs wouldn’t have to pay for the extra level.
Open Data is becoming more common-place, but there’s still a lot to do to help it become even more widespread, with proper APIs that people can reuse rather than just offering CSV or Excel files that people then have to clean, transform and serve themselves. APISpark, the API platform I’m working on at Restlet, can help simplifying the transformation or raw data into a useful API!
As to hackathons, I’ve not really participated in any code-48-hours-in-a-row hackathon-during-the-weekends, for I’m not really fond of them, as it’s not super handy for good work/life balance and because I believe creativity needs to take its time to really mature and execute on great ideas. But I’ve participated in “hackergartens”, where you spend a few hours during an evening to make useful contributions to Open Source projects, which I find more interesting and rewarding. As for the Summer of APIs, we’ve called it a hackathon, but it’s actually a 3-month long event, where people can really take their time to work on their cool API ideas, without the rush of those crazy weekend hackathons!
You are a regular conference speaker. What was the first conference you attended? Where there any seminars that impressed you greatly?
The first conference I attended, if I recall correctly, was JavaOne, in 2006. For my very first talk, I was on stage in front of roughly 500-600 persons, to speak about the Groovy programming language. Furthermore, that was also my fist talk in English, which is not even my native language. I was wondering if I’d be really stressed and would screw it all, but it actually went fine. A bit of apprehension, but after a few minutes, I was in the flow!
And since then, I don’t know how many talks I’ve given, but it’s probably over a hundred!
I don’t recall a particular edition of a seminar that impressed me more than others, but I’ve been really impressed by the huge size of the old JavaOne conferences when they were still held in the Moscone center. I’ve also enjoyed conferences in scenic places like New Orleans or events where I met some of my idols! More than the particular event or location, what always mattered the most to me was meeting great and interesting folks!
How would you define a perfect API? Is it possible to create one?
I’m not sure there can really be a perfect API, in the sense that, from a consumer perspective, different consumers might have different expectations and needs with this API, and secondly, from a purely technical angle, there are sometimes different ways to implements certain aspects of your API. For this second point, for example, I see APIs implementing pagination differently, or versioning in the URL vs content negotiation, etc, and someone with a strong opinion on these aspects might not think your API is perfect.
What do APIs mean for business and e-Commerce in particular? Do you think their role will change in the upcoming years? What does the future hold for APIs?
I’m not a specialist in e-Commerce, but it seems to me that APIs have already helped to simplify the job of small to medium businesses to sell their products on bigger marketplaces like Amazon. This approach is interesting both for those big players that can expand their offering to more diversity, as well as for the small ones who have an open window on the whole world. Somehow, e-Commerce APIs really lower the barrier to entry on the market.
More generally on APIs, my impression is that we’re going to continue seeing a trend towards what I often call “lego APIs”, where anybody will be able to build upon a set of useful APIs, like combining lego bricks. But the more you rely on various APIs, the more you’re at risk of having your system or platform be at the mercy of a particular APIs, so I believe that more API middleware infrastructure will be useful to offer a more versatile and resilient platform, combining redundant APIs, offering circuit breakers, transforming APIs into more familiar or useful ones, etc. Furthermore, I also see such API platforms being enriched with a certain level of business logic, to orchestrate and customize those APIs, beyond what the original API authors really intended.
It was a pleasure for us to interview Guillaume. We want to thank him for his answers and wish him all the best in the future. 🙂
