DEV Community: Etinosa Obaseki

The Opportunity Cost of Non-functional Requirements

Etinosa Obaseki — Thu, 11 Jun 2020 07:37:00 +0000

Requirements Engineering

In Software Engineering, requirements are descriptions of what the system should do and how it should behave. Requirements also specify the constraints the system will operate under.

The process of Requirements Engineering is extremely important and often sets the tone for the rest of the Software Development Lifecycle regardless of the development model (Waterfall, Agile, etc.) in use.

Requirements are divided into:

Functional Requirements which are concerned with what the system should do.
Non-functional Requirements are concerned with how the system should be.

Non-functional Requirements (also called quality attributes) are the major concern of Software Architecture.

Opportunity Cost of Quality Attributes

Most quality attributes in building information systems have a triangular relationship where as you lean towards any two, you forgo more of the third.

Consider an example with regards to cybersecurity and performance in in these systems. You can have:

Security
Performance
Usability

Caching will improve performance and usability, but will introduce vectors for attack thus, compromising security.

Of course, there are patterns and techniques that invalidate cycles like these, but it helps to be aware of them.

You can have Personalization, apps, recommendations tailored to your taste and Portability, these preferences migrate with you as you move from one medium or device to another but Privacy will need to take a hit.

As we've said, there are ways to escape the cycle depending on how much we're willing to re-architecture.

For example, with these 3 P's, if the user had their own, self hosted service for managing Preferences and they could take that with them to other Platforms, then that would take care of the Privacy concern, since no third party would need to be involved.

References and Further Reading

Wikipedia: Non-functional requirement https://en.wikipedia.org/wiki/Non-functional_requirement
Software Engineering 9th Edition by Ian Sommerville: https://www.pearson.com/us/higher-education/product/Sommerville-Software-Engineering-9th-Edition/9780137035151.html

Deep Dive into The Laravel Artisan file

Etinosa Obaseki — Wed, 03 Jun 2020 19:33:26 +0000

Introduction

The popular PHP framework, Laravel comes with a CLI tool, artisan that offers a lot of the functionality that makes the framework so useful.

From preinstalled system commands like $ php artisan migrate to any custom commands you write, you've used artisan.

In this article, we'll explore every line of the artisan file and figure out what they do and how it's all tied together.

The artisan File

#!/usr/bin/env php
<?php
 
define('LARAVEL_START', microtime(true));
 
/*
|--------------------------------------------------------------------------
| Register The Auto Loader
|--------------------------------------------------------------------------
|
| Composer provides a convenient, automatically generated class loader
| for our application. We just need to utilize it! We'll require it
| into the script here so that we do not have to worry about the
| loading of any our classes "manually". Feels great to relax.
|
*/
 
require __DIR__.'/vendor/autoload.php';
 
$app = require_once __DIR__.'/bootstrap/app.php';
 
/*
|--------------------------------------------------------------------------
| Run The Artisan Application
|--------------------------------------------------------------------------
|
| When we run the console application, the current CLI command will be
| executed in this console and the response sent back to a terminal
| or another output device for the developers. Here goes nothing!
|
*/
 
$kernel = $app->make(Illuminate\Contracts\Console\Kernel::class);
 
$status = $kernel->handle(
    $input = new Symfony\Component\Console\Input\ArgvInput,
    new Symfony\Component\Console\Output\ConsoleOutput
);
 
/*
|--------------------------------------------------------------------------
| Shutdown The Application
|--------------------------------------------------------------------------
|
| Once Artisan has finished running, we will fire off the shutdown events
| so that any final work may be done by the application before we shut
| down the process. This is the last thing to happen to the request.
|
*/
 
$kernel->terminate($input, $status);
 
exit($status);

Line by Line Analysis

Line 1

#!/usr/bin/env php

This line is something called a shebang. A shebang tells the command line where to look for the interpreter for a particular script.

For example, when writing bash scripts it is common to see a shebang such as #!/bin/bash at the top which points to the bash shell that will execute the script.

The shebang in this bash example uses an absolute path to the bash executable while the one from the artisan file uses a logical path. This UNIX Stack Exchange Question features some interesting views on the subject.

It only works on UNIX-like systems, so Mac OS X or Linux but not Windows (although, if you use git bash it should work).

In the artisan case, our shebang uses the env command to find the first php executable in the user's path, wherever it may be.

Shebangs mostly allow you run scripts in the command line without first calling the interpreter. For example, running artisan commands without prepending php to it.

You can set this up by first making the artisan script executable via chmod +x artisan and then running ./artisan <your-command>

Take note of the dot in front of the artisan. That tells the shell that you want to run that as a command.

The next line is just a regular opening php tag, so we'll skip ahead to line 4.

Line 4

define('LARAVEL_START', microtime(true));

This line creates a PHP constant LARAVEL_START and assigns it the value of microtime(true)

According to the PHP Documentation, "microtime() returns the current Unix timestamp with microseconds.". It returns a string value by default, but passing the optional $get_as_float parameter as true returns a float instead.

So, where does this get used in the framework and what is it for? Well, I ran a quick search on the laravel/framework repo and didn't find any references to the constant.

My best guess, is that it's used to test how fast the framework starts up or serves request. You can compare the LARAVEL_START value to the value of microtime(true) when your request is completed.

I found this Stack Overflow question and answer that seems to support my guess. Although, it's asking about the variable in index.php (the application entrypoint for web requests just as artisan is the entrypoint for console "requests").

