JavaOne — How Languages Influence Each Other: Reflections on 14 Years of Apache Groovy

Last week, I was in San Francisco for my tenth JavaOne! I had two sessions: one on the past / present / future of Java Platform-as-a-Service offerings, and one on programming language influences, and particularly how was Apache Groovy influenced, and how it also inspired other languages.

Here's the abstract:

Languages have been influencing one another since the dawn of computer programming. There are families of languages: from Algol descendants with begin/end code blocks to those with curly braces such as C. Languages are not invented in a vacuum but are inspired by their predecessors. This session’s speaker, who has been working on Apache Groovy for the past 14 years, reflects on the influences that have driven the design of programming languages. In particular, Groovy’s base syntax was directly derived from Java’s but quickly developed its own flavor, adding closures, type inference, and operators from Ruby. Groovy also inspired other languages: C#, Swift, and JavaScript adopted Groovy’s null-safe navigation operator and the famous Elvis operator.

And you can have a look at the slides below:


Apache Groovy is a multi-faceted language for the Java platform, allowing developers to code in a Java-friendly syntax, with great integration with the Java ecosystem, and powerful scripting and Domain-Specific Language capabilities, while at the same time being able to offer you type safety and static compilation.

In this presentation, I revisited some of the influences from other languages, from the C-family and its Java older brother, going through its Python-inspired strings, its Smalltalk and Ruby heritage for named parameters and closures, its type system à-la-Java. But I'm also showing some of the innovations Groovy came up with that were later borrowed by others (Swift, C#, Kotlin, Ceylon, PHP, Ruby, Coffeescript...). Things like Groovy's trailing closure, Groovy builders, null-safe navigation, the Elvis operator, ranges, the spaceship operator, and more.

Ultimately, inspiration is really a two-way street, as languages don't come from nowhere and inherit from their older brothers and sisters. No language is perfect, but each one of them somehow help the next ones to get better, by borrowing here and there some nice features that make developers more productive and write more readable and maintainable code.

DevFest Toulouse — Building your own chatbots with API.AI and Cloud Functions

A few weeks ago, my buddy Wassim and I had the chance to present again on the topic of chatbots, with API.AI and Cloud Functions, at the DevFest Toulouse conference.

Here's the latest update to our slide deck:


Chatbots, per se, are not really new, in the sense that we've been developing bots for things like IRC for a long time, but back in the day, it was simply some regular expression labor of love, rather than the natural language that we use today. The progress in machine learning, in both speech recognition (for when you use devices like Google Home) and natural language understanding (NLU), is what led us to being able to speak and chat naturally to those chatbots we encounter now.

In this presentation, we're covering the key concepts that underpin the NLU aspects:
  • Intents — the various kind of sentences or actions that are recognized (ex: "I-want-to-eat-something")
  • Entities — the concepts and values that we manipulate or that are parameterizing intents (ex: the kind of food associated with the "I-want-to-eat-something" intent)
  • Context — a conversation is not just a request-reply exchange, but the discussion between you and the chatbot can span longer back'n forth exchanges, and the chatbot needs to remember what was previously said to be useful and avoid any frustration for the user
We're also clarifying some of the terminology used when working with the Google Assistant and its Actions on Google developer platform:
  • Google Assistant — a conversation between you and Google to help GTD
  • Google Home — voice activated speaker powered by the Google Assistant
  • Google Assistant SDK — kit to embed the Google Assistant in your devices
  • Agent / chatbot / action — an actual app serving a particular purpose
  • Actions on Google — developer platform to build apps for the Assistant
  • Apps for the Google Assistant — 3rd party apps integrated to the Assistant
  • Actions SDK — a software SDK for creating apps
  • API.AI — a platform for creating conversational interfaces
It's important that your chatbot has a consistent persona, that corresponds to the core values or attributes of your brand, the spirit of your bot. A bot for children will likely be more friendly and use easy to understand vocabulary, vs a more formal tone for, say, a bank chatbot).

There are some great resources available for seeing if your chatbot and its conversation is ready for prime time:
Our tool of choice for our demo is API.AI, for implementing the voice interactions. It's clearly one of the best platforms on the market that makes it simple to create intents, entities, handle contexts, deal with many predefined entity types, that also provides various pre-built conversations that you can peruse.

For the business logic, we went with Google Cloud Functions which allows us to define our logic using JavaScript and Node.JS. We also took advantage of the local Cloud Functions emulator, to run our logic on our local machine, and ngrok for creating a tunnel between that local machine and API.AI. In API.AI, in the fulfillment webhook, you'll put the temporary URL given by ngrok, that then points at your local machine, via ngrok's tunnel. That way, you can see changes immediately, thanks to the live reloading supported by the emulator, making it easy to evolve your code.

Cloud Functions is Google's function-as-a-service offering, which is a serverless service, taylored for event-oriented systems as well as for direct HTTP invocation, and you pay only as you go, as requests are made or events are sent to your function. It's a cost effective solution, that scale automatically with your load.

To finish, we're also saying a few words about how to submit your bot to the Actions on Google development platform, to extend the Google Assistant with your own ideas.

Cloud Functions et API.AI à Devoxx Belgique pour vos interfaces conversationnelles

Pour Devoxx France, j'avais développé l'embryon d'un petit chatbot pour découvrir l'agenda de la conférence. Mais c'était plus un "proof of concept" qu'un projet vraiment fini. Mais je vais pouvoir reprendre cette ébauche et l'étoffer bientôt, car j'aurai le plaisir d'approfondir le sujet pour Devoxx Belgique ! 

