The Minimalist Developer

Don't Put All Your Tokens in One Basket

2026-07-08T08:30:00+00:00

AI is present everywhere these days, whether you like it or not, especially in our industry.

The degree of reliance goes to extremes, to the point where a service disruption means no work gets done at all.

I am not here to debate the pros and cons of AI in development, but to explore alternative strategies to reduce risks and tame the costs of money-hungry AI machines.

What we are trying to avoid</h2>
Outages continue to be a regular occurrence. Anthropic's status page</a> paints a good picture of the situation, with incidents practically every day. GitHub Copilot</a> struggles to keep up with demand, just to name a few.
Rate limits have tightened as providers shift from heavily subsidized to trying to (unsuccessfully) monetise.
In early 2025, OpenAI lowered default tokens-per-minute caps for new accounts, and Anthropic introduced stricter tier limits that require escalated payment plans to bypass</a>
Regional access remains unpredictable. Anthropic updated its list of supported countries in early 2025, dropping service in several markets</a> without advance notice, while OpenAI's terms continue to shift in response to evolving data sovereignty rules. A global product can find its core feature legally inaccessible in a key jurisdiction overnight not because the code changed, but because a compliance checkbox was unticked.
Not to mention the increasing involvement of governmental entities actively in "regulation" with less-than-opaque reasoning, like the debacle around Anthropic's Fable 5 (their latest model family)</a>.
In a multi-jurisdiction world, trusting a single provider's availability map is an operational gamble.
Those are the headlines, broadcasted everywhere. There are subtle and more prevalent issues that can be just as damaging for teams that heavily rely on AI.

Silent Downgrades</h3>
The API stays identical, but the model behind it doesn't. Your prompts stop working as expected, and nobody sends a changelog. We see this particular example with the Fable 5 now back in the picture, which will fall back to Opus 4.8 for various tasks</a>.
This could be due to a myriad of reasons:

A/B testing</li>
Cost optimization</li>
Safety or policy updates.</li> </ul>
The reason is not really important for us, LLM's are not known for their determinism when you add all those extra variables on top it doesn't help.
Creeping billing</h3>
Unlike the early days, the open buffet of tokens is closed</a>. We are seeing the landscape shift from attracting users to desperately showing the world that the AI money-burning-machine can be a sustainable business model.
Providers employ many tactics to make sure their IPO is within reach: they deprecate old model IDs, or quietly remove the most cost-efficient variants from their catalogues. Your prompts still work, but the underlying model has been swapped to a more expensive one without a notice period.
In 2025, OpenAI began enforcing usage tiers that unlock cheaper rates only after a monthly spend threshold, meaning small teams and startups pay a premium simply for being small. The economies of scale don't get passed down; they get priced out.
Token pricing</a> has also been updated to a more complex and difficult-to-predict model: input, output, and even per-route within the same model family have different prices.

Strategies</h2>
The following strategies are not exclusive; they work best when combined into a layered approach that matches your team's risk tolerance and budget.
Standardise on the OpenAI API format</h3>
OpenAI API design has become the de facto standard for LLM interaction. Most providers and local runtimes (Ollama, llama.cpp servers, vLLM, etc.) support this interface, assuming your stack can target it.
Write your code against the interface, not against a specific vendor. Swapping providers becomes a simple configuration change, not a code rewrite. This decoupling protects you from vendor lock-in and enables flexible experimentation.
Choose the right tool for the job</h3>
Not everything requires a frontier bazooka. Most people would be surprised how far smaller models have come. Running locally (or self-hosted) won't beat frontier models on raw capability, but they don't disappear, don't raise prices, and don't relay information home. For a lot of tasks—classification, summarisation, structured extraction—they're already good enough.
Consider a tiered approach for models:

Baseline models, where you can balance speed and performance for most of everyday tasks: Claude Sonnet 4.6, GPT-4o, DeepSeek v3.2 </li>

Smaller, quicker models for completion or simple tasks: Qwen2.5-Coder 1.5B, DeepSeek-Coder 3B </li>

Frontier models, for tasks that require deep, nuanced understanding, like planning a difficult technical solution: Claude Opus 4.8, DeepSeek v4-pro, GPT-5.5 </li> </ul>
It is prudent to also maintain a chain of fallbacks with different providers mechanism ensuring that your core functionality remains robust and independent.
Abstract the provider behind your own layer</h3>
Don't scatter SDK calls across your codebase. Route everything through one thin layer you control, ensuring a single point of management for all external interactions.
With this approach, you can easily switch models per task or per cost budget, add retries, timeouts, and a local fallback in one place, and log and evaluate outputs to catch silent downgrades.
LiteLLM</h4>
You don't have to build this layer yourself. There are a few robust projects like LiteLLM</a> which acts as a proxy and SDK that exposes a single OpenAI-compatible interface in front of 100+ providers—OpenAI, Anthropic, Bedrock, local Ollama, you name it.

