Forem: Ismael González Trujillo

Software development: 5 career lessons from running 🏃🧑‍💻

Ismael González Trujillo — Wed, 04 Mar 2020 16:41:52 +0000

Last year I took up running and I wanted to share some things I learned along the way. Basic lessons, bordering on the self-evident, that can be applied to running, other sports or, why not, career development.

#1 - Starting is the hardest part

At first I couldn't run five minutes without taking a walk break. After years of being a couch potato my body and my mind weren't prepared for this. Starting was going to be hard and I had no other choice than accepting it. But, as it usually happens, I'm not a special case.

Every day it gets a little easier. You just have to do it every day. That's the hard part.

Couch to 5K (C25k) is a beginners 8-week program that starts with a mix of running and walking, gradually building up strength and stamina to fully running 5K.

So I went through the pain of completing the full program and, imagine what... I saw progress! Who would have imagined? Developing a new skill (like running) is a process made of different stages.

The four stages of competence are the psychological states involved in the process of progressing from incompetence to competence in a skill:

Unconscious incompetence: The learner isn't aware that a skill or knowledge gap exists.
Conscious incompetence: The learner is aware of a skill or knowledge gap and understands the importance of acquiring the new skill. It's in this stage that learning can begin.
Conscious competence: The learner knows how to use the skill or perform the task, but doing so requires practice, conscious thought and hard work.
Unconscious competence: The individual has enough experience with the skill that they can perform it so easily they do it unconsciously.

As software developers we go through these stages, not once, but multiple times in our careers. It's a cycle that starts over and over again at different levels. Starting a new job in a new position, new project with a different team, new programming language or paradigm, new framework... They all require us to master new skills.

#2 - Don't compare to others

Once I finished the 8-week C25k program, I started looking at my times and comparing them to my running friends'. Then I started wondering. Why am I so slow?

There's an immediate and easy answer to that question. I had just started running. But very rarely do we just accept this obvious truth. Because... other people who have also just started running are faster than us. Well, the truth is that genetics also plays an essential role in running performance, along with age, exercising history and a myriad of other factors. It would be impossible for you to know how all of them are affecting other runners.

We tend to make a lot of assumptions. But the truth is that reality is way too complex to make these direct comparisons.

But the main reason why you shouldn't compare yourself to others is this one:

Comparison is the thief of joy.

A much more positive approach is to compare with your previous self and focus on your progress.

Career comparison can also be dangerous, even if the original intention is positive. Pay inequality is a big problem for underrepresented groups, not only in tech. Making it visible might seem like a good idea. Trying to get everyone to go public with their salaries, however, starts an infinite loop of misleading comparisons where all the individual circumstances are ignored.

#3 - Set achievable goals

Being able to run 5k was my first goal. Running a marathon wouldn't have been realistic given my fitness level. Setting long-term goals is a good way to improve motivation, but I prefer working towards short-term ones. Some short-term goals I've already achieved include:

Completing C25K.
Joining a running club.
Doing a parkrun.
Running a 5k race.
Running 10k in under 1 hour.

These are S.M.A.R.T. goals, as defined by George T. Doran in a paper included in the November 1981 issue of Management Review:

Specific (simple, sensible, significant).
Measurable (meaningful, motivating).
Achievable (agreed, attainable).
Relevant (reasonable, realistic and resourced, results-based).
Time bound (time-based, time limited, time/cost limited, timely, time-sensitive).

// Detect dark theme var iframe = document.getElementById('tweet-1207854448086835203-163'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1207854448086835203&theme=dark" }

Need inspiration for your programming goals? Have a look at the comments on this post.

What are your goals as developer for 2k20+?

Andreas ・ Jan 4 '20

#watercooler #discuss #question

#4 - Slow down to avoid burnout

Ok, I can run. But I am very slow so I set a (SMART) goal to run 5k in under 25 minutes by the end of the year. So every time I go for a run, I push really hard to try to do a new PB. This, obviously, doesn't work. Your body and your mind need recovery.

Multiple studies have shown that runners of all ability and experience levels seem to improve the most when they do approximately 80 percent of their training at low intensity and 20 percent at moderate and high intensity.

Feeling drained from pushing too hard is not alien to software developers.

// Detect dark theme var iframe = document.getElementById('tweet-1213136318139699200-592'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1213136318139699200&theme=dark" }