The next few lines we'll look at feature the first docblock in the artisan file.

Lines 6 - 16

/*

|--------------------------------------------------------------------------

| Register The Auto Loader

|--------------------------------------------------------------------------

|

| Composer provides a convenient, automatically generated class loader

| for our application. We just need to utilize it! We'll require it

| into the script here so that we do not have to worry about the

| loading of any our classes "manually". Feels great to relax.

|

*/

Here we have a docblock describing the composer-provided autoloader and why Laravel uses it.

A fun fact about Taylor Otwell and Laravel's docblock is that (for multiline comments) each line is exactly 3 characters less than the preceding. Go ahead and check for yourself here!

And, interestingly, according to this tweet, he did them by hand.

https://twitter.com/taylorotwell/status/563929477265121280

The next line we'll consider focuses on including the autoloader.

Line 18

require __DIR__.'/vendor/autoload.php';

This require directive loads in the autoload.php file that is included in the vendor directory after successfully running $ composer install

To learn more about how Composer works especially in the context of Laravel I would recommend this excellent article by Alan Storm on the subject.

Next, we'll turn our attention to Line 20

Line 20

$app = require_once __DIR__.'/bootstrap/app.php';

This line creates and initializes the $app variable with the contents of /bootstrap/app.php

app.php initializes a new instance of the Laravel application which is basically the IoC container and returns that value from the script.

Thus, the $app variable contains an instance of our Laravel application and we can basically load and use any parts of the application we want.

For example, using the make() method to resolve a class' dependencies and create an instance of it.

This is exactly the same as what we can do with the app() helper method that we use within our code.

Next, more comment shenanigans!

Lines 22 - 31

/*

|--------------------------------------------------------------------------

| Run The Artisan Application

|--------------------------------------------------------------------------

|

| When we run the console application, the current CLI command will be

| executed in this console and the response sent back to a terminal

| or another output device for the developers. Here goes nothing!

|

*/

Here we have another docblock. Once again, with each line 3 characters less than the preceding.

Doing something like this, especially if it's by hand, would have to be difficult.

I remember watching an episode on Laracasts where Jeffrey Way says it's just another example of how much care and detail Taylor Orwell puts into the framework. I'm inclined to agree.

This block talks about the app lifecycle from the console command to output along with a cheeky "here goes nothing!".

Next we'll use the $app variable from above on Line 33.

Line 33

$kernel = $app->make(Illuminate\Contracts\Console\Kernel::class);

So, here we initialize another variable, $kernel, using the app container to resolve Kernel class via the make() method.

Of course, it's not a concrete class we are passing into the make() method but an interface. This is a great example of the SOLID principles at work in Laravel, particularly the Liskov Substitution Principle and Dependency Inversion.

It allows us to easily switch out the concrete kernel class that is called if we need to by simply changing the binding of the interface to the concrete class.

Typically, within our own application code, we will register such bindings within a service provider class as recommended by the Laravel Documentation on the matter, but in the artisan file, such a binding would happen too late.

So, instead the binding is done within the /bootstrap/app.php. This file binds the different Kernels for console (which is used by artisan) and web as well as the Exception Handler.

$app->singleton(

    Illuminate\Contracts\Http\Kernel::class,

    App\Http\Kernel::class

);

 

$app->singleton(

    Illuminate\Contracts\Console\Kernel::class,

    App\Console\Kernel::class

);

 

$app->singleton(

    Illuminate\Contracts\Debug\ExceptionHandler::class,

    App\Exceptions\Handler::class

);

As we see from the above, the Kernel contract resolves to App\Console\Kernel.

With the instance of Kernel loaded into the variable, we are now set to run the actual artisan command.

The next few lines we'll consider handle this.

Lines 35-38

$status = $kernel->handle(

    $input = new Symfony\Component\Console\Input\ArgvInput,

    new Symfony\Component\Console\Output\ConsoleOutput

);

Here we assign the output of the $kernel->handle() method into the $status variable.

If we visit the App\Console\Kernel class, we'll find that it inherits from Illuminate\Foundation\Console\Kernel which is where the handle() method resides.

The method takes two arguments - $input and $output - runs some bootstrapping to load the providers and other required services before creating an instance of the artisan application and calling it's run($input, $output) method.

The method returns the status code of the action and it is this value that eventually gets passed into our $status variable in the artisan file.

The input and output variables we passed to the run() method must be instances of Symfony\Component\Console\Input\InputInterface & Symfony\Component\Console\Output\OutputInterface respectively. This is another example of the two SOLID principles we mentioned earlier. Being able to easily switch out the concrete implementations makes it easier for us to use a different input and output for testing purposes or if our application needs are different.

Up next, we encounter another docblock.

Lines 40 - 49

/*

|--------------------------------------------------------------------------

| Shutdown The Application

|--------------------------------------------------------------------------

|

| Once Artisan has finished running, we will fire off the shutdown events

| so that any final work may be done by the application before we shut

| down the process. This is the last thing to happen to the request.

|

*/

You know the drill by know. Another docblock that leaves me wondering how much time must have gone into phrasing the sentences.

This one talks about the shutdown process for the command.

Line 51

$kernel->terminate($input, $status);

To begin the shutdown process, we make a call to the terminate() method on the $kernel instance. Once again, this method is defined on Illuminate\Foundation\Console\Kernel and simply calls the terminate() method on the app instance.

The terminate() method takes in two arguments but appears to do nothing with them.