One interface, many backends: swap providers with a config change, not a rewrite.</li>
Built-in retries, fallbacks, and per-model routing covering the abstraction concerns above, off the shelf.</li>
Cost tracking and rate limiting in one place, so you can catch a "premium tier" surprise before it hits the invoice.</li> </ul>
The point isn't LiteLLM specifically, it's that your code should talk to your boundary, and let something like this sit behind it.
Own your data and prompts</h3>
Keep prompts, evals, and any fine-tuning data versioned in your own repo. If you can rebuild your behaviour on a different model, you're portable.
Conclusion</h2>
Redundancy isn't paranoia, it's the same engineering discipline you'd apply to any critical dependency. You wouldn't build on a single database with no backups and no migration path. AI providers deserve exactly that skepticism.

The Illusion of Competence

2026-06-26T17:00:00+00:00

Am I Missing Something?</h2>
We are four years into the "AI revolution," and it brought along a lot of possibilities, misinformation, fear mongering, j
In the midst of all the nonsense and absurd claims, one always makes me scratch my head: "Oh, now with AI, SaaS is dead! You can do it all yourself."
It left me questioning myself for quite a while: is my sarcasm meter broken?
Might Not Be That Easy</h2>
This sounds strange to me because any reasonably seasoned software developer or manager has faced the same question for decades: should we buy or build?
When we calculate the cost of building, we have to weigh so many things: maintenance, domain know-how, infrastructure, support, scalability, security. And those are just the known requirements. We also need to consider the cost when things fail, and they always fail. What is the impact then?
Big Opportunities... for Problems</h2>
The "just write your own" logic is perfectly fine for low-risk, low-complexity applications that you already know how to operate and maintain (and BTW, there are indeed a lot of micro SaaS ideas that fall into this category). Which raises the question: why would you be paying for it in the first place?
In any other scenario, an alarm starts ringing right behind my ear.

"Hey, we pay so much for Stripe. For what? Just let Claude run free!" said the overly confident CTO of a somewhat successful e-commerce company with three developers. </blockquote>
How many of those developers have experience with payment systems, fraud detection, legislation, refund workflows, and the rest? Zero.
So they let Claude run free. Three months later, a silent rounding bug in their refund flow had quietly overcharged a chunk of customers. No fraud detection meant chargebacks piled up, and the payment processor flagged the account. The "savings" evaporated, plus the cost of the engineering scramble, the lost trust, and the legal review. The realization that they were out of their depth came expensive and late.
This might be an extreme example, but, scaled to their respective proportions, the same dynamic applies to almost everything.
It's not about AI itself</h2>
To be clear, this is not an argument against AI. AI is excellent at accelerating the parts you do understand: scaffolding the integrations, writing tests, generating boilerplate, documenting workflows. The distinction is between using AI to move faster on a problem you can reason about, versus using it to replace expertise you simply do not have. The former is leverage. The latter is a liability waiting to blow up.
Conclusion</h2>
AI is an immense help for so many professions, including development, but it's not a silver bullet. Buy versus build never went away; AI just made it easier to pick the wrong answer with more confidence.

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

2025-02-18T07:00:00+00:00

Assumptions, clarifications, and reasons</h2>
What are we going to do today? We're going to build a minimalist blog using Zola</a> (built with Rust</a>, btw), AWS CDK</a>, Tailwind CSS</a>, and a tiny bit of Typescript</a>.
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</a> / 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.</li>
Familiarity with AWS and CDK.</li>
I want to.</li> </ol>
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</a> / 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</a> - 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.</li>
It has to be statically generated - I don't want server-side render something that will never/very unlikely to change.</li>
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.</li>
The frontend setup should be simple and easy to extend.</li> </ul>
With that in mind, I quickly narrowed down to a few challengers Gatsby</a> and Hugo</a> 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</h2>
CDK</h3>
First, let's install AWS CDK.
# This will install the CDK command line tool globally npm install -g aws-cdk</code></pre>
This is the condensed version, you can find more information in their Getting started page</a>.
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</code></pre> 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</a> before reading any further.
Zola</h3>
Make sure you have Zola installed. They have a pretty extensive list of ways of installing it</a>.
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</code></pre> 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</a> 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</code></pre>
Accessing http://127.0.0.1:1111</a> should show the standard Zola welcome page.
Congratulations, you made a website.
Tailwind CSS</h3>
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</code></pre> Now we should have all the pieces in place so we can start to put our blog together.
Infrastructure</h2>
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</a> 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</a> to enable a much faster, reliable, and cheap way to deliver our website.
This setup will look something like this:

S3 Bucket</h3>
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, });</code></pre> 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, });</code></pre> 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, });</code></pre> 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, }, ], }, }); </code></pre> 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: ["/*"], });</code></pre>
Deployment</h2>
Alright, now we can already start deploying.
# First build the website zola build # Then deploy cdk deploy</code></pre>
If everything went well you should see your Stack ARN</a> 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

2025-02-10T07:25:00+00:00

Legacy</h2>
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</h2>
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</h2>
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?</h2>
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</h3>
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</h3>
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</h3>
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</h2>
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?

2025-01-16T18:25:00+00:00

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.

Setting Up Typescript Project From Scratch

2020-11-29T10:25:00+00:00

TL;DR</h2>
You don't want to read through all those steps? Dive in straight into coding, just clone/download/fork this repository</a> with the resulting base project of this post 😀.
Introduction</h2>
Whenever learning a new language after configuring a proper development environment</a>, 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</li>
Unit test setup: Jest</li>
Style guide: Airbnb style guide for Typescript</li>
NPM Scripts: Wrap up common commands in NPM scripts</li>
Pre commit hooks: To ensure we don't tarnish our immaculate repository</li> </ul>
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</h2>
1 - Initiate the Project</h3>
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}</code></pre> The above command will generate this structure:
ts-project ├── src └── tests └── unit └── src </pre>
Hop into the project's folder.
cd ts-project</code></pre> Initiate an empty Git Repository:
git init</code></pre> Add a .gitignore file at the root of the project with the following content:
node_modules/ dist/</code></pre> 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</code></pre> Install Typescript: npm install --save-dev typescript</code></pre> 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</code></pre> This line deserves a word or two. Alongside NPM, it is installed another tool called NPX</a>. 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.</code></pre> 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 } }</code></pre> For a detailed description of what each of these fields means, please check the official documentation right here</a>. Let's tweak this a little bit. Add two new keys to the compiler options "outDir": "dist", "sourceMap": true</code></pre> outDir: being the destination folder of the transpiled code will be stored, in this case, we go with the most common of all, dist.</li> sourceMap: enables the generation of source map files. They allow debuggers and other tools to show the original Typescript when debugging the compiled Javascript.</li> </ul> And at the root we add: "include": [ "./src/**/*" ]</code></pre> 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/**/*" ] }</code></pre>2 - Unit Tests</h3> For unit tests, I have been using Jest</a> 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</code></pre> 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', ] };</code></pre> And our testing setup is done. 3 - Style guide and linting</h3> This is a crucial step to ensure, among other things consistency. I am have been working with the Airbnb style guide for Javascript</a> 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</a>, 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</code></pre> And add .eslintrc.js to the project root with the content: module.exports = { extends: ['airbnb-typescript/base'], parserOptions: { project: './tsconfig.json', }, };</code></pre> In case you went through my last post "Setting up Neovim for typescript development</a>" 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</code></pre> Check out its documentation</a> to learn more about the extension. 4 - NPM Scripts</h3> Let's leverage the NPM scripts</a> 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" }</code></pre> 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</code></pre>5 - Pre-Commit Hooks</h3> Finishing up with some fail-safes, it can make our lifes much easier. Git hook</a> 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</a> to run our scripts before the commits. To install it, run: npm install --save-dev pre-commit</code></pre> And then add this to package.json: "pre-commit": [ "test", "lint", "compile" ],</code></pre> 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</h3> 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;</code></pre> 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'); });</code></pre> Now, from the command line at the root of the project, run: npm run lint && npm run test && npm run compile</code></pre> 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</code></pre> We've made it! Conclusion</h2> 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 2020-11-23T19:00:00+00:00 Introduction</h2> First things first, right? Yes. So, I am learning Typescript</a> 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</a>, 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</h2> 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</a> short and straight to the point post on what is Neovim and how to install it. Git</h3> 🔗 git-scm.com</a> 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</h3> 🔗 nodejs.org</a> We need to, you know, run the code after compiling it. I currently am using version 12. Plug</h3> 🔗 github.com/junegunn/vim-plug</a> 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</h2> CoC</h3> 🔗 github.com/neoclide/coc.nvim</a> 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'}</code></pre> And run on Neovim: :PlugInstall</code></pre> 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</code></pre>CoC Tsserver extension</h3> 🔗 github.com/neoclide/coc-tsserver</a> 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</code></pre> To check if everything went as expected, run this: :CocList extensions</code></pre> 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</code></pre> 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 </li> tsserver.openTsServerLog </li> tsserver.goToProjectConfig </li> tsserver.restart </li> tsserver.organizeImports </li> tsserver.watchBuild </li> </ul> 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. </blockquote> A pretty sweet list, huh? Conclusion</h2> 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 2020-08-10T07:00:00+00:00 Ah, 2020, what a year! Raging Covid-19 pandemic</a>, killer wasps</a>, Bolsonaro</a>, a family of wild boars stealing notebooks from naked middle-aged men</a>, bubonic plague</a>, 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</h2> 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</a>. 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</a> (also from Ikea) in the middle, and voilá: We had a desk. Computers</h2> 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</a> 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</h2> 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</a>. Now I am back to the basics, 90% of the time using only a single 4k 28" Samsung U28E590</a> 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</a>. It allows me to organize the workspace much better, with a 28" display, there is not much need for more space. Keyboard</h2> 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</a> (Gateron blues switches) with the notebook and a Pok3r</a> (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</h2> Neglected and often forgotten, the mouse is only a central piece when I am playing, that's when I use a Logitech G305</a>. 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</a>, 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</a>, and never looked back. Headphones</h2> 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</a>, 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</a>, 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>, a headphone amplifier, and Digitial Audio Converter. Chair</h2> For budget reasons, I chose the JÄRVFJÄLLET</a> 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</h2> 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. About me 2020-08-07T07:00:00+00:00 About Me</h1> Hey there! My name is Rafael and I'm a tech enthusiast with a knack for building cool stuff and leading teams to do the same. I've been around the block for a while, building serverless setups to sleek web experiences. On this blog, I spill the beans on my adventures in tech, share tips on staying productive on the terminal, and talk about my love for minimalism. Whether you're a coder, a manager, or just someone looking to make tech work for you, stick around for a good laugh and some solid advice. Hello World, Again... 2020-08-07T07:00:00+00:00 Hello, world! My name is Rafael Dias, I am a Brasilian self-taught software engineer currently working at picture-perfect Munich, Germany, it is a great pleasure to have you here! Here I will talk about software development, career, technology, gadgets, all geek-related stuff, you get the drill. But before we begin, I know what you are thinking... Another blog? Why?!</h2> Oh God, yet another blog, why? Don't we have billions of blogs already? Why bother to create another one? Those are the questions I posed to myself over and over again, maybe the good old habit of self-sabotage playing its role, or just common sense trying to do its job, who knows? After much deliberation on the subject, I understood the reasons that make sense for me to create yet another blog, to be honest, there are four very compelling ones: 1 - It helps me to learn new things</h3> There is no better way to ensure you know something than trying to explain to others. In the process of explaining a complex topic, I found myself digging deeper and solidifying fundamental knowledge that has been proved invaluable in my day-to-day work. 2 - Improves my communication skills</h3> It should be no secret by now that one of the most crucial, yet most often neglected, skill to a developer is communication. Being able to convey complex and abstract ideas in a simple and accessible way is priceless. And writing is one of the best exercises for me. 3 - Showcase my interests and skills</h3> It is not an easy task to showcase your interests and skills, especially if you are mainly working with systems architecture and backend development like in my case. So breaking down personal projects and ideas helps to lay out what interests me, my way of thinking, and my skills. 4 - The possibility of helping others</h3> The gratifying feeling of helping someone to solve an irritating problem, or to understand new paradigms, or technologies is unparalleled to me. And where does the newborn go from here? The net is vast and infinite</h2> Indeed the topics are endless, so much stuff to talk about so little time! That's why I will try to focus on serverless solutions, systems architectures, and productivity, which currently are my favorite topics to think and talk about, so expect the majority of the content to be about those things. Even though I have failed miserably several times before when trying to keep a schedule on content, I will try to keep at least two posts a month. So, I hope to see you back here soon!

Strategies</h2>
The following strategies are not exclusive; they work best when combined into a layered approach that matches your team's risk tolerance and budget.</p>

Conclusion</h2>
Redundancy isn't paranoia, it's the same engineering discipline you'd apply to any critical dependency. You wouldn't build on a single database with no backups and no migration path. AI providers deserve exactly that skepticism.</p>

TL;DR</h2>
You don't want to read through all those steps? Dive in straight into coding, just clone/download/fork this repository</a> with the resulting base project of this post 😀.</p>

Git</h3>
🔗 git-scm.com</a></p>
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</p>

NodeJS</h3>
🔗 nodejs.org</a></p>
We need to, you know, run the code after compiling it. I currently am using version 12.</p>

Plug</h3>
🔗 github.com/junegunn/vim-plug</a></p>
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.</p>

The Minimalist Developer

Don't Put All Your Tokens in One Basket

The Illusion of Competence

Conclusion</h2>
AI is an immense help for so many professions, including development, but it's not a silver bullet. Buy versus build never went away; AI just made it easier to pick the wrong answer with more confidence.</p>

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

Take control of your learning journey

3. Tactical</h3>
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.</p>
An awesome tool to play around and figure out trends is Google Trends.</p>

Why Everybody Wants To Get Rid Of Software Developers?

Setting Up Typescript Project From Scratch

Setting Up Neovim For Typescript Development

Home Development Setup 2020 - Pandemic Edition

About me

Hello World, Again...

1 - It helps me to learn new things</h3>
There is no better way to ensure you know something than trying to explain to others. In the process of explaining a complex topic, I found myself digging deeper and solidifying fundamental knowledge that has been proved invaluable in my day-to-day work.</p>

4 - The possibility of helping others</h3>
The gratifying feeling of helping someone to solve an irritating problem, or to understand new paradigms, or technologies is unparalleled to me.</p>

The Minimalist Developer

Don't Put All Your Tokens in One Basket

Strategies</h2> The following strategies are not exclusive; they work best when combined into a layered approach that matches your team's risk tolerance and budget.</p>

Conclusion</h2> Redundancy isn't paranoia, it's the same engineering discipline you'd apply to any critical dependency. You wouldn't build on a single database with no backups and no migration path. AI providers deserve exactly that skepticism.</p>

The Illusion of Competence

Conclusion</h2> AI is an immense help for so many professions, including development, but it's not a silver bullet. Buy versus build never went away; AI just made it easier to pick the wrong answer with more confidence.</p>

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

Setup the project</h2> CDK</h3> First, let's install AWS CDK.</p>

CDK</h3> First, let's install AWS CDK.</p>

Infrastructure</h2> I like to start with the infrastructure setup because it allows me to keep deploying as the project progresses.</p>

Deployment</h2> Alright, now we can already start deploying.</p>

Take control of your learning journey

3. Tactical</h3> 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.</p> An awesome tool to play around and figure out trends is Google Trends.</p>

Why Everybody Wants To Get Rid Of Software Developers?

Setting Up Typescript Project From Scratch

Setup</h2> 1 - Initiate the Project</h3> Define the folder name that will house our project. In this case, let's call it ts-project</strong>.</p>

1 - Initiate the Project</h3> Define the folder name that will house our project. In this case, let's call it ts-project</strong>.</p>

Setting Up Neovim For Typescript Development

Home Development Setup 2020 - Pandemic Edition

About me

Hello World, Again...

1 - It helps me to learn new things</h3> There is no better way to ensure you know something than trying to explain to others. In the process of explaining a complex topic, I found myself digging deeper and solidifying fundamental knowledge that has been proved invaluable in my day-to-day work.</p>

4 - The possibility of helping others</h3> The gratifying feeling of helping someone to solve an irritating problem, or to understand new paradigms, or technologies is unparalleled to me.</p>

Strategies</h2>
The following strategies are not exclusive; they work best when combined into a layered approach that matches your team's risk tolerance and budget.</p>

Conclusion</h2>
Redundancy isn't paranoia, it's the same engineering discipline you'd apply to any critical dependency. You wouldn't build on a single database with no backups and no migration path. AI providers deserve exactly that skepticism.</p>

Conclusion</h2>
AI is an immense help for so many professions, including development, but it's not a silver bullet. Buy versus build never went away; AI just made it easier to pick the wrong answer with more confidence.</p>

3. Tactical</h3>
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.</p>
An awesome tool to play around and figure out trends is Google Trends.</p>

1 - It helps me to learn new things</h3>
There is no better way to ensure you know something than trying to explain to others. In the process of explaining a complex topic, I found myself digging deeper and solidifying fundamental knowledge that has been proved invaluable in my day-to-day work.</p>

4 - The possibility of helping others</h3>
The gratifying feeling of helping someone to solve an irritating problem, or to understand new paradigms, or technologies is unparalleled to me.</p>