Burnout is, unfortunately, a common phenomenon in our career. It can be defined as a state of physical or emotional exhaustion that also involves a sense of reduced accomplishment and loss of personal identity and is often due to long-term and unresolvable job stress.

Want some tips to avoid burnout? Addy Osmani has you covered.

// Detect dark theme var iframe = document.getElementById('tweet-1207395911405453312-140'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1207395911405453312&theme=dark" }

#5 - Learn from others

Running is a sport that suits introverts and extroverts. A long run is perfect for those who enjoy having me-time. But it's also great as a social activity. You can do it with friends, colleagues or a running club. Even though I lean towards the introverted side of the spectrum and I do a majority of my runs solo, I've enjoyed running with my colleagues every Thursday or at my local parkrun (where I also volunteer). Sharing my experience with others has increased my motivation and taught me a lot about running.

If you enjoy the social component of software development there are a lot of ways to keep yourself up-to-date with new technologies, get to know new interesting people and work on interesting projects:

Meetups
Hackathons
Tech talks
Open Source community

Some of these social gatherings can even push your performance to unimaginable limits...

// Detect dark theme var iframe = document.getElementById('tweet-1199794084669345792-986'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1199794084669345792&theme=dark" }

Conclusion

Taking up running has made me reflect on basic aspects of career development like the four stages of skill competence, setting SMART goals, the importance of avoiding burnout, or the social aspect of learning.

Think about them. They will help your career in the long run.

Building cross-platform apps for mobile, web and voice (part II)

Ismael González Trujillo — Sun, 08 Dec 2019 07:55:45 +0000

In this article and its part I we explore the technologies available to build a cross-platform experience which includes voice assistants. Assuming we want to build a small and simple to-do list app for Android, iOS, web and the Google Assistant, how can we provide the best experience for each platform while making sure our app can scale?

To bring to life the tech stack defined in the previous article, we’ve created VOXE (VOice X-platform Experience). VOXE is a simple proof-of-concept to-do list app for Android, iOS, web and the Google Assistant. One single repository, which contains:

A NativeScript (Angular) app that compiles to Android, iOS and web.
A Dialogflow agent.
A Cloud Function for the Google Action fulfillment.

The app makes use of Cloud Firestore to store the data.

VOXE architecture

The repository is publicly available on GitHub.

potatolondon / voxe

VOice X-platform Experience. A to-do list app for Android, iOS, web and Google Assistant

Firebase: Infrastructure and services

VOXE makes use of three Firebase services:

Hosting: for the web app.
Authentication: we will use Google here for simplicity but Firebase supports many other authentication methods such as passwords, phone numbers and other popular federated identity providers like Facebook, Twitter, etc.
Cloud Firestore.

The first two services are easily configurable via the Firebase Console. Let’s dig into our data model and security rules.

Cloud Firestore data model

Cloud Firestore is a NoSQL, document-oriented database. Unlike a SQL database, there are no tables or rows. Instead, the data is stored in documents, which are organised into collections.

We’ll need, then, a collection of to-do documents (todos), each of which will define the following fields: content (string), createdAt timestamp (number) and userId (string).

Security rules

Since we’re relying on Firebase client SDKs and not on a bespoke API, how do we make sure users only have access to to-do items created by themselves?

Every database request from a Cloud Firestore mobile/web client library is evaluated against a set of security rules before reading or writing any data. These rules define the level of access for a specific path in the database using conditions based on authentication and data fields.

Let’s have a look at the security rules for our database:

service cloud.firestore {
  match /databases/{database}/documents {
    match /todos/{todo} {
      allow read, delete: if request.auth.uid == resource.data.userId;
      allow create: if request.auth.uid == request.resource.data.userId;
      allow update: if request.auth.uid == resource.data.userId && request.auth.uid == request.resource.data.userId;
    }
  }
}

resource.data represents the document accessed by the query.
request.auth.uid is the id of the authenticated user.
request.resource.data represents a new or updated document.

So this set of security rules will make sure that:

Users can only read and delete documents whose userId field matches their user uid.
User can only create documents whose userId field matches their user uid.
User can only update documents whose userId field matches their user uid and this field can’t be changed.

Our database is now ready to roll.

NativeScript: A cross-platform native and web app

In our previous article we discussed some of the benefits of using NativeScript for building cross-platform apps, focusing on its code-sharing capabilities using Angular.

