On curiosity and sharing with the world

At the end of December, I was contacted by someone I didn’t know, who asked me some interesting questions, and that led me to quite a bit of introspection.

As a Java Champion and with your career history. I wanted to ask you what you consider are the most important skills for a Java programmer to have in their toolbox, especially a Senior Java programmer? Or maybe even a better question is what skills you developed that helped you become the Java Developer/Groovy Language Developer that you are today.

In a nutshell, as I answered this person, for me it all boiled down to lots of curiosity, and the desire to share my findings with the world. It’s not really about knowing specific methodologies, technologies or languages, or which soft or hard skills to master. It’s about the core attitudes from which all the rest will derive from. But first, a bit of background about me.

A bit of history

Alright, so if I was contacted (and actually a few others as well) with those questions, it’s because I’m considered to be a visible and public person. Because I’m known for my work in the Java community and more precisely in the Apache Groovy ecosystem. I’ve been in the field for quite a number of years, along with my contributions in Open Source, and that makes me a senior developer. But how did I get there?

You’ve learned a lot during your studies, but often, not much of what you learned is immediately applicable in your daily duties and tasks. So there’s even more to learn to become a productive developer. I started working as a junior Java developer in 2001. I was lucky to have had a great mentor that helped me design and write better code. I also spent quite some time reading Java and development related news websites or blogs. I wanted to know what were the latest trends (new language features, frameworks), the best tools for the job, how developers were developing on their projects. So clearly, I was pretty curious to look beyond just what I was doing at work, but to see if I could become a better programmer by learning from others. There’s so much great content on the web, so much information that is shared, from best practices to bug fixes explanations, that you can learn a lot. That’s also more or less when I started blogging. I saw so many useful blog posts that helped me, that I thought it would be a good thing to share back things I learned that could be helpful to others as well.

In 2003, at work, I needed a way to extend an app I was working on, and clearly, some kind of scripting solution was what would allow the end-users of our app to further customize and tailor the application to their needs. So I spent some time reviewing existing Java scripting solutions, but none were really ideal. Fortunately, that’s when Groovy was born. It was embryonic, and not really ready for prime time though. But it was what I needed.

I started playing with Groovy, but quickly I encountered tons of problems and bugs. Since the code was Open Source, I started looking at its codebase, outside of work. I quickly understood where some of the bugs were coming from, and found ways to fix them. Since the community was pretty open, I participated in the mailing-lists to tell about those bugs, to help other users. It was nice to feel being part of a nice, friendly and helpful community.

I used the bug tracker to file bugs and feature requests, and when I could I even submitted some patches to fix these. My patches were accepted, and in a handful of months, I was asked to become an official committer on the project (which I gladly accepted). By working with the other committers, I learned a lot about Java, the JVM, or how open source projects worked. That was super interesting. Since the code was public, I really wanted all my contributions to be top-notch, perfectly well tested and commented. Somehow I had the impression that the scrutiny of my peers mandated that I had to produce even better code than at work! So I perfected my craft. A lot.

Since I had already started sharing my findings on my blog (and later on on social networks), I became part of the so-called “blogosphere”, and started interacting with other bloggers. I wrote about Java and Groovy, of course, but the discussions with other open source developers, allowed me to also meet them in the real world. We even started a meetup of open source developers that shared what they were working on. That’s how I did my first public presentation, to show Groovy to my peers, in 2004 or so, at our local gatherings. I came to know people working for big companies like Sun or Oracle, as well as smaller actors, from freelancers, to entrepreneurs. A handful of those companies started using Groovy, and that’s how one day, someone asked if I’d be ready to talk with them at a big conference. That was for JavaOne! My first big conference and presentation was in the US in front of 600 persons. Woh… That’s how I started sharing more widely with the world, and also started travelling to spread the word.

I spent a lot of time on Groovy and its ecosystem, and I later got the chance to both work on those technologies for a living (after doing quite a bit of consulting), as well as even creating my own company to focus on the project. At the same time, I was still continuing presenting about Groovy, and still improving the language thanks to the feedback I was getting from the many developers I was meeting all around the world. I was doing developer advocacy at the same time as product management and development. Three hats in one. And by doing developer advocacy, that’s also what landed me my current job of developer advocate at Google.

