Skip to main content

Everybody makes mistakes, even Google doc writers

Yesterday I was exploring the new Android SMS Retriever API, since it seemed to promise to make the user's phone verification a much more straight-forward and also permission-less process. 

Soon I got disappointed since it requires to use a paid third-party service such as Twilio...

But at least I got to see something unusual, not everyday one comes across a code syntax error in an official Google documentation.
Can you spot it? (at the end of the second code snippet).

According to the footnote, the last update of that page was on July 7th, so two months and a week ago.

So have I been the first one to notice this? Or maybe just the first one to raise the voice about it? I have also been nice enough to report it to Google.

I came across the above tweet which announces this API to the world, it includes a link to the docs and as you can see, 118 people re-tweeted it and 190 liked it...
Did any of this people bother to open the link and have a look to the docs? 
And I guess fire up Android Studio to play a little with the API is way too much to ask... I am starting to think that there is a significant proportion of posers among the so-called Android devs...

Anyway, as I said at the beginning, everybody makes mistakes, and actually this is a small one, and it is so obvious that I do not think it would block anyone trying to use the API for the first time.

But I think API docs with few code snippets are not enough to engage devs. 
I do not understand why Google (or any other company trying to seduce a community of devs to use their tools) does not make available the source code (through Github ideally) of an example/PoC simple app which uses and highlights the main features of the new API.
IMHO, this should be done for every non-trivial API.
To see complete and working code helps a lot.
This is actually what I did myself in a previous post.
If you are given the complete example code, you can compile it locally, you can run the unit tests and also some use cases.
All of this is incredibly valuable and saves a lot of time to the users-to-be of the API.

Probably Google uses their own internal tool to write and publish their documentation (some kind of customized and more advance Google Docs). 
I use Confluence and I am quite happy with it, you can tell is by Altassian, I really like their products, they seem to be made by developers for developers, not like many other corporate tools (SharePoint or ServiceNow, just to name a couple).

In Confluence you can insert a properly-formatted snippets of code, however, it would be nice if you could actually select the programming language of the snippet (e.g., Java or C/C#, etc...), so the editor would perform a basic code syntax check
Actually, the technology behind it is not new, the Web IDEs used in most coding challenge sites such as Codility do that and much more.

But until some doc-writing tool provides that functionality or someone invents the "unit tests for docs", I guess we will keep seeing these type of errors in documentation from time to time.


Popular posts from this blog

Kafka + WebSockets + Angular: event-driven microservices all the way to the frontend

In the the initial post of the  Event-driven microservices with Kafka series (see here  or  here ), I talked about the advantages of using event-driven communication and Kafka to implement stateful microservices instead of the standard stateless RESTful ones. I also presented the architecture and the source code of a related proof of concept application. In this post, I would like to show how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. Hence, in the first post of this series, we got rid of HTTP as the communication protocol among microservices in the backend, and now we are also replacing it (with WebSockets) as the communication protocol between the frontend and the backend. Ok, but why would you do that? Because it provides a better experience to the end user!. Using WebSockets you can build legit  real-time user interfaces, the updates are pushed immediately from the server to the client

Cómo pedir cita previa en la DGT y desesperarse en el intento

El uso de la tecnología para la agilización de la administración española es simplemente bochornoso (y me quedo corto). Además todo el mundo lo sabe, sin ir más lejos, la última gran chapuza  informática en el Ministerio de Justicia va a costar al menos  60 millones  extra.  Pero como el dinero sale del bolsillo de los ciudadanos, pues aquí no pasa absolutamente nada y nadie asumirá ninguna responsabilidad. Esta es la triste realidad de la España actual. Pero es que hasta un trámite tan sencillo como pedir cita previa en una de las Jefaturas Provinciales de Tráfico desespera hasta al más templado. Y como quiero ser muy específico y una imagen vale más que mil palabras, a continuación voy a documentar todo el proceso que es de todo menos intuitivo. Todo empieza abriendo este enlace Y como podéis ver en la imagen previa, con la primera pantalla (vamos a obviar que la interfaz parece que ya haya cumplido la mayoría de edad, tiene pinta de ser de finales de los 90) llega la pri

A Java dev journey to full-stack: first chapter

The Motivation I am an experienced Java developer and (surprise!) I like Java. I know it is not perfect but it works just fine for me (I enjoy type-safety and I do not consider verbosity a disadvantage, quite the opposite). I also know that some people dislike Java, which is also fine. But recently I decided to step out of my confort zone as developer, my goal isn't to be one of the "cool kids" neither trying to monetize a new skill in the job market. I have a quite practical motivation: I want to be able to build more (different) stuff. That's exactly the same reason why I learnt Android development by myself a couple of years ago. Web applications are ubiquitous, even more than native mobile apps, and thanks to cloud computing, one can easily and inexpensively release their idea/app to the World Wide Web. I already did some Web development in the past, in the bad old days of JSP and JSF, but the process was slow and painful. Nowadays the Web landscape h