La vidéo (en Français) de la présentation que j'ai donnée à Devoxx France sur le sujet a été publié il y a quelque temps sur YouTube, et vous pourrez la voir ci-dessous :


Pour Devoxx Belgique, avec mon comparse Wassim, nous allons développer un chatbot complet, avec API.AI et Cloud Functions, qui, je l'espère, sera intégr" à l'application d'agenda de Devoxx, et peut-être aussi à l'application mobile. Les spectateurs pourront poser des questions à cet agent, pour savoir ce qu'il y a comme présentation en ce moment, pour trouver des sujets qui les intéressent, en savoir plus sur les présentateurs, ou savoir quand ils pourront manger des frites ou voir le film ! Nous présenterons tout cela avec Wassim lors d'une BOF.

J'aurai aussi l'occasion d'approfondir le sujet des interfaces conversationnelles avec Benjamin Fuentes d'IBM et Tara Walker d'Amazon, pour avoir un panorama de ce qui se fait niveau outillage pour permettre aux développeurs de créer eux même leurs chatbots, comment brancher la logique métier nécessaire, comment intégrer leurs créations en mode web ou mobile, et plus encore.

Anvers, à très bientôt !

Cloud Shell and its Orion-based text editor to develop in the cloud

After deploying in the cloud, there's a new trend towards programming in the cloud. Although I'm not sure we're quite there yet, there are a couple of handy tools I've been enjoying when working on the Google Cloud Platform

I had been using the built-in Cloud Shell console, on the Google Cloud console, to have a terminal already pre-configured for my Google Cloud project. It allows you to easily have access to your whole environment, run commands, etc, just like you would from your own computer. The fact that all the command-line tools you can imagine (gradle, maven, gcloud sdk, etc) are already there is helpful, as well as the fact that you are already configured for using other cloud services.

To launch the shell, look no further than the top right hand corner, and click on the little [>_] button. It will launch the terminal in the bottom part of your cloud console.

 
You will see the console popping up below, and you'll be ready to access your project's environment:

But look at this little pen icon above? If you click it, you'll get your terminal in full screen in another window, but more interestingly, it will launch a proper file editor! It's an editor based on Eclipse Orion's web editor. You have your usual file browsing pane, to navigate to and select which files you want to edit, and you also have things like syntax highlighting to better understand the code at hand. 


The more friendly those built-in web editors will become, the sooner we'll really be able to develop in the cloud. I believe I will still continue to work on my local computer a long, but there are already times when I prefer running some operations directly in the cloud: for example, tasks that are really network hungry, they benefit directly from the wonderful network that cloud shell has access to, which is much snappier than the connection I have at home on my DSL router. For example, running some Docker build command, or fetching tons of dependencies for Node or Maven/Gradle, and it's really much nicer and faster within Cloud Shell. So having the added capability of also editing some files in my project make things pretty snappy.

There was a recent article on the Google Cloud blog outlining the beta launch of the Cloud Shell's code editor, which is why I wanted to play with this new built-in editor.

Apache Groovy and Google App Engine at JavaOne

I'll be back at JavaOne in San Francisco in October to speak about Apache Groovy and Google App Engine

Apache Groovy

I've been involved with the Apache Groovy project for 14 years now, it's a long time, and it's interesting to see how the language has evolved over time, how it was influenced by other languages, but also how it influenced those other languages itself! Let's see which operators or syntax constructs evolved and moved from one to the other.

Google App Engine

These days, the hype is around containers, containers everywhere! We tend to relegate Platform-as-a-Service solutions to the side, but it's still one of the most convenient way to deploy and scale an application today. After all, Snapchat and others are able to take advantage of a PaaS like App Engine, so why couldn't you too? (and you don't need to scale to their level anyway, but you'd still get the convenience of easy development and deployment)

Anyhow, I've invited my friends from Heroku and Oracle to join me for a panel discussion on the theme of Java PaaS-es. We'll see how Java PaaS-es are relevant today, more than ever.

The abstracts

So if you want to lear more about those two talks, here are their abstracts.

[CON5034] How Languages Influence Each Other: Reflections on 14 Years of Apache Groovy 

Languages have been influencing one another since the dawn of computer programming. There are families of languages: from Algol descendants with begin/end code blocks to those with curly braces such as C. Languages are not invented in a vacuum but are inspired by their predecessors. This session’s speaker, who has been working on Apache Groovy for the past 14 years, reflects on the influences that have driven the design of programming languages. In particular, Groovy’s base syntax was directly derived from Java’s but quickly developed its own flavor, adding closures, type inference, and operators from Ruby. Groovy also inspired other languages: C#, Swift, and JavaScript adopted Groovy’s null-safe navigation operator and the famous Elvis operator.

[CON5945] Java PaaS -- Then, Now and Next 

Java developers want to deploy their apps easily. Fortunately, there are great solutions for them in the form of Platform-as-a-Service for Java. In this discussion panel, we will share the views of Oracle, Heroku and Google engineers about their respective Java PaaS-es, how this space has evolved over the past few years, and what makes a great developer experience for users today. We'll discuss the future of PaaS in light of new technologies like microservices, containerization, and serverless architectures. Finally, we'll open up the space for an interactive discussion with the audience.

(with Joe Kutner from Heroku, Shaun Smith from Oracle, Ludovic Champenois from Google, and Frank Greco from NY JavaSIG as moderator)
 
© 2012 Guillaume Laforge | The views and opinions expressed here are mine and don't reflect the ones from my employer.