Forem: John Alcher

Automated Cloud: Web Hosting Basics

John Alcher — Sun, 24 Jan 2021 22:45:24 +0000

Introduction

This article covers the second part of the "Automated Cloud" series where we deploy a simple web page onto an EC2 instance and have it publicly available on the internet.

The Tasks

Account Basics
Web Hosting Basics (this article)
~~Auto Scaling~~
~~External Data~~
~~Web Hosting - PaaS + S3~~
~~Microservices~~
~~Serverless~~
~~Continous Delivery~~

Task #2 - Web Hosting Basics

The steps for this task is pretty straightforward:

Deploy an EC2 instance with a simple static "Coming Soon" page.
Make the process repeatable
Checkpoint: The HTML page served by the EC2 instances is publicly viewable.

Deploying a static page onto an EC2 instance

To start, I manually provisioned (using the AWS console) a t2.micro EC2 instance running Amazon Linux 2. I then attached two security group rules that: allow TCP connections on ports :22 and :80 to access the instance through SSH and HTTP, respectively.

Once I'm SSH'ed onto the machine, I installed [Nginx (https://www.nginx.com/) and configured a simple nginx.conf that serves a static page at the root. I have a spare domain wabby.xyz, so I thought I'd use that as the basis of the project. At this point, the web page is now publicly viewable by accessing the EC2 instance's public IP. What would the website do? Not really sure yet, lol. We'll see as I progress through the sections :)

Making it repeatable: EC2 User Scripts

As I was doing the steps above, I have a separate tab open for taking notes of the commands that I was running. Once I was able to access the EC2 instance with my browser and confirm that my index.html file is being served, I terminated it and re-created a new one, this time adding a User Data script containing the steps that I executed manually.

#!/bin/bash
# Update and install Nginx
yum update -y
amazon-linux-extras install -y nginx1

# Create the static page to be served
mkdir -p /data/www
echo "<h1>Coming Soon: Wabby-as-a-Service</h1>" > /data/www/index.html

# Create a simple nginx.conf
tee /etc/nginx/nginx.conf << EOF > /dev/null
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    server {
        location / {
            root /data/www;
        }
    }
}
EOF

# Reload and run Nginx on startup
systemctl start nginx
systemctl enable nginx
nginx -s reload

After half an hour debugging why my script isn't working (learned a lot: HEREDOCs, the tee command, systemctl, the
/var/log/cloud-init* log files, etc.), I was able to recreate the initial instance using the script above. You do this by going to: EC2 > Launch Instance > Step 3 (Configure Instance) > Advanced Details > User Data and pasting the script above. Do note that the User Data script is ran as the root user, so the commands do not need to be prepended with sudo.

Automation

Now comes the fun part: trying out Terraform and automating the provisioning of the instances. I basically just tried to list down what I need to achieve my manual infrastructure:

The default VPC
An EC2 instance
A pair of security group rules

The tricky part is the configuration of the provisioned instance. I was about to dive into Ansible to install the software that I need, but I realized the User Data script that I used was "good enough" for this exercise. I think I'll try to stick to this approach until I appreciate what Ansible can do for me!

Here's the Terraform script to provision the resources I listed above:

// main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 2.70"
    }
  }
}

provider "aws" {
  profile = "default"
  region  = "ap-southeast-1"
}

resource "aws_default_vpc" "default" {}

