3 links about WebRTC

WebRTC (Real-Time Communications) is a communication way between 2 (or more) browsers without a server doing the job. It allows, for instance, to make video streaming, radio broadcasting stations, chats, or real-time edition apps.

World Base Chat: Meet your neighbors

Some weeks ago, at the beginning of the lockdown in Spain, I did a fork from another project to create World Base Chat, a tool to meet your neighbors online. It allows you to chat with your neighbors, the ones you know and the ones you don’t.

A bit of history

When the lockdown started, I encouraged the use of Next Door. This is a platform that allows neighbors to be in touch, make groups, offer and request help… However, some users said to me that this is requesting a lot of information and that’s true.

Next week, Google announced the shut down of Neighbourly, an app to connect you with your neighbors and make sharing local information more human and helpful.

I wanted a way to talk to people from my town to know, for instance, if I can help them with something. But, I also wanted the possibility to talk to people from NYC, New Delhi, and other locations to ask them how is the situation there. I wanted the capacity to ask people at the origin of the information in a time full of fake news.

I forked another project to build, spending only two days, the seed of World Base chat, a web app to meet your neighbors.

There are some users using the app, so I think that it could be a real thing.

World Base Chat app
World Base Chat

It is not too beautiful, but it owns the functionalities that everybody needs to stay in touch with their neighbors.

Functionalities of World Base Chat

It allows anonymous users to chose a location to chat with anybody connected to the same location or the regions that contain it. So, if you choose Madrid (the city), you can chat with people in Madrid (the city and the region) but also in Spain and in the World chat. Everybody is in the World chat because all the people are on the planet or orbiting around.

You can also create a group linked to any location. You can create a group for your neighborhood. A group to contact your friends from the bowling alley. You can create a group for your University campus or for the basketball court. Yes, you can create a group for whatever you want and share the link to spread the new meeting point.

You can also see some ‘Top hosts’ that are currently active, and the data from Wordlometer related to coronavirus, in order to avoid fake news.

I know that this is very basic functionality, but this bus just started its trip and I am thinking about the next stops while doing some little improvements.

Next stops

I did some tests and got some data, and I think that the bigger next stop is private chats with the possibility to add voice and/or video to the conversation. I am starting to validate this and I trust that it is going to be a changemaker.

There are other nice-to-have like beauty and/or custom user names, maybe a registry, an emoji keyboard, drawing open graph information when people share a link… but my bid is for video chat. What do you think?

I would love read your feedback, just here or in the World Base Chat.

Best papers awards in Computer Science of 2018

