Forem: Rafael Dias

Minimalist blog with Zola, AWS CDK, and Tailwind CSS - Part 1

Rafael Dias — Wed, 19 Feb 2025 08:30:04 +0000

Originally posted in https://www.theminimalistdeveloper.com/minimalist-blog-with-zola-and-tailwindcss-part-1/

Assumptions, clarifications, and reasons

What are we going to do today? We're going to build a minimalist blog using Zola (built with Rust, btw), AWS CDK, Tailwind CSS, and a tiny bit of Typescript.

We will have a fully functional blog structure that you can pimp up as you see fit, we will not cover CI/CD pipelines, nor any automation.

I can already feel some of you itching out to furiously type: Why not use Vercel / Whatever other company that does the same thing / whatever instead! :angry foaming face:

For a few reasons:

I like to have control over the infrastructure of my personal websites so I can easily experiment.
Familiarity with AWS and CDK.
I want to.

With that out of the way, let's move on.

I've used a few different engines on different personal websites, and I tend to use them as experiment grounds as much as mediums to share my thoughts.

The setup I had before in this blog before was a NextJS / Vercel / Headless CMS combo. I hated it, way too many pieces for my use case, and didn't align with my preferred workflow.

So I scraped that and started fresh with a few rules to guide the development:

The content has to be stored in Markdown - I take notes and do drafts in Markdown, so it felt like it would shorten the actions necessary to push content out if everything was Markdown.
It has to be statically generated - I don't want server-side render something that will never/very unlikely to change.
The tool has to be simple and robust enough with as few dependencies as possible. I want to be able to pick up and run in whatever machine in no time.
The frontend setup should be simple and easy to extend.

With that in mind, I quickly narrowed down to a few challengers Gatsby and Hugo being the usual suspects.

I've had experience with both in the past and had some gripes with both of them. After some research I came across Zola, it is a static website generator written in Rust with 0 dependencies, that works with an extended version of Markdown.

Seemed too good to be true, but it isn't. A healthy community, with over 14k stars on GitHub and good enough documentation? I am in.

Setup the project

CDK

First, let's install AWS CDK.

# This will install the CDK command line tool globally
npm install -g aws-cdk

This is the condensed version, you can find more information in their Getting started page.

Now, create the blog folder, in our example it will be my-blog.

mkdir my-blog
cd my-blog
npx cdk init app --language typescript

The above commands will create the initial setup for our infrasctucture in Typescript with a Git repository.

I am assuming you have set up your AWS account and credentials, if not follow the official tutorial before reading any further.

Zola

Make sure you have Zola installed. They have a pretty extensive list of ways of installing it.

Now, let's set up our blog. Within the my-blog folder, we created in the previous step, run the following command:

zola init my-blog -f

Note that we used the -f flag, which means to force the creation of the blog structure within a folder that already contains files.

This command will prompt a few questions, among them if you want to use SaSS compilation and if you would like to have a search enabled.

For the purposes of this example, we will answer no to both of them, don't worry, if you change your mind later you can update these details at any time on the config.toml is located in the root of the project folder.

After, that you should have your blog folder set up and can already see it in action.

zola serve

Accessing http://127.0.0.1:1111 should show the standard Zola welcome page.

Congratulations, you made a website.

Tailwind CSS

Tailwind is one of the fastest and cleanest ways of putting presentable websites together, of course, in my opinion.

To install it, from the my-blog folder:

npm install tailwindcss @tailwind/cli

Now we should have all the pieces in place so we can start to put our blog together.

Infrastructure

I like to start with the infrastructure setup because it allows me to keep deploying as the project progresses.

Static websites, I believe it is one of the easiest and cheapest things to have on AWS. We could simply just use an S3 bucket and put all the output generated by Zola there and call it a day but this is neither elegant nor cost-effective.

We will leverage CloudFront to enable a much faster, reliable, and cheap way to deliver our website.

This setup will look something like this:

S3 Bucket