resource "aws_security_group" "wabby_sg" {
  name        = "wabby_sg"
  description = "Security group for the Wabby project."
  vpc_id      = aws_default_vpc.default.id

  ingress {
    description = "Allow SSH from everywhere."
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "Allow HTTP from everywhere."
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    description = "Allow all outbound traffic."
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "web" {
  ami             = "ami-00b8d9cb8a7161e41"
  instance_type   = "t2.micro"
  security_groups = [aws_security_group.wabby_sg.name]
  user_data       = <<-EOT
#!/bin/bash
yum update -y
amazon-linux-extras install -y nginx1

mkdir -p /data/www
echo "<h1>Coming Soon: Wabby-as-a-Service</h1>" > /data/www/index.html

tee /etc/nginx/nginx.conf <<EOF > /dev/null
worker_processes  1;

events {
  worker_connections  1024;
}

http {
  server {
    location / {
      root /data/www;
    }
  }
}
EOF

systemctl start nginx
systemctl enable nginx
nginx -s reload
EOT

  tags = {
    Name = "wabby_web_server"
  }
}

The code is again pretty self-explanatory. It creates an EC2 instance with the appropriate security group rules to allow SSH and HTTP access. The instance configuration is done with the User Data script we created earlier. The default VPC is used to keep things simple. If most of these are not familiar, you might want to do the Terraform tutorial to get up to speed.

I'll see you on the next part!

Automated Cloud: Introduction

John Alcher — Sun, 24 Jan 2021 22:43:31 +0000

Introduction

This article serves as the introductory entry on my "Automated Cloud" series, as well as covers the first task of setting up an AWS account.

Motivation

I'm currently aiming to get certified for the AWS Solutions Architect - Associate examination, and have been using various materials (courses, whitepapers, blogs, etc.) to prepare. Absorbing the theory has been fine, but I feel that I need to supplement it with some hands-on experience. That's when I came by this wonderful Reddit post by u/SpectralCoding and thought this would be a perfect set of exercises to get my hands dirty and apply my theoretical knowledge.

I plan to do all the tasks manually, using the AWS Console, to fully appreciate how to operate the required resources. Upon satisfaction of this manual setup, I would try to automate the provisioning and configuration using appropriate tools, most probably Terraform and Ansible.

Do note that I do have experience deploying applications on AWS, as well as managing them using Terraform and Ansible. But I think that the iterative "from-scratch" approach that I'll be doing with these tasks could yield a lot of learning potential.

The Tasks

Account Basics (this article)
Web Hosting Basics
~~Auto Scaling~~
~~External Data~~
~~Web Hosting - PaaS + S3~~
~~Microservices~~
~~Serverless~~
~~Continous Delivery~~

Task #1 - Account Basics

This series assumes the use of a new AWS account operating under the 1 year Free Tier. The tasks to accomplish for this article is as follows:

Create an IAM user for your personal use.
Set up MFA for your root user, turn off all root user API keys.
Set up Billing Alerts for anything over a few dollars.

Personal IAM User

The "root" AWS user is the one you access when you first login to a fresh AWS account. This user has all the elevated controls for all available resources, so it is paramount to not use this user aside from the initial setup. We use the AWS IAM service to manage the users and permissions for an AWS account.

I created a personal user for this project with access to the Billing and AdministratorAccess policies. The IAMUserChangePassword is there as well since the account needs to change its own password upon logging in the first time.

MFA, disable root API keys

To further lockdown the root user, enabling Multi-Factor Authentication is considered best practice. To do this, you go to My Security Credentials > Multi-factor Authentication (MFA) > Assign MFA Device.

As for the root API keys (Access Keys), a fresh account should not have any keys generated yet. If you have keys already on a root account, you can disable them by going to My Security Credentials > Access keys (access key ID and secret access key).

Billing Alerts

Billing alerts, or Budgets in the AWS console, is a great way to track your cloud spendings and not be surprised when the monthly invoice comes. Given that our account operates under the Free Tier, it is also the perfect way to keep our costs to a minimum when utilizing AWS resources that are not covered / exceed the Free Tier limit.

To create a new Budget, go to Billing > Budgets > Create Budget.

That should do it for the first task!

Automation

How do I automate all of this? At this point, I think this is a "meta-task" that precursors the rest of the project, and automating it would not yield many benefits. I'm curious about your thoughts on this, so please comment below if you think otherwise.

The automation starts on the next task where we provision an EC2 instance and serve a simple web page.

I'll see you on the next part.

Transferring a Jekyll Blog from Vercel to AWS

John Alcher — Sun, 25 Oct 2020 23:36:33 +0000

Introduction

This blog is built with Jekyll, a static site generator written in Ruby. And for the longest time, Vercel (formerly Zeit) is my hosting option of choice. Vercel offers everything one might need for a static website: Github integration, framework support (for Jekyll and Hugo to name a few), and even domain management under one neat dashboard. But as I try and expand my knowledge with cloud technologies, it makes a lot of sense to move this small traffic personal blog onto my cloud provider of choice.

This article documents the process that I took in order to achieve that.

Background

Let's start with an overview of my current setup. I have a static site that I build with Jekyll, which I host using Vercel. In the middle is a Github repo that is integrated with Vercel's webhooks enabling push to deploy capabilites. To top it off, my domain name is registered under Namecheap in which I also manage through Vercel's domain management system.

The End Goal

Ideally, I would like to replace the role of Vercel in my stack with AWS services. That means I have to find a way to replace the following features:

VCS Integration (push to deploy)
DNS Management
Static Content Hosting

Something Live on the Web

Let's knock off something easy and something that we can quickly see. Using S3, I can get a 100% replica of my live blog by hosting the generated static site within a bucket configured for web hosting. To configure a bucket, I just followed the defaults within the S3 Bucket Creation wizard with the exception of the following:

Under Properties -> Static website hosting, I checked "Use this bucket to host a website"
Under Permissions -> Block Public Access, I unchecked "Block all public access"
Under Permissions -> Bucket Policy, I added the following policy:

I now have an S3 Bucket that can be used to serve a static website. If I run bundle exec jekyll serve within my local project, I will be given a _site directory that contains the static assets needed to serve my blog. What left is to put the contents of this directory. That should be simple enough, right? Let's just open the Bucket's file dialog, CTRL+A the directory's contents, and we're pretty much done...

Nope! You apparently cannot upload directories using the S3 Bucket wizard. We are engineers, we shouldn't be using the UI that much. Let's use the command line instead!

The AWS CLI

If you're going to do a decent amount of work with AWS services, you'll be pretty inefficient (and probably error-prone) if you spend your time using the every changing web interface of the AWS Management Console. The AWS CLI provides unified access to all AWS has to offer. Let's take advantage of it by sycning our S3 Bucket with the contents of the _site directory. After making sure that you have configured your account, we just need to enter the following command:

$ aws s3 sync _site s3://bucket-name

At this point, you can now access your S3 Static Website! You can find the URL under Properties -> Static website hosting. Here's mine: http://alcher.dev.s3-website-us-east-1.amazonaws.com/

Conclusion

We didn't have much parity with our Vercel setup, but we did accomplish a lot -- particularly a static website with high availability using S3 Buckets. Here's our setup so far:

Let's see what we can further improve. I'll see you on the next one!

Do you write tests when exploring a new idea?

John Alcher — Sun, 20 Sep 2020 07:51:45 +0000

Hi!

I've been toying with a new project idea and have spent half a day doing exploratory programming to see how the different components would come together. I did cover a lot of ground, and in fact I'm probably going to pursue this project after a few more rounds of exploration.

This is in contrast to my usual workflow where I follow rigorous TDD. Now I find myself asking this question: when would be a good time to stop writing code, do some housekeeping, and start to build a test suite?

If you have had a similar experience before, I'm very curious on how you approached this scenario.

Do you follow TDD, perhaps a lighter version, when exploring new ideas?
If not, when do you start writing tests for the validated idea?
Either way, at what point of these kinds of projects do you start configuring the "nice to haves" (linter config, coverage frameworks, pre-commit hooks etc)?

I'm really eager to hear your thoughts. Stay safe!

What to test in Django: Endpoints

John Alcher — Mon, 17 Aug 2020 00:31:23 +0000

Introduction

Times are changing, and data is king^[1]. We usually store data within an RDBMS such as PostgreSQL or MySQL. Within a Django application, we manage and interface with our data using Django Models — something that we have explored last time. But this is not enough; we need a way to expose an interface in which this data is to be interacted with. Seeing that we are interested in building web applications, we are at mercy of the HTTP protocol. So we expose API Endpoints that allows clients to programatically interface with our data.

In this article, we will explore how we can test these API Endpoints.

Endpoint Testing: Django REST Framework

Let's take a quick look at the Django REST Framework, which we'll refer as DRF from now on. As stated in their home page:

Django REST framework is a powerful and flexible toolkit for building Web APIs.

And I can say with confidence, and probably thousands of other developers as well, that it indeed lives up to its tagline. It offers a LOT of functionality that makes API development easier, such as Serializers and ViewSets. The documentation is superb, the community support is great, and the mental model of how everything fits just makes sense.

As for testing, DRF provides the APIClient and APITestCase classes. These classes extend Django's django.test.Client and django.test.TestCase, respectively. Both of these components work with their Django counterparts, but the extra goodies do come handy from time to time.

Let's proceed by creating the endpoints that we'll be writing our tests for.

Get them bread: DRF ViewSets and Serializers

Going against the spirit of TDD, let's write a bunch of endpoints that will allow clients to do BREAD Operations^[2] against a Django Model. We'll create a Film model to supplement the previous article:

from django.db import models

class Film(models.Model):                             
    title = models.CharField(max_length=255)      
    description = models.CharField(max_length=255)
    release_year = models.DateField(auto_now=True)

    def __str__(self):                                 
      return self.title

We'll be using a ModelSerializer for the presentation logic:

from restframework import serializers
from .models import Film

class FilmSerializer(serializers.ModelSerializer):
    class Meta:
        model = Film
        fields = "__all__"

... and a ModelViewSet to implement the endpoints:

from restframework import viewsets
from .serializers import FilmSerializer


class FilmViewSet(viewsets.ModelViewSet):
    queryset = Film.objects.all()
    serializer = FilmSerializer

All that is left to do is to register the viewset to a URL mapping within the urls.py file:

from .views import FilmViewSet
from rest_framework.routers import DefaultRouter

app_name = "films"
router = DefaultRouter()
router.register(r'films', FilmViewSet)
urlpatterns = router.urls

With just 20 or so lines of code, we already have:

Extensible data representation for both presentation and data access.
Complete REST-ful routing, with sensible route names for URL lookup.

What would automated tests look like for these API endpoints?

Test Browse and Read Endpoints

We'll be starting with the endpoints that fetches data for us:

from rest_framework import status
from rest_framework.test import APITestCase
from .models import Film
from .serializers import FilmSerializer

class FilmViewsTest(APITestCase):
    @classmethod
    def setUpTestData(cls):
        # (1)
        cls.films = [Film.objects.create() for _ in range(3)]
        cls.film = cls.films[0]

    def test_can_browse_all_films(self):
        # (2)
        response = self.client.get(reverse("films:film-list"))

        # (3)
        self.assertEquals(status.HTTP_200_OK, response.status_code)
        self.assertEquals(len(self.films), len(response.data))

        for film in self.films:
            # (4)
            self.assertIn(
                FilmSerializer(instance=film).data,
                response.data
            )

    def test_can_read_a_specific_film(self):
        # (5)
        response = self.client.get(
            reverse("films:film-detail", args=[self.film.id])
        )

        self.assertEquals(status.HTTP_200_OK, response.status_code)
        self.assertEquals(
            FilmSerializer(instance=film).data,
            response.data
        )

This should hopefully all make sense as it's basically the same as testing a Django Model, or a Python class for that matter. The only difference is that instead of asserting the properties and methods of a class, we are interacting with its interface through HTTP. Let's take a closer look:

We create a set of data to test with.
We issue a GET request to the Film's "index" endpoint, which by convention will return all the available films in our system. Note that the reverse lookup name, aptly called films:film-list, is auto-generated by DRF's ViewSet class.
The response contains data related to, well, the response of our GET request. We assert that it did return a 200, and the response body has the same number of items with the total films that we created.
Using the FilmSerializer class that we created earlier, we assert that each film in the response is properly formatted.
We do the same process for the test of reading a specific film, with the main difference that we are only checking a singular film instead of looping through a list of many.

Test Add and Edit Endpoints

The Add, Edit, and Delete endpoints share an important characteristic: they all modify the database state in one way or another. We'll group the Add and Edit endpoints together because they function similarly enough:

# ...


class FilmViewsTest(APITestCase):
    # ...


    def test_can_add_a_new_film(self):
        # (1)
        payload = {
            "title": "2001: A Space Odyssey",
            "description": 
                "The Discovery One and its revolutionary super " \
                "computer seek a mysterious monolith that first " \
                "appeared at the dawn of man.",
            "release_year": 1968
        }

        response = self.client.post(reverse("films:film-list"), payload)
        created_film = Film.objects.get(title=payload["title"])

        self.assertEquals(status.HTTP_201_CREATED, response.status_code)
        # (2)
        for k, v in payload.items():
            self.assertEquals(v, response.data[k])
            self.assertEquals(v, getattr(created_film, k))

    def test_can_edit_a_film(self):
        # (3)
        film_data = {
            "title": "InceptioN",
            "description": 
                "Cobb steals information from his targets by "  \
                "entering their dreams. Saito offers to wipe "  \
                "clean Cobb's criminal history as payment for " \
                "performing an inception on his sick competitor's son.",
            "release_year": 2001
        }
        film = Film.objects.create(**film_data)
        # (4)
        payload = {
            "title": "Inception",
            "release_year": 2010
        }

        response = self.client.patch(
            reverse("film:film-detail", args=[new_film.id])
        )
        # (5)
        film.refresh_from_db()

        self.assertEquals(status.HTTP_200_OK, response.status_code)
        for k, v in payload.items():
            self.assertEquals(v, response.data[k])
            self.assertEquals(v, getattr(film, k))

That's a mouthful. Take a minute to read through it. In a nutshell, we are accessing the create and update facilities of our Film model — the difference is that it sits behind our API and we interact with it through HTTP verbs (POST and PATCH). We can see that:

We prepare a payload of data that we would like to create a film with and POST it to the films:film-list endpoint.
A neat trick: we loop through the keys in our payload and compare the response body. The tedious alternative is to write assertions for each field manually.
As for the editing endpoint, we first create a film to test against.
Then we PATCH through the fields that we would like to be updated against the films:film-detail endpoint.
We then refresh the film instance and check if the changes have been persisted.

Test the Delete Endpoint

Lastly, let's see how we'll test the Delete endpoint:

# ...


class FilmViewsTest(APITestCase):
    # ...

    def test_can_delete_a_film(self):
        response = self.client.delete(
            reverse("films:film-detail", args=[self.film.id])
        )

        self.assertEquals(status.HTTP_204_NO_CONTENT, response.status_code)
        self.assertFalse(Film.objects.filter(pk=self.film.id))

The code should be self-explanatory. It's a pity that there's no assertIsNotEmpty available in the unittest module, so we have to resort to the closing assertFalse call to check that the filtered queryset is empty. It logically works, but it violates the law of least surprise^[3].

Conclusion

In this article, we have touched on the following points:

What the Django REST Framework is, and how it helps us in API development and testing.
Using ModelViewSet and ModelSerializer to build a set of REST-ful BREAD endpoints.
How to test each endpoints by issuing HTTP requests through an APITestCase.

I hope you get something out of this article. May your endpoints stay REST-ful and your breads loaves fresh. Stay safe!

Footnotes

What to test in Django: Models

John Alcher — Sun, 09 Aug 2020 21:44:04 +0000

Introduction

Software testing is the discipline of determining correctness of a software. Automated tests, on the other hand, is the process of writing program that tests a software automatically. There is a whole plethora of discussions around the internet^[1] about the upside of writing automated test suites, so I'm not going to bore you with my own opinions on the matter. But if you care about the quality of software you produce, and you already test your programs manually, I can confidently assure that having an automated test suite will increase your productivity and confidence with your codebase.

The Django web framework provides a solid set of testing facilities out of the box adhering to the batteries included philosophy. With these already provided, ^[2]you can use a collection of tests — a test suite — to solve, or avoid, a number of problems:

When you’re writing new code, you can use tests to validate your code works as expected.
When you’re refactoring or modifying old code, you can use tests to ensure your changes haven’t affected your application’s behavior unexpectedly.

A Django project contains a bunch of moving parts which are prime candidates to write tests for. This article will focus on Django Models.

Anatomy of a Django Model

Let's start by examining what a Django Model looks like. Using the Sakila DVD Rental Database as a reference (ER diagram^[3]), we might represent the actor table with this code:

from django.db import models

# (1)
class Actor(models.Model):                             
    # (2)
    first_name = models.CharField(max_length=255)      
    last_name = models.CharField(max_length=255)
    last_update = models.DateTimeField(auto_now=True)

    # (3)
    film = models.ManyToManyToManyField(               
        "films.models.Film",
        related_name="actors",
        null=True,
        on_delete=models.SET_NULL,
    )

    # (4)
    def __str__(self):                                 
      return f"{self.first_name} {self.last_name}"

This code shows as a few things:

A Django model inherits from the django.db.models.Model class, allowing it to be mapped to a specific database table.
Instances of django.db.models.Fields can then be attached as properties to the model, allowing them to be mapped as table columns. Here we define a Many-to-Many relationship between an Actor and a Film. Note that the null and on_delete kwargs implies that an Actor doesn't necessarily need to have a Film attached to it.
Relationships are an integral part of any RDBMS, and Django allows us to conveniently construct and access these relationships in an Object-Oriented manner.
Finally, models are just Python classes underneath the hood, so we can define custom (or magic) methods for business/presentation/meta logic.

With this information in mind, we can now explore how and what we can test a Django Model.

Testing Model Fields

Writing tests for a Model's fields are probably the easiest and requires the least effort. Basically, we would be asserting that a model does indeed have the expected fields, giving us guarantee that the corresponding table columns exist. Here's what it looks like:

from datetime import datetime
from django.test import TestCase

from .models import Actor

# (1)
class ActorModelTest(TestCase):              
    # (2)
    @classmethod
    def setUpTestData(cls):                                     
        cls.actor = Actor.objects.create(
            first_name="John", 
            last_name="Doe"
        ) 

    # (3)
    def test_it_has_information_fields(self):                   
        self.assertIsInstance(self.actor.first_name, str)
        self.assertIsInstance(self.actor.last_name, str)

    # (4)
    def test_it_has_timestamps(self):                           
        self.assertIsInstance(self.actor.last_update, datetime)

Here's what this code does:

We subclass the Django TestCase class, which in turn inherits from the unittest module's TestCase. This allows us to use assertion methods such as assertTrue() and assertEquals(), as well as some database access facilities such as setUpTestData().
Using the aforementioned setUpTestData() class method, we create a single Actor instance to be used by the rest of the test methods. Read the documentation on why we use this instead of the setUp() method from unittest.TestCase.
We then test that the first and last name fields do exist in the created Actor instance. We do this by running assertions on the specific properties that they are of a specific type, in this case str.
Similarly, we check if the last_update field exists as well, asserting that it is of the datetime.datetime type.

Running your test suite will then confirm that, indeed, the Actor model has the fields you expect!

Testing Model Relationships

Testing for Model Relationships works similarly with Model Fields:

# ...

from films.models import Film

class ActorModelTest(TestCase):
    #  ...

    def it_can_be_attached_to_multiple_films(self):
        # (1)
        films = [Film.objects.create() for _ in range(3)]      
        # (2)
        for film in films:
            film.actors.add(self.actor)                         

        # (3)
        self.assertEquals(len(films), self.actor.films.count()) 
        for film in films:
            # (4)
            self.assertIn(film, self.actor.films)

The new test method should be self-explaining:

We create a bunch of Film objects to test with.
We then attach the Actor instance we created in the setUpTestData() method for each of the Film's related Actors.
Our Actor instance should have the same amount of films as we created.
And each of the films we created should be in the Actor's set of related films.

We can now be sure that our Models are connected properly.

Intermezzo: What's up with these tests?

A lot of people would say that these methods are testing the framework code and that we didn't accomplish much by writing these tests. I say that they test our integration with the framework (i.e. testing that we use the correct Django's database access features) instead of testing how the framework code works (i.e. testing the internal implementation of an IntegerField). And those are perfectly fine in my book.

At the very least, these types or tests are very easy and fast to write. And momentum is very important in testing, doubly so if you follow TDD. If still in doubt, tests like these are easy to delete down the line.

Considere them a low-risk, medium-return investment on your portfolio of test suites.

Testing Model Methods

Lastly, let's see how one would write a test for custom Model methods:

# ...

class ActorModelTest(TestCase):
    #  ...

    # (1)
    def test_its_string_representation_is_its_first_and_last_name(self): 
        full_name = f"{self.first_name} {self.last_name}"
        # (2)
        self.assertEquals(str(self.actor), full_name)

A quick tip: tests are meant for validation, but they are also perfect as added documentation. Don't be afraid to write overly descriptive names for your test methods. One should be able to glance over a testcase and get an overhead view on how the specific module or class works.
Testing our __str__() method. Should be self-explanatory.

We can see that this is a pretty trivial scenario, but logic on custom methods can grow quickly if not kept in check. When more tables and fields are added down the line, we might have the following methods on the Actor class:

A good one is a check_availability(timedelta) method that checks if the Actor can be booked for a certain period of time.
Or a compute_salary(movie) for calculating how much an Actor should be paid for a specific Movie.
Maybe even a retire() method that sets some database fields for the Actor, signifying that the Actor no longer accepts work.

All of these methods require custom logic, and writing tests for these will give us confidence that our code adheres to what we expect it to do.

Conclusion

In this article, we have touched on the following points:

What software testing is, and what Django provides in its testing facilities.
What a Django Model is made of.
How to test a Model's fields.
How to test a Model's relationships.
How to test a Model's custom methods.

I hope you get something out of this article. May your tests be green and plenty. Stay safe!

Footnotes

^[1] a few links that you might find interesting:
^[2] in verbatim, https://docs.djangoproject.com/en/3.1/topics/testing/
^[3] from https://www.postgresqltutorial.com/postgresql-sample-database/

React, Django, and PostgreSQL Dockerized — Part 1: Development Setup

John Alcher — Sun, 05 Jul 2020 00:00:00 +0000

Introduction

React and Django are both mature solutions to solve common development objectives. Bring in PostgreSQL into the mix as the primary data store, what we get is stack of battle-tested technologies that is a delight to work with.

Goals

The goal of this series is to combine this stack with the power of containerization using Docker. With Docker, we hope to achieve the following:

Easier onboarding and development setup, because the only dependency we need is Docker itself.
More streamlined continuous integration (CI) process, because tests can be ran within containers.
Better deployment process to cloud providers, because similarly, all we need is Docker itself to spin up our application services.
This leads to a better deployment pipeline for continuous delivery (CD), tying together our DevOps Lifecycle.

This articles focuses on the first one.

Starter Kit

Throughout this article, I'll be referencing the Starter Kit that I host on Gitlab. This includes the docker-compose.yml file and the Dockerfile for each service defined.

Please note that depending on when you are reading this article, the master branch may already have had a few changes. You can follow along with the dev-setup branch for this article.

Explanation

Figure 1: Docker Development Setup Visualization

The web service is responsible for the React frontend and the Django API. I find that combining the whole web tier into one service is the simplest approach, as opposed to deploying a separate service for the frontend.

It utilizes a volume to map the contents of the web directory to the defined WORKDIR for that image. This is what allows changes from your machine to be reflected directly on the Docker container, allowing you to continue with the usual development cycle without rebuilding the containers for each change.

The following ports are then mapped to their respective counterparts on the host machine: 8000 for the Django API, 3000 is for the React dev server, and 35729 for the NodeJS livereload.

Environment Variables are then loaded from the .env.dev file, allowing further customization if necessary.

Lastly, stdin_open is enabled to allow us to run the React dev server in interactive mode, giving us invaluable feedback as we write code.

Here's what the docker-compose.yml looks like for the web service:

version: '3.7'

services:
  web:
    container_name: web
    build:
      context: ./web
      dockerfile: Dockerfile
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - ./web/:/usr/src/web/
    ports:
      - 8000:8000
      - 3000:3000
      - 35729:35729
    env_file:
      - ./.env.dev
    stdin_open: true

Next up is the db service. This is the PostgreSQL server that our Django API can communicate with for data persistence. We use the stock 12.0-alpine image and define the credentials through environment variables. The container is then attached to a volume in order to persist the data throughout shutdowns and restarts.

We'll also make the web service depend on the db service. With conjunction to the web/entrypoint.sh file, this will ensure that Django won't try to connect to the PostgreSQL service while it's still booting up.

Here's what the final docker-compose.yml looks like after adding the db service:

version: '3.7'

services:
  web:
    container_name: web
    build:
      context: ./web
      dockerfile: Dockerfile
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - ./web/:/usr/src/web/
    ports:
      - 8000:8000
      - 3000:3000
      - 35729:35729
    env_file:
      - ./.env.dev
    stdin_open: true
    depends_on:
      - db

  db:
    container_name: db
    image: postgres:12.0-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    environment:
      - POSTGRES_USER=dev_user
      - POSTGRES_PASSWORD=dev_password
      - POSTGRES_DB=dev

volumes:
  postgres_data:

Usage

We could run the services defined with just Docker installed in our machine, but that won't be suitable for a productive development setup.

I suggest to have npm installed in order to build the node_modules on our host machine, which is then accessible through the volume in the web service. This enables IDE autocompletion for the React part.

Python, on the other hand, is much more forgiving with this regard. There are a couple of high quality extensions for your favorite IDE that allows you to connect to a remote server (in this case to our Docker container). Here's some helpful articles to get you started:

To get started we need to run the following commands:

$ cp .env .env.dev                                       # <- 0
$ chmod +x web/entrypoint.sh                             # <- 1
$ npm install --prefix ./web/frontend/                   # <- 2
$ docker-compose up -d --build                           # <- 3
$ docker-compose exec web npm start --prefix ./frontend/ # <- 4

The contents of .env should be good enough as is, but you can reconfigure it as needed.
Make the entrypoint executable.
React dependencies are then installed on our host machine for IDE autocompletion.
The images are then built, and the containers ran in detached mode. The files generated in the previous step is also copied over to the web container.
We can now boot up the React dev server, with hot reload enabled.

You can now access the React application on http://localhost:3000/ and the Django API on http://localhost:8000/. Click on the button to test if your frontend is integrated with the API:

Figure 2: React integrated with Django on Docker containers

If you get the "API Integration Works!" alert, you're good to go!

Conclusion

In this article, we took a glance on a development setup for a React+Django+PostgreSQL stack using Docker containers. We reviewed the overview of the architecture for this setup, the details of each services, and how they connect to the host (and among themselves).

For the next article, we'll implement a Continuous Integration (CI) pipeline for our stack.

I'll see you then.

Care to share some painfully funny debugging stories?

John Alcher — Sat, 04 Jul 2020 21:17:45 +0000

Let me start:

I have a React + Django API that sits behind Nginx that I'm trying to containerize with Docker. For some reason, React can't get pass the CORS policies of the API, even though I can manually open the API endpoints on my browser without any problems. I even tried using CURL and HTTPie to issue the requests, and I can successfully get the response with the appropriate Access-Control-Allow-Origin header.

The culprit? UBlock Origin tags the endpoint /api/ping/ (that is used within the API) as an advertisement server. Big yikes!

Practical Tips for Handling Forms in React

John Alcher — Sun, 03 May 2020 22:02:29 +0000

Preface

This is a snippet from my notes as I learn ReactJS for work. If you have any suggestions on how I can improve my code samples, or if you found anything catastrophically wrong, please do not hesitate to let me know!

Introduction
Create a Generic onChange Handler
Reset a Form Through an initialState
Move State Closer to Forms
Conclusion

Introduction

So you've learned about what React is and why is it all over the place these days. You've learned what components and props are, as well as how to manage their state and lifecycle. You are also now familiar with the concept of controlled components (i.e. how to manage state through form inputs). In this article, we'll take a look at a few techniques that we can utilize in order to make working with Form Inputs in React more easier.

Note: Examples in this article heavily use ES6 features. If you are not familiar with ES6, Tania Rascia's overview is a good place to start.

Create a Generic `onChange` Handler

In order to achieve parity on a state and <input/> value (also called two-way data binding), we need to set an <input/>'s value to its corresponding state and also bind an onChange handler that computes the new state value when the <input/> has been changed. Let's take a look at an example from the ReactJS website (refactored for brevity):

class RegistrationForm extends React.Component {
  state = { name: '' }

  handleChange = event => this.setState({name: event.target.value})

  handleSubmit = event => {
    alert('A name was submitted: ' + this.state.value);
    event.preventDefault();
  }

  render() {
    return (
        <form onSubmit={this.handleSubmit}>
            <label>
                Name:
                <input type="text"
                    value={this.state.name}
                    onChange={this.handleChange} />
            </label>
            <input type="submit"
                value="Submit" />
        </form>
    );
  }
}

What this example does is that when the <input/>'s value changes, the state.name property is also updated. But the state being updated (name) is hardcoded, which prevents it from being reusable when there are multiple inputs. A solution that I commonly see is to create a handler for each input, which would like this:

state = { name: '', password: '' }

handleNameChange = event => this.setState({name: event.target.value})

handlePasswordChange = event => this.setState({password: event.target.value})

render() {
    return (
        <form onSubmit={this.handleSubmit}>
            <label>
                Name:
                <input type="text"
                    value={this.state.name}
                    onChange={this.handleNameChange} />
            </label>

            <label>
                Password:
                <input type="password"
                    value={this.state.password}
                    onChange={this.handlePasswordChange} />
            </label>

            <input type="submit"
                value="Submit" />
        </form>
    );
}

If we would be working with one or two <input/>s, this approach would work just fine. But one can imagine when requirements down the road dictates that we need to add more field to this form, then a 1:1 input to handler ratio would quickly become unmantainable. This is where a Generic Handler comes in.

As the name implies, a Generic Handler catches all input events and updates their corresponding state. The key that will be used for the state lookup will be inferred from the name attribute of an <input/>. This is what it looks like:

handleChange = event => {
    const {name, value} = event.target;

    this.setState({ [name]: value });
}

render() {
    return (
        <form onSubmit={this.handleSubmit}>
            <label>
                Name:
                <input type="text"
                    value={this.state.name}
                    onChange={this.handleChange} />
            </label>

            <label>
                Password:
                <input type="password"
                    value={this.state.password}
                    onChange={this.handleChange} />
            </label>

            <input type="submit"
                value="Submit" />
        </form>
    );
}

Now both <input/>s only use one handler to update their corresponding state. But what if we need to apply custom logic to specific <input/>s before updating the state? An example would be to validate if an <input/>'s value is valid, or to apply formatting to specific value. We can do this by checking the name of the <input/> and conditionally applying the desired logic:

state = {
    name: '',
    password: '',
    age: null,
}

handleChange = event => {
    let {name, value} = event.target;

    // Custom validation and transformation for the `age` input
    if (name === 'age') {
        value = parseInt(value);
        if (value < 18) {
            alert('Minors are not allowed');
            return;
        }
    }

    this.setState({ [name]: value });
}

handleSubmit = event => {
    event.preventDefault();
    console.log(JSON.stringify(this.state)); // Ready for processing
}

render() {
    return (
        <form onSubmit={this.handleSubmit}>
            <label>
                Name:
                <input type="text"
                    value={this.state.name}
                    onChange={this.handleChange} />
            </label>

            <label>
                Password:
                <input type="password"
                    value={this.state.password}
                    onChange={this.handleChange} />
            </label>

            <label>
                Age:
                <input type="number"
                    value={this.state.age}
                    onChange={this.handleChange} />
            </label>

            <input type="submit"
                value="Submit" />
        </form>
    );
}

If the handleChange method becomes too bloated down the line because of the multiple branches, you might want to consider factoring the complex <input/>s onto their own component and manage the logic there.

Reset a Form through an `initialState`

As you might have already experienced, a common process when using an HTML form that creates something is:

Enter data into the form fields.
Submit the form.
Wait for the data to be processed (by an HTTP request to a server, for example).
Enter data again onto a cleared form.

We already have steps 1 to 3 (if we count the console.log call as step #3) implemented in the previous example. How could we implement step #4? A perfectly fine (though somewhat naive) solution is to call setState and pass what the original state object might contain:

state = {
    name: '',
    password: '',
    age: null,
}

handleSubmit = event => {
    event.preventDefault();
    console.log(JSON.stringify(this.state)); // Ready for processing

    // Reset the state
    this.setState({
        name: '',
        password: '',
        age: null,
    });
}

Copy and pasting, more often than not, is a good indicator that a better solution is available. What if we add more fields in the future? What if we only want to reset some parts of the form? These could be easily solved by creating an initialState member on your class:

initialState = {
    name: '',
    password: '',
    age: null,
}

state = { ...this.initialState }

handleSubmit = event => {
    event.preventDefault();
    console.log(JSON.stringify(this.state)); // Ready for processing

    // Reset the state
    this.setState({ ...this.initialState });
}

Want to persist the name when the form is cleared? Simply move it from the initialState to the state and it won't get overwritten upon submission:

initialState = {
    password: '',
    age: null,
}

state = {
    name: '',
    ...this.initialState
}

handleSubmit = event => {
    event.preventDefault();
    console.log(JSON.stringify(this.state)); // Ready for processing

    // Reset the state except for `name`
    this.setState({ ...this.initialState });
}

Move State Closer to Forms

With React, it is tempting to move all state as high up the component tree as possible and just pass down props and handlers when necessary.
Functional components are easier to reason with after all. But this could lead to bloated state if we shoehorn everything on the top-level component.

To demonstrate, let's say that the <RegistrationForm/> component in the previous example is under an <App/> component in the component tree. <App/> keeps an array of users in its state and we would like to push the newly registered user from the <RegistrationForm/> component. Our first instict might be to move state up to the <App/> component and make <RegistrationForm/> a functional one:

class App extends React.Component {
    state = {
        users: [],
        newUser: {
            name: '',
            password: '',
            age: null,
        },
    }

    handleChange = e => {
        let {name, value} = event.target;

        // Custom validation and transformation for the `age` input
        if (name === 'age') {
            value = parseInt(value);
            if (value < 18) {
                alert('Minors are not allowed');
                return;
            }
        }

        this.setState({ newUser[name]: value });
    }

    handleSubmit = e => {
        e.preventDefault();

        const users = this.state.users.slice();
        const {name, password, age} = this.state.newUser;
        users.push({name, password, age});

        this.setState({users});
    }

    render() {
        return <RegistrationForm newUser={this.state.newUser}
            handleChange={this.handleChange}
            handleSubmit={this.handleSubmit}/>
    }
}

const RegistrationForm = ({newUser, handleChange, handleSubmit}) => (
    <form onSubmit={handleSubmit}>
        <label>
            Name:
            <input type="text"
                value={newUser.name}
                onChange={handleChange} />
        </label>

        <label>
            Password:
            <input type="password"
                value={newUser.password}
                onChange={handleChange} />
        </label>

        <label>
            Age:
            <input type="number"
                value={newUser.age}
                onChange={handleChange} />
        </label>

        <input type="submit"
            value="Submit" />
    </form>
)

This solution works, and nothing is inherently wrong with it. But let's take a step back and look at it with fresh eyes: does the <App/> component really care about the newUser state? Opinions might vary, but heres mine: I think that unless <App/> manages other components that might need to access it, the newUser data should be managed solely by who it's concerned with -- <RegistrationForm/>. The <App/> component doesn't necessarily care about the low-level details, it just wants a way to add a new user.

Let's do just that!

class App extends React.Component {
    state = { users: [] }

    addUser = user => {
        const users = this.state.users.slice();
        users.push(user);

        this.setState({ users });
    }

    render() {
        return <RegistrationForm addUser={this.addUser}/>
    }
}

class RegistrationForm extends React.Component {
    state = {
        name: '',
        password: '',
        age: null,
    }

    handleChange = e => {
        let {name, value} = event.target;

        // Custom validation and transformation for the `age` input
        if (name === 'age') {
            value = parseInt(value);
            if (value < 18) {
                alert('Minors are not allowed');
                return;
            }
        }

        this.setState({ [name]: value });
    }

    handleSubmit = e => {
        e.preventDefault();
        this.props.addUser(this.state);
    }

    render() {
        const {name, password, age} = this.state;

        return (
            <form onSubmit={this.handleSubmit}>
                <label>
                    Name:
                    <input type="text"
                        value={name}
                        onChange={this.handleChange} />
                </label>

                <label>
                    Password:
                    <input type="password"
                        value={password}
                        onChange={this.handleChange} />
                </label>

                <label>
                    Age:
                    <input type="number"
                        value={age}
                        onChange={this.handleChange} />
                </label>

                <input type="submit"
                    value="Submit" />
            </form>
        );
    }
}

See the difference? Now, <App/> itself doesn't know how the newUser object is being built. It doesn't have handlers that work with DOM events, which makes sense since it doesn't render any form inputs itself. <RegistrationForm/>, on the other hand, returns HTML <input/>s directly, and it only makes sense that it handles input events on its own.

Conclusion

Things to take away from this article:

A generic onChange handler can reduce repeated handler code.
Inferring state from an initialState can be useful for resetting a component's state.
Think twice when moving state up the component tree.
Components that render HTML <input/>s directly should be the one with event handlers.

Links and References

Heroku: Go with MySQL Notes

John Alcher — Sat, 28 Mar 2020 03:12:51 +0000

Originally hosted on my [blog](https://johnalcher.me/2020/heroku-go-mysql-notes/)

Introduction
The App
Provisioning
Gotchas
Links and References

Introduction

In this article, we'll be exploring Heroku's offering for deploying Go web applications that are backed with a MySQL database. We'll be looking at an example app, provisioning a database addon for our Heroku dyno, and some tricky gotchas that one might encounter with this endeavour. Let's get started!

The App

I've been learning Go the past few weeks, and have decided to make some projects to bolster my knowledge. I decided to follow the API and Microservices section of FreeCodeCamp's Curriculum. The third project, a URL Shortener App, is the first project from the API and Microservices section that requires a data store. I've contemplated for a while and have been really tempted to just write the data on disk (to a txt or csv file) to keep things simple. But I realized it would be fun to try out deploying a Go app that uses MySQL as its data store onto Heroku.

The app itself is pretty straightforward. You give it a link, it stores it, and gives you a short link that redirects you to the link you've originally provided. It uses nothing but the standard library, except from the 3rd party MySQL driver.

Here's a live demo and the source.

Provisioning

In order to deploy this app from my local machine to Heroku, I need to provision a dyno and an instance of MySQL (called ClearDB). To do this, issue the following commands

$ heroku login # Make sure you already have an account
$ heroku create <your-app-name-here>
$ heroku addons:create cleardb:ignite

We're live! You can now access the app through https://<your-app-name-here>.herokuapp.com/. Now is also the time to get your database credentials with the following command:

$ heroku config | grep CLEARDB_DATABASE_URL
CLEAR_DATABASE_URL => mysql://alphanum-username:alphanum-password@us-cdbr-iron-east-01.cleardb.net/heroku_alphanum_name?reconnect=true

This is the ClearDB connection string that you'll need to connect to the database instance that we have just provisioned. We'll use this later.

Gotchas

Make sure your Procfile is properly formatted

Heroku's configuration file named Procfile is actually quite strict with its syntax. A common pitfall I see (and have encountered myself) is the following mistake:

web:bin/my-app # Wrong

This will throw an H14 error (see heroku logs --tail) because of the missing space between web: and bin/my-app

web: bin/my-app # Correct

Use and set the proper environment variables

Heroku uses an environment variable, aptly named PORT, to determine which port a web app will run on. This means you can't (and shouldn't, anyway) hardcode the port within your app. You should use the os module and load the port from the environment variables:

The database credentials shouldn't be hardcoded within the app as well, obviously. You should use an environment variable for this, which we will call DATABASE_URL:

import (
    "os"
    "log"
)

func main() {
    port := os.Getenv("PORT")

    if port == "" {
        log.Fatal("$PORT is not set")
    }

    dns := os.Getenv("DATABASE_URL")

    if dns == "" {
        log.Fatal("$DATABASE_URL is not set")
    }
}

Properly format the DNS string

We've already covered how to get the ClearDB url earlier, but we can't just plug it in as our DATABASE_URL and be done with it. So let's say the CLEARDB_DATABASE_URL that we've been assigned is:

mysql://alphanum-username:alphanum-password@us-cdbr-iron-east-01.cleardb.net/heroku_alphanum_name?reconnect=true

We have to format it as follows:

alphanum-username:alphanum-password@tcp(us-cdbr-iron-east-01.cleardb.net)/heroku_alphanum_name

Note that the host part is wrapped inside tcp()

You should now have a fully working Go web application backed by a MySQL database!

Links and References

Laravel: Queued Notifications for a Deleted User or Eloquent Model

John Alcher — Sat, 27 Apr 2019 09:19:29 +0000

Cover by freestocks from Pexels

Contents
Introduction
Our Problem At Hand
The Obvious Symptom
Solution
Don't Forget The Tests!
How about Regular Eloquent Models?
- As an array
- Only relevant fields
Conclusion

Introduction

Out of the box, Laravel provides strong facilities for utilizing queues and/or Redis to support your queued jobs, mails, or any other expensive (time or resource-wise) operations. But the asynchronous nature of queues might bite you in your back side when dealing with objects wherein their current state is tricky to visualize once the queued action is executing. In this article, we'll take a look at two instances where this may be the case.

Our Problem at Hand

Our friends at ACME Airconditioning has a shopping cart system wherein customers can buy their desired AC units online, provided they have an account in the system. Now, a feature request had come in where the specs is described (in GWT) as follows:

Feature: Farewell Email Promotion for a Deleted Customer
    Scenario: Customer deletes their account
        Given I have my email verified

        When I delete my customer account

        Then I will receive an email containing ACME's farewell promo

Now how do we implement this feature? It seems straightforward: send the user an email before deleting their account:

// CustomerController.php

public function destroy(Customer $customer)
{
    $customer->notify(new FarewellPromotion());
    $customer->delete();

    // ...
}

// FarewellPromotion.php

class FarewellPromotion extends Notification implements ShouldQueue
{
    use Queueable;

    public function toMail($notifiable)
    {
        return (new MailMessage)
            ->line('We are sad to see you go.')
            ->line('How about a 2-for-1 special?')
            ->action(
                'Buy Now,
                '/farewell-promo'
            );
    }
}

But to our surprise, $customer never receives the email! Why? Let's examine it further.

The Obvious Symptom

Hmmm, take a second look at the program flow. It should become apparent when you consider that $customer->notify(new FarewellPromotion()); pushes the notification into a queue, thus notifying the user asynchronously. In a nutshell, the account deletion happens before the notification is sent. This causes the notification to fail because the recipient that it is intended for is already deleted (or more precisely, null).

Solution

You can solve this by not queuing the notification (unacceptable for UX) or by storing the customer's email address and sending the mail directly (slightly better, but discards the abstraction of the notifications). But luckily, Laravel supports On-Demand Notifications that allows notification to be sent without a Notifiable instance (in our case, the customer).

// CustomerController.php

public function destroy(Customer $customer)
{
    $customer->delete();

    // Doesn't matter if it's before or after deletion since 
    // the Customer instance still has its properties 
    // up until the request context expires.
     Notification::route('mail', $customer->email)
            ->notify(new FarewellPromotion());

    // ...
}

Don't Forget The Tests!

Once you changed the implementation from a simple notification into an on-demand one, you'd have to change any test cases that account for this feature. A testcase might look something like this:

/** @test */
public function customers_that_deletes_their_account_is_notified_of_the_farewell_promo()
{
    Notification::fake();

    $customer = factory(Customer::class)->create();

    $this->delete('/customers/' . $customer->id);

    Notification::assertSentTo(
        $customer,
        FarewellPromotion::class
    );
}

This testcase would now fail because $customer is already null once the assertion is made. Instead, we should use the AnonymousNotifiable class to proxy for our customer, as is the case when using Notification::route

use Illuminate\Notifications\AnonymousNotifiable;

Notification::assertSentTo(
    new AnonymousNotifiable,
    FarewellPromotion::class
);

How about Regular Eloquent Models?

That covers how to notify a deleted Customer model that uses the Notifiable trait. But what if we need a deleted model for a queued notification? Consider the following:

Feature: Recommend another Product when a Customer's "liked" Product is Deleted
    Scenario: A Product is Deleted
        Given I have my email verified
            And I have "liked" a product

        When that product is deleted

        Then I will receive a notification that recommends me another product.

Now obviously, blindly passing the Product model into a queued notification will result with the same async problem that we encountered before:

// ProductsController.php

public function delete(Product $product)
{
    $product->delete();

    $product->likers->notify(new SimilarProductRecommendation($product));
}

// SimilarProductRecommendation.php
class SimilarProductRecommendation extends Notification implements ShouldQueue
{
    use Queueable;

    private $product;

    public function __construct(Product $product)
    {
        $this->product = $product;
    }

    public function toArray($notifiable)
    {
        return [
            'message' => $this->product->name . ' has been deleted. Try this other product....' 
        ];
    }
}

There is no clear cut solution about it, because unlike Customer, Product is not Notifiable and we won't be able to leverage the Notification::route() method. When I'm faced with this problem, I use one of the following solutions:

1. Pass an array representation of the model

// ProductsController.php
public function delete()
{    
    $product->delete();

    $product->likers->notify(new SimilarProductRecommendation($product->toArray()));
}

// SimilarProductRecommendation.php
class SimilarProductRecommendation extends Notification implements ShouldQueue
{
    use Queueable;

    private $product;

    public function __construct(array $product)
    {
        $this->product = $product;
    }

    public function toArray($notifiable)
    {
        return [
            'message' => $this->product['name'] . ' has been deleted. Try this other product....' 
        ];
    }
}

2. Pass only the relevant model fields

// ProductsController.php
public function delete()
{    
    $product->delete();

    $product->likers->notify(new SimilarProductRecommendation($product->name));
}

// SimilarProductRecommendation.php
class SimilarProductRecommendation extends Notification implements ShouldQueue
{
    use Queueable;

    private $productName;

    public function __construct(string $productName)
    {
        $this->productName = $productName;
    }

    public function toArray($notifiable)
    {
        return [
            'message' => $this->productName . ' has been deleted. Try this other product....' 
        ];
    }
}

Both of these solutions bypass the unpredictable state of the deleted model by passing in separate values instead of a reference to the model itself.

Conclusion

In this article, we've covered the trickiness that queued notifications might present when handling deleted entities. We've also covered how to notify a deleted User (or any model that implements the Notifiable trait, to be precise) and testing the said action. Lastly, we took a look at passing deleted Eloquent model references to a queued notifications, and discussed a couple of solutions on how to "access" these deleted models.

Five Things to Consider for a Fresh Laravel Project

John Alcher — Sat, 02 Mar 2019 04:19:20 +0000

Originally posted in my blog

Introduction

In this short article, we're going to explore some things you might consider for your new Laravel project. A lot of new developers goes straight from laravel new myproject to writing code without any thoughts or considerations, so here's a list of things that could be of use after your first git init. Let's get started!

Disclaimer

The following are just opinions and shouldn't be taken as hard rules to follow. I suggest you try them out, see if it feels right, and decide from there. You think it just made things complicated? Revert the change and let it be :)

1. Move your Eloquent models into a `Models` namespace

The default Laravel directory structure places most of your application logic within the app directory, in which several Artisan commands will generate files within a predefined directory/namespace for you. As an example, php artisan make:request SaveArticle will create a new file named app/Requests/SaveArticle.php which is also namespaced for you under App\Requests.

But how about your application's Models? The documentation regarding directory structure states that:

"When getting started with Laravel, many developers are confused by the lack of a models directory. However, the lack of such a directory is intentional. We find the word "models" ambiguous since it means many different things to many different people. Some developers refer to an application's "model" as the totality of all of its business logic, while others refer to "models" as classes that interact with a relational database... "

That's fair enough, I must say. But personally, after working on a bunch of Laravel projects, I see that Eloquent models start to clog up the root app directory more often than not. So I suggest that from the start (with the default User model), create and move your Eloquent models within a Models directory. Down the road when you need more separation, you can easily add a Models\Billing or Models\Customers depending on your problem domain.

2. Use an in-memory SQLite database for testing

I personally feel like this should be the out-of-the-box configuration for Laravel. When you run your test suite, PHPUnit will honor the contents of your phpunit.xml. One of the very first things that I change for a new Laravel project is to use an in-memory SQLite database instead of creating a traditional RDBMS like MySQL or PostgreSQL specifically for tests. This will make test execution faster, and if you stick with standard SQL commands, can be a huge benefit for running CI tests.

To do this, you need to edit your phpunit.xml set the DB_CONNECTION and DB_DATABASE within the <php> block:

<php>
  <env name="DB_CONNECTION" value="sqlite"/>
  <env name="DB_DATABASE" value=":memory:"/>

  <!-- omitted for brevity... -->
</php>

3. Install Telescope for development

After struggling a bit with setting up and production issues, I've finally settled in and accepted Laravel Telescope as a staple for my current and future projects. This little first-party tool gives your development experience a nice boost. It allows you to inspect requests, render sent mail, watch your queue live, and a whole lot more.

Just make sure to read the installation instructions carefully so you won't yourself into weird issues down the line.

4. Change the application name

This is more of a consideration if you're building a package that is meant to be reused, but you might want to change your application name so that the app directory will be namespaced according to your preferred name, instead of just App. An Artisan command is available that does this exact thing:

$ php artisan app:name Foo

This will namespace your app directory, so that App\Providers will be Foo\Providers etc.

5. Change the frontend preset

A web application can be expected to do some extensive front-end work in its lifetime. Laravel gives us some excellent front-end tooling for free with Laravel Mix and the pre-generated VueJS structure that can be found within the resources/js directory. But do you know that you can just as easily swap this preset with React or even remove the preset entirely? Just go ahead and

# Swaps from Vue to React
$ php artisan preset react
# ... or remove the scaffold and go vanilla!
$ php artisan preset none

Conclusion

We covered some techniques that you might consider for your new Laravel project. Again, feel free to adapt, remove, or extend these ideas depending on the needs of your project. Remember to make smart decisions across the lifetime of your project!

Do you have any questions? Feel free to contact me on Twitter @alchermd. Until next time!

Forem: John Alcher

Automated Cloud: Web Hosting Basics

Introduction

The Tasks

Task #2 - Web Hosting Basics

Deploying a static page onto an EC2 instance

Making it repeatable: EC2 User Scripts

Automation

Automated Cloud: Introduction

Introduction

Motivation

The Tasks

Task #1 - Account Basics

Personal IAM User

MFA, disable root API keys

Billing Alerts

Automation

Transferring a Jekyll Blog from Vercel to AWS

Introduction

Background

The End Goal

Something Live on the Web

The AWS CLI

Conclusion

Do you write tests when exploring a new idea?

What to test in Django: Endpoints

Introduction

Endpoint Testing: Django REST Framework

Get them bread: DRF ViewSets and Serializers

Test Browse and Read Endpoints

Test Add and Edit Endpoints

Test the Delete Endpoint

Conclusion

Footnotes

What to test in Django: Models

Introduction

Anatomy of a Django Model

Testing Model Fields

Testing Model Relationships

Intermezzo: What's up with these tests?

Testing Model Methods

Conclusion

Footnotes

React, Django, and PostgreSQL Dockerized — Part 1: Development Setup

Introduction

Goals

Starter Kit

Explanation

Usage

Conclusion

Care to share some painfully funny debugging stories?

Practical Tips for Handling Forms in React

Preface

Contents

Introduction

Create a Generic onChange Handler

Reset a Form through an initialState

Move State Closer to Forms

Conclusion

Links and References

Heroku: Go with MySQL Notes

Contents

Introduction

The App

Provisioning

Gotchas

Links and References

Laravel: Queued Notifications for a Deleted User or Eloquent Model

Contents

Introduction

Our Problem at Hand

The Obvious Symptom

Solution

Don't Forget The Tests!

How about Regular Eloquent Models?

1. Pass an array representation of the model

2. Pass only the relevant model fields

Conclusion

Five Things to Consider for a Fresh Laravel Project

Introduction

Create a Generic `onChange` Handler

Reset a Form through an `initialState`

1. Move your Eloquent models into a `Models` namespace