DEV Community: iwaduarte

Creating a blog. A complete guide to move towards madness.

iwaduarte — Mon, 25 Sep 2023 17:06:06 +0000

I was chilling...

That it is not me, but indeed is chilling on this paradisaical island (DALLE-2).

When I started creating my site, I had in mind two things:

I needed to show that I was capable of delivering good code and that I understood things at a high level ("senior").
It had to be easy to develop the website, thus I could focus on coding, articles, and features.

These ideas were old (early 2018). Way older than the influx of new developers, COVID-19, the IT crisis, and layoffs. I wanted to
enter, at the time, a very competitive market: working remotely. For that, I needed a stunning website. I did not do much
at first, my first website was kind of ugly, it had no articles but a dummy bot that caught the attention of just one nice recruiter.

Forward to 2022, I needed a better UX/UI and my sister helped me create a design
for me. One thing came to mind, where would I put my articles? I wanted to write things, and make jokes, and make my mistakes.

One great platform was Medium. Simple, I thought. I will just hyperlink everything to Medium and get some data from their API to
display only the initial information on my site. The problem is. Medium is not that great, they make integrations look bad. They discontinued their API and made it
hard to scrape as well. People created tutorials on how to circumvent that. It is a pain to do it.

I barely had any articles, and one solution worked if you had less than 10 posts. So I did that. Serverless in mind, I would create a lambda function
that would grab the page, parse the data, and return a formatted object to the requester.

//articles.js
const { XMLParser } = require("fast-xml-parser");
const axios = require("axios");

const parser = new XMLParser();
const response = {
statusCode: 200,
headers: {
"Content-Type": "application/json",
"Access-Control-Allow-Origin": "*"
},
isBase64Encoded: false
};

exports.handler = async () => {
const xmlData = await axios
.get(`https://medium.com/feed/@iwaduarte`)
.then(({ data }) => data);

const javascriptObject = parser.parse(xmlData);
const items = javascriptObject?.rss?.channel?.item;

const newItems = items.map((item) => {
const {
category: categories,
guid,
title,
"dc:creator": author,
"content:encoded": content,
} = item;

    const description = content.substring(0, 300);
    const partialContent = content.substring(
      content.indexOf(`<figure>`),
      content.indexOf(`<figcaption>`)
    );
    const thumbnail = partialContent.replace(/.*src="(.+)".*/, "$1");
    return { categories, guid, title, author, description, thumbnail };
});

response.body = JSON.stringify(newItems);
return response;
};

That would work for months and I would be okay if Medium did not limit the number of posts to 10 and if I did not have
errors when grabbing content because my regex was not properly set (no matter how I changed it).

As you can see, the images are broken or incorrect, and only 7 articles are shown

To make things worse other people's articles started to become blocked and not even clearing the cache would work anymore. They started
limiting people. They started a massive enshitification through paywalls.

If you have not seen it I have also talked about that here.
In short, enshitification is the act of making the services on the web worse over time.

And that started bothering me. I mean. I write on your platform, and you can not even give me the right to read articles?
You do not even allow me to easily grab a few articles and post metadata to use on my site? You need therapy for your controlling issues mate.
And I need to stay away from you (or at least partially).

I was chilling man, I swear...

Migrating to Astro

My site is mostly static. I was looking for a solution where I could start writing that involved the minimum changes possible.
After lots of investigation it came down to Next.js and Argo. With Argo being the recommended choice for my use case.
No need for server-side mambo jambo, and thousands of tools, just the simplicity out of the box. The plug-and-play approach.

If you are already using CRA I recommend following these steps:

Migrate to vite : Migrate to Vite from Create React App
Update to Astro:

  npm uninstall @vitejs/plugin-react
  npm install astro @astrojs/react

Rename vite.config.js to astro.config.mjs
Inside astro.config.js rename import react from '@vitejs/plugin-react' to import react from '@astrojs/mdx'
In package.json rename the "scripts" properties commands from vite to astro
Create a folder called pages inside the root directory
Create a file called index.astro inside pages
Put the content of the index.html inside index.astro and import your App.jsx

---
// index.astro
import App from '../App.jsx';
import '../style.css';
---

<head>
  <meta charset="utf-8" />
  <link rel="icon" type="image/png" href="/favicon.ico" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <meta name="theme-color" content="#000000" />
  <meta name="description" content="iwaduarte portfolio dev fullstack" />
  <title>@iwaduarte</title>
</head>
<App client:only='react'/>

Run npm run dev
If you are starting from scratch I recommend following the Astro documentation.

That should be sufficient to migrate or start your application. You are now using Astro as your framework. Astro uses the concept of micro-frontend and islands which means that you can use React, Svelte, and Astro combined without having to migrate anything.

Concerning blogs, Astro uses markdown by default as an option to create your blog posts. It is an easy markup language for creating formatted text that is adopted across several websites, it is well-supported and can be converted to HTML, PDF, etc. Websites like GitHub (README.md) and Reddit support user-generated markdown content which makes its use more appealing.

Creating content with ASTRO

Astro gives you a powerful way of setting up content. Which is the content folder. It is that simple!
The context folder will be important because will give you Astro APIs that allow you to grab info on your static files. Inside this content folder you will have to put either valid .md (markdown) or .mdx files.

These files will contain all your text. Let's set a very simple example so you can use it inside your platform:

Create a content folder inside the root folder.
Create a blog folder inside content
Create a file called my-first-post.mdx
Create the following

---
title: My first post
subtitle: Hey, hey, hey.
description: ""
tags:
- introduction
author: Yo
date: "Some date"
slug: /blog/my-first-post
---

Every programmer would be like:

It doesn't work... Why?
It works...? Why

The power of MD and MDX files

With markdown files, you can write things like "###" and "[]()" and that will respectively stylize a header text and create a link. It is so intuitive that once you get the gist of it and set things up will be writing like
Stephen King!! Maybe, not like him. But at least fast.

Markdown does not support JavaScript by default. To solve that, and to add integration with jsx mdx was created. You can use jsx combined with markdown. Which is great for framework components. You can extend mdx functionality with plugins. You can create content faster if use javascript only. I will show a great example later. For more info about mdx please check their amazing website: https://mdxjs.com/docs/what-is-mdx/

Migrating articles from MEDIUM

Now things start to get more serious. You have set up everything. Your migration to Astro works, and you need to import all your posts from Medium.
This is a very delicate topic. I am sorry, but currently, it is not an easy task. It is a long process but with this guide, you will wish you could find me a buy me a coffee (I hate coffee, so I will pass).

If you do not want to port your old posts because you are averse to long processes, you can start writing brand new from your new Astro application and keep the old posts as hyperlinks. I do recommend however that you grab a cup of coffee, tea, or chocolate and embark with me on this journey.

We are going to use two packages: miry/medup and medium-to-markdown

miry/medup

macOS

If you have a linux or macOs system the installation will be a breeze.

brew tap miry/medup
brew install medup

Windows

For Windows is mandatory to use WSL. This package runs with the Crystal Language which is not fully supported in Windows.

Install WSL2 with Ubuntu on Windows

Open PowerShell as Administrator and run:

wsl --install

Install Ubuntu from the Microsoft Store. You can find Ubuntu under the Linux section.
Launch Ubuntu from the start menu. The first time you launch it, it will complete its installation and ask you to create a user and set a password.

Linux and Windows (WSL2 Ubuntu)

Before installing Homebrew, update and upgrade the Ubuntu packages by running the following commands:


sudo apt update
sudo apt upgrade

Install Homebrew by pasting the following command in your Ubuntu terminal:


/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Setup Homebrew Environment Variables: After the installation, add Homebrew to your shell profile:


echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> ~/.profile
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

Install medup


brew tap miry/medup
brew install medup

Usage:

You have medup installed now.

You are going to grab all your articles in Medium using the command below. The USERNAME is the same as the one used on the url medium.com/@USERNAME

medup -u USERNAME -d posts/USERNAME --assets-images

Note: If you are on Windows and want to access the folder path you can run:

explorer.exe .

You can grab all files and posts and move them to your content/blog/ folder previously set. This library is great at downloading formatted files but some errors could occur:

does not give you the assets: you will have to manually download your images
does not properly format bold text: it will give spacing between bolding ** word** when it should be *word*
not downloading some articles

Apart from that the files are almost properly formatted in Markdown, which gives you 90% of the job done.

For the remaining articles (if for some reason they have not been downloaded) you will use the second library. It is way poorer implementation than the @medup one, but it will give you a markdown-ish file to work with. Hopefully, you will have a few files for using this library.

medium-to-markdown

Install npm if not already installed
Clone the repo

git clone https://github.com/dtesler/medium-to-markdown.git

Navigate to medium-to-markdown folder
Run

 npm install

Individually find the article post URL and run the command:

npm run convert https://medium.com/@USERNAME/article > article.md

Move the files to the content/blog/ folder previously set.
Rename the files to have small filenames, make it easy to type inside the browser (i.e. 06-08-2023-a-very-big-title-name.md => small-title.md)

In possession of your markdown files, you will have to fix the errors discussed above. That should take you a good chunk of your time if you have many files
however if you have an IDE and know some regex like this one (!\[(.+[\)\.]).+\.\w+\)) things can go way easier. Just use that regex to match tags
and use the power of capturing groups to replace things that you would need. And voilà, you are now a mass editor.
Like I keep saying in most of my posts, I got your back mate.

Once everything is properly formatted we can start displaying the posts on your platform.

Displaying my posts

You will now dynamically set a router file to be able to display your posts from the content without having to manually
create a file every time you create content. For that, follow these steps:

Create a blog folder inside pages
Create a file called [...slug].astro
Inside that file put the following code

---
import { getCollection } from 'astro:content';
export async function getStaticPaths() {
  const blogPosts = await getCollection('blog');
  return blogPosts.map(post => ({
    params: { slug: post.slug.replace('/blog','') }, props: { post }}
  ));
}

const { post } = Astro.props;
const { Content } = await post.render();

---
<Content/>

