Pre-trained Machine Learning APIs presentation and video

Last month, for the first time, I visited Riga (Latvia), for the DevTernity conference. I really enjoyed my time there, and wish to come back with other topics next time. The organizers took very well care of the speakers, and the presentations were very interesting.

I had the pleasure to talk about the pre-trained machine learning APIs provided by Google Cloud Platform, and say a few words as well about TensorFlow and Cloud ML Engine.

The talk was recorded, and I wanted to share with you the video and the slides of the presentation.

And here is the deck:

The 2018 countdown: A tip a day about Google Cloud Platform

A few weeks ago, I've started a new blog dedicated to Google Cloud Platform, to share tips'n tricks I come across while exploring the platform, getting to know new products, or gathered through experience with a particular service I've been using:

With the holidays season, I went with a "2018 countdown" approach (like an "advent calendar" without the religious connotation), where I publish a tip every day of the month of December.

As of today, December 18th, we already have 18 tips available!

Those tips span about a dozen technologies! (as you can also explore the tips via "tags", which represent a technology / service / API / product each)

Initially, I thought it would be a challenge to author tips every day (without even thinking of the fact you have to publish tips during weekends, holidays or vacations), but there are actually plenty of tricks to share. Furthermore, I opened the blog to contributions: anyone who wants to contribute a tip or two is welcome, and should just share with me a quick gist describing the tip. I've already received a bunch of contributions, from 8 distinct authors. Thanks a lot to Alexandre, Bastien, Fabien, Graham, Jim, Mark, Victor, or Wassim!

Although it all started as a tip a day for the 2018 countdown, it won't stop there. Perhaps the frequency will be a bit lower (once a week? more?), but I definitely intend on continuing sharing tips on a regular basis next year and beyond!

If you want to help, please spread the word! Tell your friends and colleagues about the site:

Also please follow the @gcptips Twitter account where new tips'n tricks are announced.

And if you've got some time, don't hesitate to share your own tips! All help is welcome :-)

Gradle vs Maven and Gradle in Kotlin or Groovy

Once in a while, when talking about Gradle with developers, at conferences or within the Groovy community (but with the wider Java community as well), I hear questions about Gradle. In particular Gradle vs Maven, or whether developers adopt the Kotlin DSL for Gradle builds.

In the past, I blogged several times about using BigQuery and the Github dataset to analyze open source projects hosted on Github, by running some SQL queries against that dataset. You might want to have a look at this past article on some Gradle analysis with BigQuery. Considering those questions popped up recently, I decided to do a quick run through those questions with some simple queries.

Gradle vs Maven?

First, let's look at Maven builds. We can run the following query:

SELECT count(*) 
FROM [bigquery-public-data:github_repos.files] 
WHERE path LIKE '%pom.xml'

There are 1,125,150 pom files.

Then, for Gradle, I ran this query (even if projects could have different build file names):

SELECT count(*) 
FROM [bigquery-public-data:github_repos.files] 
WHERE path LIKE '%build.gradle'

There are 414,329 build.gradle files.

So that's 1 Gradle build file for 2.7 Maven build file.

Gradle builds in Kotlin or in Groovy?

Now for Kotlin, the convention seems to be about naming your build files with build.gradle.kts. So let's run the following query:

SELECT count(*) 
FROM [bigquery-public-data:github_repos.files] 
WHERE path LIKE '%build.gradle.kts'

There are only 207 Gradle builds files written in Kotlin.

Basically, Groovy-based Gradle builds are 2000 times more popular than Kotlin-based builds.

A grain of salt

Now, all that said, remember that developers can name their build files differently, that it's only a snapshot of the projects available on Github, and furthermore, just open source projects (at least projects that explicitly have a LICENSE file). Note for example as well that there are Gradle based projects that also have a pom.xml file available, although they're not using Maven for their build. 

Also, perhaps it'd be more interesting to run the queries by counting repositories, rather than build files: Perhaps Gradle users tend to split their build files in smaller build files, in a less monolithic way than with Gradle? Practices and habits may vary greatly. 

For the Gradle vs Maven question, at Devoxx Belgium, I ran the following (more complex) query where I look at repositories containing Gradle or Maven build files:

select file, count(file) FROM (
  (SELECT 'gradle' as file, count(repo_name)
  FROM `bigquery-public-data.github_repos.files`
  WHERE path LIKE '%build.gradle'
  GROUP BY repo_name)
  (SELECT "maven" as file, count(repo_name)
  FROM `bigquery-public-data.github_repos.files`
  WHERE path LIKE '%pom.xml'
  GROUP BY repo_name)
group by file

Gradle and Maven are already much closer to each other by looking at repository counts than just by pure number of build files, perhaps indeed showing a trend with Gradle users to modularize their builds more.

We get 118,386 repositories using Gradle versus 143,290 repositories using Maven. So Gradle is almost at the same level as Maven from that repository perspective, Still catching up with Maven!

Famous last words

Don't necessarily draw too big conclusions out of those figures, there are many ways to make stats, and those figures are only a small fraction of all the projects in existence in the world... but at least, they certainly exhibit a certain trend, which is still interesting to know and think about!

The JDK built-in web server with Apache Groovy

In my timeline, I saw a tweet from Joe Walnes about the built-in HTTP server available in the JDK since Java 6. It's super convenient, starts super fast, easy to use, but I often forget about it. I'd probably not use it for serving planet-wide load, but it's very useful when you need to create a quick service, a little mock for testing some web or micro-service.

Here's a little hello world for the fun.

I'm taking advantage of Apache Groovy's closure-to-functional-interface coercion support, as well as the with{} method to reuse the HttpServer instance for two method calls on the same instance (I could've used it for the http variable as well, actually).


HttpServer.create(new InetSocketAddress(8080), 0).with {
    createContext("/hello") { http ->
        http.responseHeaders.add("Content-type", "text/plain")
        http.sendResponseHeaders(200, 0)
        http.responseBody.withWriter { out ->
            out << "Hello ${http.remoteAddress.hostName}!"

More voice control for Actions on Google

Today, there were some interesting announcements for Actions on Googlefor building your conversational interfaces for the Google AssistantAmong the great news, one item particularly caught my attention: the improved SSML support:

Better SSML
We recently rolled out an update to the web simulator 
which includes a new SSML audio design experience. 
We now give you more options for creating natural, 
quality dialog using newly supported SSML tags, including <prosody>, 
<emphasis>, <audio> and others. The new tag <par> is coming soon 
and lets you add mood and richness, so you can play background music 
and ambient sounds while a user is having a conversation with your app. 
To help you get started, we've added over 1,000 sounds to the sound library.
Listen to a brief SSML audio experiment that shows off some of the new features here.

SSML stands for Speech Synthesis Markup LanguageIt's a W3C standard whose goal is to provide better support for a more natural sounding speech generation.

So far, Actions on Google had limited SSML support, but today, there's a bit more you can do with SSML to enhance your apps' voice!

At the Devoxx Belgium conference last week, in a couple of talks showing Dialogflow, 
Actions on Google, and Cloud Functions, I showed some quick examples of SSML.

For example, I made an attendee do some squats on stage! (but the camera didn't catch that unfortunately.) I created a loop over a tick-tock sound to mimick a countdown. I repeated x times the tick-tock sound. With x audio elements. But we can do better now, by using the repeatCount attribute instead!
<audio src="gs://my-bucket-sounds/tick-tock-1s.wav" repeatCount="10" />

It's much better than repeating my audio tag 10 times!

If you want to make your interactions even more lively, you could already use the Actions on Google sound library, or use a free sound library like Freesound.

But there's a promising upcoming tag that's gonna be supported soon: <par/>
If you will, par is a bit like a multi-track audio mixer. You'll be able to play different sounds in parallel, or make the voice speak in parallel. So you could very well have a background sound or music, with your app speaking at the same time.

Speaking of voice, the human voice goes up and down in pitch. With the prosody element, you can define the rate, pitch, and volume attributes. For instance, I make my voice sing some notes with semitones (but to be honest, it doesn't quite sound yet like a real singer!)

  <prosody rate="slow" pitch="-7st">C</prosody>
  <prosody rate="slow" pitch="-5st">D</prosody>
  <prosody rate="slow" pitch="-3st">E</prosody>
  <prosody rate="slow" pitch="-2st">F</prosody>
  <prosody rate="slow" pitch="0st">G</prosody>
  <prosody rate="slow" pitch="+2st">A</prosody>
  <prosody rate="slow" pitch="+4st">B</prosody>
  <prosody rate="slow" pitch="+6st">C</prosody>

You can also play with different levels of emphasis:

  This is 
  <emphasis level="strong">really</emphasis>

Learn more about all the support SSML tags in the Actions on Google documentationIt's gonna be even more fun to create lively voice interactions with all those improvements!

© 2012 Guillaume Laforge | The views and opinions expressed here are mine and don't reflect the ones from my employer.