Open your infrastructure stack definition at ./lib/my-blog-stack.ts and add the follow resource in the body of the constructor function:

    // This is where we will store all the assets generated from Zola, 
    // essentially our entire website.
    const website = new cdk.aws_s3.Bucket(this, "my-blog", {
      // This speeds up the transfer of our files to S3
      transferAcceleration: true,
      // This tells S3 to only allow access to our bucket through SSL 
      enforceSSL: true,
      /* 
        This tells S3 to remove all the contents of the bucket when we remove 
        the stack. This is particularly useful if you decide to have multiple 
        instances of the stack to let's say test a feature. 
        If you don't add this when you remove the stack, it will get stuck 
        because the bucket will be filled with files and the Stack will refuse 
        to continue the removal leading to manual intervention.
      */
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      // This is very important, we don't want anyone from the outside world to
      // be able to access our files directly
      blockPublicAccess: cdk.aws_s3.BlockPublicAccess.BLOCK_ALL,
    });

The next step is to grant access to CloudFront, so it can access our bucket as an origin for our website's files.

    const cloudfrontOAI = new cdk.aws_cloudfront.OriginAccessIdentity(
      this,
      "MyOriginAccessIdentity",
      {
        comment: "Allows CloudFront to reach the website bucket",
      },
    );

    website.grantRead(cloudfrontOAI);

    const s3origin = new cdk.aws_cloudfront_origins.S3Origin(website, {
      originAccessIdentity: cloudfrontOAI,
    });

Now a small trick, if we just put our files there and ask CloudFront to pick them one to one as the requests arrive we will face a bunch of 404's. That is because CloudFront does not resolve paths ending in '/' to '/index.html' like Zola will create for us.

A simple and clean solution is to introduce this bit of logic in CloudFront via a CloudFront function that makes this adjustment on the viewer request event.

This event happens before the request reaches CloudFront's cache, allowing us to direct the selected requests to the right files.

This is the function.

    const indexRedirector = new cdk.aws_cloudfront.Function(this, "Function", {
      code: cdk.aws_cloudfront.FunctionCode.fromInline(`
      function handler(event) {
          var request = event.request;
          var uri = request.uri;

          if (uri.endsWith('/')) {
            request.uri += 'index.html';
          }
          else if (!uri.includes('.')) {
            request.uri += '/index.html';
          }

          return request;
        }
      `),
      runtime: cdk.aws_cloudfront.FunctionRuntime.JS_2_0,
    });

Finally, we get to our CloudFront distribution, that will look like this:

    const cdn = new cdk.aws_cloudfront.Distribution(this, "my-blog-cdn", {
      // This determines which object to look for in the root folder
      defaultRootObject: "index.html",
      minimumProtocolVersion: cdk.aws_cloudfront.SecurityPolicyProtocol.TLS_V1_2_2021,
      /* 
      Behaviors determine how CloudFront handles the assets. 
      In our case we will only need the default one.
      */ 
      defaultBehavior: {
        // Origin tells CloudFront where to look for the files being requested
        origin: s3origin,
        // Please, compress the files
        compress: true,
        // This is very important, determins which HTTP methods we allow on 
        // CloudFront, in our case only GET and HEAD methods
        allowedMethods: cdk.aws_cloudfront.AllowedMethods.ALLOW_GET_HEAD_OPTIONS,
        /* 
        This determines how we want CloudFront to behave with HTTP and HTTPS
        protocols. We will ask to redirect HTTP requests to HTTPS
        */
        viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
        // Cache both methods requests
        cachedMethods: cdk.aws_cloudfront.CachedMethods.CACHE_GET_HEAD_OPTIONS,
        // We use a managed cache policy called caching optimized
        cachePolicy: cdk.aws_cloudfront.CachePolicy.CACHING_OPTIMIZED,
        // here we add the function that will take care of adding the extra 
        // index.html bit on the matching url's
        functionAssociations: [
          {
            function: indexRedirector,
            eventType: cdk.aws_cloudfront.FunctionEventType.VIEWER_REQUEST,
          },
        ],
      },
    });

Right now you could already use your stack as is, but it would be necessary a lot of manual effort, uploading files manually, cleaning up the CDN distribution, etc, etc.

There is a huge quality of life improvement with just a few lines of code, the following bit will tell CDK when deploying the changes, to look for specific folders under a path, put them into the S3 bucket and also clean up the CDN cache so we can visualize the changes.

    new cdk.aws_s3_deployment.BucketDeployment(this, "my-blog-deploy-website", {
      // Point to the folder where Zola will put the output of the website
      sources: [cdk.aws_s3_deployment.Source.asset(
        path.join(__dirname, "../public")
      )],
      // Tell to which S3 bucket to upload to 
      destinationBucket: website,
      // Point to which Cloudfront distribution should be used
      distribution: cdn,
      // Tell which path should be cleaned when deployed
      distributionPaths: ["/*"],
    });