2018 has finished with a lot of innovations. It brought a lot of awards for papers about several disciplines of Computer Science at different conferences this year. Here we have the abstract of some of them:

  • Memory-Augmented Monte Carlo Tree Search

    This paper proposes and evaluates Memory-Augmented Monte Carlo Tree Search (M-MCTS), which provides a new approach to exploit generalization in online realtime search. The key idea of M-MCTS is to incorporate MCTS with a memory structure, where each entry contains information of a particular state. This memory is used to generate an approximate value estimation by combining the estimations of similar states. We show that the memory based value approximation is better than the vanilla Monte Carlo estimation with high probability under mild conditions. We evaluate M-MCTS in the game of Go. Experimental results show that MMCTS outperforms the original MCTS with the same number of simulations.

  • Finding Syntax in Human Encephalography with Beam Search

    Recurrent neural network grammars (RNNGs) are generative models of (tree,string) pairs that rely on neural networks to evaluate derivational choices. Parsing with them using beam search yields a variety of incremental complexity metrics such as word surprisal and parser action count. When used as regressors against human electrophysiological responses to naturalistic text, they derive two amplitude effects: an early peak and a P600-like later peak. By contrast, a non-syntactic neural language model yields no reliable effects. Model comparisons attribute the early peak to syntactic composition within the RNNG. This pattern of results recommends the RNNG+beam search combination as a mechanistic model of the syntactic processing that occurs during normal human language comprehension.

  • Voice Interfaces in Everyday Life

    Voice User Interfaces (VUIs) are becoming ubiquitously available, being embedded both into everyday mobility via smartphones, and into the life of the home via ‘assistant’ devices. Yet, exactly how users of such devices practically thread that use into their everyday social interactions remains underexplored. By collecting and studying audio data from month-long deployments of the Amazon Echo in participants’ homes-informed by ethnomethodology and conversation analysis-our study documents the methodical practices of VUI users, and how that use is accomplished in the complex social life of the home. Data we present shows how the device is made accountable to and embedded into conversational settings like family dinners where various simultaneous activities are being achieved. We discuss how the VUI is finely coordinated with the sequential organisation of talk. Finally, we locate implications for the accountability of VUI interaction, request and response design, and raise conceptual challenges to the notion of designing ‘conversational’ interfaces.

  • Relevance Estimation with Multiple Information Sources on Search Engine Result Pages

    Relevance estimation is among the most important tasks in the ranking of search results because most search engines follow the Probability Ranking Principle. Current relevance estimation methodologies mainly concentrate on text matching between the query and Web documents, link analysis and user behavior models. However, users judge the relevance of search results directly from Search Engine Result Pages (SERPs), which provide valuable signals for reranking. Morden search engines aggregate heterogeneous information items (such as images, news, and hyperlinks) to a single ranking list on SERPs. The aggregated search results have different visual patterns, textual semantics and presentation structures, and a better strategy should rely on all these information sources to improve ranking performance. In this paper, we propose a novel framework named Joint Relevance Estimation model (JRE), which learns the visual patterns from screenshots of search results, explores the presentation structures from HTML source codes and also adopts the semantic information of textual contents. To evaluate the performance of the proposed model, we construct a large scale practical Search Result Relevance (SRR) dataset which consists of multiple information sources and 4-grade relevance scores of over 60,000 search results. Experimental results show that the proposed JRE model achieves better performance than state-of-the-art ranking solutions as well as the original ranking of commercial search engines.

  • An empirical study on crash recovery bugs in large-scale distributed systems

    In large-scale distributed systems, node crashes are inevitable, and can happen at any time. As such, distributed systems are usually designed to be resilient to these node crashes via various crash recovery mechanisms, such as write-ahead logging in HBase and hinted handoffs in Cassandra. However, faults in crash recovery mechanisms and their implementations can introduce intricate crash recovery bugs, and lead to severe consequences.In this paper, we present CREB, the most comprehensive study on 103 Crash REcovery Bugs from four popular open-source distributed systems, including ZooKeeper, Hadoop MapReduce, Cassandra and HBase. For all the studied bugs, we analyze their root causes, triggering conditions, bug impacts and fixing. Through this study, we obtain many interesting findings that can open up new research directions for combating crash recovery bugs.

  • Delayed Impact of Fair Machine Learning

    Fairness in machine learning has predominantly been studied in static classification settings without concern for how decisions change the underlying population over time. Conventional wisdom suggests that fairness criteria promote the long-term well-being of those groups they aim to protect.
    We study how static fairness criteria interact with temporal indicators of well-being, such as long-term improvement, stagnation, and decline in a variable of interest. We demonstrate that even in a one-step feedback model, common fairness criteria in general do not promote improvement over time, and may in fact cause harm in cases where an unconstrained objective would not.
    We completely characterize the delayed impact of three standard criteria, contrasting the regimes in which these exhibit qualitatively different behavior. In addition, we find that a natural form of measurement error broadens the regime in which fairness criteria perform favorably.
    Our results highlight the importance of measurement and temporal modeling in the evaluation of fairness criteria, suggesting a range of new challenges and trade-offs.

  • Large-Scale Analysis of Framework-Specific Exceptions in Android Apps

    Mobile apps have become ubiquitous. For app developers, it is a key priority to ensure their apps’ correctness and reliability. However, many apps still suffer from occasional to frequent crashes, weakening their competitive edge. Large-scale, deep analyses of the characteristics of real-world app crashes can provide useful insights to guide developers, or help improve testing and analysis tools. However, such studies do not exist — this paper fills this gap. Over a four-month long effort, we have collected 16,245 unique exception traces from 2,486 open-source Android apps, and observed that framework-specific exceptions account for the majority of these crashes. We then extensively investigated the 8,243 framework-specific exceptions (which took six person-months): (1) identifying their characteristics (e.g., manifestation locations, common fault categories), (2) evaluating their manifestation via state-of-the-art bug detection techniques, and (3) reviewing their fixes. Besides the insights they provide, these findings motivate and enable follow-up research on mobile apps, such as bug detection, fault localization and patch generation. In addition, to demonstrate the utility of our findings, we have optimized Stoat, a dynamic testing tool, and implemented ExLocator, an exception localization tool, for Android apps. Stoat is able to quickly uncover three previously-unknown, confirmed/fixed crashes in Gmail and Google+; ExLocator is capable of precisely locating the root causes of identified exceptions in real-world apps. Our substantial dataset is made publicly available to share with and benefit the community.

  • SentiGAN: Generating Sentimental Texts via Mixture Adversarial Networks

    Generating texts of different sentiment labels is getting more and more attention in the area of natural language generation. Recently, Generative Adversarial Net (GAN) has shown promising results in text generation. However, the texts generated by GAN usually suffer from the problems of poor quality, lack of diversity and mode collapse. In this paper, we propose a novel framework – SentiGAN, which has multiple generators and one multi-class discriminator, to address the above problems. In our framework, multiple generators are trained simultaneously, aiming at generating texts of different sentiment labels without supervision. We propose a penalty based objective in the generators to force each of them to generate diversified examples of a specific sentiment label. Moreover, the use of multiple generators and one multi-class discriminator can make each generator focus on generating its own examples of a specific sentiment label accurately. Experimental results on four datasets demonstrate that our model consistently outperforms several state-of-the-art text generation methods in the sentiment accuracy and quality of generated texts.

  • Understanding Ethereum via Graph Analysis

    Being the largest blockchain with the capability of running smart contracts, Ethereum has attracted wide attention and its market capitalization has reached 20 billion USD. Ethereum not only supports its cryptocurrency named Ether but also provides a decentralized platform to execute smart contracts in the Ethereum virtual machine. Although Ether’s price is approaching 200 USD and nearly 600K smart contracts have been deployed to Ethereum, little is known about the characteristics of its users, smart contracts, and the relationships among them. To fill in the gap, in this paper, we conduct the first systematic study on Ethereum by leveraging graph analysis to characterize three major activities on Ethereum, namely money transfer, smart contract creation, and smart contract invocation. We design a new approach to collect all transaction data, construct three graphs from the data to characterize major activities, and discover new observations and insights from these graphs. Moreover, we propose new approaches based on cross-graph analysis to address two security issues in Ethereum. The evaluation through real cases demonstrates the effectiveness of our new approaches.

  • LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation

    The monolithic server model where a server is the unit of deployment, operation, and failure is meeting its limits in the face of several recent hardware and application trends. To improve heterogeneity, elasticity, resource utilization, and failure handling in datacenters, we believe that datacenters should break monolithic servers into disaggregated, network-attached hardware components. Despite the promising benefits of hardware resource disaggregation, no existing OSes or software systems can properly manage it. We propose a new OS model called the splitkernel to manage disaggregated systems. Splitkernel disseminates traditional OS functionalities into loosely-coupled monitors, each of which runs on and manages a hardware component. Using the splitkernel model, we built LegoOS, a new OS designed for hardware resource disaggregation. LegoOS appears to users as a set of distributed servers. Internally, LegoOS cleanly separates processor, memory, and storage devices both at the hardware level and the OS level. We implemented LegoOS from scratch and evaluated it by emulating hardware components using commodity servers. Our evaluation results show that LegoOS’s performance is comparable to monolithic Linux servers, while largely improving resource packing and failure rate over monolithic clusters.

  • Should I Follow the Crowd? A Probabilistic Analysis of the Effectiveness of Popularity in Recommender Systems

    The use of IR methodology in the evaluation of recommender systems has become common practice in recent years. IR metrics have been found however to be strongly biased towards rewarding algorithms that recommend popular items –the same bias that state of the art recommendation algorithms display. Recent research has confirmed and measured such biases, and proposed methods to avoid them. The fundamental question remains open though whether popularity is really a bias we should avoid or not; whether it could be a useful and reliable signal in recommendation, or it may be unfairly rewarded by the experimental biases. We address this question at a formal level by identifying and modeling the conditions that can determine the answer, in terms of dependencies between key random variables, involving item rating, discovery and relevance. We find conditions that guarantee popularity to be effective or quite the opposite, and for the measured metric values to reflect a true effectiveness, or qualitatively deviate from it. We exemplify and confirm the theoretical findings with empirical results. We build a crowdsourced dataset devoid of the usual biases displayed by common publicly available data, in which we illustrate contradictions between the accuracy that would be measured in a common biased offline experimental setting, and the actual accuracy that can be measured with unbiased observations.

  • SuRF: Practical Range Query Filtering with Fast Succinct Tries

    We present the Succinct Range Filter (SuRF), a fast and compact data structure for approximate membership tests. Unlike traditional Bloom filters, SuRF supports both single-key lookups and common range queries: open-range queries, closed-range queries, and range counts. SuRF is based on a new data structure called the Fast Succinct Trie (FST) that matches the point and range query performance of state-of-the-art order-preserving indexes, while consuming only 10 bits per trie node. The false positive rates in SuRF for both point and range queries are tunable to satisfy different application needs. We evaluate SuRF in RocksDB as a replacement for its Bloom filters to reduce I/O by filtering requests before they access on-disk data structures. Our experiments on a 100 GB dataset show that replacing RocksDB’s Bloom filters with SuRFs speeds up open-seek (without upper-bound) and closed-seek (with upper-bound) queries by up to 1.5× and 5× with a modest cost on the worst-case (all-missing) point query throughput due to slightly higher false positive rate.

  • A Constant-Factor Approximation Algorithm for the Asymmetric Traveling Salesman Problem

    We give a constant-factor approximation algorithm for the asymmetric traveling salesman problem. Our approximation guarantee is analyzed with respect to the standard LP relaxation, and thus our result confirms the conjectured constant integrality gap of that relaxation.
    Our techniques build upon the constant-factor approximation algorithm for the special case of node-weighted metrics. Specifically, we give a generic reduction to structured instances that resemble but are more general than those arising from node-weighted metrics. For those instances, we then solve Local-Connectivity ATSP, a problem known to be equivalent (in terms of constant-factor approximation) to the asymmetric traveling salesman problem.

  • Authoring and Verifying Human-Robot Interactions

    As social agents, robots designed for human interaction must adhere to human social norms. How can we enable designers, engineers, and roboticists to design robot behaviors that adhere to human social norms and do not result in interaction breakdowns? In this paper, we use automated formal-verification methods to facilitate the encoding of appropriate social norms into the interaction design of social robots and the detection of breakdowns and norm violations in order to prevent them. We have developed an authoring environment that utilizes these methods to provide developers of social-robot applications with feedback at design time and evaluated the benefits of their use in reducing such breakdowns and violations in human-robot interactions. Our evaluation with application developers (N=9) shows that the use of formal-verification methods increases designers’ ability to identify and contextualize social-norm violations. We discuss the implications of our approach for the future development of tools for effective design of social-robot applications.

  • HighLife: Higher-arity Fact Harvesting

    Text-based knowledge extraction methods for populating knowledge bases have focused on binary facts: relationships between two entities. However, in advanced domains such as health, it is often crucial to consider ternary and higher-arity relations. An example is to capture which drug is used for which disease at which dosage (e.g. 2.5 mg/day) for which kinds of patients (e.g., children vs. adults). In this work, we present an approach to harvest higher-arity facts from textual sources. Our method is distantly supervised by seed facts, and uses the fact-pattern duality principle to gather fact candidates with high recall. For high precision, we devise a constraint-based reasoning method to eliminate false candidates. A major novelty is in coping with the difficulty that higher-arity facts are often expressed only partially in texts and strewn across multiple sources. For example, one sentence may refer to a drug, a disease and a group of patients, whereas another sentence talks about the drug, its dosage and the target group without mentioning the disease. Our methods cope well with such partially observed facts, at both pattern-learning and constraint-reasoning stages. Experiments with health-related documents and with news articles demonstrate the viability of our method.

If you want more, you can visit the Jeff Huang’s list.

Tech roundup 1: a journal published by a bot

Read a tech roundup with this week’s news that our powerful bot has chosen: blockchain, AI, development, corporates and more.

Gooooooood morning, Y’all!!! Hey, this is not a test, this is a tech roundup. Time to rock it from the Delta to the DMZ.

AI, bots and robots

Blockchain and decentralization

Woman computer scientist of the week
Carolina Cruz-Neira is a Spanish-Venezuelan-American computer engineer, researcher, designer, educator, and a pioneer of virtual reality (VR) research and technology. She is known for inventing the CAVE automatic virtual environment. She previously worked at Iowa State University (ISU), University of Louisiana at Lafayette and is currently the director of the Emerging Analytics Center at the University of Arkansas at Little Rock.

Cloud and architecture

Development and languages

Quote of the week

The best code is no code at all.

Enterprises

Other news

Suscríbete al blog por correo electrónico

Introduce tu correo electrónico para suscribirte a este blog y recibir avisos de nuevas entradas.

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 (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 (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.