A code-sharing project is one where we keep the code for the web and mobile apps in one place. Let’s have a look at some examples of how we have benefited from this architecture on VOXE.

At component level, these files define the app homepage:

home.component.ts: Angular component definition (web and native).
home.component.html: web template file.
home.component.tns.html: mobile template file.

It is also possible to use the naming convention for platform-specific styling:

home.component.scss: web styles.
home.component.android.scss: Android styles.
home.component.ios.scss: iOS styles.

We’ve been able to write an implementation for the Home component (home.component.ts) that works both for web and mobile but this might not always be possible. In fact, for the Authentication and Firestore services, this isn’t possible since we’re forced to use the Firebase native client SDK for each platform. For this to work, again, we use the naming convention to define two different services. For example, the Firestore service is defined by these files:

firestore.service.ts: web implementation using the angularfire library.
firestore.service.tns.ts: mobile implementation using nativescript-plugin-firebase.
firestore.service.interface.ts: interface used by both implementations of the service.

Actions on Google: The voice experience

As previously discussed, some of our app features could be triggered via voice (or text) commands using the Google Assistant. Let’s assume we want to be able to read our to-do list, add and remove items. Here’s a diagram of the conversation flow:

In order to achieve this integration we’ll need to follow these three steps:

Create an Action in the Google Actions Console.
Create a Dialogflow Agent.
Deploy a Fulfillment.

Dialogflow

Dialogflow is a natural language understanding platform that allows us to design and build conversational user interfaces. A Dialogflow agent is a virtual agent that handles these conversations with your end-users. Although the focus of this article is on the Google Assistant, it’s important to mention that Dialogflow can also be used to build text chatbots that can be integrated with different platforms.

To describe how to do something we use intents. We want our Action to respond to requests like:

Read my list
Add a new item to my list
Remove an item from my list

We can create these intents in Dialogflow. Here’s the list of Intents in VOXE:

List of intents in VOXE

For each of the intents we need to provide training phrases. These are example phrases for what end-users might type or say, referred to as end-user expressions. For each intent, we create many training phrases. When an end-user expression resembles one of these phrases, Dialogflow matches the intent. “Please read my list”, “Remove an item from my list” or “Add an item to my list” are examples of training phrases for intents in VOXE.

Training phrases for “Add item request” intent

Training phrases can contain parameters of different entity types, from which we can extract values. For example, when the user mentions the item to be added to, or removed from the list, this list item is extracted as a parameter.

“item” parameter for “Add item request” intent

But how does Dialogflow know in which point of the conversation we are, so only the right intent for our invocation phrase can be triggered? Contexts are the key to controlling the flow of the conversation and are used to define follow-up intents. When an intent is matched, any configured output contexts for that intent become active. While any contexts are active, Dialogflow will only match intents that are configured with input contexts that match the currently active contexts.

Input and output contexts for “Add item request” intent

Fulfillment

We’ve discussed so far how intents represent the input of the conversational action. But what about the output? In Dialogflow, intents have a built-in response handler that can return static responses after the intent is matched. Different variations of this response can be specified, and one of them will be selected randomly.

Responses to “Add item request” intent

Most of the time we will need dynamic responses for our intents. The “Read list” intent is a good example. We need some code to access the database and read our list. For this to happen we need to use fulfillment for the intent. This tells Dialogflow to use an HTTP request to a webhook to determine the response.

In order to build the fulfillment for VOXE we’ve used the Node.js® client library for Actions on Google. We have deployed our code to a Cloud Function using Firebase.

This snippet shows the implementation for the “Read list” intent handler:

'use strict';

// Import the Dialogflow module and response creation dependencies
// from the Actions on Google client library.
const {
  dialogflow,
  BasicCard,
  List,
  SignIn,
  Suggestions,
} = require('actions-on-google');

// Import the firebase-functions package for deployment.
const functions = require('firebase-functions');

// Instantiate the Dialogflow client.
const app = dialogflow({
  debug: true,
  clientId: 'YOUR_CLIENT_ID_HERE',
});

// Init firebase
const admin = require('firebase-admin');

admin.initializeApp(functions.config().firebase);
const db = admin.firestore();
const auth = admin.auth();
const todosCollection = db.collection('todos');

// Middleware to store user uid
app.middleware(async (conv) => {
  const { email } = conv.user;
  const user = await auth.getUserByEmail(email);
  conv.user.storage.uid = user.uid;
});