The ever changing nature of our field

From the narrated history above, there’s a theme that emerges: curiosity. But what lead me to being curious? Tons of people are doing 9-to-5 jobs, and that’s totally fine. However, as we spend so much time in our lives at work, for me, it had to be interesting and motivating. To be interesting, work has to be somehow entertaining — beside spending quality time with great coworkers. If it’s not interesting, you get bored very easily, and you don’t want to wake up every morning to go to the office. So how not to be bored? By making your job more interesting. How to make it more interesting? Well, if you’re passionate about what you’re doing, it’s much easier to go through the day and do fun and interesting things, event for a project that could appear as not being very fancy.

Programming was first a hobby, for me, as a child and teenager. It never really occurred to me it could become my job. Initially, I just wanted to be… an “engineer”. Perhaps in aerospace, or something like this. Who hasn’t dreamt of becoming an astronaut? It’s only late in my studies that I thought I could actually become a developer. So my hobby, my passion, became my job. But there’s a big difference between working on stuff you want, versus being asked to work on stuff for the company which hired you. In order to not be bored, be sure to push for improving the project in interesting ways both for you and the end-users. If possible, perhaps try to introduce and learn new technologies that can make the product better, and at the same time make you learn something new. Be passionate about improving both your projects and your skills.

Notice also that in our field, we actually don’t really have a choice but to learn. When I was a student, my current job didn’t even exist. When I started working, the languages or tools I’m using today weren’t available then yet. So in IT, in programming, etc, there’s always a new language, a new tool, a new practice, new patterns, etc, that come to light. It’s a field where we have to be in a constant learning state, in order to stay relevant. If you’re not learning, your skills will rot, you’ll be less employable, you’ll diminish your chances of having a fantastic job. So you have to be curious and learn all the time. To not be bored, but also to get better at your craft.

With all those new tools, languages, frameworks, technologies, you have to keep up with what’s going on. You have to be ready to learn something new.

Sharing is caring

We talked a lot about being curious, about learning all along, but I also mentioned about sharing. As the saying goes, sharing is caring, but it’s also about creating opportunities for you.

Sharing what I learned or worked on was helpful for others too (who encountered similar problems, for example), but it’s also how I came to meet wonderful people along the way. Even mentors and role models. If I hadn’t blogged or tweeted, I wouldn’t have been able to start making presentations at meetups and conferences. And many of the friends I have today are friends I met along the way, at meetups, conferences, working on open source projects together, and so on.

Without sharing my code, I wouldn’t have had the opportunity to meet my future employers and colleagues, as well as the co-founders of my own startup. Sharing is great to be visible, of course, but it’s a wonderful way to meet new people from whom you’ll learn a lot.

Open source is sharing too. Working on open source projects, nurturing communities and ecosystems around those, further allowed me to meet great people around the world. And it’s what lead me to get the jobs at companies I was interested in. It created great professional opportunities.


Let’s try to wrap up a bit. It’s really not about learning a particular tool or technology. It’s all about being curious and passionate about your craft, and to share what you’ve learned with the world.

Be curious!

It’ll make your daily job more interesting. You will learn lots of great new technologies. You’ll become a better developer by learning from your peers. You’ll improve your craft and expertise. It’ll increase your employability. You’ll even likely become an expert in your field!

Share with the world!

Write, blog, tweet, present about the things you’ve learned at meetups or conferences. You’ll learn a lot from others along the way. Write and share code, and/or contribute to open source projects. You’ll meet awesome peers and mentors. And will create all sorts of interesting job opportunities.

Be curious and share with the world!

Tip: Making a Google Cloud Storage bucket or file public

Google Cloud Storage is the ideal product to store your object files (binary files, pictures, audio/video assets, and more).

Until recently, there was an option in the Google cloud console with a checkbox to quickly make a file or bucket public. However, and I would add “unfortunately”, users tended to inadvertently clicking the checkbox, thus making potentail confidential assets public. So this risky, but easy, option, has been removed to avoid any unwanted data leak.