And now, the final line.

Line 53

exit($status);

According to the PHP Docs, this method terminates the execution of a script. It goes on to say the following about the optional $status argument:

If status is a string, this function prints the status just before exiting.

"If status is an integer, that value will be used as the exit status and not printed. Exit statuses should be in the range 0 to 254, the exit status 255 is reserved by PHP and shall not be used. The status 0 is used to terminate the program successfully."

Conclusion

In exploring the artisan file, I have regained an appreciation for Laravel's architecture.

The entrypoint for web requests (index.php) will feature many of the same structures and ideas.

Gitpodifying a new Laravel Application

Etinosa Obaseki — Tue, 26 May 2020 16:41:39 +0000

Introduction

Gitpod is a SaaS platform that offers Ready-To-Code dev environments. What this means is that GitPod allows you describe your Development Environment as code and easily provision or share it.

This is great for letting people quickly try out a new library or framework and even for day to day development.

This article from the GitPod blog is a great explanation for the problem GitPod solves as well as a fantastic general purpose guide.

Here, we'll extend on that specifically for the Laravel framework and see how to create a Ready-To-Code environment for our projects.

Getting Started

The first step is to navigate to the GitHub repository you'd like to set up.

For this example, I'll use a Laravel project we're building at WTXtra.

The GitHub repository is publicly available at https://github.com/WeTalkSound/trivyeah-core/.

Next, we'll just edit this URL slightly to launch a Gitpod workspace for this repo.

We'll add "gitpod.io/#" in front of the repo URL and hit enter. For the example above, that'll be https://gitpod.io/#https://github.com/WeTalkSound/trivyeah-core/

For first time Gitpod users, you'll be asked to sign in with GitHub and authorize the application.

When we go to this URL, Gitpod begins building our workspace and you'll see the splash screen.

To determine how to set up the environment, Gitpod follows the instructions in a .gitpod.yml file. If this file does not exist, then it approximates an environment based on your repo.

Set up .gitpod.yml

The gitpod.yml file specifies the commands that the environment should run on build as well as the Dockerfile to use to build the container. Adding a custom Dockerfile is optional, but potentially offers us more control over the environment we end up with.

So, we'll create a simple .gitpod.yml file with the following:

image:
  file: .gitpod.Dockerfile

And right next to it, create a .gitpod.Dockerfile like so:

FROM gitpod/workspace-mysql               

USER gitpod

This uses the gitpod/workspace-mysql as the base image. This image installs and configures MySQL with a root user with no password.

This works to get you an environment with (almost) everything you need, but there is still some basic housekeeping most Laravel apps will need to take care of.

Setting up a Database

On the first run of our environment, we'll need to create the database our app will use.

If you're familiar with docker, you can easily do this from within your custom Dockerfile. However, I prefer to do it from the .gitpod.yml file.

Within the Gitpod configuration file, we can specify any number of tasks to be run. We can specify tasks to be run only the first time a container is being provisioned or we can specify that it be run even time the container starts.

image:
  file: .gitpod.Dockerfile
tasks:
  - init: mysql -u root -e "create database trivyeah"

We'll modify our .gitpod.yml file and add the tasks section to it. It specifies that on init, we'll run the command mysql -u root -e "create database trivyeah" which will log into MySQL as root (with no password) and execute the command specified by the e flag, in this case, creating a database called trivyeah.

Creating a .env file

We'll use the .env.example file provided by default with new Laravel installations. In here, we'll specify all the keys that need to be used by the application, including the database name we created above.

...
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=trivyeah
DB_USERNAME=root
DB_PASSWORD=
...

Any other default information we'll need to provision our app can be added to the env.example file.

Next, we will copy the .env.example file to the .env file

image:
  file: .gitpod.Dockerfile
tasks:
  - init: mysql -u root -e "create database trivyeah" && cp .env.example .env

We'll add this to the init command, since we only want it to copy for the first run of the container.

Installing Dependencies

This is another action we will need to perform on initialization of the environment. We'll run the composer and npm (or yarn, if you prefer) commands in the init action as well.

image:
  file: .gitpod.Dockerfile
tasks:
  - init: mysql -u root -e "create database trivyeah" && cp .env.example .env && composer install && npm install

At this point, we can begin using artisan commands for any other application specific setup we need to.

For example, we'll need to generate a unique application key for our .env

Generate Application Key

In a new Laravel application, we'll need to run the php artisan key:generate command to fill the APP_KEY field in the .env file.

However, it's a command we'll only need to run the first time. So, we'll add it to the init field of our configuration again.

image:
  file: .gitpod.Dockerfile
tasks:
  - init: mysql -u root -e "create database trivyeah" && cp .env.example .env && composer install && npm install && php artisan key:generate

At this point, all the set up should be done. If you have any other setup specific to your Laravel app, they can be added here as well.

The init entry is getting unwieldy and so we'll refactor it as soon as we're done with everything else.

The next thing to do is run migrations before we serve the app.

Run Migrations

For migrations, I prefer to run them each time I use the container, in case there has been a change.

I also run the seeders at this point to populate the database with any required data or test data.

Since I want the command to always run, I'll add it to a command entry on the .gitpod.yml file.

image:
  file: .gitpod.Dockerfile
tasks:
  - init: mysql -u root -e "create database trivyeah" && cp .env.example .env && composer install && npm install && php artisan key:generate
    command: php artisan migrate --seed

Apart from running each time we run our environment, command task entries have another key differences from init tasks.

