Blog

Las 3 leyes de la deontología informática

  1. f. Parte de la ética que trata de los deberes, especialmente de los que rigen una actividad profesional.
  2. f. Conjunto de deberes relacionados con el ejercicio de una determinada profesión.

Recientemente nos hemos topado con noticias que tal vez no llamen mucho la atención de primeras, pero para los que estamos en el “mundillo del metal” (que diría Bonilla) creo que sí lo son. Hemos visto como compañeros tecnólogos se han revelado en las grandes empresas: en Google, en Amazon y ahora en Microsoft; para presionarlas y que dejen de hacer cosas que no les parecen éticas.

La ética es un tema muy subjetivo. He tenido la suerte de poder estudiarla desde pequeñito, lo que me ha hecho tener la creencia de que no se debe juzgar a nadie sin estar en su pellejo. Puedes ser crítico, puedes opinar distinto, incluso puedes ser radical y oponerte de manera activa a lo que sea, pero no hay una distinción absoluta entre el bien y el mal y por lo tanto las circunstancias de cada uno van a afectar mucho a su toma de decisiones.

Supongo que muchos hemos vivido algún caso en el que se nos planteaba una cuestión ética, que normalmente pasa por “hacer lo que me mandan o hacer lo que está bien”.

Mi caso (más grave) ya lo conté en Twitter hace unos meses, a raíz del “amago” (que me alegro enormemente de que finalmente no se materializase) de extradición de Falciani:

En resumen, me pidieron que ocultase unos datos de una empresa (pública) porque le iban a hacer una auditoría. Me negué y un compañero lo hizo. No estoy de acuerdo con las acciones de mi jefe por aquel entonces ni del compañero que las ejecutó, pero no les juzgaré a ellos pues sólo estoy en situación de juzgarme a mi.

Creo firmemente que debemos ser cuidadosos con lo que hacemos y que debemos actuar siempre en conciencia de lo que creemos que está bien. Nuestras acciones tienen efectos y hoy en día, la informática otorga mucha capacidad a los que la controlan. Además, la gente que trabajamos en tecnología tenemos la suerte de que hoy por hoy, podemos elegir nuestro trabajo pues la demanda de profesionales es altísima. Todo esto nos da un gran poder y como todos los amantes de Spiderman saben: un gran poder conlleva una gran responsabilidad.

Pero bueno, hablar del bien y del mal es muy fácil y “gratuito”, es mejor hablar de cosas concretas. Miremos, por ejemplo, el código deontológico de los ingenieros informáticos colegiados en el Colegio Profesional de Ingenieros en Informática de Andalucía. No os miento si os digo que no conozco a ni un sólo informático que no haya incumplido alguna de las normas “básicas” que ahí se establecen. Yo el primero de todos, que quede claro. ¿Y vosotros? ¿Las habéis cumplido todas siempre? ¿A rajatabla? ¿Y la gente que conocéis? Me apostaría una caña a que haciendo memoria alguna ocasión se os ocurre.

Probáblemente, que nadie cumpla dicha deontología quiere decir que lo que esta marca difiere mucho de lo que la mayoría cree que es ético o no y es que, como decía al principio, la ética es un tema muy subjetivo.

Además, aún con sus 8 páginas de normas, creo que la mencionada deontología se deja cosas en el tintero porque por ejemplo no tendría ningún tipo de aplicación en los casos que vimos al principio de Google, Amazon y Microsoft.

Quienes conocemos las 3 leyes de la robótica, sabemos que es mejor tener poca cantidad de normas suficientemente generalistas que nos permitan aplicarlas en cada caso. También es cierto que si habéis leído a Asimov sabréis que surgen excepciones constantemente que provocan que te cuestiones si esas leyes son correctas, pero en la gran mayoría de los casos funcionan adecuadamente.

De cualquier modo, creo que podemos seguir su ejemplo para tener una deontología informática que sea de aplicación en la mayoría de los casos:

  1. No emplees tus conocimientos y habilidades para hacer algo que te parezca que está mal.
  2. Si gracias a tus conocimientos y habilidades puedes hacer algo por cambiar algo que está mal, hazlo.
  3. En cualquier situación que no esté afectada por los puntos 1 y 2 intenta hacer el mejor trabajo que puedas con los recursos a tu alcance.