However, of course, it’s still possible to make buckets or files stored in Cloud Storage public. But you can’t do it without paying attention! As I never quite remember how to do that (in spite of the linked documentation easily found with a quick Google search), I decided to highlight with a few screenshots how to achieve that!

I assume you already have or created a GCP project, and you also have a bucket full of assets that you want to make public, because you need to share them on the Web, for your mobile application, etc.

To illustrate this tip, let’s have a look at the GCP cloud console:

Making a file public

First, we’ll have a look at making a single file public.

You’ll have to click the vertical triple dot icon on the right of the screen, and click on “Edit permissions”:

Once you’ve clicked on this option, you’ll be given the choice to add new permissions to members or groups of members:

In our case, we want to allow all the users to have read access on that particular file. So I’m giving the “Group” of “allUsers” the “Reader” access level. Then, once saved, in the file browser, you should see the following icon warning you the file is now public:

Making a bucket public

Instead of doing this for each individual file, you can also do the same at the bucket level, to give read access to the bucket and all its files in one go.

From the object browser, click on the “Permissions” tab. You will have to add the “allUsers” members the Storage Object Viewer role:

Click on the “Add members button”, type “allUsers”, select the “Storage > Storage Object Viewer” option, as follows, and click add:

Now if you head back to the file browser, you’ll see all the files have the little warning icon telling you the resource is publicly accessible.

For command-line gurus

I showed the visual approach from the cloud console… but there’s a one-liner you can use, thanks to the gsutil command.

For an individual file:

gsutil acl ch -u AllUsers:R gs://[BUCKET_NAME]/[OBJECT_NAME]

For a whole bucket:

gsutil iam ch allUsers:objectViewer gs://[BUCKET_NAME]

(Where you replace [BUCKET_NAME] with your project name, and [OBJECT_NAME] with the file name)


There’s also a REST API that you can use to handle your buckets and file, as well as different client libraries in different languages that you can use as well.

DevFest Paris and the serverless novelties on Google Cloud Platform

DevFest Paris took place last week, and I had the pleasure of presenting the recent developments around the serverless products of Google Cloud Platform. In particular, I'm covering Google App Engine and Google Cloud Functions. The velocity of release of new runtimes greatly increased over the past months, and developers can choose between Java, Python, Node, Go, or PHP for App Engine, and between Python, Node and Go for Cloud Functions.

As a Java Champion, I'm also happy to report that a Java 11 runtime for App Engine is coming soon, and we're opening an alpha so that users can try it and report any problems they encounter. So if you want to try out Java 11 on App Engine, please fill in this form.

Here are the slides I presented at DevFest Paris:

Mais c'est quoi un Developer Advocate ?

J'ai eu le plaisir d'encadrer des stagiaires de 3ème récemment chez Google. Nous accueillons des enfants, neveux, nièces, cousins d'employés de Google (donc non :-P, je ne prends pas de stagiaire, pas la peine de demander !!!) pour leur faire découvrir les différents métiers que nous exerçons dans l'entreprise. Et il y en a beaucoup ! 

L'un de mes stagiaires m'a interviewé lorsque je décrivais mon travail de "Developer Advocate", au sein de Google Cloud. J'ai trouvé cette interview intéressante, et je me suis dit que ça valait le coup de la partager avec vous, en Français (si, si, j'écris en Français parfois sur ce blog.) 

L'exercice de cet entretien est intéressant parce qu'il me permet d'essayer d'expliquer de manière simple ce que je fais... et ce n'est pas évidant, vu la technicité de cet univers, des produits sur lesquels on travaille (qui ne sont pas à la portée du grand public). Donc voici quelques unes des questions auxquelles j'ai eu à répondre. J'espère que vous trouverez cela intéressant.

Quel est ton métier ?

Je suis Developer Advocate pour la branche Google Cloud de Google.
C’est un titre en anglais qui n’a pas vraiment d’équivalent en Français.

Google Cloud, c’est la partie de Google qui propose des produits comme par exemple Gmail pour la messagerie électronique, Google Docs pour le traitement de texte ou de tableurs, mais qui offre également aux développeurs et ingénieurs des serveurs sur lesquels les développeurs peuvent héberger leurs applications, des bases de données pour stocker leurs données, ou bien encore des services autour de l’intelligence artificielle pour reconnaître ce qu’il y a comme objets dans des images.