// Handle the Read List intent
app.intent('read list', async (conv) => {
  const snapshot = await todosCollection
    .where('userId', '==', conv.user.storage.uid)
    .get()
    .catch((err) => {
      conv.close('Sorry. It seems we are having some technical difficulties.');
      console.error('Error reading Firestore', err);
    });

  if (!snapshot.empty) {
    let ssml = '<speak>This is your to-do list: <break time="1" />';
    snapshot.forEach((doc) => {
      ssml += `${doc.data().content}<break time="500ms" />, `;
    });
    ssml += '<break time="500ms" />Would you like me to do anything else?</speak>';
    conv.ask(ssml);
    conv.ask(new Suggestions('Yes', 'No'));
    conv.contexts.set('restart-input', 2);
  } else {
    conv.ask(`${conv.user.profile.payload.given_name}, your list is empty. Do you want to add a new item?`);
    conv.ask(new Suggestions('Yes', 'No'));
    conv.contexts.set('read-empty-list-followup', 2);
  }
});

// The rest of your intents handlers here
// ...

// Set the DialogflowApp object to handle the HTTPS POST request.
exports.dialogflowFirebaseFulfillment = functions.https.onRequest(app);

The full version of the fulfillment can be found here.

Multimodal interaction

The Google Assistant is available to users on multiple devices like smartphones, smart speakers and smart displays. This means we’re not limited to voice and text as the only method for input and output, but we can also use visuals. This is known as multimodal interaction, and takes full advantage of these devices capabilities. This makes it easy for users to quickly scan lists or make selections.

A good example of multimodal interaction happens when we need to specify an item to be removed from the list. One option is using voice (or text) to indicate the item. However, if we’re using a touchscreen device, it feels more natural to select it from the list directly.

VOXE: Multimodal interaction to remove list item

In this two-part article we discussed how to build a cross-platform experience which includes voice assistants. The first part focused on exploring the technologies available and choosing a tech stack. In this second part we explained how we built a simple to-do list prototype app using NativeScript, Firebase and Actions on Google.

Building cross-platform apps for mobile, web and voice (part I)

Ismael González Trujillo ・ Dec 8 '19 ・ 6 min read

#crossplatform #webdev #serverless #googleassistant

Building cross-platform apps for mobile, web and voice (part I)

Ismael González Trujillo — Sun, 08 Dec 2019 07:46:43 +0000

In this article and its part II we explore the technologies available to build a cross-platform experience including voice assistants. Assuming we want to build a small and simple to-do list app for Android, iOS, web and the Google Assistant, how can we provide the best experience for each platform while making sure our app can scale?

Native vs hybrid vs cross-platform

It’s been discussed already, a million times, and will be discussed over and over again. Should you build two dedicated native apps or a hybrid solution? What are the differences? Let’s try to summarise the different approaches we can take.

Going fully native while targeting Android and iOS means developing two separate apps. Two different codebases, in two different programming languages (Java/Kotlin vs Swift/Objective C). In exchange, this approach offers best-in-class performance, a consistent look and feel and better access to low level platform specific features.

A hybrid app is developed using standard web technologies (HTML, CSS and JavaScript) and runs as a web-view inside a native app. This means we can reuse the same codebase and target both Android and iOS. Although we can still access some platform specific functionality, the performance is compromised when compared to a native experience. This is the approach frameworks like Ionic and Cordova use.

Using frameworks like React Native or NativeScript, it’s possible to use JavaScript to build truly native apps. Both frameworks also provide mechanisms to access native APIs to take full advantage of the platforms. Going with one or the other will depend on many variables but, mainly, the JavaScript flavour you want to taste: React (React Native) or Angular/Vue/TypeScript (NativeScript).