Creo que siguiendo estas tres “leyes” la evaluación de cada situación se puede simplificar bastante. Los dos primeros son egoístas ya que, aunque ayudarían a que devolvamos a la sociedad un poquito de lo que nos da, también nos ayudarán a dormir mejor por la noche. El último, aunque pueda parecer el más obvio, también hay que tenerlo muy en cuenta para que no se nos olvide hacer siempre el mejor trabajo posible.

¿Cómo lo véis? ¿Estás sí que podéis decir que las habéis cumplido siempre?

¿Cómo conseguir la verdadera web abierta?

La web abierta es algo que preocupa a mucha gente desde hace bastante tiempo. Los gobiernos y grandes corporaciones monopolizan el control sobre la WWW, sobre sus contenidos, sobre sus tecnologías, sobre servicios vitales para su funcionamiento… Hay alertas que nos dicen que vamos camino a una distopía, o que incluso ya estamos en ella. ¿Cómo podemos evitarlo? ¿Cómo podemos conseguir la verdader web abierta?

No me voy a meter en grandes definiciones, ya hay otros que definen lo que és la web abierta de un modo más o menos acertado, pero para marcar un poco la línea decir que la web abierta es que la gente tenga el poder sobre la web, que tengan el control sobre sus propios contenidos para dejar acceder a todo el que ellos quieran.

Hay muchos elementos a tener en cuenta, de cara a la web abierta. Están las tecnologías a emplear, está la posibilidad de buscar la información (las búsquedas), está el acceso al contenido en sí… y son muchos los factores a tener en cuenta en cada uno de estos puntos.

Por ejemplo, el W3C (World Wide Web Consortium) tiene un pequeño wiki sobre “open web platform” en el que especifica algunas tecnologías que son completamente libres, y que sirven de base para tener una web abierta. Son las mínimas, pero no todo el mundo puede saber de todas ellas para controlar su propio contenido.

Puede que parezca un nuevo miedo, el hecho de que preocupe que la gente deje de tener el control. Sin embargo, dándole la vuelta (pasando del miedo de que quiten el control a la gente, al deseo de que lo tenga), ya en los comienzos de la Web su inventor, Tim Berners Lee, insistió mucho (sin éxito) a los desarrolladores de navegadores web de la época con que los navegadores también debían ser herramientas para que los usuarios pudiesen editar documentos, editar la web. Fue ignorado como el típico loco pesado que no sabe lo que dice, porque “¿por qué iban los usuarios querer crear sus propias páginas web? ¿Por qué iban a querer crear contenidos?“.

Respecto a este tema, la semana pasada tuve la suerte de poder (volver a) asistir al Ignite Madrid, y entre otras charlas muy interesantes pude escuchar la de Luis Roig (alias Darum) en la que advertía que “nos han robado Internet”. No haré muchos spoilers pues en breves saldrá la versión en vídeo (gallifante para el primero que lo enlace en los comentarios cuando salga), pero os diré que en 5 minutos hizo un breve e impactante repaso a la historia de la Web, defendió la web abierta y planteó el futuro que viene.

Puede que os preguntéis cuál es ese porqué que debería de haceros mover incómodos en vuestra silla. A fin de cuentas ya podéis publicar lo que queráis en miles de sitios: Facebook, Twitter, Instagram, Snapchat, … y siempre, a las malas, podréis decir lo que queráis en todos esos grupos de WhatsApp.

Voy a delegar en mi exsocio y amigo, Juan, que es un fiel defensor de la web abierta y que ya explicó en la WordCamp Madrid de 2017 “¿por qué defender la web abierta?”.