Deployment

Alright, now we can already start deploying.

# First build the website
zola build
# Then deploy
cdk deploy

If everything went well you should see your Stack ARN at the end of the output.

That is it for the first part, next, we will tackle the theme, page structure, content examples, and how everything comes together.

See you in part 2!

Take control of your learning journey

Rafael Dias — Mon, 10 Feb 2025 09:34:32 +0000

Originally published at: theminimalistdeveloper.com

Legacy

Legacy is usually the last thing a software engineer wants to hear when they are evaluating to join a company, those green fields are always so much better they present you the opportunity of picking the latest and greatest tools of the season, so you can stay up-to-date and brag about on Linkedin.

But the reality is that everything, everywhere, has legacy. Some are slightly less horrible than others, but believe me, everyone has it.

Netflix? Yes. Even Google? Oh yes.

In some instances, it is just way worse than others. There are cases where the tech is so ancient that the knowledge required to operate is not transferable to other companies or it is simply too painful to work on it.

I've experienced both myself, it's not fun.

Harsh Truth

If we remove the extremes, legacy is just part of the job, because whatever you do will become legacy, even earlier than you might think.

The pace of the development of tools, frameworks, and languages is ever-increasing, which is good, but no company can provide you the environment to keep up with it.

Companies, generally, are using technology to solve problems, and in most cases, the tech is only a detail in a much larger picture. Usually, if it works no one cares about how well-designed or how clean your code is.
And to a certain extent that is a good thing, hyper fixating on tooling is a dangerous and often disastrous path.

To strike the right balance of pros and cons when introducing new technologies is a skill honed throughout years of experience where a little bit of luck is also involved.

Often times the wrong move can be costly, even fatal. That is why most companies tend to stick to their tried and true set of tools.

The Work Never Ends

While this can be good for the company, a certain level of skepticism can save a lot of headaches. For the software engineers on the other hand can be frustrating, or even complicate the further steps on their career.

That is where side projects come into play, you control everything about it, and the focus can be whatever you want it to be, language, framework, OS, etc.

It is a playground for you to test new ideas, tools, or just practice. The more tedious or repetitive your day job is, the more important it becomes.

To some it might sound terrible: Just more work! I get it, in a way it is, but to stay competitive in software development you have to put in the extra hours to keep up with a rapidly changing environment.

You will not have this time at your day job, the company pays you to solve problems not be up-to-date, or make you technically fulfilled.

Ok, now what?

Once you decide to take on a side project, usually the first stop, and to some the last is: What to build?

Fair point, I struggled with this one so much that I created a list of ways to approach it.

Instead of giving a list of concrete ideas, here are some approaches that worked for me.

1. Copy

What tools are in my day-to-day that I enjoy using, and I know exactly how I want them to behave?

Music players, social networks, command line tools, wrappers to facilitate repetitive work, etc.

Spend a day or two paying close attention to the software that you use and love then pick one to replicate completely or partially.

2. Scratch your own itch

The good ol' strategy of trying to solve a need you already have.

Do you love Spotify but would prefer to control it via Neovim? Good one.

How about a nicer way to navigate your PRs? Great.

A good exercise in this case is to keep pen and paper at hand and every time you miss a feature or product, describe roughly what you want.
Do that for a week, and you will probably be surprised by the amount of things you will come up with.

3. Tactical

If the above approaches left you empty handed you can do the analytical way. Pick the technologies you want to learn and research for trends that you can apply.

An awesome tool to play around and figure out trends is Google Trends.

Conclusion

Companies will not, and cannot keep up with the release of every new cool piece of tech out there, it's not what they are there for.

Despite what some might think, software development requires a lot of energy both in and out of work. But having a side project you enjoy, and have at hand to try out things and experiment might be the difference for getting your next job or even the next step in your current one.

That's why I strongly advocate for side projects, there are huge benefits when you invest those extra hours.

It can make you more fullfilled, sometimes happier, but always better at your craft.

Why Everybody Wants To Get Rid Of Software Developers?

Rafael Dias — Mon, 10 Feb 2025 09:29:58 +0000

Originally published at: theminimalistdeveloper.com