Return to your content/blog files to have the following slug in the frontmatter

---
slug: /blog/small-title
---

You can go to your browser and type http://localhost:4321/blog/small-title and you should be able to see your blog post.

Embedding YouTube videos

You may have noticed that some of the YouTube videos and Codepen links that were on your site are appearing as links or looking broken.
Unfortunately, markdown does not support embedded links. The good news is that mdx with a little bit of configuration can make your site beautiful
again without using complicated JSX or any other configuration than a simple markdown.

From now on all your files are going to be renamed to .mdx, or at least the ones that need videos on the page and other advanced integrations.

Install the mdx integration and plugins

npm install @astrojs/mdx
npm install @remark-embedder/core @remark-embedder/transformer-oembed

Update the file astro.config.mjs

import { defineConfig } from 'astro/config';
import react from "@astrojs/react";
import mdx from '@astrojs/mdx';
import fauxRemarkEmbedder from '@remark-embedder/core'
import fauxOembedTransformer from '@remark-embedder/transformer-oembed'
const remarkEmbedder = fauxRemarkEmbedder.default
const oembedTransformer = fauxOembedTransformer.default

// <https://astro.build/config>
export default defineConfig({
  integrations: [mdx(
    {
      remarkPlugins:  [[remarkEmbedder, {transformers: [oembedTransformer]}]]
    }
  ), react()]
});

And that is it. To run a YouTube video you just need the YouTube link:

Tip: You need to style the iframe afterward for things like width, height, margin, etc.

🎉 Congrats 🎉🎉🥳

Now you have migrated and set up a powerful static website. It is time for celebration. Go for a walk.
Go kiss your wife and children. Play 15 minutes of chess or Dota2. Come back when you are fully recharged.
We need a few more steps to be able to claim the full benefits of this solution.

Cross-posting and POSSE

See I am not Kent C. Dodds or Dan Abramov. I am not popular. Medium however is a gigantic platform.
They invest millions of dollars every year. They have engineers, marketers, salespeople, and a huge influx
of website access.
People like you and I can not compete with them, we also can not be too much dependent on their "misalignments"
(thus the migration). We have to find a middle ground to get the most out of this relationship.

With that idea in mind comes the term POSSE - Publish (on your) Own Site, Syndicate Elsewhere.
It is a cool idea that I have found in several good articles:

We will use their reach and they will use our text for a win-win situation.

For posting things in an easy way I literally had to stop writing this article to help with a tool that does most of the job but it is kind of broken.
Yeah yeah. I know. We have been there before. But not this time mate. This time I have taken the time and made some pull requests that I
expect to be integrated into their package.

Actually, forget about the PR request. I have created a way better library for that. It is called crossposting
it solves the problem of POSSE for you, and it is better than the others (seriously, I have spent one week just writing that). It allows you to publish to 3 main sites:
dev.to, hashnode, and medium.

For installation execute the following:

npm install crossposting -g

Now you are going to configure the platforms by setting their individual keys:

# [platform]: dev | hashnode | medium
cpt setk [platform]

You have to find the tokens/API keys of each platform you intend to cross-posting. The repository has a nice tutorial
here.

Once everything is configured is time to use the tool to crosspost and profit. Navigate to the blog folder that we have set and
execute the command below:

cpt <url|path> -p dev

Where path is the name of your blog article if you are publishing from a local file and url if your article is already posted on some website.
In my case I have a local file with frontmatter metadata, which would be something like this:

cpt ./08-creating-a-blog.mdx -p dev

Nice!

Nice :P

If everything goes well. You should see your post on dev.to with images set and ready to go. The post is set for draft but when you start
using the tool you can confidently publish directly to the platform, you can even add to your integration deployment (ci/cd) tool.
Again, check the documentation it is easy to follow.

So that is it. Once more, I hope I have brought you a little bit of happiness. This is a very thorough article, I believe. If you have any doubts or suggestions, please let me know so I can help you with it.
If you think that this is amazing please leave a like, a comment, or just ignore it with love.

Cheers mate.

Node creator says you should strive for simplicity.

iwaduarte — Fri, 22 Sep 2023 05:43:25 +0000

A frustrated user. (DALLE-2)

I hate almost all software

It’s unnecessary and complicated at almost every layer. At best I can congratulate someone for quickly and simply solving a problem on top of the shit that they are given. The only software that I like is one that I can easily understand and solves my problems. The amount of complexity I’m willing to tolerate is proportional to the size of the problem being solved. (Ryan Dahl)

https://tinyclouds.org/rant

Stop the noise.

iwaduarte — Fri, 22 Sep 2023 05:39:37 +0000

With all this knowledge on the internet, people should cut the crap out of it when creating videos. There is too much bloated information already.

That way, when creating videos, please aim to:

Topics in description
Less prolix approach (less talk and more action!)
Less self-promoting (although is hard)
Deeper topics if possible.

And now I am creating rules, right? Yep. Let’s forget that this post is an utterly nonsense bullshit rant for a moment and appreciate a world where information is good, non-biased, and straightforward.

[AWS] Using API Gateway for S3 Uploads to Trigger Lambda Functions

iwaduarte — Fri, 22 Sep 2023 05:33:20 +0000

I have stated a few posts back that I would make a tutorial like that. And yet due to procrastination, I did not do it. Also, there are a lot of tutorials on the internet that try to achieve the same thing.

And that conflicts with my statement of no bullshit, no copy/pasta, direct-to-the-point mottos. When I had the idea to create this tutorial it was years ago. I had researched extensively to create a test framework for a company for which I was a consultant.

At the time, serverless was being born, and not many tutorials or tools were available. I had to resort to the few that were there and a lot of sweat and pain through the hell which is the AWS documentation.

I got to a pretty decent solution and thought: "Awesome if I could share this, someone would expend less time and I would win hearts in my goal of conquering and destroying worlds". Epic.