An init task expects to end. Long running processes such as running a development server or continuously compiling assets are not suited for init tasks. Command tasks on the other hand can run for as long as the environment is running and are suited to such tasks above.

Run Development Server

We can run the development server on Gitpod as well. We'll want to run it after migrations are done.

image:
  file: .gitpod.Dockerfile
tasks:
  - init: mysql -u root -e "create database trivyeah" && cp .env.example .env && composer install && npm install && php artisan key:generate
    command: php artisan migrate --seed && php artisan serve

Running and exposing a service on Gitpod creates a publicly accessible URL, similar to ngrok, of the form <PORT>-<GITPOD-CONTAINER-ID>. gitpod.io

There's a small problem with our current setup though. Laravel uses the value of $_SERVER['HTTP'] to generate URLs and Routes. This value will be set to localhost:8000 and not to the correct Gitpod URL.

To work around this, we'll set our APP_URL in .env to our Gitpod URL and then instruct Laravel to use that value to generate URLs and Routes.

We'll update our .env.example to the following:

APP_NAME="Your App Name"
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_URL=
...

Gitpod loads some environment variables. You can run env on the terminal to see all environment variables.

One of them is GITPOD_WORKSPACE_URL which is the same as the one in your browser when you launch a workspace. We'll need to write the variable into our .env file.

We'll use the bash utility sed for this. Essentially, we'll do two replacements. One to put in the workspace URL and another to add the port number in front.

 sed -i "s|APP_URL=|APP_URL=${GITPOD_WORKSPACE_URL}|g" .env && sed -i "s|APP_URL=https://|APP_URL=https://8000-|g" .env

The first pass replaces "APP_URL=" with "APP_URL=https://<your-workspace-id>.gitpod.io" and the second pass replaces "APP_URL=https://" with "APP_URL=https://8000-"

We'll now add this to our init entry in .gitpod.yml so that it happens right after our .env file is created.

image:
  file: .gitpod.Dockerfile
tasks:
  - init: mysql -u root -e "create database trivyeah" && cp .env.example .env && sed -i "s|APP_URL=|APP_URL=${GITPOD_WORKSPACE_URL}|g" .env && sed -i "s|APP_URL=https://|APP_URL=https://8000-|g" .env && composer install && npm install && php artisan key:generate
    command: php artisan migrate --seed && php artisan serve

That init hook has gotten quite unwieldy and we'll address it shortly. In the interim, we'll need to add some code in our AppServiceProvider to force Laravel to use our APP_URL to generate URLs and Routes.

 public function boot()
    {
        \URL::forceRootUrl(\Config::get('app.url'));
        if (\Str::contains(\Config::get('app.url'), 'https://')) {
            \URL::forceScheme('https');
        }
    }

The code we've added forces Laravel to use the app.url config entry (which is gotten from .env's APP_URL) as the root URL.

Warning: If you use an older version of Laravel the \Str::contains() method won't work and you'll have to use the string helper str_contains() instead.

Cleaning Up .gitpod.yml

The init entry in our Gitpod configuration file is messy. We can move all that to a bash script so that it's more readable.

Let's create a .gitpod-init.sh file in the root of our project and copy everything in our init entry there.

mysql -u root -e "create database trivyeah"
cp .env.example .env
sed -i "s|APP_URL=|APP_URL=${GITPOD_WORKSPACE_URL}|g" .env
sed -i "s|APP_URL=https://|APP_URL=https://8000-|g" .env
composer install
npm i
php artisan key:generate

And finally, we'll update our .gitpod.yml to use this command

image:
  file: .gitpod.Dockerfile
tasks:
  - init: bash .gitpod-init.sh
    command: php artisan migrate --seed && php artisan serve

Careful with the filenames. Watch the “.” in front.

Everything should work now.

Running our environment

At this point, we can push to our repository and run the environment. If you already had a workspace for this repo and branch, you can delete it by going to https://gitpod.io/workspaces.

Now we can create and test a new workspace by going to "gitpod.io/#https://github.com/<org-name>/<repo-name>" as we described at the beginning of the article.

If everything works as it should, we can add a badge to the Readme.md that can be clicked to launch the workspace.