The reason might be simply because they are expensive. But, as usual, I believe there is more to it.

Ever since I started programming, almost 20 years ago, there is this idea that a tool, or method can completely, or at least partially, replace a skilled developer. At first, it was the visual tools like the defunct Dreamweaver, from the family of the WYSIWYG (what you see is what you get) tools.

Quickly, it became clear that it was not as simple as allowing people to paint tables with a mouse would be enough. As the years went by, the applications only got more complex, and with it the wish to allow people to build them without developers.

Initially, I thought it was purely financially motivated. If you can make it simpler and/or faster, it will be cheaper, but I believe there is more to it.

Due to the nature of what we do, we usually work detached from the other departments of the company, mostly because it is an area that requires a lot of context from many concepts and tools to understand it. That is one of the main “hidden” points that makes the engineering role so important to be replaced by AI.

Often, the word of an engineering team is the showstopper of executives, creatives, and product people wet dream. Your idea might be fantastic, but if the engineering team deems it not feasible, or if it takes too long to implement, it might be in some way or another dead in the water.

And you add to that the lack of room for counterarguments because they are in most ways too hermetic and require deep technical knowledge to effectively navigate the discussion.

That can be a much more compelling reason than the financial, the general lack of trust and the feeling of powerlessness over the product have a massive negative effect on many companies.

Now imagine if those developers that always deny your requests, and in your opinion, take too long to complete their tasks, could be replaced by some magical tool, wouldn't that be amazing?

All the world-disrupting ideas for your app could be transmitted straight from your mind to the real world through simple prompts!

Your genius would shine without being obfuscated by lazy, awkward, slow, and overpaid developers.

Such a great idea, but unfortunately, reality is not as simple as that. The first issue that real-world ideas can't be directly translated to software without considering contextual, technical, and non-technical aspects that directly impact a system's design.

Company dynamics, other internal and external systems, physical limitations, the list goes on and on, that even the most accurate LLM cannot even scratch the surface.

A huge portion of engineering work is to disambiguate murky feature requirements, translate wishes into tangible actions, spot patterns in the human dynamics of the team and the company.

That is nowhere near the wheelhouse of the tools that flood the market today, claiming to be software engineering replacements.

See, I am not even getting into the quality of the output of those tools, which arguably, aren't particularly good to begin with.

Now, with that said, I have to also be honest, there is a general lack of soft skills ingrained in parts of our software engineering community.
Either it is a trait that naturally develops due to the environment, or is the profile of the professional that gets attracted by the field, I don't know.

It is not unusual to see unresponsive, incommunicable developers that just want to close tickets. Soft skills, and most importantly communication, are the hidden gold of the AI era that we are in.

You need to be good technically, that is not negotiable. Specialize yourself, but also be an effective communicator and nice team member.

That's why it is the first thing I probe for whenever I am hiring for our teams.

Any reasonably good engineer should be able to pick up a new language and be productive relatively quickly. On the other hand, it's hard, costly and sometimes even impossible to teach someone on how to effectively clarify complex abstract ideas from non-technical people, for example.

AI tools are amazing, they can help you be more productive, speed up tedious tasks, but we are still far off from being able to create something that can navigate the unbelievably complex network of human interactions.

And my friends, that is a good thing.

Re:Invent 2020 And Lambda's New Features

Rafael Dias — Sun, 29 Nov 2020 12:30:00 +0000

Originally posted on The Minimalist Developer

Re:Invent 2020 is approaching, and with it, a wave of new releases from AWS to multiple services, including Lambda.

This year, of course, will be an online-only event which is free. Go here to check out all the serverless sessions.

Now, let’s take a look at some of the coolest releases from the past few weeks for Lambda we will probably see covered in the upcoming events.

New Lambda Features

Lambda extensions

It is still in preview, but this is probably the most exciting release, in my opinion.

Lambda extension allows us to have code running during the life cycle event, meaning that you could, for example, create an extension to collect information before, during, and after the lambda invocation.

Also, there is a Logs API, which translates to much easier integration with 3rd party services like Datadog, Lumigo, New Relic, etc.

This sounds really nice. I want to try it out to see how it works!

AVX2 Support

This one is geared towards those who use lambdas for heavy computational load, like machine learning, scientific simulations, financial analysis, etc.

AVX2 support is availabel now to help reduce time with the computationally intensive task that way also helping to reduce costs.