Justo esta semana, me ha llegado uno de los motivos de preocupación: hace años me autoedité un libro (#yuzzsfo Descubriendo Silicon Valley) y lo publiqué en Bubok para que el que quisiera pudiese descargárselo o tener una edición impresa (que me alegro de que nadie comprase, realmente). Esta semana me dieron el aviso de que para descargar el libro ahora hay que “pagar” dando una dirección de email a cambio. Acto seguido lo descargué, lo subí a un repositorio de archivos “propio” (Google Drive), y cree un enlace de bit.ly (por medir y saber cuantas descargas tengo que sumar a las 768 que tiene en Bubok).

Así que “ya está”, tomé el control de mis contenidos y puse mi granito de arena para la web abierta… ¿seguro?

Hay mucha gente que me dirá que esto no es ningún ejemplo de web abierta. He puesto mi archivo en manos de un gigante al que le importo cero (Google), y he direccionado el tráfico a él a través de un tercero que podría cambiar el destino de la navegación de los usuarios-consumidores sin yo enterarme.

Entonces, ¿cómo es la verdadera web abierta?

El tener tu propia página puede ser web abierta. Pero por ejemplo, esta página que leéis está alojada y mantenida por el mencionado Juan por lo que yo no tengo un control total, ya que yo no tengo acceso a su proveedor de hosting. Él tampoco tiene un control total, puesto que su proveedor de hosting puede cortarle el acceso en cualquier momento.

Podría montarme una granja de servidores en casa como tiene mi amigo Inda, pero ¿bastaría con esto? Mi proveedor de Internet podría cortarme la línea, o el ayuntamiento decidir que ya no quiere que pasen cables de fibra por sus calles. Podría alguien manipular los servidores de DNS (que es el eslabón más débil de toda la arquitectura de la web, aunque eso es otra historia que deberá ser contada en otro momento) y evitar que se pudiese acceder a mi contenido más que por IP. O aún teniendo yo todo el control de mis cosas, podría ser que por el lado de los usuarios-consumidores les aplicasen restricciones similares que les impidiese llegar a mis contenidos ¿y entonces de qué serviría que yo tuviese el control sobre ellos?

La verdadera web abierta es una utopía (EMHO) que, a día de hoy, como tal es imposible alcanzar. Igual que en el trabajo en el que delegamos responsabilidades en compañeros o en la vida en la que delegamos decisiones en gobiernos, estamos obligados a delegar parte del control sobre la Web.

Debemos elegir con sabiduría que publicamos en Facebook y que en nuestra propia web. Debemos elegir si el servicio X me provee extras suficientes y me da una confianza tal como para que tenga sentido ponerme en sus manos.

Ahora bien, como con los compañeros o los gobiernos, en todo momento deberemos estar atentos a cualquier alerta para tomar medidas si hay un cambio que modifique nuestra confianza.

Chatbots (III): The magic of creating chatbots without Visual Studio thanks to FormFlow

Chatbots, conversational interfaces, that started their hype two years ago are really funny but they aren’t always useful. Design a conversation having in mind all different possible options needs a lot of effort. Is it necessary to manage all possible inputs in order to manage a simple business task? Thinking about most of the apps, the answer is “no”, else we wouldn’t have a lot of apps based on forms getting information to do something.

[En castellano]

Microsoft gives us, inside Bot Framework, an easy way to model tiny business functionalities that in other environments we would resolve using a simple form. FormFlow is an engine that, using a data model, can automatize a conversation to get all the information needed to fill the model and allow us to do whatever we want with the data.

Thanks to it we can use the omnipresence of chatbots to be more near to our public (because chatbots are in a lot of channels in which users are already present).

Let’s go to see how we can deploy a simple chatbot inside Azure. You will see that using FormFlow is so easy so we don’t need to open Visual Studio to code it. It will be like magic! We are going to do an emulator of the Sorting Hat from Hogwarts who decided, in J. K. Rowling stories, to what house the students of the school of magic were going.

It is a really easy example, but full of functionalities and details, that is going to be useful as a base to make any simple app that needs to get some data with which do something: calculate something (like in this case but also it could be calculating a loan conditions or the price for a car insurance), call to an API (for instance in order to record a request for a loan, or to request a call from a salesperson), or whatever comes to mind.

As most of the bot is based on the data model definition it will be an easy task no matter how complex it was, because the magic is coded by Microsoft inside FormFlow.

Our first move has to be creating a new bot over Azure (Web App Bot). To get the easy way, let’s use an example bot, so when we are creating the app we will tell to Azure that has to use the FormFlow template.

When it was deployed, we will have two elements with the same name: a Web App and the Web App Bot. Inside the Web App Bot options, we can find one (under Build menu) to edit code online, that’s the one that we will use to edit our bot’s code because it’s so simple that we don’t need to do complex things.

Bots based on FormFlow use a model, so we have to define one. Our Sorting Hat isn’t so magic like the one from Hogwarts, ours gets information from students in order to take a decision.

Fields of our model can be from basic types (integers, floating point numbers, strings, DateTimes, enumerations) and lists of enumerations. In our case, we will start only with enumerations because values that we will manage are too specific to our domain.

 public enum Nombres {
  Godric,
  Helga,
  Rowena,
  Salazar
 };  
 public enum Cualidades {
  Valentía, 
  Honestidad,
  Inteligencia,
  Ambición
 }; 
 public enum Colores {
  Rojo, 
  Amarillo,
  Azul,
  Verde
 }; 
 public enum ColoresDeJoyas {
  Oro,
  Negro,
  Bronce,
  Plata
 }; 
 public enum Animales {
  Leon,
  Tejon,
  Aguila,
  Serpiente
 }; 
 public enum LugaresParaVivir {
  TorreOscura,
  Bodega,
  TorreLuminosa,
  Mazmorras
 }; 
 public enum Titulos {
  Sir,
  Fraile,
  Dama,
  Barón
 }; 
 public enum Amigos {
  Ron,
  Neville,
  Hermione,
  Harry
 }; 
 public enum Accesorios {
  Espada,
  Copa,
  Diadema,
  Guardapelo
 } 
 [Serializable]
 public class SortingTest
 {
     public Nombres? Nombre;
     public Cualidades? Cualidad;
     public Colores? Color;
     public ColoresDeJoyas? ColorDeJoyas;
     public Animales? Animal;
     public LugaresParaVivir? LugarParaVivir;
     public Titulos? Titulo;
     public Amigos? Amigo;
     public Accesorios? Accesorio;

     public static IForm<SortingTest> BuildForm()
     {
         OnCompletionAsyncDelegate<SortingTest> evaluate = async (context, state) =>
         {
              await context.PostAsync(“OK”);
         };
         return new FormBuilder<SortingTest>()
                  .Message(“Hola”)
                  .OnCompletion(evaluate)
                  .Build();
     }
};

If you also want to manage new information like the name or the birth date, you only need to add new properties to our model that bot will manage and validate for you.

    public string TuNombre;
    public DateTime? FechaDeNacimiento;

As soon as we have our class model defined, we only have to add this to our project creating an online file and we can also delete the example model that is not related to our magic world.

We also have to do some minor changes in the controller to allow it use our new model instead of the one we deleted. The file name is MessagesController.cs and we will change references to the model on MakeRootDialog method.

    internal static IDialog<SortingTest> MakeRootDialog()
    {
        return Chain.From(() => FormDialog.FromForm(SortingTest.BuildForm));
    }

From this point, we can compile (build.cmd) and test our bot. Again, inside Web App Bot options we have one to test our bot using a web client without leaving Azure Portal. As soon as we say “Hi” it will answer us and we could see it asking us to fill the model.

When we are capturing all the data, we only have to process that and to do this we will change code inside BuildForm method of our SortingTest. If we test it again, we will see that we already have all working. However, it’s not very beautiful that if our bot is made for Spanish speakers it speaks in English. FormFlow is ready to localize it to different languages but in our case only will change some details using attributes over our model.

There are attributes for many things. For instance, we can set optional fields or create our very own validations. We will use a template attribute to change the question that is made for each field.

    [Template(TemplateUsage.EnumSelectOne, "Elige un {&} {||}", ChoiceStyle = ChoiceStyleOptions.Auto)]

There is a full language to edit messages format. In our case, {&} characters represent the field name and {||} characters different options for the user. The ChoiceStyleOptions enumeration allows us to indicate how options are shown.

If we would test again we will see that it is more elegant, but it is not elegant at all because of some language conflicts. For instance “Cualidad” is female and the question is not neutral so it’s not well-formed for female names. It’s the same for string and DateTime properties for what we didn’t change their template. We can use a similar attribute that is applied to one only property.

    [Prompt("Elige una cualidad {||}")]

FormFlow has more capabilities but with these, we could do some “tech magic” in few minutes to get something beautiful and functional. We only have to select one or more channels to publish it to start reaching our public just in the channel they are working daily. For instance, if you want to know what the Sorting Hat is thinking about you, you only have to visit javilopezg.com/SortingHat and talk to it.

Chatbots (III): La magia de crear chatbots sin abrir Visual Studio gracias a FormFlow

Los chatbots, las interfaces conversacionales, que empezaron a estar de moda hace un par de años resultan muy divertidos, pero no siempre son útiles. Requiere bastante esfuerzo diseñar una conversación teniendo en cuenta todas las opciones de respuesta que pueden plantear los usuarios. Pero: ¿es necesario controlar todas las posibles entradas para realizar una tarea de negocio? En la mayoría de las aplicaciones, la respuesta es un rotundo “no”. Si así fuese, no se basarían la mayoría de apps en formularios para recoger datos con los que hacer algo.

Seguir leyendo en CompartiMOSS.

Chatbots (II): How to make your phone read to you Hacker News (also contents)

Following the post series about Chatbots, I did an app to make Google Assistant allows you navigate using your voice throw Hacker News (Y Combinator‘s tech news forum) and listen to the body of the news in which you are more interested.

[En castellano]

If you are only interested in using it, you only have to talk to Google and say “Talk to Hacker News Reader. However, if you want to know main points to be able to do something similar using few hours and few lines of code stay tuned: we are going to see the 6 human characteristics that are really easy to get using Dialogflow.

Dialogflow is a Google platform (formerly API.ia) that allows us to create chatbots in an easy way.

It is so powerful that allows us to do a lot of things without a single line of code.

For instance, it has integrated a natural language processing system. If you give it few training examples, it will know what our users are trying to say, driving them to different parts of our chatbot in order to give them the correct answer.

So, it will allow us to give human capacities to our chatbot in a really easy way.

1. Listening

Intents are the main component of a chatbot inside Dialogflow. It is something like a conversation unit, it is each part that our system can understand and give an answer.

Dialogflow allows us to set events and other parameters that will launch an intent. Especially, it allows writing different sentences in order to guide the chatbot. When it will detect those it will know that that is the intent it has to launch.

It also allows writing different responses that it will launch randomly avoiding you from writing code.

2. Understanding

A chatbot picking out actions based on sentences without a single line of code is great but not powerful enough. In the end, listening sentences is not the most important but understanding the concepts that are wrapped inside them.

When you are typing example phrases, you are allowed to select some words to say the platform that they are something important and that it should abstract them from single values.

At the moment in which the language understanding motor detects some of the entities that we had mapped to variables, it will extract them and send them to us as parameters in each request.

The system is ready to understand a lot of different things, but it allows us to define our own entities in order to model exactly what we want. For instance, I created an entity with different sections from Hacker News: top, new, best, ask, show and job. Then, the system can understand that a user wants that jobs uploaded to Hacker News to be read.

3. Intelligence

If intents’ answer options are not enough, we can create our very own web service to answer request understood by the system.

Google offers some libraries and using them, create a service in any language on any platform would be really easy. However, for small things like Hacker News Reader we can code right inside the platform using node.js. This code will be deployed to Firebase only with one click.

When you are thinking about things you can do you must think that coding a service (on Firebase or anywhere) you can do literally anything.

That is, you don’t need to only use APIs to access contents because you don’t have cross-origin restrictions. You have the whole Internet in your hands.

For instance, my action allows users listen to news linked from Hacker News. To do this, it downloads the web page (like a browser) and processes that to extract contents (I didn’t a hard work, it could be better).

4. Analysis

In order to use the inline editor, we have to attend some restrictions like the one that says that “dialogflowFirebaseFulfillment” must be the name of our function if we want an automated deployment.

However, thanks to Dialogflow listening and understanding, when we are giving it some intelligence we will have really easy to give analysis capacities of requests received for our chatbot.

Map each intent to functions developed by ourselves is really easy. Intents function is listening so they will say us what a user wants.

We could also access parameters understood by the system thanks to entities (understanding).

exports.dialogflowFirebaseFulfillment = functions.https.onRequest((request, response) =&amp;gt; {
    const agent = new WebhookClient({
        request,
        response
    });
    //...

    function read(agent) {
        var number = agent.parameters.number || 0;
        //...
    }

    let intentMap = new Map();
    intentMap.set('Default Welcome Intent', welcome);
    intentMap.set('Repeat', repeat);
    intentMap.set('Back', repeat);
    intentMap.set('Read', read);
    //...
    var promise = null;
    try {
        promise = agent.handleRequest(intentMap).then(function() {
            log('all done');
        }).catch(manageError);
    } catch (e) {
        manageError(e);
    }
    return promise;
});

5. Answering

To give to our chatbot answering capacity we only have to use add method from WebhookClient. We can pass as params text, user answer suggestions or rich text cards where we can embed images, use emoticons, etc.

Keep in mind that some devices where your action may be executed could not own a display or a browser. It’s important if we want a strictly conversational interface, so we should avoid visual elements to help to our bot only with words.

6. Memory

The most disgusting thing in a conversation is having to repeat every time what we are saying so, it is really important that our bot remember what user said in previous interactions of our conversation.

For this, we will use contexts. Contexts are an element managed by Dialogflow to help to choose between intents in order to launch the correct one. They could be used to know if a client device has a display available, for instance.

Their use is not very well documented, but when you debug basic methods you see that it is trivial use them to save information between each conversation turn.

    //...
    var context = agent.getContext('vars');
    var vars = context ? context.parameters : {
        ts: (new Date()).getTime() % 10000,
        items: [],
        pointer: 0,
        list: 0,
        //...
    };
    //...
    agent.setContext({
        name: 'vars',
        lifespan: 1000,
        'parameters': vars
    });
    //...

With these 6 human capacities, you own the keys to do something similar by your own and provide a lot of functionalities to Google Assistant.

I hope they may be useful for you, the action and the information provided in this post. If yes, please share and spread the word.

We will continue with other systems that allow us to do chatbots in an easy way and with how to integrate our chatbots into other channels.

Chatbots (II): Cómo lograr que tu móvil te lea Hacker News (los contenidos también)

Siguiendo con la serie sobre Chatbots, he preparado un programilla para que Google Assistant te permita navegar usando la voz por Hacker News (el foro de Y Combinator dedicado a noticias de tecnología) y escuchar el cuerpo de las noticias que más te interesen.

[In English]

Si sólo quieres usarla basta con que le digas a Google “Talk to Hacker News Reader. Sin embargo, si quieres conocer los puntos clave para poder hacer algo similar en pocas horas y con muy poco código sigue leyendo, porque vamos a ver 6 características humanas muy fáciles de obtener gracias a Dialogflow.

Dialogflow es una plataforma de Google (antes conocida como API.ai), que nos permite diseñar chatbots de un modo sencillo.

Es tan potente, que se pueden hacer muchísimas cosas sin tirar una sóla línea de código.

Por ejemplo, tiene integrado un sistema de reconocimiento de lenguaje natural el que, dándole unos cuantos ejemplos para que entrene, será capaz de reconocer lo que quieren decir los usuarios de nuestra acción y conducirles por las partes de nuestro chatbot para que obtengan la respuesta adecuada.

Por tanto, nos permitirá dar a nuestro chatbot de capacidades “humanas” de un modo muy simple.

1. Escucha

Los intents son el componente principal de un chatbot en Dialogflow. Lo podemos ver como cada unidad de conversación, es cada parte que nuestro sistema va a ser capaz de comprender y dar una respuesta.

Dialogflow nos permite indicar eventos y otras cosas que lanzarán ese intent, y en especial, nos permite indicar distintas frases que le sirvan de guía al chatbot, para que cuando las detecte sepa qué es ese y no otro el que tiene que lanzar.

También permite indicar directamente respuestas ahí mismo, que se irán lanzando aleatoriamente sin que tú tengas que programar nada.

2. Entendimiento

Que el chatbot pueda, sin que programemos nada, distinguir unas frases de otras es genial, pero le falta algo de poder. Al final, no sólo es importante escuchar las frases si no que también hay que entender los conceptos que están encerrados en ellas.

Al introducir las frases de ejemplo, tenemos la posibilidad de seleccionar partes del texto para decirle que es algo importante que debería abstraer y entender más allá de la muestra concreta.

Cuando el motor de reconocimiento del lenguaje entienda alguna de las entidades que hayamos mapeado a variables, las extraerá y nos las pasará como parámetros en las peticiones que nos diga que tenemos que procesar.

El sistema viene ya preparado para entender muchas cosas por defecto, pero nos da la libertad de definir nuestras propias entidades que nos ayuden a modelar exactamente lo que queremos. Por ejemplo, yo me he creado una entidad con los distintos apartados de noticias de Hacker News que se pueden leer: top, new, best, ask, show y job. Así el sistema puede entender que un usuario quiere que le lean los trabajos subidos a la plataforma o las últimas noticias.

3. Inteligencia

Cuando las opciones de respuesta de los intents no son suficientes, podemos crear nuestro propio servicio web que conteste a las peticiones que haya entendido el sistema.

Con las librerías que ofrece Google es fácil montar un servicio en cualquier lenguaje y plataforma. Sin embargo, para cosas pequeñas como el Hacker News Reader, nos permite codificar directamente sobre la plataforma código en node.js que será desplegado de manera transparente para nosotros en Firebase.

Cuando penséis en las cosas que podéis hacer, daros cuenta de que tirando de un servicio (en Firebase o dónde queráis) no estaréis ejecutando código en cliente, por lo que podéis hacer literalmente todo.

Por ejemplo, no os tenéis que ceñir a usar APIs para acceder a contenidos, pues no hay restricciones de cross origin que se apliquen a vuestro código. Tenéis todo Internet a vuestro alcance de un modo sencillísimo.

Mi acción permite al usuario escuchar las noticias que están linkadas desde Hacker News. Para esto se descarga la web (como si fuese un navegador) y la procesa para extraer el contenido (no me he esmerado mucho y se podría hacer mucho mejor).

4. Análisis

Para usar el editor inline, tendremos que tener algunas restricciones como que por narices nuestra función deberá llamarse “dialogflowFirebaseFulfillment” si queremos que se despliegue automáticamente y funcione todo bien.

Sin embargo, gracias a que Dialogflow escucha y entiende, al dotar de inteligencia a nuestro chatbot lo tendremos muy fácil para que sea capaz de realizar los análisis pertinentes de cada petición del usuario.

En el código podremos de un modo sencillo mapear cada uno de los intents que hayamos creado con funciones nuestras. Como estos se encargaban de escuchar, nos indicarán lo que el usuario quiere.

También podremos acceder a los parámetros que el sistema haya entendido gracias a las entidades que hayamos creado (entender).

exports.dialogflowFirebaseFulfillment = functions.https.onRequest((request, response) =&gt; {
    const agent = new WebhookClient({
        request,
        response
    });
    //...

    function read(agent) {
        var number = agent.parameters.number || 0;
        //...
    }

    let intentMap = new Map();
    intentMap.set('Default Welcome Intent', welcome);
    intentMap.set('Repeat', repeat);
    intentMap.set('Back', repeat);
    intentMap.set('Read', read);
    //...
    var promise = null;
    try {
        promise = agent.handleRequest(intentMap).then(function() {
            log('all done');
        }).catch(manageError);
    } catch (e) {
        manageError(e);
    }
    return promise;
});

5. Respuesta

Para que nuestro chatbot conteste, tan solo tenemos que hacer uso del método add de nuestro WebhookClient. Podremos pasarle directamente texto, sugerencias de respuesta para guiar al usuario o fichas con texto enriquecido en dónde podremos embeber imágenes, poner emoticonos, etc.

Hay que tener en cuenta que algunos de los dispositivos en los que potencialmente correrá nuestra aplicación pueden que no tengan pantalla o navegador web por ejemplo. Por lo que hay que tener en cuenta que, si queremos algo puramente conversacional, deberíamos evitar los estímulos visuales y ayudar a nuestro bot a expresarse sólo con el uso de la palabra.

6. Recuerdo

Una de las cosas que más nos exasperan a todos es tener que repetir las cosas una y otra vez, por lo que es importante que nuestro bot recuerde lo que ya se le haya dicho.

Para esto usaremos los contextos. Los contextos es una estructura que maneja Dialogflow para ayudarnos a filtrar entre intents y permitir a la plataforma lanzar el adecuado. Se pueden usar, por ejemplo, para saber si el dispositivo del cliente tiene pantalla.

Su uso no está muy documentado, pero una vez que ves como funcionan los dos métodos básicos, es trivial su uso para guardar información entre cada frase de una conversación.

    //...
    var context = agent.getContext('vars');
    var vars = context ? context.parameters : {
        ts: (new Date()).getTime() % 10000,
        items: [],
        pointer: 0,
        list: 0,
        //...
    };
    //...
    agent.setContext({
        name: 'vars',
        lifespan: 1000,
        'parameters': vars
    });
    //...

Con estas 6 capacidades humanas ya tenéis las claves para poder hacer algo similar vosotros mismos y dar mucha más funcionalidad a Google Assistant.

Espero que os resulte útil, tanto la acción en sí como la información extra. Si es así compartidlo y difundid la palabra.

Seguiremos con algunos otros sistemas que nos permiten también hacer chatbots de un modo sencillo, y con cómo integrar nuestros bots en distintas plataformas.

Chatbots (I): Build an app to talk to your phone without coding

A posts series about chatbots starts today with a direction but without a clear destination.

Today we are going to see a really easy way to create an app that allows you (writing like in a chat or speaking) talk to your phone without coding, without a single line of code!

[En castellano]

A lot of you already would had used Google Assistant. It is the “Siri” from Google which you could access on Android phones saying “Ok, Google”.

Nowadays it also works on iOS phones, on Google Home, on smartwatches, on cars, on TVs, …

By the way, Google (attending the developer community program I spoke about two months ago) mailed me about they are gifting me a Google Home thanks an app I built following this method, using only a few hours. Do you want do the same?

When you access the actions console (“actions” is the name given to Google Assistant apps) you can add a new project and Google gives you some options. You can code everything using its API, you can use an advanced platform in which you can code but it gives you a lot of work done (it is named DialogFlow), or you can use templates Google provides.

As you see in the above image, there are 3 different templates:

  1. Trivia. This template allows you create a quiz. You can provide different answers and synonyms for this answers also for each question. It is ready to load contents in English, French, German and Japanese.
  2. Personality Quiz. This template is ready to create personality quizzes. For instance, you can create a quiz like the one used by Cambridge Analytics (the company that had problems with Facebook’s privacy) to get data about millions of Americans and to affect USA elections. For the time being, you can only use this to create English content.
  3. Flash Cards. This is a template that for the moment only allows you create English content. It drives you to build a teaching game to learn about things.

The first step (but with the second that doesn’t allow this option) you have to choose the kind of personality. It means that you are choosing a voice from a woman, a man or a robot. Your election is also affecting to accent, expressions and sound effects that your application is going to use.

It is really important that you copy the Google Sheets template in the second step, the one about content. If you build your sheet from a clear one, it is difficult to achieve all restrictions checked by validations coming.

Using the template you are allowed to change whatever you want to adapt it to your content, but it is really important that in the second sheet (that is ready to set different configuration params) you change the title of your application, in order to avoid conflicts with other apps created before.

Whenever you are done following this wizard (the form that takes you throw a step by step process, for the ones that are not inside the apps design and development world), you only have to follow the Overview one to set how your apps are going to be called, set descriptions, icons, etc. etc.

Done this, you are ready to send your draft to the validation process and whenever it was approved your users will be able to say to their phones “Talk to…” and magic will start.