Other cross-platform solutions that allow developers to create native apps reusing the same language and codebase are Flutter (Dart) and Xamarin (.NET/C#).

An additional solution to consider would be building a Progressive Web App. PWAs provide an installable, app-like experience on desktop and mobile that is built and delivered directly via the web. Since we’re exploring purely native solutions here (let’s put the web experience aside for now as we will come back to it in the next section) I’ll leave PWAs out of the scope of this article.

Which of these approaches is best for your app? Well, there’s no easy answer to this question. A number of factors need to be taken into account here: budget, deadlines, language of preference, performance, etc.

Since we’re aiming for a cross-platform experience and want to set ourselves up to be able to scale in complexity, to avoid exponentially increasing costs and timelines, it’s desirable to be able to reuse as much code as possible. Therefore we’re going to continue exploring the cross-platform path using JavaScript to compile to native code (React Native/NativeScript).

From web to mobile and back again

Since we’ll be building our app using web technologies, do we expect our code to render in a browser? Well… no. At least not directly.

React Native components compile to native Android and iOS components, not to DOM elements. But worry not, someone thought about this already. React Native for Web unifies both worlds, bringing web rendering to React Native components.

Now we can reuse our UI for mobile and web. However, this might not be what we are trying to achieve. After all, mobile and web are different platforms and often we want to take advantage of this to offer different user experiences. React Native for web doesn’t allow us to do this.

NativeScript and Angular make it possible to use the same codebase to build both web and mobile apps, reusing the core business logic, while being flexible enough to include platform-specific code where necessary, by using a simple file name convention.

Code sharing with NativeScript

Going “serverless”

So far we’ve discussed the technology stack for our app from the client(s) perspective. What about the backend? Again, it depends on what you’re building. You might already have a backend with an API deployed somewhere or you might need to build it from scratch.

The example to-do app we aim to build will require a database and user authentication (plus hosting for the web version). Let’s assume we want to continue using JavaScript. One of the options would be building a backend based on Node.js®. But we might not need a fully fledged backend.

An alternative would be using a platform that provides us with the services we need, like Firebase. Using Firebase makes it easy for our app(s) to benefit from a scalable infrastructure and cloud services like:

Firestore: cloud-hosted NoSQL database with live synchronization and offline support.
Authentication: multiple methods including email and password, third-party providers, etc.
Hosting: for web assets including global CDN and free SSL certificate.
Cloud Functions: custom backend code without needing to manage and scale your own servers.
And lots more…

Firebase services

Firebase seems to offer all we need for our to-do list app but, again, it might not be the right option for your app. The aim of these types of “serverless” cloud platforms (they actually run on servers, by the way) is accelerating apps and web development by removing the need to write backend code (most of the time) or manage server infrastructure.

Cloud Firestore, for example, is a cloud-hosted NoSQL database that can be accessed directly via native client SDKs. This raises, at least, an immediate concern. If the client can access the data directly, does this mean access control is non-existent? Not exactly. Firebase offers Security Rules based on user identity to secure the data for mobile/web development. These rules might not be sufficient for your use case but this doesn’t stop you from accessing the Firestore from a server (e.g. through a Cloud Function) using the Admin SDK. This way you could even build your own API on top.

The rise of voice assistants

Smart speakers and voice assistants have become ubiquitous and your app could benefit from them. If you think this is the case and some of your app features could be triggered by voice commands, then you should consider one of these assistants as an additional client. But, which one?

Amazon Alexa and Google Assistant are the two most popular options here and their functionality can be extended via Alexa Skills and Google Actions, respectively. Both assistants are now built-in in an increasing number of first and third-party smart speakers, and are available as Android and iOS apps. Although Alexa is ahead in number of skills, some people would argue that the Google Assistant is more accurate, feels more fluid and natural in conversation and provides a better integration with the host platform.

Assuming we want to integrate our app with the Google Assistant, we would need three things:

An Actions on Google project: This will allow you to access the developer console to manage and distribute your Action.
A Dialogflow Agent: This will contain all the Intents that define your Action. Intents are used to categorise a user’s intentions. They have Training Phrases, which are examples of what a user might say to your agent. For instance: “Read my to-do list” or “Add ‘Buy broccoli’ to my to-do list”.
A Fulfillment: This will receive requests from the Assistant, process the request and respond.

The fulfillment can be implemented using the Actions SDK with the Node.js® or the Java/Kotlin client library. If we use Node.js®, the fulfillment can then be deployed to a Cloud Function using Cloud Functions for Firebase. In order to integrate our Google Action with the rest of our ecosystem we will need this function to access our Firestore. This is possible thanks to the Firebase Admin SDK, as explained in the previous section.

In the second part of this article we will use the technology stack described here to build a simple proof of concept cross platform to-do list app, integrated with the Google Assistant.

Building cross-platform apps for mobile, web and voice (part II)

Ismael González Trujillo ・ Dec 8 '19 ・ 9 min read

#javascript #nativescript #firebase #googleassistant