AVX2 stands for Advanced Vector Extensions 2, and it is a specific instruction set available at certain processors. And to use it it is necessary to have in place certain libraries compiled with the proper flags.

AWS PrivateLink access

Lambda now offers the support for AWS PrivateLink. It allows calling functions from a VPC without going through public networks. Providing a private connection between your VPCs and AWS services.

I want to see how the performance is with this one. The last time I checked VPCs and Lambdas were not that great together. But it was a long time ago.

SQS batch Limit up to 10k

Amazon SQS had previously, the batch size limit of 10 messages per batch. Now it is up to 10.000, matching its brother Amazon Kinesis.

SQS Batch Window up to 5 minutes

The Batch window is a cool little feature. It tells the poller to wait until the queue has reached its batch limit or the batch window time to send to the lambda function. This is particularly useful to cut the number of invocations for non-time-sensitive computation.

Amazon MQ as an event source

Launched support for Amazon MQ as an event source for Lambda. Amazon MQ is a managed message broker service. The integration operates in a similar way to Amazon SQS and Amazon Kinesis. The Lambda services keep an internal poller to invoke the target Lambda function whenever necessary.

Conclusion

There are many more features from other services that AWS is launching. Make sure to keep an eye on the releases.

It might help you solve one of those pending problems from your backlog!

Setting Up Typescript Project From Scratch

Rafael Dias — Sun, 29 Nov 2020 10:25:00 +0000

Originally posted on The Minimalist Developer

TL;DR

You don’t want to read through all those steps? Dive in straight into coding, just clone/download/fork this repository with the resulting base project of this post 😀.

Introduction

Whenever learning a new language after configuring a proper development environment, set up a project from scratch is the next step on my list.

To understand how to have everything in the right place to start coding is essential. Of course, after the first few times, you will probably automate these steps or would rely on some boilerplate project.

The idea of this post is to walk through the very first steps necessary to have a project correctly set up for Typescript, and by correctly, I mean having these things in place:

Project structure : Folder structure, Git, NPM
Unit test setup : Jest
Style guide : Airbnb style guide for Typescript
NPM Scripts : Wrap up common commands in NPM scripts
Pre commit hooks : To ensure we don’t tarnish our immaculate repository

This structure could be used for front-end development, probably with some tweaks here and there. But for my purpose and also for the post, it is oriented for backend development.

Also, everything here is aimed towards *nix environments, either be some Linux flavor or MacOs, with NodeJS and Git installed.

Setup

1 - Initiate the Project

Define the folder name that will house our project. In this case, let’s call it ts-project.

mkdir -p ts-project/{src,tests/unit/src}

The above command will generate this structure:

ts-project
├── src
└── tests
    └── unit
        └── src

Hop into the project’s folder.

cd ts-project

Initiate an empty Git Repository:

git init

Add a .gitignore file at the root of the project with the following content:

node_modules/
dist/

Which will tell Git to not track the changes on those folders.

Initiate an NPM project. The -y tells NPM to accept all the default settings:

npm init -y

Install Typescript:

npm install --save-dev typescript

Do not ignore the —save-dev flag. It tells NPM to add the Typescript package to the dev dependency list on our newly added package.json.

Initiate Typescript by issuing:

npx tsc --init

This line deserves a word or two. Alongside NPM, it is installed another tool called NPX. NPX is a tool to execute binaries without having them installed globally. It will look for the executable first at the environment variable $PATH, then in the local project for the requested command, in this case, tsc.

The tsc portion of the command refers to the Typescript dependency. When executed, the above command should display something like this as a result:

message TS6071: Successfully created a tsconfig.json file.

It creates a configuration file called tsconfig.json with parameters necessary for Typescript to work properly.

By default, all possible configuration keys are present, but most of them, will be commented out. After cleaning up the unnecessary commented lines you will be left with something like this:

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

For a detailed description of what each of these fields means, please check the official documentation right here.

Let’s tweak this a little bit. Add two new keys to the compiler options

"outDir": "dist",
"sourceMap": true

outDir : being the destination folder of the transpiled code will be stored, in this case, we go with the most common of all, dist.
sourceMap : enables the generation of source map files. They allow debuggers and other tools to show the original Typescript when debugging the compiled Javascript.

And at the root we add:

"include": ["./src/**/*"]

Which tells the compiler to take everything from the source (src) folder.