(https://makeameme.org/meme/planning-world-domination-418f014b3d)

Nowadays we have chatGPT which gives you half-terrible answers to some topics and very good ones to others. Now serverless has been elevated and bashed.

For that reason, a tutorial in the old format would be pointless. Thus, I will try to come up with a revision of other tutorials and add my flavor to it.

Let's begin with our architecture. I want to send images to S3 using only AWS API Gateway as a proxy. These images once there will be checked for dimensions, resized if larger than 1024x1024, and if its size is bigger than 5MB deleted.

Our intended architecture ( app.cloudcraft.co )

Why use API Gateway as a proxy instead of using lambda?

Someone created a tutorial at:

https://lumigo.io/blog/the-why-when-and-how-of-api-gateway-service-proxies/

For the lazy ones:

"Cold starts:

...However, some applications have more strict latency requirements. Or maybe if the API is part of a call chain that involves multiple Lambda functions. In which case the cold starts can stack up and become problematic as a whole, even if individually they're fine."

"Cost:

Having a Lambda function in the mix means you also have to pay for the Lambda invocations as well as associated costs such as CloudWatch Logs."

"Limits

Lambda also has two concurrency limits. ThereΓÇÖs the total number of concurrent executions of ALL functions in the region."

(extracted from lumigo.io)

I would add other points here. Simplicity. Less maintenance. Configure and forget. Powerful scaling solution.

For our use case, we are going to use the Serverless Framework to speed things up.

Create a folder called upload-s3.
Go to your terminal. Navigate to the folder created.
Install these dependencies on your project:

npm init -y  
npm install -g serverless   
npm install -D serverless-apigateway-service-proxy serverless-domain-manager

Create a .env file inside the folder with a few variables that will help set your AWS services upon deployment.

CUSTOM_DOMAIN=images.yourdomain.com  
CERTIFICATE_ARN=arn:aws:acm:region:account-id:certificate/certificate-id  
SECRET=DONOTDRINKTHEKOOLAID

Create a serverless.yml file:

# Name of the service  
service: upload-s3  
# Use environment variables from .env file  
useDotenv: true  
# Provider-specific configuration  
provider:  
  name: aws  # Cloud provider  
  runtime: nodejs18.x  # Runtime language and version  
  # Deployment stage (default to 'dev' if not specified)  
  stage: ${env:stage, 'dev'}  
  region: us-east-1  # AWS region  
  versionFunctions: false  
  environment:  
    # Environment variable for the S3 bucket name  
    BUCKET_NAME: ${self:service}-apigateway-proxy  
    SECRET: ${env:SECRET}  
  iamRoleStatements:  
    - Effect: Allow  
      Action:  
        - s3:*  
      Resource:  
        - arn:aws:s3:::${self:provider.environment.BUCKET_NAME}  
        - arn:aws:s3:::${self:provider.environment.BUCKET_NAME}/*  
  apiGateway:  
    binaryMediaTypes:  
      - image/png  
      - image/jpg  
      - image/jpeg  
      - image/gif  
      - image/x-icon  
      - application/octet-stream  

# Lambda functions  
functions:  
  jwtAuthorizer:  
    handler: authorizer.jwtAuthorizer  # Path to the JWT authorizer function  

  checkFileSize:  
    # Path to the function that checks file size  
    handler: handler.checkFileSize  
    # Triggered when a new object is created in the S3 bucket  
    events:  
      - s3:  
          bucket: ${self:provider.environment.BUCKET_NAME}  # Reference to the S3 bucket created in Resources  
          event: s3:ObjectCreated:*  
          rules:  
            - prefix: temp/  


# AWS CloudFormation Resources  
resources:  
  Resources:  
    Authorizer:  
      Type: AWS::ApiGateway::Authorizer  
      DependsOn:  
        - JwtAuthorizerLambdaFunction  
      Properties:  
        AuthorizerResultTtlInSeconds: 0  
        IdentitySource: method.request.header.Authorization  
        Name: jwtAuthorizer  
        RestApiId:  
          Ref: ApiGatewayRestApi  
        Type: TOKEN  
        AuthorizerUri:  
          Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${JwtAuthorizerLambdaFunction.Arn}/invocations  
    LambdaInvokePermission:  
      Type: AWS::Lambda::Permission  
      DependsOn:  
        - JwtAuthorizerLambdaFunction  
      Properties:  
        FunctionName: !GetAtt JwtAuthorizerLambdaFunction.Arn  
        Action: lambda:InvokeFunction  
        Principal: apigateway.amazonaws.com  
        SourceArn:  
          Fn::Sub: arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ApiGatewayRestApi}/*/*  

# Custom configurations  
custom:  
  apiGatewayServiceProxies:  
    - s3:  
        path: /images  
        method: post  
        action: PutObject  
        bucket: ${self:provider.environment.BUCKET_NAME}  
        pathOverride: 'temp/{object}'  
        key:  
          queryStringParam: filename  
        cors: true  
        authorizationType: CUSTOM  
        authorizerId: { Ref: Authorizer }  
        requestParameters:  
          'integration.request.header.x-amz-acl': "'private'"  


    - s3:  
        path: /images/{filename}  
        method: get  
        action: GetObject  
        bucket: ${self:provider.environment.BUCKET_NAME}  
        key:  
          pathParam: filename  
        cors: true  
        authorizationType: CUSTOM  
        authorizerId: { Ref: Authorizer }  

  # Comment it out if you do not want a customized domain.  
  customDomain:  
    domainName: ${env:CUSTOM_DOMAIN}  # Custom domain from environment variable  
    certificateArn: ${env:CERTIFICATE_ARN}  # Certificate ARN from environment variable  
    stage: ${self:provider.stage}  
    createRoute53Record: true  


plugins:  
  - serverless-apigateway-service-proxy  # Plugin to simplify API Gateway service proxy configurations  
  - serverless-domain-manager # Comment it out if you do not want a customized domain.

Run serverless: You should have an AWS account created. If not create it here. After that, create an IAM User with permission to run your lambda and services. The configuration will be saved on your computer for future use. ( If you already have an AWS account set and configured on your PC this part can be skipped.)

Create the authorizer.mjs file and install its dependency:

npm install jsonwebtoken

import jwt from "jsonwebtoken";  

const { SECRET } = process.env;  

export const jwtAuthorizer = async (event) => {  
  const { authorizationToken, methodArn } = event;  
  try {  
    jwt.verify(authorizationToken, SECRET);  
  } catch (err) {  
    throw new Error("Unauthorized");  
  }  
  return {  
    principalId: "user",  
    policyDocument: {  
      Version: "2012-10-17",  
      Statement: [  
        {  
          Action: "execute-api:Invoke",  
          Effect: "Allow",  
          Resource: methodArn,  
        },  
      ],  
    },  
  };  
};

Create the handler.mjs file and install its dependency:

npm install --arch=x64 --platform=linux --libc=glibc sharp

import {  
  S3Client,  
  HeadObjectCommand,  
  DeleteObjectCommand,  
  GetObjectCommand,  
  PutObjectCommand,  
} from "@aws-sdk/client-s3";  
import sharp from "sharp";  

const s3 = new S3Client({});  

export const checkFileSize = async (event) => {  
  const bucket = event.Records[0].s3.bucket.name;  
  const key = decodeURIComponent(  
    event.Records[0].s3.object.key.replace(/\+/g, " "),  
  );  
  const params = {  
    Bucket: bucket,  
    Key: key,  
  };  

  const { ContentLength, ContentType } = await s3.send(  
    new HeadObjectCommand(params),  
  );  

  if (!ContentLength) return;  
  if (ContentLength > 5 * 1024 * 1024) {  
    await s3.send(new DeleteObjectCommand(params));  
    console.log(`Deleted ${key} as it was larger than 5MB`);  
    return;  
  }  

  const { Body } = await s3.send(new GetObjectCommand(params));  
  const BodyBuffer = Buffer.concat(await Body.toArray());  
  const metadata = await sharp(BodyBuffer).metadata();  
  const newKey = key.replace("temp/", "");  
  const shouldResize = metadata.width > 1024 || metadata.height > 1024;  

  const newBody = shouldResize  
    ? await sharp(BodyBuffer)  
        .resize(1024, 1024, {  
          fit: "inside",  
          withoutEnlargement: true,  
        })  
        .toBuffer()  
    : BodyBuffer;  

  shouldResize && console.log(`Resized ${key} to ${newKey}`);  
  console.log(`Moved ${key} to ${newKey}`);  

  await s3.send(  
    new PutObjectCommand({  
      Bucket: bucket,  
      Key: newKey,  
      Body: newBody,  
      ContentType,  
    }),  
  );  

  console.log(`Deleted the original file ${key}`);  
  await s3.send(new DeleteObjectCommand(params));  
};

Serverless vs CloudFormation

There are a lot of things happening above and we will touch on most points. If it is the first time you are dealing with serverless do not worry. If you are a more seasoned developer you can skip this part.

The serverless framework is a way of automating the myriad of configurations that AWS requires you to do to create their services programmatically.

There are a lot of ways of creating services via code with AWS. One of them is to use the CloudFormation service.

https://www.youtube.com/watch?v=Omppm_YUG2g

In the end, CloudFormation is just a YAML file with directives of what to create and how to create.

Import note:

Back then, this main tutorial inspired me and used a full-fledged resources feature and no serverless plugins. Thankfully for us, the plugin s*erverless-apigateway-service-proxy* is well-developed now and all boilerplate can be avoided. You can check the differences between our code and theirs by looking at this repo:

The serverless framework helps you by creating a more simplified version of a CloudFormation.json file and other configurations that are handled for you. In the end, you will only need to type:

serverless deploy

And that will be it.

Going through the serverless.yml

I have added comments on the serverless.yaml file above but I want to touch on a few points:

iamRoleStatements: Roles are temporary credentials that accounts or services can acquire. These roles let you manage/access/modify/listen to other services.

binaryMediaTypes: Every request sent to API Gateway is by default treated as text. So it is important when sending binary data (images, audio, etc.) to specify the type to prevent unwanted coercion/parsing/encoding and therefore data corruption.

functions:

Functions are the whole grail. There you add your code and forget about everything else (after the initial configuration) and that is serverless in a nutshell:

"Forget about everything. Think about your logic and code, we handle the rest."

jwtAuthorizer: This function is responsible for making the endpoint secure. Only authorized requests are allowed. This configuration is used in conjunction with the serverless-apigateway-service-proxy plugin.

checkFileSize: This is the function of our logic. It is responsible for checking the file size and deleting it in case surpasses our defined limit of 5MB and resizing images with dimensions higher than 1024x1024. I am using the package sharp for that. As you can see I have defined directives when installing it which will ensure the binary for lambda is installed.

Resources: This is the extra stuff and extra resources that you will add when the serverless framework and its plugins have failed you. It is here that you will define everything and it is pretty much copied to a CloudFront file without much alteration. For instance Authorizer: Type: AWS::ApiGateway::Authorizer will create an authorization layer in AWS that connects API Gateway to our function to ensure proper access. You can see all types of resources/services here.

custom: Here is where the pluginΓÇÖs configurations are defined. AWS is a monster with 200+ services and even the Serverless Framework can not cater to all types of needs and uses. Sometimes plugins are the best bet, sometimes we need to create everything using resources. Sometimes we just cry.

apiGatewayServiceProxies: Our serverless-apigateway-service-proxy plugin

customDomain: Our domain plugin: serverless-domain-manager

Wait what? Domains? What is that?

Domains are names (i.e. www.google.com) that point to IP addresses. When the whole serverless stack is created the naming for accessing the API is something like this:

https://api-id.execute-api.region.amazonaws.com/stage

This name can be customized with your own domain. LetΓÇÖs say you have bought your domain for your site and it is called: coolpeopleneverdies.com and you like our whole application to update images to: images.coolpeopleneverdies.com.

That is what the plugin is for. For managing and simplifying the images.coolpeopleneverdies.com part. You do not want to send that ugly ass link to your friends to flex your skills with AWS. You would like to use the domain that you bought and it is beautiful.

Before using that plugin you need to know that is mandatory (only if you want custom domains) to buy and configure your domain, the certificates, and records.

Here we have two nice tutorials on how to do it:

Route53 (inside AWS):

https://www.readysetcloud.io/blog/allen.helton/adding-a-custom-domain-to-aws-api-gateway/

Without Route53 (external domain registrar)

https://medium.com/@sameera.godakanda/custom-domain-names-for-api-gw-e1deefe27ed

Note that, the serverless.yaml file in our tutorial is configured for having the domain inside Route53 as well as its certificate (the first tutorial is the desired option). Also, there are manual parts in both tutorials above that are being automated here. So, skip those parts and follow the tutorial here instead.

If everything is looking complex already, you can just disable the whole domain's shenanigans. I have placed comments on the serverless.yaml file on the lines you need to comment/delete so you can have your application and worry about that later. No big deal.

If again, you already have your certificate set and it is using your domains in route 53 everything here will be a breeze.

Going through the .env

The variables that you should set here are variables essential to your service to work. The variables set throughout the applications are:

CUSTOM_DOMAIN, CERTIFICATE_ARN, and SECRET.

Make sure to populate these in your .env file.

How about our SECRET?

We need these to make sure that our request is secure (authorized). I have decided to use JWT because it is simple to set up and is well-adopted for authorization.

Our secret alone will not do it. It needs to be signed with a header and a payload ( that is how JWT works).

Signing is like stamping a letter and saying and making sure that it will be recognized. We use cryptographic and shenanigans for that (HMAC if you are interested in the deep bottom of the sea)

We would probably programmatically use a package to obtain the signed version providing only the SECRET. However, in our case, and for simplicity we are going to use this jwt.io website. You are going to find a VERIFY SIGNATURE field, there you should add your SECRET.

I have set a public payload with “expires”: “1h” but you can add whatever you feel like.

Copy the encoded result. That is what we are going to need to authorize our requests.

Finally…The magic is happening.

After all this initial configuration you can run our final deployment:

serverless create_domain  
serverless deploy

It will create everything for you. If you wanna see the magic happening apart from the serverless logs you should go to AWS CloudFormation. There you will have detailed information about your stack recently created.

After finishing we should start testing it. To make things more dynamic I have added a testing video.

https://www.youtube.com/watch?v=COOmY-tLESg

And there you go. After watching this amazing scene you can see that images.iwaduarte.dev is uploading and retrieving images from S3 and doing proper modifications (following our logic established at the beginning of the tutorial).

I have also created a repository where you can check how the code integrates in case you feel like you cannot work it out from here.

You can access the repo here.

Do not for one second think that this implementation was without hiccups.

I had to read and re-read the documentation on a few parts and tweak it here and there. So you are not alone if you want to customize something and you are not getting anywhere. Keep working my young one you will get there.

Also, there are a lot of optimizations and things that could be added and I have skipped or ignored.

For instance, I am installing binaries for sharp for Linux although I am deploying inside a Windows machine. https://sharp.pixelplumbing.com/install#cross-platform
I am not packaging individual functions https://www.serverless.com/framework/docs/providers/aws/guide/packaging#packaging-functions-separately
I could have added layers https://www.serverless.com/framework/docs/providers/aws/guide/layers
I am not catering for local development https://www.serverless.com/plugins/serverless-offline
I am not working with streams. I could be using the Readable Stream from the s3 GetObjectCommand, the problem is that would require much more configuration since it is very hard to use metadata and resize (sharp methods) and streams. The metadata function reads the entire stream so I may as well simplify my code considering the files are small. For more info, you can check this answer: https://stackoverflow.com/a/66837302/7350853
I particularly do not like the domain manager approach, especially because it is a separate command with a lot of implications. I have set domain configuration only using resources and works better in my view. But I did not want to make things even more complicated for you.

Well, I did not want to create a book, and yet... here we are HAHAHAHAHAH. Thanks for getting here though. Hope this tutorial helps you become a better developer. Also, there are things you will need to figure out by yourself in case you need customization, that is the path mate. Embrace it. It is like life can be pretty easy sometimes and pretty intimidating too.

(https://www.amazon.com/Confucius-Philosophy-Demotivational-Sarcastic-Poster/dp/B08LF4JNX8?th=1)

Before I become too philosophical leave a comment and I will answer as I feel like it. Cheers.

GPT 4 and Why it is Good for Chrome to Crumble

iwaduarte — Fri, 22 Sep 2023 05:25:17 +0000

A long time without writing. Yeah, in a world of noise, I do not want to be this prolific AI copy/pasta that we see everywhere. The goal is to be less lazy but still try to be original (try because the temptation is real). Every word from here is from my own troubled mind unless is corrected for mistakes (I use Grammarly or whatever is suited for that).

I will introduce an extension today. It is called form-filler. Basically, fill out forms. Nothing special, not intended for everyday use but for people looking for jobs.

You could use it for anything if configured properly but that is not the idea. I’m unemployed right now, which totally sucks. But hey, I like building stuff. So why not waste my time crafting crap that no one in their right mind would want?

Like the old adage: “Automate 1 minute worth of 2".

My plan is simple: Fill forms faster, mass apply automatically, land thousands of interviews, and get rich quicker. Also, help anyone in the same situation.

The uniqueness of form-filler is that without using any external service is capable of uploading PDF files. The idea is to automate so you apply in sites like greenhouse.io, lever.co, workable.com and so many others without even having to click and select thousands of files by yourself. Trust me mate is pretty neat.

Okay, great idea. Great time developing. Let’s input to Chrome Web Store and be done with it. Wait a minute… Shhhhhiiiiii****t: They do not accept ManifestV2 for new extensions.

ManifestV2-V3-VX and why is that a problem?

I think it happens to all companies. They start nice. They found a unique idea and/or they are better than everyone else. They say to the world: Don’t be evil. They actually mean it the first time.

Everyone holds hands. It is like a scene from a Disney World movie with a rainbow at the end. Everyone is laughing. Popcorn, coke, pizza for everyone. Wow, what a dream company, what a future ahead of us.

Money comes in.

Pressure comes high. “Money” needs to be “escalated”. Don’t be evil they continue saying.

More money. More investors. More bad decisions.

A whole company culture can shift from making this world a nice one to:
Q1 did not profit so we need to achieve profit in Q2, in order to improve and increase and escalate for Q3 and Q4.

Elementary my dear reader, I am being simplistic. Of course, there are a lot of variables. But get this like a hyperbolic generalization of Google and its decisions over the years.

From really cool products and great vision turned into ash just because they did not earn enough or did not manage properly.
https://killedbygoogle.com/

From features in services that were free and became ugly, buggy, and less appealing.
https://www.androidpolice.com/2021/04/08/five-of-the-worst-things-google-has-ever-done/
https://arstechnica.com/gadgets/2021/03/the-new-google-pay-repeats-all-the-same-mistakes-of-google-allo/

From features that did not have the user interest at hand but profit. And I am talking about you Manifest V3. You are a scam artist stunt that uses heavy words like security, privacy, and performance.

Manifest V3 when Google is claiming its security

I am not the only one claiming that. Hundreds of people are saying the same.

https://www.eff.org/deeplinks/2021/12/chrome-users-beware-manifest-v3-deceitful-and-threatening
https://www.reddit.com/r/chrome/comments/xijfgk/manifest_v3_is_bad_for_users/
https://grantwinney.com/what-is-manifest-v3-and-why-is-google-pestering-me/
https://www.techrepublic.com/article/google-makes-the-perfect-case-for-why-you-shouldnt-use-chrome/
https://www.eff.org/deeplinks/2021/12/chrome-users-beware-manifest-v3-deceitful-and-threatening

The problem is that Google holds the majority of the market share when it comes to browsers(~62%). They can decide to ignore our complaints, after all, what can we do?

Profit-first mentality means pushing the agenda without the user’s concern. It is not good for the community. But hey. It is cool. Just accept it already.

If you are the bully in school, no one dares to stand up against you. And you call all the shots, right? Right?

The “Should be Open” company that is about gains too

I could restart here, new company NON-profit, make the world a better place, blah-blah-blah.
Let’s create an Open Artificial Intelligence company blah-blah-blah. Nah mate we need to put food on the table. You know the gist.

However, these guys opened the Pandora box. Sam Altman, Ilya Sutskeve (the main responsible for the ChatGPT code) and its engineering team were responsible for this revolution.

And kudos to these guys. Amazing innovation. Great disruptive technology.

If you lived under a rock and for some reason, you do not know what is chatGPT I will ask you to just come back to your rock. You have no quarrels here mate. Kidding. “Google” about it.

The idea was so great that shook the entire industry. Now you have a digital handyman that you pay nothing and you take all the credits. Love it.
Sign me up for it. And then millions did. Making the fastest-growing user base ever.

That alerted the attention of big players. The Call-Me-Evil-I-Do-Not-Care guys (aka Microsoft) joined the battle and started heavily investing in these technologies. I mean who would not want it? This is truly great technology.

And how the behemoth Google after being a prolific AI player did not have something similar?

The problem with making big bugs mentality is that innovation goes against it. Since innovation sometimes loses big bucks for no return at all. After all, innovation is research, development, testing, failures, and is not cheap at all.
We have seen before, thousands and thousands of companies that started to lose track even if did not look like it.

Blockbuster Entertainment Inc., Xerox Holdings Corporation, Kodak, etc.
https://www.forbes.com/sites/biancamillercole/2019/01/10/innovate-or-die-how-a-lack-of-innovation-can-cause-business-failure/?sh=382b33af2fcb

So Microsoft is amping the bets and Google is trying to recover, Open.ai is the new baby on the market. What does that have to do with ManifestV3?

“A war is made of many battles, maybe when weak we need to retreat” — Cap. No One

When you are losing market. And the sentiment is that you are not cool anymore. When the youngest are shifting their habits. Sometimes you need to realize that being stubborn will not take you anywhere.

And even if you are stubborn the new solutions that come with the new disruptive technology will embrace the neglected. In short, users will get heard eventually because that is the beauty of competition, I guess.

Companies like Firefox and others to come can grab a substantial part of the market share if played right. Google is losing battles and losing the market (albeit slowly). And this perception is crucial to make the right play.

We all moved from Internet Explorer to Firefox and then to Google. Maybe is time to reverse shift and Google does not have any moat left.

A sad feeling that it is all for nothing

Yep. So that is what I think will happen and that is why I am against Manifest V3 (those links are to be read Mr. Slacker). So I decided to not put my extension in the Google Web Store for the time being. However, I am aware that things can not go your way. And if I was great at predicting the market I would be rich (none is the case). Therefore, the feeling is just sadness.

You can still use my form-filler in Google though (Chromium-based browsers) and you can use it in Firefox if you already made the change. Everything is further explained here:
https://github.com/iwaduarte/form-filler

The worst part is that I have some ideas that could improve people’s daily lives and I could use the reach that Google has. But as the saying goes: If you can not win them, annoy them, criticize them, and then join them.
“Don’t be hypocritical”.

Also don’t get me wrong here. I do like money, a lot haha. It is not about margins or dividends but how you are smart about it. Google has amazing brain power. Every bright kid in the town (the world actually) wants to join it. But…politics, revenues, and short-sighted vision are making this ugly transition from the Google cool-kid to the Google bully-moronic and no one likes it.

Please be cool. Always. The coolest. Me.

Everything is so astonishing when you are cool. (DALLE-2)

Applying laziness to the extreme: A new code generator for Node.js

iwaduarte — Thu, 21 Sep 2023 16:33:15 +0000

In my dev journey, I have always “clicked” the lazy button. Lazy is the way pretty much like Dudeism is. Going with the flow and taking it easy until your boss is yelling at you about the bloody deadline.

Instantly, you wake up and rush to do the things you are supposed to. You are running behind schedule and your panic button starts buzzing. “The new project”, they said. In an attempt to give yourself hope, you shake your head look at the clock, and think: “I am so fuck**d”.

Fear not, my brave comrade. Here at Chaos Company Unlimited, we have your back.

I present to you the short version of this tutorial (tl;dr):
https://www.npmjs.com/package/express-sire

Go there, use it, and speed up the skeleton of your Node.js projects. Leave feedback, comments, and rages on the GitHub page (or not, be your own master MUAHAHAHA).

The long story is also called:

The Wizard, The Revolutionist, and The Draughtsman

When I was a baby…kidding.

The year is 2009 and a mate called Ryan is fed up with how JavaScript is being treated. A lot of bullies from their high-bloated OOP castles, throwing rocks and saying: “Java? — Script developers, please”. “Scum”. “Deserve to die, no less”

They chant at all corners with a little sense of pride. Not anymore. A magician at Google is creating a powerful engine. In the distant future, that engine name will baptize cars.

Ryan is young and naive and thinks all the time about revolutions. He hates complexity and bloated configurations. He heard that the wizard Lars Bak and his musketeers are making the potion engine available.

Quickly, he grabs the engine papers and starts developing his revolution. With time and to his surprise, millions would join his cause and he would be responsible for creating a massive battalion. The Node battalion. Fuck***g Node.js. By many historians the greatest battalion of all time.

In a tavern, a few hours from there a new designer for the black arts would have his moment to shine. He would join Ryan's army and help that naive crusade, he would be responsible for a decent part of Ryan’s battalion victories and fame.

And his name:
TJ Holowaychuk. (Pause here, I have to google every time to get this name right).

They killed, cursed and left their battalion afterward, but that is not the point…

Node is the runtime that powers everything. And that is all matter for now… (Deno and Bun are watching)

Back to TJ

TJ created thousands of packages (a “little” exaggeration to increase the narrative), things like express.js, commander.js, stylus, koa so on and forth.

The guy was so prolific that had people questioning if he was not a team instead of a person. He started as a designer with a level novice to become a one-of-a-kind developer.

That is the living proof that with dedication you can reach everything. (Bullshit. You cannot. But let’s give a hopeful vibe to that text).

Our mate created our beloved express-generator as well. What does it?
(See? I told you cannot reach everything). It generates a web server with the express framework. An easy and simple server created rapidly.

Express-generator generates files for you. Generates a web server for you. It generates all the boilerplate code so you do not have to type and create files and configure everything from scratch.

You can from there think about the logic. The business. The actual code. Instead of configuring things. It is simple enough that will not force you to write in a certain way or put through gigantic documentation so you can learn how to generate the “right way”. (Criticism intended)

It is good because express is good and simple. Therefore, it generates more of the simple. It is good for beginners and good for seasoned developers too.

What happened then? Why did you create express-sire?

I wanted to use a scaffold to increase my productivity. I want to be fast and lazy and the same time. Having configurations been done for me that I knew it would be the same for the thousandth time.

I looked at the solutions out there. Like a true JavaScript developer, I did not like it. No. They are not worse than mine. They are probably way more complex than what I did and that is why I like what I have done even more.

I have looked at yeoman and the express ones out here and nothing met my criteria, which are:

Be simple.
Up to date.
Simple
Stupid
Did I say simple?
Oh, working like a lego block is a must too.

You would choose what you wanted to be installed. If you want it this way okay. If you wanted that way, okay. I want this with that and that. Okay got it.
That is the whole idea. To provide a “click buttons generator that lets you choose what kind of delicious ingredients you want”

And simple and stupid enough like express-generator. So, I went there for wisdom. Ohh boy. It gets interesting…

The steps in building

The thing with express-generator is that it is getting old. And code gets old. It gets legacy. Because it is not as successful as it should 9.000 weekly downloads against 21.000.000 (express) it did not adhere to the current practices.

It still uses templating and pure/raw/old SSR. In an era of SPA, SSG, modern SSR, and micro-frontends the old way with templating is not as used anymore.

Still uses CJS (CommonJS). Node and packages are moving to ESM. It is a messy and painful process but still, it is coming and nothing can prevent it. JavaScript language is evolving (for the best or worse) and new practices are being adopted every year.

It does not offer the lego block. It is minimalist and I love this simple tool. But I am greedy and lazy and want everything done by a computer so I can get the credit.

With all that, I went and created a mutated version of this minimal tool.

I wanted to create the same way express-generator did. It creates templates by delegating some “options” to a templating engine in this case EJS.

EJS is a simple templating language that lets you generate HTML markup with plain JavaScript. (source)

A template file (app.js.ejs) inside the express-generator module would look like this:

Although EJS is used to generate HTML files, the strategy here is to use the same templating but to build a .js file. An elegant and great solution at the time. Nowadays it seems off.

EJS uses a method render to render and parse and everything else and it is a big library. It uses a lot of regex and functions and if and else's and it is a “complicated way” to create files. Especially in a world of Template Literals.

Note: I am not saying that EJS is bad. Far from that. I am saying that for our task is overkill.

We did not need any of the above. JavaScript built-in feature would carry us away and deliver the message. The idea is to create a file from this powerful sorcery (template literals) and others had the same concept too (here, here, and here).

With template literals being the choice now we need to define how would be the best way of “parsing” the string template into an actual JavaScript object. Some strategies were thought of.

First approach. Requiring the file:

Second approach. Combining it with regex:

Third and final. Using eval:

You can guess. I choose eval. “Wait did you say eval?” Yep. Eval.
“But..But.. Eval is E-V-I-L”. My comrade, avoid generalization and read the response above.

I will make it clear:

Although it can be dangerous to run JS code like this, if the templates are files that are in your control and written by you. I guess it can be done.

And that is how I did. Apart from that, I found an awesome explanation from Safia Abdalla. She wrote a short but interesting text about how template literals work under the hood. I will not spoil it because it is easy to read and get the gist of it.

https://dev.to/captainsafia/how-do-template-literals-in-javascript-work-under-the-hood-4g2b

Okay. Templates done. What else?

We need to provide users with an interface, so they can install or provide commands inside a terminal. For that, I have tried to keep the minimum possible number of dependencies without having to reinvent the wheel. It is always the same approach: less work and simplicity, yielding big results.

I have followed a few tutorials on the internet and I have read the express-generator codebase.

https://www.twilio.com/blog/how-to-build-a-cli-with-node-js

https://medium.com/henriquekuwai/criando-sua-cli-com-node-js-d6dee7d03110 (Portuguese)

https://www.sitepoint.com/javascript-command-line-interface-cli-node-js/

I did not follow their tutorial exactly but I got a good understanding of how it works and how it should work.

I worked with these beautiful libraries myself (as you can see in the package.json)

Chalk: to have beautiful colors.
Inquirer: to ask questions to the user.
Figlet: to have a badass ASCII lettering
Minimist: to parse cli input arguments.

I have also tried to keep the package so low on new JavaScript features that Node users from v10 could adopt it and use it, but that did not work as expected and I had to revert to support Node v12.

The package also installs things that I completely think are necessary but completely optional like:

ESM Modules or CJS
Git
Compression
Helmet
Sequelize

I have made a few decisions related to adding Prettier as a default installation. Because it annoys me that people are still arguing over things that I think are bike-shedding and code formatting is one of them.

All decisions apart I think this project is great and has a lot of paths to grow. I can (and will) implement more optional features so the user has everything it needs by lunch when the boss is yelling at the door and 15 minutes later, they are smiling with a project built to the awe of the audience.

See? I told you I would get your back covered. Fear not mate. We are here for each other.

Cheers.

More (external) reading:

Efficient, reusable application templates and scaffolding

Start New Projects Faster: 10 Scaffolding Web Dev Tools

Simplicity vs Performance: How to transition between the background color and an image

iwaduarte — Thu, 21 Sep 2023 16:14:25 +0000

When developing my new website https://iwaduarte.dev/ I wanted to have a “killer” feature: to hover over an element and have an image appear.

I didn’t know at the time, this apparently silly task would be a herculean one.

The path of a developer is the one where none cares. You spend weeks trying to learn and circumvent a difficult obstacle in order to increase the quality of a feature. To fix a difficult bug. Increasing the performance of an animation to improve CPU and memory usage. Compressing everything with gzip to have your files served faster from the back end. Dropping requests from 1 second to 0.2s by refactoring the architecture or properly indexing the database.

Does not matter, the result is always the same:

People do not care

How could they? They do not understand what task have you done or how long it took. How stressed you were or how hard you took on your shoulders. They did not experience it. They only saw the result and well: it looks okay but…

Complex jobs are difficult to measure and appreciate. What was the last time you kissed your open-source Android phone thanking the gods of development for a such beautiful piece of art?
Instead, you blamed the lags and silly configurations and everything else. And you are, my friend, a developer as well.

If we do not get the effort and understand the intricacies of a task is hard to get the whole picture. That is why every profession will have a time where someone asks you to do: “a simple thing that will cost nothing of you”.

For us are: “Could you build a better Medium/Instagram but with this better thing that I have thought of?”. For lawyers: “Could you listen to my sob story and offer free consultancy?”. For dentists: “Could look at my mouth and see why my teeth are so painful?”. Of course, the compensation is either minimal or non-existent.

All these freebies requests and hard time measuring other people's worthiness are because people lack the understanding of how hard is to accrue that knowledge/skillset or how hard is to build those things and everything else related. They are blind. They are oblivious.

For that reason, consider yourself as someone that should enlighten them and bring them closer to the problem. I promise they will pay attention if you deliver the bits and pieces as if they are a curious kid.

With that, I will bring you to the problem. Maybe you did not know that we had one.

The problem

The objective is pretty simple, we hover over a background element and smoothly appear a beautiful image.

Simple right?! Firstly you create a CSS like shown below adding the property on hover and the image. For smoothness, you would add the property transition. Yep. That does not work. (For more info on CSS transitions go here.)

codepen:

That would be step 1.

You could add transition and try swapping background with background-image and background-color. Try using opacity and everything else. That would not work. (You are welcome to try)

After a lot of attempts, you will either be frustrated and let it go or this absurd task or you would try to find a solution to understand why that bloody simple property is not giving you the expected results.

After googling and reading, you discovered that the property background-image is not animatable. Shockingly, background it is though and you try clever different techniques to no avail as well. Life is hard you think.

Those were the steps that I have done anyway. I have spent a few hours trying different approaches only to realize that 0 of them had any impact. Reading and trying answers from different sources on stack overflow did not make it either.

I have learned that in relation to transition:

background-image to background-imageworks in Chrome but does not work in Firefox. *(Google is not following the standard).*
background-color to background-color works just fine as the specs say.
background with a URL to background-color does not respect the transition property although both of them are in the specs as well.
Not even trying to set multiple backgrounds ( like background: transparent, url(image.png)) by making one of them transparent| rgba(X,Y,Z,0) would work because color needs to be the last one as shown in the MDN docs.

codepen:

Therefore, you learned that you cannot easily use the property transitionwith background-image. Stupid as it is, you would have to navigate to the realm of hacks and tricks and that realm is far from simple.

Hacks and tricks:

The internet:

Most of the internet had the same ideas that appeared to me either too complicated or bloated.

1 — Would have to set up a position property that would create a new stack context (i.e position: absolute, position: relative )

2 — You would have to work with pseudo::elements and most of the tutorials were using either ::before or ::after

3 — After the elements were stacked we would make one of them disappear by using transition property work with opacity

In my opinion, that would lead to a bloated solution, which made me furious. I spent so much time trying to write less code as possible and then for some reason I would have to circumvent this lack of implementation from the CSS committee with that amount of code…Shame!Shame!

I hated them for a brief period until I realized that in this story I am John Snow, do not know the whole picture and I am probably not bothered to investigate why the implementation was not done.

Ygritte yelling: “You know nothing John Snow” (DALLE-2)

Still as clueless as I am, I did not want to give up. Eventually, I would learn a different way, a simpler one. Keep digging, keep experimenting and you can achieve wonders I thought to myself.

Happily, I came up with a different solution. That for me was simpler than the whole “junk” I found on the internet. “It is the best and I am the best”. “I am proud”. “I am a genius”. I know every developer can relate to these feelings.

I have achieved the solution by using freaking box-shadow.

codepen:

Box-shadow is a property that works by adding shadow to a box. As you know by now everything on an HTML page is a damn bloody box. This property has a inset parameter that puts the shadow on top of the box instead of the corners.box-shadow is also animatable and we could use it with the transition property.

Solved. “Genius”. “Geniality”. “Einstein”. I was like, mate you are a beast. THE GOOOOAAAT. You did what no one ever did. Let’s test with another browser and be done with it.

And that is what I did. I made my ego so inflated by throwing nice compliments to myself that I forgot what is the drawbacks of this solution.

And boy. I am dumb.

The dumb boy who cried drawbacks

Firstly, there are concerns about animating box-shadow , they are not performant. They do not scale.

To understand that you should briefly know the CSS properties and browser animations.

Modern browsers are like black boxes, most developers do not bother knowing (including myself) all the nitty-gritty details of it. Modern browsers are beasts, made from people way smarter than any of us.

They are in the top 1%. They are the FANGers ( I will stop inventing words someday). And for that reason, we trust them blindly. The problem is they give us so many choices to work with and we end up doing the wrong approach, patting ourselves on the back and calling ourselves geniuses.

In reality, you should go and understand the details or at least have a vague idea of what is what. And for animations you could start here:

Why are some animations slow?

In summary, there are phases when a browser is trying to display something on a webpage, they are called rendering pipelines. They have 4 steps: the first step (Style) calls the second one (Layout) which calls the third one (Paint) which calls the last one (Composite).

Think of CSS properties living in one of these realms. Some of them would demand the browser to do all of it over again (box-shadow). Some will ask a lot less (opacity).

Also, by searching about box-shadow performances I have found a few articles as well:

https://tobiasahlin.com/blog/how-to-animate-box-shadow/
How do you animate the box-shadow property in CSS without causing re-paints on every frame, and heavily impacting the performance of your page? Short answer: you don’t. Animating a change of box-shadow will hurt performance.

https://blog.cloud66.com/box-shadow-transition-performance
Adding a CSS transition to animate the box-shadow of an element is a handy trick. It’s a design technique that’s often used on hover to highlight something. If you've used this effect you might have noticed that sometimes the performance can be sub optimal making the animation slow.

Stop animating box-shadows the wrong way! https://www.youtube.com/watch?v=u6Rur7G8HNY

All these articles/videos ask you to return to the very first solutions that we have encountered. They go to a detailed performance review as to why you shouldn’t use box-shadow animations. They recommend the “bloated” but performant ones. What should we do now?

The clash between simplicity and performance. The last chapter.

If you have read my previous articles, you would know that I am always striving for simplicity. It is my motto and how I try to do things. Simplicity is also an abstract concept. Sometimes it can be perceived by one but not the other.

Performance is also my baby. Why bother building something that doesn’t scale? That it is too costly because of that? The performance also indicates bad code, it is a metric that says: “Something is smelling funny here” or in other words, is a code smell indicator.

On these occasions that, to have one you have to let it go from the other, you have to ask yourself. Who is going to be hurt by that? Can I afford that?

Let’s say I work for Canva (Canva is a web app tool for design). And I am implementing this feature that is going to be used by millions. That I have to be performant otherwise I would end up losing customers, revenue, and money. And my work stability relies on that. You should come up with an answer here.

But now let’s say that I have a solid team, working on a feature that will not be used by many. Mostly internally. Although the team is very great together it lacks the skills to code CSS because their background differs. Would you hurt some performance for a more readable code in this scenario?

Now my scenario is that I have a website that few people would access and spend seconds on it. I have other things to do and I understand the drawbacks of my choice, should I change for performance? Should I stick with simplicity?

Note that these answers are not definitive. Each one of you could get to a solid and different argument of why you would not do X or Y. It is not about who is right. The idea here is to understand and have solid reasons as to why you chose to hurt one for the other.

Once we know the drawbacks of our choices, we expect that the decision will come easier. You would turn into a better developer and would grow to know that it is not always a black-white decision but layers of geniality and stupidity.

So that is my take for you. Whatever you do, be bold and stupid, aim for the best out there (either simplicity or performance) and know your damn drawbacks.

Good luck!

Deployment (GitHub actions, Bitbucket pipelines), the stupid way

iwaduarte — Thu, 21 Sep 2023 14:59:05 +0000

Every now and then someone will come up with new words: DevOps, GitOps, *.(*.)Ops, CI/CD, multifactor deployment pods orchestrated in virtual containers (I think I have invented that one).

Thing is, every single developer/team/company wants to achieve a simple objective. Have their files/product/”disruptive technologic” out there for the public to see. It is not always pretty though.

What is the best way of doing that?

Let me dress my armor, my friend, I will start running from the best practice war before we dive into that topic.

That is me, running from the war of best practices in my new shining armor. (DALLE-2)

People are used to mixing the things that they know with the term best practices. They learn something through sweat and tears and they hold to it. They hold to it even if there is better tech or way to do it out there, they hold to it because “it gets the job done”. They hold to it because they mastered it.

It is okay. No problem with that. Learning something every second for the sake of learning is just terrible as well. No one should be forced to constantly learn. It is stressful and can get you a lot of headaches.

The real problem is when you try to force on others your limitations or point of view as if they are the “right way of doing something” without a solid reason to do so and without having tried other alternatives and their pitfalls.

For that reason, I want you to step back from your constructions and beliefs and bear with me for a second. If you do not like my suggestion you can always come back and read it again (hahaha) or stick with your position on the matter.

Specifically, in terms of deploying something, my opinion is that you should strive for simplicity and autonomy.

Explaining the way codes are shipped in the most straightforward way

(You seasoned developer, can skip that part)

Currently, we have different ways of shipping code but mostly works in that way:

Someone creates a code in their preferred programming language either by creating a new feature, editing existing functionality, or removing something. After that, they save what they did, and nowadays they use Git (VCS).

After committing the change, they usually push their data to a specific hosted version control system (HVCS) that stores the code for team contribution/sharing. We can name a few:
GitLab, GitHub, Bitbucket.

There they usually review the code and diss the things that they do not like it. Through friendly or toxic comments, undisputed or heavy back-and-forth discussions they get to an agreement and the code can then move forward.

Once the code is approved, it finally gets to the part for which this tutorial was created.

Code is pushed and follows a specific YAML file. It contains a set of rules and commonly the goal is to connect to a specific cloud service, set arbitraries environment variables, and send the code their way.

That is what the YAML is for. Securely send data to a specific cloud service ( AWS, Google Cloud, Azure ). They call the whole process, CI/CD, deployment, etc etc etc. (Hey picky, I know they are not the same, but they kind of are.)

The picky guy staring at me and shaking his head (DALLE-2)

If we could establish the steps of these files would be something like that:

To connect and send data to the cloud service.
Sometimes to do some testing and check some linting rules
To create the container image (as the container read it, a file with directives of what this “mini-computer” should have installed and configurations) or bundle or whatever it needs to be transformed.
To set up environment variables.

These 4 steps are not mandatory and by no means exhaustive either. They could appear isolated or in conjunction with the others. By looking at this you could think: “This should be straightforward work”.

And yet people manage to make this YAML file even more complex than needs to be.

The problem with too complex configuration files

Let me start with examples, I will show you a few different files that are way too complex and a few that should be simple enough.

Show me the DAMN CODE!

Sorry. It is my second post, I am striving for quality. :P

This below would be one of the complex ones that could be simplified. (It is tricky because **it looks* simple)*

image: someimage
pipelines:
  branches:
    master:
      - step:
          name: Deploy to Prod 
          #deployment: production
          script:
            - export AWS_ROLE="XXXXXXXXXXXXXXXX"
            - export AWS_ACCOUNT_NAME="XXXXXXXXXXXXXXXXXX"
            - export AWS_ACCOUNT_ID="XXXXXXXXXXXXXXXXXXXX"
            - export ENV="prod"
            - export timeStamp=$(date +%s)
            - export DBHOST=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
            - export LAMBDA_FN=YYYYYYYYYYYYYY
            - make deploy

I know you probably are wondering. What is the problem with that code and what does it do?

Make yourself this question. What is this configuration is intending to do? Remember my young Padawan, “send some code to someplace”.

Could you with that file alone see exactly what is going on here? See where is going? See which service is being called? Let me spoil for you, no you can not. They are using MAKE, motherf*** MAKE. That is insane!

I will show you partially what the command: make deploy is doing

ifdef DOTENV
   DOTENV_TARGET=dotenv
else
   DOTENV_TARGET=.env
endif

ifdef AWS_ROLE
  ASSUME_REQUIRED?=assumeRole
endif

################

deploy: $(ENV_RM_REQUIRED) $(DOTENV_TARGET) $(ASSUME_REQUIRED)
   docker-compose run --rm serverless make _deps _buildLayer _deploy


# Create .env based on .env.template if .env does not exist
.env: XXXXXXXX

# Create/Overwrite .env with $(DOTENV)
dotenv: YYYYYYYYYYYY

_deps:
   echo "//registry.npmjs.org/:_authToken=$(NPM_TOKEN)" >> .npmrc
   yarn config set registry http://registry.npmjs.org
   yarn install --no-bin-links

_buildLayer:
   mkdir -p folder
   mv database folder
   mv node_modules folder
   echo 'folder'
   ls ./folder

_deploy:
   sls deploy --force -v

Could you make a guess what are they trying to do now? I will facilitate it for you:

1 — Create env variables

2 — Set registry for private package usage

3 — Deploy using the serverless framework (sls deploy)

4 —Setting everything through a docker container

Serverless here is another beast and goes out of the scope of this tutorial. What I wanna show you is that they used MAKE to create the same things that you could achieve with the YAML file alone.

But why did they do it?

The rationale behind this is to avoid vendor locking and to be agnostic-ready. If they wanna move from Bitbucket to GitLab to GitWhatever they would do it and the code would stay pretty much the same.

These kinds of rationales are in my view overzealous. They show your ego side more than anything else. Yep, you know how to create performant pipelines with MAKE, you know your bits. You are competent. But still, you lack the simplification. The dumb-down approach that everyone is asking for.

They are also too concerned with vendor locking. One way or another we are going to be vendor locked at something. Does not matter. Either AWS or Azure, GitLab or Git, Java or Node.js. Therefore, trying to predict the future is not a great strategy in my books.

It is worth noting that although programming languages are not vendors if you think indirectly they are. They are the first architectural decision that will base all your choices afterward.

The agnostic approach or silver bullet approach which is worrying about changing lines of code in the future is not effective as well. How many times did you change your well-planned architecture? If everything runs well and you are not facing some significant cost/performance/errors issues you are probably giving that system a stamp of the legacy system to be.

Changing and breaking things are crucial parts of any human cycle. Do not be too concerned too soon. Wait until you get the problem… Capisci?

How I would change that for simplicity?

image: someimage
pipelines:
  branches:
    master:
      - step:
          name: Deploy to Prod 
          #deployment: production
          script:
            - export AWS_ROLE="XXXXXXXXXXXXXXXX"
            - export AWS_ACCOUNT_NAME="XXXXXXXXXXXXXXXXXX"
            - export AWS_ACCOUNT_ID="XXXXXXXXXXXXXXXXXXXX"
            - export ENV="prod"
            - export timeStamp=$(date +%s)
            - export DBHOST=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
            - export LAMBDA_FN=YYYYYYYYYYYYYY
            - npm install
            - npm install serverless -g
            - sls deploy --force -v

You can now look at that file and see exactly what is going to do. You do not need to iterate through thousands of files to get the gist of what is going on.
It is easier, it is simpler and it is straightforward.

And with that comes the first suggestion. Try to put the minimum number of files out there. In case you have 100000 lines of YAML file. Okay. You deserve a better organization but instead of organizing first assuming that your configuration will grow, embrace the chaos and let run wild for a while. You can thank me later.

The problem with environment variables

Where to put my .env variables?

Firstly, what is env variables ? You can check this article https://www.freecodecamp.org/news/what-are-environment-variables-and-how-can-i-use-them-with-gatsby-and-netlify/ (you can skip the gatsby and netlify part)

Another current problem is related to where to store environment variables. People waste too many times arguing about where should be the safest place out there and they ended up doing the silliest things ever.

I have seen companies store their environment variables in a database. Seriously.IN A DATABASE, in a TABLE, plain ENGLISH, and contained every single token/PWD/user to every service used inside their application. Please, do not do this. There is no rationale behind it, sometimes we do not know any better.

The most common place is to use a file .env. It has led to problems like people committing their credentials to public repositories.

Another way is to store the credentials in a secrets manager in the cloud.
From there your application asynchronously would request the credential when needed. For using ou would need to use their SDK. Here goes a simple example.

https://stackoverflow.com/questions/57618689/how-do-i-use-aws-secret-manager-with-nodejs-lambda/57618800#57618800

For more info, you can check this: using AWS SSM.

Both of the solutions are fine. If you have configured your .env variables correctly they will be a strong candidate. The simplest, easiest, laziest way that I can think of is to combine .env files and the hosted version control system feature that allows saving encrypted secrets to be used in the deployment phase.

GitHub calls it Action secrets, Bitbucket calls it Repository variables. If done right that will suffice for 90% of the cases.

For GitHub you would go for that link:
https://github.com/your-username/your-repository/settings/secrets/actions

You can see that environment variables are encrypted as described in the image. (GitHub settings)

For Bitbucket you would have:
https://bitbucket.org/your-username/your-repo/admin/addon/admin/pipelines/repository-variables

In Bitbucket you can encrypt or not. Your choice.

And then you would configure your file as follows:

Bitbucket YAML:

pipelines:
  branches:
    master:
      - step:
          name: Test and deploy to dev
          image: node:16
          caches:
            - node
          deployment: test
          script:
            - npm install
            - npm install serverless -g
             - serverless config credentials --provider aws --key $AWS_KEY --secret $AWS_SECRET
            - touch .env
            - echo "DB_NAME=$DB_NAME" >> .env
            - echo "DB_USER=$DB_USER" >> .env
            - echo "DB_DIALECT=$DB_DIALECT" >> .env
            - echo "DB_PASS=$DEV_DB_PASS" >> .env
            - echo "DB_HOST=$DEV_DB_HOST" >> .env
            - serverless deploy
          artifacts:
            - dist/**

Explained steps:

1— The variables $AWS_KEY and $AWS_SECRET are set in the repository variables section (as explained above) and they are important to the serverless framework.

2— Then we create a file .env with the command .touch env and we start populating the secrets/variable in it (i.e “DB_NAME=$DB_NAME” >> .env )

3 — This .env file will be sent with other files to the selected destination (in that case they will send environment variables to AWS lambda)

GitHub YAML:

name: Deploy to Fargate
on:
  push:
    branches:
      - master
jobs:
  deploy:
    name: Deploy Node to ECS Fargate
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16.x]
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2-beta
        with:
          node-version: '16'
      - name: Install dependencies
        run: npm install

      - name: Set env variables
        run: |
          touch .env
          echo "NODE_ENV=stage" >> $GITHUB_ENV
          echo "SERVICE_NAME=${{ secrets.SERVICE_NAME_PROD }}" >> $GITHUB_ENV
          echo "AWS_ACCESS_KEY=${{ secrets.AWS_ACCESS_KEY_ID}}" >> .env
          echo "AWS_SECRET_ACCESS=${{ secrets.AWS_SECRET_ACCESS_KEY}}" >> .env
          echo "DATABASE=${{ secrets.DATABASE}}" >> .env
          echo "DATABASE_HOST=${{ secrets.DATABASE_HOST}}" >> .env
          echo "DATABASE_USER=${{ secrets.DATABASE_USER}}" >> .env
          echo "DATABASE_PASSWORD=${{ secrets.DATABASE_PASSWORD}}" >> .env

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY}}
          aws-region: ${{ secrets.AWS_REGION_ECS }}
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag, and push image to Amazon ECR
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: ${{ secrets.ECR_REPOSITORY }}
          IMAGE_TAG: ${{ env.NODE_ENV }}-latest
        run: |
          # Build a docker container and
          # push it to ECR so that it can
          # be deployed to ECS.
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

      - name: Fill in the new image ID in the Amazon ECS task definition
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ecs-task-definition-${{ env.NODE_ENV }}.json
          container-name: container-name
          image: ${{ steps.build-image.outputs.image }}

      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          service: ${{ env.SERVICE_NAME }}
          cluster: ${{ secrets.ECS_CLUSTER_NAME }}
          wait-for-service-stability: true

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS }}
          aws-region: ${{ secrets.AWS_REGION }}

Explained steps:

1 — This is a little more convoluted example. It sends data to a service called Fargate through a series of GitHub actions from other repositories (official AWS ones)

2 — It needs the environment variables that were set in the repository in Action secrets (above).

3 — It creates the .env file that will be saved inside that image that will run on Fargate

4 — Not only uses the environment variables for creating the .env file but to connect to AWS services.

This is a way more complex YAML file with several steps and configurations and yet it uses one file. If you read carefully you can see what is going to do, it uses the secrets from the VCS service and sends the code to the Fargate service.

Straightforward, boring even. And if you know a little about YAML configuration, you would say: “simple to follow”. However, if you do not know what is all this jargon, fear not.

They have provided beautiful documentation:

GitHub — Understanding GitHub actions

BitBucket — Configure bitbucket-pipelines.yml (same as YAML)

In the last part of this tutorial let’s discuss when you have different branches and similar code for them.

The problem with having different branches and similar behavior

Run actions on specific branches

For BitBucket, branches are part of the configuration, so you can set the specific branch and the configuration will run exclusively. That feature is very important (kudos to the Atlassian team) because you can have a separate development branch and production in the same config file. Something like:

pipelines:
  default:
    - step:
        name: Build and test
        script:
          - npm install
          - npm test
  branches:
    master:
    - step:
          name: deploy  to PRODUCTION
          image: node:16
          caches:
            - node
          deployment: test
          script:
            - npm install
            - npm install serverless -g
            - serverless config credentials --provider aws --key $AWS_KEY --secret $AWS_SECRET
            - touch .env
            - echo "DB_NAME=$DB_NAME_PROD" >> .env
            - echo "DB_USER=$DB_USER_PROD" >> .env
            - echo "DB_DIALECT=$DB_DIALECT_PROD" >> .env
            - echo "DB_PASS=$DEV_DB_PASS_PROD" >> .env
            - echo "DB_HOST=$DEV_DB_HOST_PROD" >> .env
            - serverless deploy
          artifacts:
            - dist/**
    develop:
      - step:
          name: deploy to DEVELOP
          image: node:16
          caches:
            - node
          deployment: test
          script:
            - npm install
            - npm install serverless -g
            - serverless config credentials --provider aws --key $AWS_KEY --secret $AWS_SECRET
            - touch .env
            - echo "DB_NAME=$DB_NAME_DEV" >> .env
            - echo "DB_USER=$DB_USER_DEV" >> .env
            - echo "DB_DIALECT=$DB_DIALECT_DEV" >> .env
            - echo "DB_PASS=$DEV_DB_PASS_DEV" >> .env
            - echo "DB_HOST=$DEV_DB_HOST_DEV" >> .env
            - serverless deploy
          artifacts:
            - dist/**

In that case, if you push an application to the master branch only the master gets updated, and development is skipped. Pretty neat huh?

How about GitHub?

I do not know why it is different. Many times in my journey I did not like how they made things and everything seemed more complicated. As you know by now I have aversion to cleverness when brings more stuff for me to learn/work.

Some of the tutorials that I have read before coming up with my (rant) one are pretty good, except when it comes to branches:
https://keithweaverca.medium.com/only-run-github-actions-on-specific-branches-694782fcc07

https://medium.com/sysf/how-to-set-up-github-workflows-and-create-github-actions-using-docker-3a5ba7ec0988

They have the same strategy. If you create a branch you create a different file.And “new branch — new YAML” paradigm it goes against what I have defended here so far, do you remember my young Padawan?

“Try to put the minimum number of files out there.”

And with that and the help of the best place to copypasta code:

https://stackoverflow.com/a/58142412/7350853

After reading that you can see the solution. We could now come up with a better version. Using if’s. Simple if’s. Well known by every developer that has touched a surface of a keyboard. Great. Let’s do this.

Reusing the same Fargate YAML file:

name: Deploy to Fargate
on:
  push:
    branches:
      - master
jobs:
  deploy:
    name: Deploy Node to ECS Fargate
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16.x]
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2-beta
        with:
          node-version: '16'
      - name: Install dependencies
        run: npm install

      - name: Set env variables for DEVELOP
      if: github.ref == 'refs/heads/develop'
        run: |
          touch .env
          echo "NODE_ENV=dev" >> $GITHUB_ENV
          echo "SERVICE_NAME=${{ secrets.SERVICE_NAME_DEV }}" >> $GITHUB_ENV
          echo "AWS_ACCESS_KEY=${{ secrets.AWS_ACCESS_KEY_ID}}" >> .env
          echo "AWS_SECRET_ACCESS=${{ secrets.AWS_SECRET_ACCESS_KEY}}" >> .env
          echo "DATABASE=${{ secrets.DATABASE_DEV}}" >> .env
          echo "DATABASE_HOST=${{ secrets.DATABASE_HOST_DEV}}" >> .env
          echo "DATABASE_USER=${{ secrets.DATABASE_USER_DEV}}" >> .env
          echo "DATABASE_PASSWORD=${{ secrets.DATABASE_PASSWORD_DEV}}" >> .env
      - name: Set env variables for PRODUCTION
      if: github.ref == 'refs/heads/master'
        run: |
          touch .env
          echo "NODE_ENV=dev" >> $GITHUB_ENV
          echo "SERVICE_NAME=${{ secrets.SERVICE_NAME_PROD }}" >> $GITHUB_ENV
          echo "AWS_ACCESS_KEY=${{ secrets.AWS_ACCESS_KEY_ID}}" >> .env
          echo "AWS_SECRET_ACCESS=${{ secrets.AWS_SECRET_ACCESS_KEY}}" >> .env
          echo "DATABASE=${{ secrets.DATABASE_DEV}}" >> .env
          echo "DATABASE_HOST=${{ secrets.DATABASE_HOST_PROD}}" >> .env
          echo "DATABASE_USER=${{ secrets.DATABASE_USER_PROD}}" >> .env
          echo "DATABASE_PASSWORD=${{ secrets.DATABASE_PASSWORD_PROD}}" >> .env
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY}}
          aws-region: ${{ secrets.AWS_REGION_ECS }}
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag, and push image to Amazon ECR
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: ${{ secrets.ECR_REPOSITORY }}
          IMAGE_TAG: ${{ env.NODE_ENV }}-latest
        run: |
          # Build a docker container and
          # push it to ECR so that it can
          # be deployed to ECS.
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

      - name: Fill in the new image ID in the Amazon ECS task definition
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ecs-task-definition-${{ env.NODE_ENV }}.json
          container-name: container-name
          image: ${{ steps.build-image.outputs.image }}

      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          service: ${{ env.SERVICE_NAME }}
          cluster: ${{ secrets.ECS_CLUSTER_NAME }}
          wait-for-service-stability: true

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS }}
          aws-region: ${{ secrets.AWS_REGION }}

As you can easily see, using the IF clause ( if: github.ref == ‘branch' ) we have set the Actions secrets for production and the Action secrets for development and they will only populate the .env file when the specific branch is committed.

That is the stupidest way ever and I am proud. It is so straightforward that you will not need MAKE or thousands of files or anything else. Just a little bit of if’s here and there, a few env variables set and there you go you are mastering the way of becoming a Jedi of KISS.

KISS (Keep it simple, stupid) (DALLE-2)

It is worth noting, that I know, the world is full of complicated cases and specific scenarios that would need some level of complexity. Most of your rationale defending your idea can indeed be the only and only solution. I will not dispute that, there are complex cases that I as a blub programmer will not even conceive in my limited perception/knowledge.

And that is fine. I am aiming at the ones that do not have a clue of what they are doing or did not stop to think a little bit if that would bring joy a few weeks later when everyone forgets what they did.

I am defending simplicity and autonomy. I could go and show several other cases and problematic approaches but I guess that I have delivered the message of how to be utmost sophisticated.

Finally you can face them my young one. Without any hesitation or fear.

My padawan is starting to believe. (DALLE-2)

Good luck with your journey!

A bad introduction. A poorly written saga. A virgin (not anymore).

iwaduarte — Thu, 21 Sep 2023 10:35:30 +0000

This will be a big fluffy post for the rare times. To be honest I do not like it writing “that much”. However, in this special case, it is mandatory ( like losing my virginity was). It is full of mistakes, a lot of undesired attention, critics, and a lot of bad performance but in the end, we always remember it.

Let me warn you, no bullshits are needed. I am just starting myself and I will be your guide talking mostly about tech. You will be impressed (or not) by how stupid I sound and sometimes how deeply I will talk.

I hope we could really learn something together and open our horizons. I will maybe throw some jokes out of a context too in an attempt to make things special between us (we never know if I can get you to worship me later…)

In that journey, I will throw at you my unique perspective. For instance, being a lazy professional I will always go to the easiest simple route with less work involved. Nothing much fancy, nothing much complex. Just the simple yet sophisticated how to get things done.

Considering that I am not a native speaker, sometimes I will use my own jargon and maybe it will make you confused but as soon as we get to know each other you will get the gist of it.

In summary (TL;DR): Nowadays there are a lot of people generating crap/noise (o/). This is just another pretentious guy that thinks that he could do better and his introduction.

Why are you writing anyway?

How many times did you get to a text or a video or even a podcast where someone spent 3000 lines speaking and speaking and speaking about something that everyone knows and does not have relevance, so in the end (or even worse in the middle) they brought something that is really really interesting but they go and explain it poorly or wrongly and makes everyone confused? (imagine here a poker face, let’s work it out your imagination a little)

Yeah. There are A LOT of people like that. There is A LOT of content like that. The Internet brought knowledge and connection but brought a lot of noise as well. Luckily for us, I am not that guy.

Or even a lot of people that get other’s people tutorials/ideas and make a crap version in order to bring attention to themselves?

Nope. I am not that guy either.

I propose to do things differently. I do not know if I am going to succeed. But I might as well try. If I see something marvelous you will have a backlink to the content and maybe a small commentary like “That is *f*** awesome read it and get smart”*

If I am talking about something that needs explanation. You will get that from me. Concise, direct to the point, and well-explained topics.

So what I will bring to the table:

**Direct to the point: ‘No bullshit attached. You are going to know exactly what I am going to talk about.
**“Deep” (as far as my knowledge goes): No “5 silly things that you probably only need to look to understand”. Here you will have thoughtful discussions of how SSL(TLS now) really works from Caesar times to RSA/DH. How to do a proper search (not using the LIKE operator) with only a database with FTS capabilities. How to configure API Gateway with S3 to trigger lambdas (using CloudFormation). How to profile and improve React component's performance while using nested maps.
It is about myself and it is about others too: Maybe I will make a friend, maybe I found love or hate. Maybe I will be ignored. Who cares…?
Simple kid stupid communication: Layman’s terms all the way even in the technical aspects. Like the old man, Feynman said (I have not read it much): “I’m smart enough to know that I’m dumb.”
Portuguese/English content: This is also a medium for learning languages. Some of these tutorials will be also written/translated into Portuguese with slight changes. So viewers could get both languages practice. I believe it will be extremely beneficial for my fellow Brazilians.

Although I want to guarantee that I will bring insightful content I can not predict the future. After all, I am not mother Diná :P

Mother Diná getting embarrassed to be put on the spot.

So let’s hope your stay here makes you wiser and if that is not the case at least you can have some fun at my ludicrous jokes. I promise that in that case, I will give you my best.