[![Gitpod Ready-to-Code](https://img.shields.io/badge/Gitpod-Ready--to--Code-blue?logo=gitpod)](https://gitpod.io/#https://github.com/<org-name>/<repo-name>)

Our Laravel project is now Gitpod enabled and can deploy ready-to-code environments in one click.

Many thanks to Gabriel Nwogu for testing this out and suggesting changes.

5 Tools that add color to my Web Apps

Etinosa Obaseki — Thu, 21 May 2020 11:54:48 +0000

I'm bad with colors. It's one of those facts of Life, sorta how the sky is blue or pigs don't fly. It's one of my greatest artistic weakness (along with my inability to draw straight lines).

However, humans are not the dominant species on the planet because of their ability or lack thereof, but because of their development and use of tools.

So, in the spirit of the human spirit (🤫) of overcoming our inherent limitations, here are the tools I use to improve my color grade.

1. Coolors.co

Coolors is a great tool for generating cool looking and complementary color schemes.

Coolors.co Interface

It allows you ‘lock’ a color (or several) and then generate other colors that would go well with it or alternatively, generate your entire palette from scratch.

It also has a really cool feature for extracting color palettes from images.

Check it out here.

2. Material.io Color Tool

Material Design isn't the dad it was a few years ago, but it remains hugely relevant as an approach to designing modern interfaces.

The Color Tool from Material.io allows you select a primary and secondary color and then let's you preview how these will look on different material design inspired layouts.

The Color Tool from Material.io

The tool also provided tips on readability based on the color scheme you've selected.

Link here.

3. Material Palette

Material Palette is another Material Design oriented tool. This one is a bit more interesting than the former in that it actively alters the colors you pick to make them fit better.

Material Palette's generator.

After you pick two colors, it generates a palette of eight colors along with recommendations on how and where they should be used.

Link.

4. uiGradients

UIGradients provides a wide range of premade gradient backgrounds and allows you either download as an image or get the CSS rules to create the gradient in your app.

uiGradient's selection

Gradients are great alternative to solid color backgrounds, although you'll need to be careful to ensure that your app maintains it's readability.

Check it out.

5. Subtle Patterns by TopTal

Sometimes, I want to break the monotony of solid color backgrounds with getting anything too extravagant.

Subtle Patterns are great for that. The repository of several background images is maintained by TopTal and has found plenty of use in many of my projects.

Toptal's Subtle Patterns

The site allows you search for patterns and offers a live preview of each background.

Convinced? Give it a try.

Do you have different tools that you use to help with color/design issues in your web apps? I'd love to hear about them. I need all the help I can get. 😅.

Hit me up on Twitter! @obasekietinosa

Running Scheduled Firebase Functions Locally

Etinosa Obaseki — Tue, 19 May 2020 22:58:09 +0000

TL;DR Use $ firebase functions:shell and then type in the name of your function (tab autocomplete is available) along with any arguments you need to pass and press enter. You receive the output to the console.

While developing Firebase Functions, we need to run them locally to ensure that everything works as we might expect before we deploy the function to the cloud.

For HTTP Functions, it's a straightforward process to run $ firebase serve in the terminal and then visit the browser.

Firebase Scheduled Functions can have one of several triggers (similar to HTTP Functions that are triggered by a HTTP Request).

The problem is that we often cannot set up the trigger for Scheduled Functions the way we can for HTTP Functions.

For example, with the PubSub triggers it would be impractical to try to set up a pubslisher-subscribe system on our local environments and test that our functions run every minute as prescribed.

We'll instead leave that to the Firebase team. Instead, we want to test that our functions executes as it should.

Use $ firebase functions:shell and then type in the name of your function (tab autocomplete is available) along with any arguments you need to pass and press enter. You receive the output to the console.

If vs Ternary vs Switch-Case for conditionals

Etinosa Obaseki — Tue, 12 May 2020 19:46:48 +0000

Conditionals are programming structures that determine the flow of the program based on an evaluation.

In most C-style languages, such as JavaScript, there are multiple ways of handling conditional logic.

In this article, I'll discuss the if-else, ternary operator, ? and switch-case and how I decide which to use for different situations.

Whenever I write code that will need to be maintained either by myself or someone else, I like to consider the developer experience of that code.

Will I (or the eventual maintained) easily be able to grasp the purpose of the code? Am I likely to misunderstand what the code actually does? Does the code significantly deviate from expected affordance?

If-Else vs Ternary

let isEvenOrOdd = number => {
    if(number % 2 == 0){
        return "Is Even"
    }
    else {
        return "Is Odd"
    }
}

For scenarios with this-or-that (only two possible) outcomes, I prefer to use a ternary because it's less code for the maintainer to parse. In a large project, those could be a lot of lines saved.

let isEvenOrOdd = number => {
    return number % 2 == 0 ? 
        "Is Even" : "Is Odd"
}

However, for more complex conditionals we may need else ifs

For example, a conditional with three possible options.

let meal = null
if(time == "morning") {
    meal = "breakfast"
} else if(time == "afternoon") {
    meal = "lunch"
} else {
    meal = "dinner"
}

We could handle this case with a ternary operator(s) as well.

let meal = null
time == "morning" ?
    meal = "breakfast"
    :
    time == "afternoon" ?
        meal = "lunch"
        :
        meal = "dinner"

Of course, despite looking fancier than ordinary If-Elses, this is probably less readable than the previous example.

Let's switch this up a bit.

Switch Statements

Switch Statements allow us to evaluate several cases against a single expression.

Our meal example from above would be represented thus:

let meal = null
switch(time) {
    case "morning":
        meal = "breakfast"
        break
    case "afternoon":
        meal = "lunch"
        break
    default:
        meal = "dinner"
}

Conclusion

Switch statements are versatile and could provide a more readable alternative to If-Elses and ternary operators.

The Pain of Multimedia in HTML Emails

Etinosa Obaseki — Wed, 06 May 2020 07:47:18 +0000

I gave a talk at Frontstack this year and it was an amazing experience. I'm sharing the essence of my talk here ICYMI and also because I write better than I speak sometimes, so you might enjoy this more.

I'll start off with a quick introduction. I'm Etin Obaseki, Software Engineer whose current life motto is Life, Learn, Loop.

Multimedia across the web has come in leaps and bounds. We can now easily use various forms of media all across the web almost ubiquitously. Videos, audio, animation. All sorts of wonderful things.

What about emails? Emails are notoriously hard to make look good for a number of reasons. Multimedia is a definite no. Or is it?

What can we do right now? What will the email of the future look like? Let’s find out.

The Introduction

We've all sent emails. Whether it's to let friends and family know how you're doing or to express your 'slight confusion' to a colleague at work or to rail at the customer service unit of your bank for yet another unexplained debit.

The emails we'll be discussing today though are more the kind sent out by brands to their audience. Whether it's a newsletter or a service notification, we'll be discussing if and how we can spruce up that email with multimedia.

If you've ever designed and sent out HTML emails, you'll know just how terrible they can be to write and test.

Thankfully, there are more and more tools that make this process a breeze and I share some of my favourite here.

My First Foray into Emails

At my first job, I had to build and send our newsletter. My boss had a couple of requirements for the newsletter including:

A two column layout
News articles and featured images on each column
Videos from YouTube
A Twitter Feed

I wrote an entire article on the lesson in humility that this was.

But, in summary, my first few attempts turned out poorly.

I had not written a HTML email before that, but I figured it would be easy because I had built one or two websites.

It wasn't and I learnt the first two lessons of my career:

Don't overestimate yourself (although, sadly, it hasn't stuck as much as I would have liked.) and
Email != Web

Email != Web

Although, nowadays, we get our emails over the web, they are different platforms.

Email clients and web browsers evolved very different and as such there are wide variations on the things they can do and how they go about doing those things.

What can’t we do with Emails?

I've outlined some of the most jarring not-haves I have encountered while building emails.

No JavaScript

Most email clients will, for security reasons, not run any JavaScript at all in your email. So you absolutely cannot rely on any JS tricks for anything in your email.

Embed iFrames

One of the requirements for my first email was embedding a “featured video” from our YouTube channel within the email.

iFrames will be blocked by most email clients as they'll usually contain scripts and could pose a security flaw.

Use HTML5 tags/features

Because most email clients haven't kept up with the times HTML 5 tags and features will not work here.

Use flexbox, CSS grid or even floats for layout

Emails use tables for their layouts. No flexbox, no grid. Not even those clever hacks with floats and clearfixes. If you want layouts use tables.

Embed audio or video content

No MULTIMEDIA support!!!

Although multimedia support is non-existent on email, it does support most picture formats quite well and it is one of these that will end up saving everything. The GIF.

GIF Things Up!

GIFs are a great way to add interactivity to our emails.

Similar to the ways we use them on social media, we can add a lot of meaning and context to our emails by creatively applying GIFs.

It is important to note that images may not always load on an email and so we must design conscious of this point of failure and degrade gracefully in instances where images are not available.

Here are a few clever GIF uses in emails I've seen or thought up.

A Countdown Timer

I first saw this done on a marketing email encouraging me to buy at a discounted price before the deadline. And there was a countdown timer right in the email.

A countdown timer GIF

The trick is to have a GIF that counts down for long enough for your users to read your email, say 60 seconds and then update that GIF each time.

This StackOverflow answer, also the source of the GIF above, does a great job of explaining the implementation. Alternatively, you could use a service like Cloudinary to create a GIF that continuously updates its countdown time.

Signature/Text Animation

What better way to close off your email than with a personal touch?

A GIF of you signing your name would be very cool (I, at least, would find it very much so).

You could also use it to call attention to your headings.

Yes. This text shaking in different colors is pretty cool. Made with Loading.io

Animated/Specially Shaped Buttons

We can make our call-to-actions more appealing by adding animations to them. CSS animations might not work on your email client though and so once more GIFs come to our rescue.

An Enter Button. https://www.animatedimages.org/img-animated-button-image-0328-88732.htm

We simply create a GIF that looks like the button we want and wrap the image in an <a></a> tag.

Video Previews

Another potential use case for GIF is to preview videos. We could put a short clip as a GIF and allow people link to the full video by clicking.

Hakuna Matata. GIF from Disney's The Lion King

Unfortunately, there's no way to include audio that I know of.

Conclusion

I hope that this gives you some ideas for your next email. If you come up with something cool, I'd love to see it. Hit me up on Twitter and share!

Database Operations on the Firebase Realtime Database using the JS SDK

Etinosa Obaseki — Tue, 28 Apr 2020 16:07:15 +0000

Google’s Firebase allows us the ability to run our backend infrastructure without actually managing said infrastructure.

Some of the services Firebase offers include Cloud Functions for running backend code, Authentication and Databases

There are two database offerings in the Firebase console: The real-time database and the cloud database. This article is focused on basic operations on the real time database.

The Realtime Database

The Firebase Realtime Database is a managed NoSQL database service. As with other Firebase services, we do not need to worry about managing the underlying infrastructure or resources.

Being a NoSQL database, the data is not stored in a relational (tabular) form but instead uses a document model in JSON format. Data is stored in key-value pairs.

The Realtime Database showing the root node and children nodes
This same data represented in JSON would be as shown below:

{

  "games" : {

      "-M5GU2j383E8MaXXbLT3" : {

      "current_quesion" : 0,

      "latest_tweet" : "1251784979954241536",

      "start_tweet" : "1251784906830733315",

      "users" : {

        "AnxiousEtin" : 0,

        "ObasekiEtinosa" : 0,

        "tetrazoid" : 0

      }

    }

  }

}

The root node (trivyeah-twitter-client) contains the child node games which holds -M5GU2j383E8MaXXbLT3 as a child. That node has several nodes with concrete values (such as current_question with 0) but also contains a node users with children of its own.

References and Paths

Interaction with the database is done via references. A reference is a pointer to a particular node on the database. This reference will allow use access the data stored on that node, it’s children and perform operations on the node.

Using the firebase-admin package, we’ll get a reference to the DB.

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var db = firebaseAdmin.database().ref()

db now holds a reference to the root, in the above example trivyeah-twitter-client, of our database and we can perform any operations on it.

If we instead wanted a reference to some other node on the document, we would pass a path to the desired node to the ref() method.

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var gameDb = firebaseAdmin.database().ref('games')

The above code would give us a reference to the games node. To get a more deeply nested node pass the path separated by slashes e.g ref('games/-M5GU2j383E8MaXXbLT3/users')

We can also achieve this by using the child() method on any database reference. By passing in a path to any child node we want, we can get a reference to that node.

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var gameDb = firebaseAdmin.database().ref('games')

var childNodeUsersDb = gameDb.child('games/-M5GU2j383E8MaXXbLT3/users')

Database Operations

The four basic functions of persistent storage are Create, Read, Update and Delete. Let’s look at each of these operations on the Firebase Realtime Database.

Create Operations

Create operations persistent a new record to storage. In the Realtime Database the set method is the basic write operation. There are two different ways of using it and will be shown here.

(Over)Writing to a Path

Using the set method will write data to the location specified, if there was any data at that location, it will be overwritten.

It takes any JavaScript value as its first argument and this value will be persisted. From the official documentation, “You can pass set a string, number, boolean, null, array or any JSON object.“

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var foodDb = firebaseAdmin.database().ref('breakfast')

foodDb.set({
    cereal: {
        calories: 3,
        price: 50,
        comment: "Great for when you're in a hurry"
    }
    fufu: {
        calories: 12,
        price: 10,
        comment: "Cheap, but long lasting. Really long"
    }
})

This example above sets everything at the breakfast node to the object we passed in. Anything that may have been there before is overwritten.

Adding Data to a Node

To add data to a node that already contains data without overwriting the data already on the node, we use the push() method. It returns a reference to a newly created child node on the originally referenced node.

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var mealsDb = firebaseAdmin.database().ref('meals')

let newMeal = mealDb.push() //newMeal will hold the reference to the new record and can be set without overwriting it's siblings

newMeal.key 
//returns the key for the new record. Something like "-M5GU2j383E8MaXXbLT3"

We may then use the set() method on this new reference.

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var mealsDb = firebaseAdmin.database().ref('meals')

let newMeal = mealDb.push()

newMeal.set({
    timeOfDay: "morning",
    mealEaten: "fufu"
    stomachStatus: "bloated",
    caloriesGained: 30
})

If you don’t need the reference of the new node for any other operations, you can chain the push() and set() calls.

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var mealsDb = firebaseAdmin.database().ref('meals')

let newMeal = mealDb.push().set({
    timeOfDay: "morning",
    mealEaten: "fufu"
    stomachStatus: "bloated",
    caloriesGained: 30
})

Cases where you need to append to a node using your own key is considered an update action. Let’s look at what those are like.

Update Operations

Update operations append data to the reference specified without overwriting any other properties.

{

  "meals" : {
    "-K5GU2p242E8MaXHbQT1" : {
          timeOfDay: "morning",
          mealEaten: "fufu"
          stomachStatus: "bloated",
          caloriesGained: 30
      },
    "-K5GU2r322X8YadRZQT1" : {
          timeOfDay: "afternoon",
          mealEaten: "cornflakes"
          stomachStatus: "slightlyFull",
          caloriesGained: 2
      }
  }

}

Assuming we had the above in our database and we intend to add to the meals node without affecting any of its existing children, we would pass an object containing our desired key to the update() method.

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var mealsDb = firebaseAdmin.database().ref('meals')

let newMeal = mealDb.update({
    uniqueMealKey: {
        timeOfDay: "evening",
        mealEaten: "nightcap"
        stomachStatus: "light",
        caloriesGained: -4
    }
})

Read Operations

The JS SDK supports non-blocking reads and has several events that prompt a read. The on() method takes the event we want to listen to as the first argument and a callback where we can access a snapshot of the data as the second argument.

Note: The callback we pass to the on() method is fired every time our event takes place but if you only want to perform the read and the associated callback a single time then use the once() method instead. Both methods have identical signatures.

The events we can perform read on are:

“value”
“child_added”
“child_changed”
“child_removed”
“child_moved”

Sticking with our meals node, we can retrieve all the meals using the value event.

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var mealsDb = firebaseAdmin.database().ref('meals')

mealDb.once("value", function (snapshot) {
        let meals = snapshot.val()
    }
})