The end result is something like this:

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "dist"
  },
  "include": ["./src/**/*"]
}

2 - Unit Tests

For unit tests, I have been using Jest for quite some time now, no complaints.

Very straight forward and simple testing framework.

To install all the packages necessary run:

npm install --save-dev \
  jest \
  babel-jest \
  @babel/core \
  @babel/preset-env \
  @babel/preset-typescript \
  @types/jest

Then add a babe.config.js at the root of the project with the content:

module.exports = {
  presets: [
    ['@babel/preset-env', { targets: { node: 'current' } }],
    '@babel/preset-typescript',
  ]
};

And our testing setup is done.

3 - Style guide and linting

This is a crucial step to ensure, among other things consistency. I am have been working with the Airbnb style guide for Javascript for almost two years, and love it. Helps to fix smaller mistakes literally pointing out to you.

To be able to use the same ruleset on Typescript, we are going to use a package called eslint-config-airbnb-typescript, which is a drop-in replacement for the normal eslint-config-airbnb but with all the Typescript goodness.

To install, run the following:

npm install --save-dev \
    eslint \
    eslint-config-airbnb-typescript \
    eslint-plugin-import@^2.22.0 \
    @typescript-eslint/eslint-plugin@^4.4.1

And add .eslintrc.js to the project root with the content:

module.exports = {
  extends: ['airbnb-typescript/base'],
  parserOptions: {
    project: './tsconfig.json',
  },
};

In case you went through my last post ”Setting up Neovim for typescript development” you will notice that this style guide uses Eslint, and we configured the only tsserver. To add Coc support for Eslint run:

:CocInstall coc-eslint

Check out its documentation to learn more about the extension.

4 - NPM Scripts

Let’s leverage the NPM scripts system to facilitate interacting with the tooling we just set up.

This seems like a trivial, maybe unnecessary step, but having the tooling abstracted by the scripts can help to decouple it from other parts like some editor shortcuts or CI/CD pipelines. So in case, you decide to change your testing library or build process, we can simply change it in one place.

Add this piece of code at the root of the package.json:

"scripts": {
    "test": "jest",
    "lint": "eslint",
    "compile": "tsc"
}

These are pretty self-explanatory, but here are examples of how we can use these scripts. From the project root run:

# This will run the testing library Jest
npm run test
# This will run the linting
npm run lint
# This will run the compilation
npm run compile

5 - Pre-Commit Hooks

Finishing up with some fail-safes, it can make our lifes much easier. Git hook is a neat feature from Git, it allows us to run scripts in certain key events like before applying a commit, before pushing, and many others.

In this example, we will use a package called pre-commit to run our scripts before the commits. To install it, run:

npm install --save-dev pre-commit

And then add this to package.json:

"pre-commit": [
    "test",
    "lint",
    "compile"
],

This will make sure that every time you issue a commit command, runs all the three npm scripts. That way, we will never be able to event commit broken or invalid code.

6 - Testing

With everything in place, let’s write a “hello world” and test it. Add an index.ts to your src folder, located at the root of the project with this content:

/**
 * Hello world function
 *
 * @param {string} name
 */
function helloWorld(name: string) {
  return `Hello world, ${name}`;
}

export default helloWorld;

And add an index.spec.ts at tests/unit/src with this content;

import helloWorld from '../../../src/index';

test('Hello world works', () => {
    expect(helloWorld('Foo'))
        .toBe('Hello world, Foo');
});

Now, from the command line at the root of the project, run:

npm run lint && npm run test && npm run compile

Which should result in something like this:

> ts-project@1.0.0 lint /Users/username/ts-project
> eslint

> ts-project@1.0.0 test /Users/username/ts-project
> jest

 PASS tests/unit/src/index.spec.ts
  ✓ Hello world works (2 ms)

Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 0.898 s, estimated 1 s
Ran all test suites.

> ts-project@1.0.0 compile /Users/username/ts-project
> tsc

We’ve made it!

Conclusion

These kinds of steps are valuable to understand all the moving parts that compose a base project structure, but after a couple of times, these steps should be automated or a boilerplate that fits your needs created.

We went through all the steps to set up a solid foundation for our experiments and projects. Now the only thing left is to build something cool.

Setting Up Neovim For Typescript Development

Rafael Dias — Mon, 23 Nov 2020 19:00:00 +0000