Quelles sont les principales activités dans ce métier ?

Le rôle d’un Developer Advocate est d’être une sorte de représentant des développeurs (nos utilisateurs et clients qui créent des applications). Nous collectons les retours de ces développeurs pour voir comment améliorer les produits de Google, en écoutant leurs besoins, leurs demandes, les problèmes qu’ils rencontrent.

Par ailleurs, une autre grande partie de ce rôle (la partie la plus visible de l'extérieur), c’est de présenter et promouvoir les produits de Google (Google Cloud dans mon cas). Il s’agit alors d’écrire des articles, de coder des exemples de programmes utilisant nos technologies, enregistrer des vidéos, préparer des présentations que nous donnons lors de conférences locales ou internationales, puis aussi tirer partie des réseaux sociaux pour faire passer notre message.

Enfin, nous sommes également les utilisateurs “zéro” de nos futurs nouveaux produits. Nous sommes donc les premiers à tester ces produits, pour voir ce qui fonctionne ou pas, s’ils sont faciles à utiliser, s’ils ont des bugs, si l’on peut trouver des façons de les améliorer ou de les enrichir avant de les sortir publiquement.

Travailles-tu plutôt seul ou en équipe ? Pourquoi ?

Je travaille dans une équipe internationale, répartie dans différents pays, avec des bureaux à San Francisco, Seattle, New York, Londres, Paris ou Tokyo. Parfois je travaille effectivement en équipe, à plusieurs sur un même sujet, mais beaucoup de mes activités sont aussi solitaires, comme lorsque l’on prépare une démonstration et une présentation pour une conférence.

Dois-tu prendre des initiatives ? Pourquoi ?

Le poste de Developer Advocate est un travail qui demande beaucoup d’autonomie, et donc qui nécessite de prendre soi même beaucoup d’initiatives. C’est à moi de décider sur quel sujet travailler, quel article écrire, à quelle conférence je souhaite assister. 

Parfois, les Developer Advocates ont des demandes venant des chefs de produits qui souhaiteraient que nous représentions leur produit, mais c’est généralement par soi même que l’on décide sur quoi travailler.

As-tu des responsabilités ? Si oui lesquelles ? Pourquoi ?

Je n’encadre personne, donc je n’ai en tout cas pas de responsabilité managériales. Par contre, je me focalise sur une certaine gamme de produits, et c’est de ma responsabilité de représenter et d’améliorer ces produits là.

As-tu des contacts avec des personnes autres que tes collègues de travail ? Pourquoi ?

Comme une partie de mon travail consiste à aller présenter les produits de Google Cloud à des conférences, des “meetups”, des groupes d’utilisateurs, je rencontre effectivement beaucoup de monde lors de ces événements. Egalement au travers des réseaux sociaux, j’interagis souvent avec des développeurs aux quatre coins du monde. Et j'ai également la chance de pouvoir rencontrer nos clients, pour discuter de leurs problèmes, de leurs besoins, mais aussi de leurs réussites.

Les activités sont-elles variées ou répétitives ?

Les activités sont effectivement variées, aussi bien de la programmation (pour préparer des démonstrations des produits), de la communication (pour des présentations), de l’écriture (pour les articles, la documentation que nous rédigeons), mais aussi le voyage au travers le monde permets de découvrir de nouveaux horizons et de nouvelles cultures.

Dois-tu organiser ton travail ou plutôt exécuter des consignes ?

Comme je le disais plus haut, c’est un travail qui demande beaucoup d’autonomie, donc c’est à moi d’organiser mon travail, d’autant plus que j’ai déjà un certain niveau d’ancienneté. Il arrive parfois qu’on me demande certaines choses effectivement, mais le plus souvent c’est à moi de m’organiser.

Est-ce que le travail est fatigant (nerveusement et physiquement) ? Pourquoi ?

Parfois oui. Il y a beaucoup à faire : Google Cloud possède de nombreux produits, qui sont développés rapidement, il y a donc énormément de choses à couvrir et étudier. Ce qui est également fatigant, c’est le fait de voyager au travers le monde avec les décalages horaires, les tracas associés au voyage de manière générale. 

Outre le voyage et la quantité de travail, il faut travailler régulièrement avec la maison mère qui est sur la côte Ouest des Etats-Unis, avec 9 heures de décalage horaire, ce qui veut dire qu’il faut pouvoir faire des conférences téléphoniques avec mes collègues outre-Atlantique après 18 ou 19 heures, voire parfois même à 21 ou 22 heures ! Autre exemple, lorsque l’on donne des présentations à des “meetups”, c’est souvent le soir après le travail, donc on peut rentrer parfois très tard chez soi.

Est-ce que cette profession permet d’obtenir une promotion ? Laquelle ?

Dans ce rôle, il y a différents grades, différents niveaux. Quand on commence dans ce métier, on entrera à un certain niveau, et au fil des années, on pourra progresser et monter de niveau en niveau. L'entreprise n'attends pas la même chose de ses employés en fonction de leur niveau d'ancienneté. Nous avons une sorte d'échelle qui décrit ce qui est attendu de chacun à chaque niveau de sa progression hiérarchique.

Quels sont les diplômes requis ?

Il faut généralement un Bac+5 (type mastère, école d’ingénieur) en informatique et avoir déjà une certaine expérience professionnelle dans le domaine de l’informatique pour bien comprendre la problématique de nos utilisateurs et clients.

Quel est le contenu des études ?

Dans mon cas (un DESS en informatique), ce sont des études qui permettent aux étudiants d’apprendre comment fonctionnent les ordinateurs, d’apprendre des langages de programmation, comment écrire des algorithmes, comment fonctionne les réseaux informatiques ou les bases de données, etc.

Est-ce qu’il y a d’autres formations possibles (formation continue, cours du soir, autres) pour cette profession ?

Bien qu’un diplôme Bac+5 en informatique soit le plus commun, du moment qu’on a une bonne expérience professionnelle dans le domaine, il est aussi possible de bifurquer vers cette profession. Mais il n’y a à proprement parlé pas de formation spécifique pour le rôle de Developer Advocate à ma connaissance.

On demande souvent aux jeunes "qu'est-ce que tu voudras faire plus tard ?" 
Dans mon cas, je voulais être "ingénieur", et j'aimais bien l'informatique, mais ce qui est amusant c'est qu'à l'époque où j'ai fait mes études, le métier de "Developer Advocate" n'existait pas vraiment. Donc qui peut dire quels métiers existeront quand vous serez sur le marché du travail ? Il faut savoir s'adapter, car de nouveaux métiers voient le jour régulièrement, et il n'y aura pas forcément de formation spécialisée pour y parvenir, ou de parcours type.

Quelle sont les qualités requises ?

Outre le fait d’être un bon ingénieur en informatique (savoir programmer, etc.), il faut aussi avoir de très bonnes capacités communicationnelles, un esprit de synthèse et de vulgarisation, car nous devons aider nos utilisateurs et clients à comprendre comment se servir de nos produits. 

Par ailleurs, la majeure partie de mon travail s’effectue en anglais, qui est la langue de la maison mère, mais la langue internationale en informatique et lorsque l’on voyage. Donc il faut absolument être bon en Anglais pour ce travail.

Machine Learning APIs with Apache Groovy

At GR8Conf Europe last year, I talked about how to take advantage of the Google Cloud machine learning APIs using Apache Groovy

With Groovy, you can call the Vision API that recognises what's in your pictures, or reads text.
You can invoke the Natural Language API to understand the structure of your text.
With the Speech-To-Text API, you can get transcriptions of what's been said in an audio stream, or with Text-To-Spech, you can also generate human-like voices from your own text. 

With those ready-made APIs, no need to be an expert data scientist! Just call an SDK or a REST API, and you're ready to go.

Here's the video of the presentation:

And here are the slides that I showed:

In a previous article, I also presented one of the sample that I used with the Vision API.

The Call for Paper for the new edition of GR8Conf Europe is still open, so don't miss the opportunity to tell the world about all the cool things you've been doing with Apache Groovy!
© 2012 Guillaume Laforge | The views and opinions expressed here are mine and don't reflect the ones from my employer.