on()/once() is an asynchronous method and accepts a callback.

When the database call is complete, the callback is fired and passed a DataSnapshot instance. This object contains the state of the database at the moment that the event ("value" in this case) was fired. We can call the val() method on the snapshot to get a JavaScript object (or primitive value) representing the values of the node reference that the event was called on.

{
    "-K5GU2p242E8MaXHbQT1" : {
        timeOfDay: "morning",
        mealEaten: "fufu"
        stomachStatus: "bloated",
        caloriesGained: 30
    },
    "-K5GU2r322X8YadRZQT1" : {
        timeOfDay: "afternoon",
        mealEaten: "cornflakes"
        stomachStatus: "slightlyFull",
        caloriesGained: 2
    },
    "uniqueMealKey": {
        timeOfDay: "evening",
        mealEaten: "nightcap"
        stomachStatus: "light",
        caloriesGained: -4
    }
}

We would get the above JavaScript object in our meals variable and could then carry out what ever actions we wanted on it.

On the DataSnapshot instance, there are other methods available. You can view them in the documentation here.

Delete Operations

We have covered removing data from a node in passing earlier in the article. To delete a node, simply use the set() method on its reference to set it to null

const firebaseAdmin = require('firebase-admin')

firebaseAdmin.initializeApp();
var mealsDb = firebaseAdmin.database().ref('meals')