Originally posted on theminimalistdeveloper.com

Introduction

First things first, right? Yes. So, I am learning Typescript whenever I start learning a new programming language, I begin by setting up a development environment.

Everything necessary to properly run the code snippets, tests, etc. It feels like a solid foundation to start building on.

Since my weapon of choice is Neovim, here I will describe what it took for me to have a development environment for Typescript with autocomplete, jump to definition, code validation, documentation display in place, and all that good stuff.

Requirements

This post will focus specifically on the components necessary for Typescript development. I am assuming you already have Neovim installed and configured. If that is not your case, don't panic! Check out this short and straight to the point post on what is Neovim and how to install it.

Git

🔗 git-scm.com

Coc and its extensions require Git. It is fair to assume that every developer has Git on their machines, but better safe than sorry :D

NodeJS

🔗 nodejs.org

We need to, you know, run the code after compiling it. I currently am using version 12.

Plug

🔗 github.com/junegunn/vim-plug

Plug is a plugin manager for Vim/Neovim. It is possible to achieve the same result with any other plugin manager for Vim or Neovim, but if you want to follow along with this post, it is easier to have Plug in place.

Installation

CoC

🔗 github.com/neoclide/coc.nvim

CoC or Conquer of Completion is a plugin that interfaces with language servers to provides a lot of great features like proper autocomplete, jump to definition, documentation display, refactoring tools, etc.

The installation of the CoC is very straight forward. Simply add this line to your init file:

Plug 'neoclide/coc.nvim', {'branch': 'release'}

And run on Neovim:

:PlugInstall

Which is the command from Plug to install the plugins listed on your init file. Remember to source again your init file:

source /path/to/your/init.vim

CoC Tsserver extension

🔗 github.com/neoclide/coc-tsserver

CoC plugin on its own does not do much for us. We need to install an extension to add the features we want.

The extension in question is called Tsserver, which is a language server for Typescript and Javascript.

To install, run this command from Neovim:

:CocInstall coc-tsserver

To check if everything went as expected, run this:

:CocList extensions

This will open up a window with all the installed extensions for CoC, you should see listed, something like this:

+ coc-tsserver 1.5.6 ~/.config/coc/extensions/node_modules/coc-tsserver

That means that everything is correct!

So, what can we expect from this extension?
Here is the feature list from the official Github repository:

Supports javascript & typescript and jsx/tsx.

Installs typings automatically.

Commands to work with tsserver, including:

tsserver.reloadProjects

tsserver.openTsServerLog

tsserver.goToProjectConfig

tsserver.restart

tsserver.organizeImports

tsserver.watchBuild

Code completion support.

Go to definition.

Code validation.

Document highlight.

Document symbols of current buffer.

Folding and folding range of current buffer.

Format current buffer, range format, and format on type.

Hover for documentation.

Implementations codeLens and references codeLens.

Organize imports command.

Quickfix using code actions.

Code refactor using code actions.

Find references.

Signature help.

Rename symbols support.

Rename imports on file rename, require watchman installed in your $PATH.

Search for workspace symbols.

A pretty sweet list, huh?

Conclusion

As we've seen, it is not that difficult to have a complete Typescript setup running with Neovim and CoC in no time.
There is so much more we can tweak and improve. This is the bare minimum to get you going with Typescript on Neovim.

Next, let's dig a little deeper on Tsserver CoC extension and some other cool Neovim plugins!

Home Development Setup 2020 - Pandemic Edition

Rafael Dias — Mon, 10 Aug 2020 07:00:00 +0000

Ah, 2020, what a year! Raging Covid-19 pandemic, killer wasps, Bolsonaro, a family of wild boars stealing notebooks from naked middle-aged men, bubonic plague, whatever your wildest nightmares can request, 2020 can deliver.

Amid such challenging times, we have been, most of us forcedly, working from home for the past five months or so, so a good home-office setup is more relevant than ever!

It comes as no surprise to anyone that your workstation and equipment can impact drastically, not just your productivity but your overall well being. Our work environment is sometimes where we spent the bulk of our days, so every detail counts.

Luckily for us at home, me and my wife, we have been improving and experimenting with the home office way before the lockdown started, so when the pandemic struck, we were all set.

We designed the space for the two of us, but I will focus in this post on my workstation, which is focused mainly on development.

The Desk