mealDb.child('uniqueMealKey').set(null)

Using the child() method to get a reference to the child node on meals we want to delete, we then call set() on that reference and pass it null. This will remove all the data on uniqueMealKey.

Conclusion

These are how the basic DB operations are performed on the Firebase Realtime Database using the Firebase JS SDK. The SDK is also available in Java, Go and Python. Although, the Go and Python SDKs perform blocking reads.

References

Firebase Database Admin Docs – https://firebase.google.com/docs/database/admin/start

My Year in Firebase: Experiences with Building & Deploying on the Platform

Etinosa Obaseki — Tue, 21 Apr 2020 18:28:53 +0000

I began using the Firebase platform last year along with a number of other technologies and it has been an interesting ride. I'm going to document my experience here.

Love At First Byte?😍

Firebase's landing page

My introduction to Firebase came when, in 2018, I got a gig to add Google Analytics to a web app (I charged quite a bit for that 😅). The front end was built in the Ionic Framework and hosted on Firebase Hosting while the back end was in Java and hosted elsewhere.

Thinking about it now, it was my earliest exposure to Distributed Client-Server Architecture on the web. All my prior experience had been with monoliths that served straight to the clients plate.

I was intrigued.

I ran git clone and set up Analytics on the project fairly quickly.

Time to deploy? Phew. Google to the rescue. The Firebase Docs were extremely helpful.

I'd need to install the Firebase CLI, firebase-tools using NPM:

$ npm install -g firebase-tools

And deploying?

$ firebase deploy

'I was in love!

Job done and I got paid!

But, how much does such a great service cost? Absolutely nothing!(With limits, of course 😒).

Marry me FiFi!

Did I get her number?☎️

Well, I didn't really think about Firebase much after that. Most of my work was still done in just PHP, so I didn't really have a use for it day-to-day.

This changed when in November 2018 I had to build a portfolio website for myself. That's quite an interesting story itself, but the two most relevant parts are that

I didn't have the money to pay for a domain and (shared) hosting like I usually would for my projects
I had just begun to learn React from a Wes Bos course

After building the portfolio website in good time, it was time to set up my project on Firebase.

Our First Date💑

To set up the project we'll need to head to the Firebase Console and create a new Project. A Firebase Project contains "Apps" which share Firebase resources like Authentication, Database, etcetera.

After setting up the project on the Console, the next thing to do is initialize Firebase in my portfolio website. We do this by running:

$ firebase init

A few on screen prompts later, where we select the project we want to work on and the Firebase feature we want to use and voila! We're ready to deploy.

Can you feel the fire?

We also need to specify whether it's a Single Page Application (in which case all requests will be redirected to index) and where our public folder is. In the case of my portofolio app it was the build directory.

Now, when we run the firebase deploy command from earlier, it'll copy the files from the public directory we specified and upload them to the Firebase cloud.

We are Live!!! 🎉

Once the deploy is successfully done, we get our own URL: https://your-app-name.firebaseapp.com (and more recently, you also get https://your-app-name.web.app).

That was smooth, wasn't it? Connecting to a custom domain is just as easy. Simply navigate to the Hosting tab from your Project page on the Firebase Console and click Connect Custom Domain.

The Console's sidebar

You'll need to already own a domain, of course, and be able to update it's DNS Records. The process varies across providers but generally you do the following:

Add a TXT Record provided in the Console to prove ownership of the domain.
Add an A record pointing to the Firebase Hosting's public IP
Add another A record pointing to another Firebase public IP for redundancy.

And in 0-48 Hours your domain should be provisioned along with a free SSL certificate.

What Else Can This Baby Do? 😉

So, that covers Hosting, which was far and away my most used Firebase service this year. But what other goodies does Firebase provide?

From the sidebar we can already see a lot of things, but my next favourite feature has to be Firebase Databases, specifically the Realtime Database. There's also Cloud Firestore, but I haven't used that yet.

The Firebase Realtime Database

The Realtime Database is a cloud NoSQL database implementation, which means it's similar to MongoDB. It stores data in an Object-Key format and can access several records very quickly.

My favourite thing about it? It comes with a REST API right out of the box! Define your data structure and you can access it RESTfully via https://your-app-name.firebase.io/node-name.json and do all the usual GETs, POSTs, PUTs & DELETEs.

It saved me the trouble of building a full back end for a few small projects I built in React.

I also had plenty of joy using Firebase functions to build a Twitter Bot.

Cloud Functions for Firebase

Firebase Functions allow you run server side code without infrastructure. Serverless, as the kids are calling it these days.

Inspired by the numerous bots built by Shalvah, it allowed me write a NodeJS function to search Twitter for tweets that were a quote by someone famous and upload that quote to the Firebase Database (remember that guy?).

Typically, I'd have to spin up a server and set up a cron job to fire that function at intervals, but with Cloud Functions I can create a PubSub function that runs on some event (in this case, every 15 minutes).

In Conclusion 👋

Firebase has become my first choice development platform. It's easy to use and incredibly versatile.

I'm building a SAAS Product in Q1 2020 and I'm attempting to convince my team that it's what we should use.

Wish me luck.