Everything starts with the desk. It’s the foundation of the workspace.

First, I was looking for two distinct desks, ended up leaning towards a big tabletop one able to support two workspaces. It felt cleaner and more uniform.

I chose a kitchen tabletop from Ikea called KARLBY. It was almost the exact size of the wall the station is on, not as wide as I hoped for, but it was relatively cheap, and it is gorgeous.

As feet, I repurposed the ones from an old table that now lives on the basement storage, added an ALEX drawer (also from Ikea) in the middle, and voilá: We had a desk.

Computers

Currently, I have two computers in use. There is also an ancient Macbook Pro 13” from 2012, which I am planning to repurpose as a Linux machine for development. But that’s a topic for another post.

The main machine is a Macbook Pro 15” 2019 A.K.A the work-machine, it is not mine actually, the company provided for me. It sits most of the time on a BookArc alluminum support from Twelve south.

My personal computer at the moment is an AMD desktop (Windows/Manjaro dual boot) that I’ve built end of last year, A.K.A Doom Eternal machine because that’s all I have been doing on that computer since March.

Monitors

By far, the most tried and tested aspect of my setup. I tried a lot of combinations, dispositions, and models.

Dual monitor, triple monitor, dual monitor + iPad, dual monitor + laptop + iPad, ultrawide monitor, you name it. Curious about all the variations? Check out my Instagram at @the.minimalist.developer.

Now I am back to the basics, 90% of the time using only a single 4k 28” Samsung U28E590 hooked to a monitor arm I’ve found on Amazon.

Depending on the tasks at hand, I might feel more comfortable with two screens, when this happens I open up the laptop and I am good to go.

When working on the desktop, I rarely, if ever, feel the need for an extra monitor because of the I3 desktop manager. It allows me to organize the workspace much better, with a 28” display, there is not much need for more space.

Keyboard

Yep, I am the despiteful coworker that uses those typewriter-like sounding keyboards. What can I do? It feels so good!

We type all day long, better be typing on something enjoyable, right? On top of the feeling, there is also an ergonomic benefit.

Currently, I am using an Anne Pro 2 (Gateron blues switches) with the notebook and a Pok3r (MX Clear switches) on the desktop.

Usually, only one would be at home, and the other would be at the office, but since all this pandemic, I brought all my stuff from the office back home.

But to be honest, none of those are the endgame for me. I will be building a new one soon.

Mouse

Neglected and often forgotten, the mouse is only a central piece when I am playing, that’s when I use a Logitech G305.

While at work, my entire workflow revolves around the keyboard. My development environment resumes practically in just a terminal. On my browser, I use extensions to facilitate the control with the keyboard.

The amount of interactions left to the mouse is small, that’s why I never paid much attention to it. But after a lot of time using Apple’s Magic Mouse, I decided to invest in a device focused on ergonomics, my wrist was killing me, even with relatively low usage.

I learned about trackballs, and after reading a lot of praising reviews decided to give it a shot. Loved it!

Ended up choosing a Kensington Expert Mouse, and never looked back.

Headphones

What kind of developer setup does not have headphones? Especially now, that all the meetings happen remotely, headphones are an extreme necessity.

Most of the time, I use Apple’s Airpods, which works great, except when you have a lot of stuff connected over Bluetooth. If that’s the case, you can face a lot of connectivity issues, like I have been facing ☹.

While playing or listening to music, I use the Beyerdynamic DT 150, the famous German tank, super well built, the rustic, weird, retro design is a con for some, I dig it. I hook these up to a Fiio K3, a headphone amplifier, and Digitial Audio Converter.

Chair

For budget reasons, I chose the JÄRVFJÄLLET from IKEA. It is a good looking chair, but I don’t find it very comfortable, the neck/head support feels weirdly positioned, the arms have no adjustments whatsoever, among other things.

I mean, what could I expect from a 200 euros chair? High end, good quality office chairs can easily pass the 1000 euro mark. It is an investment that will last for a long, long time, one that I plan to make shortly.

Conclusion

At least for me, it seems that my workspace will always be a work in progress. While writing this post, I noticed how many things I want to improve, swap, or change, and it is a lot!

Even with all the details that can be improved, this is still the best setup I have ever had, and proved time and time again to have been a wise investment. It makes my time at the computer that much more enjoyable and comfortable, which is essential during these prolonged indoor times we have been going through.