DEV Community: Jerry

Only 34% of developers got this JS concept right 😱❗️❗️

Jerry — Wed, 29 Mar 2023 06:17:33 +0000

The question in that poll may seem simple but in reality, there is a few things going on.

If you are wondering the answer to that question is steak.

Let’s break that down.

Pass By Reference

Objects within Javascript are pass by reference by default.

What that means is variable definition and assignment are linked to the object as a reference.

So, any changes to that object means... You are changing the original object ❗️

The reason this is not ideal is because you are mutating the value of an object for all the code using that object.

And that can lead to really hard to debug bugs.

So, what can you do about it ?

Well, that’s where cloning comes in.

Let‘s see how that works.

Object Cloning

One way to combat against this issue is through cloning of the object when re-assigning or when you are changing it.

When you clone an object, you are essentially creating a new copy of it.

So, that variable no longer references the original, it now references the new copy.

This way when you make changes to that object, it doesn’t affect the original object.

So, how do you do this in Javascript ?

Let’s look at some techniques you can use to achieve this.

Object Cloning techniques (Javascript)

Here are 3 methods for cloning objects:

Object.assign - creates a shallow copy of the object
Spread operator - creates a shallow copy of the object
structuredClone - creates a deep copy of the object

The difference between shallow and deep is that deep will copy all the nested objects within the object. Shallow will not do this.

And there you have it!

Remember be careful when mutating or changing references to objects.

It can leads to nasty bugs!

If you learned something new or enjoyed this article, be sure to give it a like or share with someone you know!

Typescript: 5 Resources To Become A Pro

Jerry — Sun, 26 Mar 2023 03:51:38 +0000

Photo by Johnny Caspari

1. Learn TypeScript in 5 minutes

Don’t have hours to look through documentations ?

Check this quick guide that will get you up to speed on Typescript!

Link 👉 Learn TypeScript in 5 minutes

2. Learn TypeScript – The Ultimate Beginners Guide

Learn TypeScript – The Ultimate Beginners Guide

3. Typescript handbook

A lot of references, and comprehensive guide to the language (syntax, features and best practices).

Link 👉 Typescript handbook

4. TypeScript Deep Dive

A very comprehensive deep dive into Typescript with practical examples.

Tips, Tricks, best practices and more.

Be sure to check it out!

Link 👉 TypeScript Deep Dive

5. React + Typescript cheatsheet

A lot of great information about using Typescript.

It’s a very comprehensive cheatsheet with a lot of example.

I refer to it a lot.

It’s a must have in your bookmark! (Especially if you use React)

Link 👉 React + Typescript cheatsheet

That’s all.

Be sure to bookmark this, and if you found this article helpful, please share it with someone you know!

Thinking in React (Visualized)

Jerry — Fri, 17 Mar 2023 04:44:28 +0000

When working with React.js, one of the most important thing you need to do is to shift your thinking.

It introduces a new mental model for developers to think and approach developing User interfaces (UI) in an easy and understandable way.

You declare how your HTML should look and act without worrying about the details.

React.js handles all the details of the HTML like rendering, updating and removing elements from the HTML DOM for you.

The documentation describes this as “Thinking in React”.

Yeah... but what does that actually mean ?

Let’s dive into the process with an example!

1. Isolate the User Interface into independent components

When we look at an User Interface (UI), we need to think about the “components” or the parts that make up the whole.

In this example, this LinkedIn Page Card will likely be composed of:

Card
Button
Image

All of the individual components add up to the whole of the User Interface (UI).

2. Create an hierarchical data relationship

Now that we have our individual components, we now need to think about how they relate to each other.

In addition, how will the “data flow” through out these components.

In this example, Card will be the parent, and the data will flow downwards (pass via props) to the children (Button, Image).

3. Think about where the state should live

Within React.js, each components can have their own state (using useState).

The question comes down to: Where should we put the state ?

Looking at the “Follow” button, we may need an external API which means we may need some loading state while that gets processed.

So, in this case, the state is better kept within the Card component.

4. Write the Code

Once you are finished with designing the components, state and data flow.

It’s time to actually code it out!

Here is what the scaffold may look like:

And... That’s it!

Did you learned something new ?

Be sure to give it a reaction then share it with someone who think will enjoy this post! ❤️

Hey, I am also on LinkedIn - https://www.linkedin.com/in/ijerrychang/.

I am always looking to connect with like minded techies 🤓 - just send me an invite!

The Science Behind Expert Decision Making

Jerry — Sat, 11 Mar 2023 21:06:29 +0000

The recognition-primed decision (RPD) model was introduced by Dr. Gary Klein.

It’s a model for understanding how these experts are able to instantaneously come up with answers or solutions in highly complex situations.

These results are from research that studied firefighters, and later on military operations have shifted their training to applied similar models into their training on decision making.

There are four distinct phases of this expert intuition process.

Let’s go through the process!

1️⃣ 𝗖𝘂𝗲 - A pattern is recognized in a situation (System 1)

2️⃣ 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 (𝗠𝗲𝗺𝗼𝗿𝘆) - The pattern is matched with a piece of information in the associative memory (System 1)

3️⃣ 𝗔𝗻𝗮𝗹𝘆𝘀𝗶𝘀 - Analysis takes place to determine if it makes sense or if it will work (System 2)

4️⃣ 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻 - A decision is proposed or made (Assuming it passes phase 3)

💡 System 1 vs System 2

You may have noticed I labeled the steps with either System 1 or 2.

These two systems were introduced by Dr. Daniel Kahneman in his book “Thinking fast and slow” to better understand how humans think.

System 1 - intuitive thinking or “fast thinking”
System 2 - analysis or “slow thinking”

This means that step 1 and 2 in the RPD process are the works of system 1.

This is why these experts are unable to trace the steps of how they arrived at a solution or answer because this process happens automatically.

It is their intuitive thinking that allows them to not only recognize the pattern but retrieve the correct information.

You can probably tell why this is important for individuals like firefighters and military personnels because these individuals tend to operate in highly complex, fast paced and time sensitive environments.

How can I apply this to my learning ?

Even though this says “expert decision making”, this process is the same for everyone.

When you are learning, you can improve stages 1 and 2 in the decision making process in order to make it easier to recall information.

Specifically, these are the cue (stage 1) and information retrieval (stage 2) phase of the decision making process.

And how you improve these two phases will be different for everyone.

What that means in practice can be exposing your brain to multiple sources of information (videos, images, audio and writing) when learning.

This will improve your brain’s ability to recognize patterns in programming or anything else you are learning about.

Again, you don’t have to measure this or see if it works.

Just make sure you are exposing yourself to multiple sources of information to enhance the cue process, and let your brain do all the heavy lifting!

And that’s Dr. Gary Klein’s model for understanding expert intuition.

Next up we’ll contrast this with another model by Dr. Paul Meehl.

It uses the same RPD process described above but we’ll take a look at why it doesn’t work in some scenarios for some experts (ie Stock pickers and political scientists ).

That’s all for now.

If you learned something or enjoyed this post then be sure to share it with someone who you think would benefit from it!

Be sure to follow me to stay up-to-date 👉 @jareechang

Understanding Identity Access Management (An analogy)

Jerry — Sat, 11 Mar 2023 20:43:37 +0000

What is this IAM thing ?

and… why do I need to know about it ?

It’s a must know! It’s a major key when working in the cloud 🔑

Here is a good way to think about it.

Imagine you are going to a conference, and within the venues there are security personnel in different areas checking people’s passes.

The passes may have the following groups:

Staff - The people working there (Organizers, equipment, catering etc)

Speakers - The people speaking at the conference

General - The general admission for the attendees

Each of these groups will be allowed to enter with their pass, and have access to different parts of the venue.

Identity Access Management (IAM) works in a very similar fashion.

It identifies who is trying to access what then grants access if they have the appropriate permissions.

The only difference is that IAM is controlling the access to cloud resources.

These resources may include things like storage, network, compute services and much more in any of the cloud vendors.

All of which are very common building blocks for most cloud infrastructures.

Since all these services rely on IAM, I consider it a foundational piece.

Just like with our example of the conference, IAM is the security personnel.

It determines who can access what based on a defined policy or a configuration.

Before we part, let’s do a review!

💡 Review

► IAM is the security personnel within the cloud, it controls who and what for access control in all of the services (The technical term for this is Authentication & Authorization)

► IAM is the building block in which all others services build on top of

► IAM is one of the core pieces for security in the cloud

And… That’s all.

If you are in the process of learning about the cloud, I highly encourage you to start with IAM.

Like I said, it’s such a foundational piece; and once you learn it, it’ll make learning other services that much easier.

Do you agree ? or should someone learn something else to start ?

Let me know in the comments 👇

The Mystery of Expert Intuition (Preview)

Jerry — Wed, 01 Mar 2023 07:25:35 +0000

Have you ever been in a highly complex situation with an expert and out of no where they just have an answer instantaneously ?

And when asked about how they knew, they just reply with “trust me, I just know” or “I had a hunch”.

How is it that they are able to do this instantaneously, and with high accuracy ?

Is it Magic ? Or is it something else ?

We’re going to get to the bottom of this!

In the book “Thinking fast and slow” by Daniel Kahneman, he presents two models to better understand this phenomenon which is referred to as expert intuition.

🧠 𝗧𝗵𝗲 𝘁𝘄𝗼 𝗺𝗼𝗱𝗲𝗹𝘀 𝗳𝗼𝗿 𝗲𝘅𝗽𝗲𝗿𝘁 𝗶𝗻𝘁𝘂𝗶𝘁𝗶𝗼𝗻 𝗮𝗿𝗲:

1️⃣ Dr. Gary Klein’s model (high validity intuition)

2️⃣ Dr. Paul Meehl’s model (low validity intuition, statistical method)

These results are from years of research on studying clinicians, surgeons, firefighters, nurses, military operations, business operations, stock pickers and pundits.

We’re going to dive deep into the inner workings of both of these models to dispel some of this “magic” that goes on.

💡 𝗪𝗵𝘆 𝗶𝘀 𝘁𝗵𝗶𝘀 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗳𝗼𝗿 𝗽𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹𝘀 ?

𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻 𝗠𝗮𝗸𝗶𝗻𝗴 - It will help us to better understand what is behind this seemingly “magical” decision making process (That experts use)
𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 - It will also provide insights on how to build expertise
𝗗𝗶𝘀𝗰𝗲𝗿𝗻𝗺𝗲𝗻𝘁 - It will help us understand in what situations should you supplement expert intuition with other decision making methods

I will be posting a lot more about this topic in the coming weeks.

It’s going to be a good one so stay tuned!

Make sure you like this post, and be sure to follow me 👉 @jareechang

Save Yourself From Data Loss 😱 ️

Jerry — Wed, 01 Mar 2023 03:17:32 +0000

So, what is blob storage ?

It is slightly different from storing a file on your computer.

In fact, it’s a distributed system.

What that means is that it’s a system that was engineered for availability, reliability, disaster recovery and ease of use.

Just like a car or airplane or any other mission critical systems.

A key feature is this disaster recovery capability which provides backups for the files that you store in the blob storage.

How Does It work ?

When you upload a file to a blob storage, you have an option to specify data redundancy or replication across zones (This will depend on the cloud provider).

What that means is that the cloud vendor is going to take that file you’ve uploaded and make copies of it then put it in their data centers around the world.

So, whenever a disaster strikes in one region, only one data center is affected.

That means only one copy of your data is affected.

While all the other copies in other data centers are not impacted.

This reduces the risk of data loss drastically.

And that’s the power of blob storages.

In fact, this one feature is probably one of the biggest blocks in many of the commonly used services to provide disaster recovery for other storages and databases.

Because who wants to lose critical data or files ?

𝗪𝗵𝗮𝘁 𝗮𝗿𝗲 𝘁𝗵𝗲 𝗰𝗼𝗺𝗺𝗼𝗻 𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 ?

Amazon S3
Google Cloud storage
Azure Blob storage

💡 Note: The pricing and capabilities will be slightly different but the overall offerings should be relatively similar

And that’s it!

If you didn’t know this was possible... well, now you know!

Did you find this post helpful ?

Then consider sharing it with someone you know!

Astro: One idea to change your view about it (FOREVER)

Jerry — Fri, 10 Feb 2023 06:13:57 +0000

Content

Content
Introduction
The types of websites you build
The Use case
Conclusion

Introduction

We’re going to talk about Astro.

Most folks see Astro as yet another framework but I think there is something more to it.

There is an unique use case for Astro that many folks are not talking about!

Before we talk about the use case, let’s review some of the key features of Astro.

The key features include:

Static (by default) - You can build your website using Javascript but the output is just a static site by default in Astro (Zero JS by default)
Partial Hydration - Usage of the “island architecture” to selectively add interactive components into the website
Flexible Framework support - Astro takes a compiler first approach, meaning it supports many frontend frameworks (React, Svelte, Vue etc)

These key features make Astro well suited for these specific scenarios.

Before we start that discussion, let’s start by looking at the different types of websites we build as developers.

This will help us to see which type of sites is most suited to be built with Astro.

The types of websites you build

If we take a step back and look at the types of website we build, the sites tend to falls into these 5 categories.

Here is what the spectrum looks like:

It can be further divided into the sub-categories:

Content Focused (more static) - Marketing, Publishing, Ecommerce
Interaction Focused (more dynamic) - Ecommerce, Stateful, Apps

The capabilities of Astro fits within the ranges of Marketing, Publishing and Ecommerce very well.

However, if you look at most companies, it typically is a combination of both.

You typically have a product then you also have a separate marketing site.

You may ask — Ok, how does Astro fit into this picture ?

The Use case

The use case that that many folks are not talking about is using Astro for rapid experimentation and prototyping (especially at scale).

So, that means using it for within the Marketing, Publshing and Ecommerce context when you already have a product in place.

This will allow you to re-use some of the code from existing Product (APIs, Components etc) to quickly build your prototypes or experiments separate from the product codebase.

Again, this an underrated use case because most folks see Astro as just another framework.

When applied in this way, I see it leveraging the full strength of what Astro has to offer.

I supose a good slogan to describe this process would be: Build simple, fast sites while leveraging existing code.

Why can’t I just use our existing stack to do this ?

In reality, you can use any stack to do this.

Astro just fits this use case a lot better (categories: Marketing / Publishing / Ecommerce).

This is the use case that it was originally designed for.

I guess it comes down to:

The level of fidelity of your experiments and prototypes
The quantity of experiments and prototypes

If we are talking about large quantities and high to medium fidelity prototypes and experiments, Astro definitely wins in this category.

Astro’s advantages (compared to other frameworks):

Great balance between flexibiltiy (Island architecture) and baseline performance (static by default)
Simplicity in deployment (Astro build outputs just html, js, css by default)

While the newer versions Astro provides features to build more complex sites (ie with SSR and API), I still see Astro being most powerful in this “sweet spot”.

Conclusion

And there you have it!

A different way of looking at how Astro can be used to its fullest potential.

And of course, the code that you re-use doesn’t have to be from a product, it can be any existing codebase (as long as Astro supports the framework).

You can re-use the code to come up with prototypes, and experiments without having to build something from scratch.

I hope this helps you to see Astro in a different way!

Give it a try, and let me know what you think.

If you enjoyed that or learned something new, please share this article with a friend or co-worker 🙏❤️! (Thanks!)

tRPC vs GraphQL: Why you shouldn’t use GraphQL

Jerry — Wed, 01 Feb 2023 05:07:18 +0000

Content

Content
Introduction
GraphQL
tRPC
Flexibility
Workflows
Decisions with GraphQL
Hidden cost of optionality
Language choice
Conclusion

Introduction

In this article, we’re going to compare the two technologies.

When it comes to technology, I always try to be as objective as possible and examine its the trade off being made.

Those trade offs or constraints will give guide your decision to know if it will work in your situation.

And that’s what we are going to talk about!

The star history may be in part to do with the “hype” of a new technology.

I suppose another way to look at it is maybe people were just using GraphQL for the wrong things ?

That is until a simpler tool came along to fit a certain need for their use case.

I’ll let you be the judge of that one.

In this article, we’ll start off with a brief introduction of the core idea behind the two technologies.

Then, we’ll dive in deeper to look at the technologies from a few perspectives.

These include:

Flexibility
Workflows
Decisions with GraphQL
Hidden cost of optionality
Language support

GraphQL

What is GraphQL ?

I think of GraphQL much like a “SQL-like” interface for your backend (or data sources).

It provides a clear contract between the consumer (clients) and the provider (backend).

Many of the components that make up “contract” are managed by tools built by open source and GraphQL community.

These are things like the graphql codegen, apollo, and so forth. So, the great thing is that there is a lot of support!

If you boil down GraphQL down to its core, there are a few stand out benefits.

The core benefits:

GraphQL schema - The data schema that creates the contract between the consumer(s) and provider
Flexibility - The flexibility in the data querying (“SQL-like” experience), workflow and process
Well supported client SDKs - The tooling in GraphQL is very well supported in many languages (Typescript, Go, Python, Ruby etc)

Now... just look at the “benefits” of GraphQL — It looks like it’s a no-brainer to adopt it right ?

Hold on just a second... There is a bit more to it than that!

To get GraphQL “right”, it does take a bit of work, and decisions upfront. We’ll talk about that in a little bit.

Ok, enough about GraphQL, let’s talk about tRPC.

tRPC

There are some similarity between tRPC and GraphQL.

They are similar in that they both try to unify the consumer and provider around a “contract”.

For tRPC, instead of the aligning around a general specification, it aligns directly via Typescript types.

That means the RPC endpoint defined on the backend is available to be used on the frontend via Typescript automatically when you are using tRPC.

It sounds a bit like magic doesn’t it (It does feel that way when you try it! ✨)

So, what are the benefits ?

The core benefits:

Speed of development & A Snappy DX - Defining a router (function), and having it available on client side right away (similar experience to HMR)
Ease of synchronization - Since the consumers and providers are very coupled, it becomes very easy to keep the two in sync to keep up-to-date

Now that we have a good overview of the technologies.

How flexibile is each technology ? Well, let’s find out.

Flexibility

When using tRPC, everything down to the workflow is quite set in stone — Or a better way to describe it is that it‘s opinionated.

The consumers(s) and providers are very tightly coupled.

This how tRPC is able to achieve this “seamless” experience between the frontend and backend.

So, really, tRPC isn’t really the most flexible technology (that can be a good or bad thing depending on your situation).

Other the other hand, when using GraphQL, you get a lot of flexibility in how you use it, the workflow and the process.

The contract between the two (consumer & provider) is very clear, and you can almost think of it as two separate things.

But... Is this level of flexibility good ?

Well, let’s see what kind of choices you need to make in order to work with GraphQL.

Workflows

To compare the two workflows, let’s use an analogy of cutting down a tree.

tRPC is like pre-made chainsaw that you can just use right away.

Whereas GraphQL is like a chainsaw that comes with the components, and in order to use it, you’d have to assemble it.

“Build[ing] the tool” also includes fleshing out the developer workflow and process.

So, GraphQL obviously has the edge of being more flexible.

Now the question is: Do you need this level of flexibility ?

Decisions with GraphQL

So, what kind of decisions do you need to make when using GraphQL ?

Here are a few:

Language choice
Type of workflow and Developer Experience (DX)
Code first or schema first (with codegen) ?
How do we handle the GraphQL query on the client ? How do we share the generated types ?
Many more... (This is just the tip of the ice berg)

This is not exactly an overwhelming list of choices.

However, it still requires the person (or team) using GraphQL to make those decisions or choices upfront.

For most folks who just need to have a simple API to read, update data and ship things.

GraphQL is most likely not going to be a good choice.

This is because when you adopt GraphQL, you are also assuming the hidden cost of it’s flexibility upfront.

If you want to be able to share code between multiple clients and provider in Typescript, tRPC provides that out of the box.

You don’t need to build a tool from the ground up just achieve this.

To me, GraphQL’s flexibility is its strength and weakness.

❓ Ask yourself:

When it comes to your workflow, and setup... how much flexibility do I (really) need ?

Hidden cost of optionality

So, when it comes to GraphQL’s flexibility, why is it a hidden cost ?

It’s easy to just look at the benefits of GraphQL, and say its a no-brainer to use it.

When you have that much flexibility in your application (and workflow), you also need to assume the responsibility that comes with that.

When working with GraphQL, you need to make many decisions and choices upfront.

The impact of these decisions and choices that you make compound over time.

So, in reality, when adopting GraphQL you should treat it like an investment — you should be ready to invest upfront and on an on-going basis.

When you get it right, you can make it really work for you (and your team).

But the catch is it also goes in the other direction.

Language choice

Another consideration when comparing the two technologies may be which languages it supports.

tRPC: Only supports Typescript

GraphQL: Supports Typescript, Python, Ruby, Go, Kotlin, etc

GraphQL gives you more choices when it comes to building your GraphQL backend server.

Conclusion

So, what are you saying... I should use tRPC ?

Actually, no.

I think you should always default to REST if you are unsure.

It’s easier to start with REST then transition to either solutions — tRPC or GraphQL.

It’s much complicated to do the reverse.

When should I use tRPC ?

Go with tRPC if you want to enhance the overall developer workflow for an internal API using Typescript (on client, react-native, backend).

This will allow your team to move quicker and ship more things.

When should I use GraphQL ?

Go with GraphQL if you want to have flexibility.

Whether that’s in how you query data (ie the “SQL like” querying), the workflow & process or in the language choice.

Just make sure you are prepared to assume the responsibility that comes with the level of flexibility that GraphQL offers.

That means investing the time & resources to build the tooling, platform and infrastructure to facilitate the end-to-end flow.

This could be used for an internal or external API.

Again, the important thing is to treat adopting GraphQL like an investment (think back to the compounding graph).

And... that’s all for now!

If you enjoyed that or learned something new, please share this article with a friend or co-worker 🙏❤️! (Thanks!)

Next.js: Build the simplest tagging system

Jerry — Sun, 22 Jan 2023 04:22:47 +0000

Content

Content
Introduction
The Existing Site
Requirements
The Tagging System Design
1. An Next.js API endpoint
2. Pre-generated data
3. Manifest file
The UI
Conclusion

Introduction

This site that I am using to host all my articles is using Next.js or specifically Vercel.

The approach that I took to hosting this site is to keep it as simple as possible.

This is because I rather not have the hassle to the infrastructure burden, so everything is to be as simple as possible.

I recently re-visited the usability of my site, and I realized a lot of my articles are hidden behind the “Writing” link.

It was difficult to know what articles were available or even find relevant articles.

So, this led me explore options, and one of the ways that many blogs (ie Wordpress sites) do this is via a tagging system.

This article will discuss the architecture behind how to build a simple one using Next.js (with Vercel).

The Existing Site

Before making any adjustments, let’s take a look at how my site generate the articles.

Like I said, my site is very simple with no external integrations, no CMS, no Database.

It’s just using Markdown.

How does the markdown get on the site ?

The utility will read the markdown (*.md extension)
Extract and transform the metadata from it
Next.js will render all of that information (using getStaticProps)

Ideally, for simplicity, I wanted to keep this same workflow and layer on a tagging system.

(Because I am lazy 😂)

Let’s talk about how we can go about to doing that.

💡 Note:

My site uses Static Site Generation (SSG) because everything comes from the markdown, and I don’t deploy that often.

Occasionally, I do deploy for edits or release new articles.

Requirements

Since this is my personal site, the aim is to optimize for simplicity.

This means one of key goals for me is to have the least amount of infrastructure burden.

The requirements:

Keep it as simple & minimal as possible
Maintain the existing flow (Pagination etc)
No external integeration (ie no DB, no CMS)
No Infrastructure burden

Even though this may not be the “best practice”, it made sense for me given my constraints.

The Tagging System Design

Now comes the idea.

The idea that I had in mind was an API that returns articles based on the tag provided in the query string.

Let’s go through the components in more detail.

1. A Next.js API endpoint

This will return the data based on the tag query in the URL.

For Example:

/writing?tag=aws - This would return all articles that were tagged with "AWS"

Here is an example of the JSON response.

JSON response (sample):

{
  "entries": [],
  "pagination": {
    "total": 4
  }
}

This api will read the JSON data directly from the filesystem.

Vercel actually supports this but you do need to configure it 👇.

💡 Note:

If you want to support reading from the filesystem, you need to turn on nftTracing on Next.js config.

This allows for “Output File Tracing”, and Next.js will put all the files that need to be read on the production server.

Now comes the question of: How do we get this data or where does it come from ?

2. Pre-generated data

In my website, I already have an existing utility for parsing these articles in markdown.

So, to get these new JSON data, I just needed to write another script to aggregate the articles into categories.

I would need to pre-generate the data because we need it available in production when our API reads a particular file.

The file convention: {name-of-the-tag}-tag.json

3. Manifest file

As part of the processing (using the script), it will also generate a manifest file which will contain the following:

The tags that are used
The number of articles in each tag

Example:

{
  "astro": 6,
  "frontend": 7,
  "aws": 35,
  "cloudfront": 11,
  "cdn": 16,
  "edge": 4,
  "aws-lambda": 8,
  "terraform": 11,
  "ci-cd": 5,
  "http-caching": 3,
  "build-system": 2,
  "dev-ops": 7,
  "open-id-connect": 3,
  "postgre-sql": 7,
  "aws-ecs": 7,
  "next-js": 2
}

On the UI, this is the file that I use to render the different tag available on the site.

The UI

Here is what the resulting UI for the tagging system.

Conclusion

And... That’s it!

This is a simplified tagging system built with Next.js using Vercel.

Again, this may not be the “best practice” but given the requirements that I had, it worked for me.

There are values in adding constraints, it tends to lead to more creative solutions!

What do you think ? Got any ideas on a different way to build something like this ?

Reach out, and Let me know! I’d love to hear it!

Also, if you learned something new, please share this article with a friend or co-worker 🙏❤️! (Thanks!)

See it in action here 👉 www.jerrychang.ca

Career Success: 5 Tips on How To Take It To The Next Level (with resources)

Jerry — Sun, 15 Jan 2023 20:17:53 +0000

Cover image by Rachel McDermott

Highlight

Here are some of the tips I wish I knew earlier.

Many of these things I still use and apply.

Here are the tips:

Learning how to learn - Figure out your style
Self Advocacy - Do a great job, then tell others about it
Negotiating compensation - It’s difficult but try to always negotiate
Going beyond your bubble - See, and think beyond just what you are doing right now
Gain clarity - Know where you are going

Let’s go through them in more details 👇

Learning how to learn

Photo by Tim Mossholder

If there is one thing that is common for ALL people working in the tech industry, its this — You are learning ALL the time.

If that is the case, you should try to figure out how you learn.

Do I learn best reading, writing, through diagrams/images or watching videos ?
What are ways I can myself on track ? and motivated to learn ?
How do I design my learning so I find the balance between being over challenged or under challenged ?
How do I track my learning ? (Hint: Use Notion or Trello)

💡 Tip:

The goal should be to get to a point where you can systemize your learning and make this into a process.

That way, the more you improve this process, the better you learn.

Resources:

Prioritization

Learn how to prioritize your task.

Even better, learn how to prioritize it for impact.

💡 Tip:

What does impact mean ?

Impact to me means how can I get the most value with what I am working with, and with the time I can put in.

Don’t come up with 5 or 10 or 20 items. Come up with one thing.

Once you do that, just do that one thing.

Every week or month, try to slot your tasks into the “Eisenhower Matrix or Box”.

// Detect dark theme var iframe = document.getElementById('tweet-1613523380367495168-272'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1613523380367495168&theme=dark" }

Reflect and review the tasks in each category.

Then set goals to move towards “Important” tasks.

This is a continual process.

Resources:

Self Advocacy

Unfortunately, it’s not enough to do a great job or work.

Beyond just doing the work, you must also advocate for yourself.

Tell people about what you did, and how it adds value.

Communicate the value of the work, and value you bring to the table.

// Detect dark theme var iframe = document.getElementById('tweet-1483956048214077445-37'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1483956048214077445&theme=dark" }

💡 Tip:

It doesn’t have to be shameless or “slimey”, if you actually did the work, and delivered on it then don’t be afraid to talk about it.

Resources:

Negotiating compensation

Let’s be honest... no one teaches this.

There is no class for this.

Would this help your career ? Yes, you bet it would.

A lot of people like to tell you: “we have a salary range here”.

That’s just code name for we want to pay you the minimum amount.

Get paid for what your worth.

Here are some resources:

Going beyond your bubble

Most people like to say — learn a new programming language or a new framework every year.

This is great but you have to realize the goal of a developer or programmer is not to code.

The goal is to provide value through your work, and sometimes it does include coding.

// Detect dark theme var iframe = document.getElementById('tweet-1478241315783544832-706'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1478241315783544832&theme=dark" }

Try to read up on how the software you build adds value or provide value to the end-user.

Do you work on a marketing site that sells shoes ? or plant fertilizer ?

Read a little bit about marketing, conversions or analytics
Read a little bit about the shoes & the plant fertilizer
Ask someone from another team questions about these things
Read some reviews online, and see what people are talking about

Don’t just be a “coder”, be a problem solver, no matter the problem, solve it.

Resources:

12 things your manager may not be telling you - Louie Bacaj

Gain clarity

Photo by Evgeni Tcherkasski

If you ask most people where do you want to be in 5 years ? in 10 years ?

Guess what is the most common answer ? I don’t know or I am not sure.

”If you don't know where you want to go, then it doesn't matter which path you take.” - Lewis Carroll

Gaining clarity allows you to move in the direction you want to go.

In the future, do you want to work as data scientist ? frontend ? backend ? graphic design ? content creator ? or whatever else

The thing is you won’t know exactly where you want to go but you should have a vague idea of where you want to go.

It’s better than not knowing at all.

Just know that this direction will change and evolve as you start moving towards it, and that’s ok.

// Detect dark theme var iframe = document.getElementById('tweet-1480061554917724161-933'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1480061554917724161&theme=dark" }

Being in motion is better than standing still in a fast moving world.

Move towards a direction that opens up future optionality.

Conclusion

That’s it!

If you found this helpful, please help someone else by sharing it or tagging someone in the comments!

Thanks! ❤️🙏

Zod: The Next Biggest thing after Typescript

Jerry — Sun, 08 Jan 2023 19:27:16 +0000

Content

Content
Introduction
Understanding the why
Managing contracts
Traditional approach
The Zod Way
Simple example
1. Defining the Zod schema
2. Convert Zod schema into Typescript types
3. Create some pizzas
4. Run-time validations
Establishing a new standard - End-to-end Typesafety
Striking the right balance
Conclusion

Introduction

I recently came across a neat little library called Zod.

My first reaction looking through the documentation was this looks interesting.

It wasn’t until I tried it that I felt the difference — The difference is MASSIVE.

Nothing comes close to it.

It’s a different approach but once you try out Zod, I think you would know what I mean.

In my opinion, Zod’s approach hits the right balance between robust code, and developer experience (DX) when working with data validation in Typescript.

⚠️ Disclaimer: After reading this article, you may not want to use any other validation library! (You’ve been warned)

Understanding the why

Typescript introduces great checks during development by statically checking the code meets the “contract” defined in the types.

This works for most cases, however, in production, it becomes more complex.

Javascript - Typescript does not run in production, it compiles down to Javascript
Loose contracts - Typescript type contracts are not enforced when code is compiled to Javascript
Data predictability - Data quality and sources tend to be un-predictable in complex system running in production

Hence, for this reasons, there is a need for run-time validation to enforces these contracts within Javascript.

Managing contracts

When we work with functions in Javascript, it consists of inputs and outputs.

A certain set of inputs will give you certain set of outputs — This is what I call a contract.

It is not too different from a contract you sign a contract with your bank or insurance or telecommunication company.

There is a certain level of guarantee when you sign on for their services.

By establishing a contract it forces us to narrow the scope of the inputs and outputs.

In essence, you reduce the surface area hence making the function more predictable.

Now comes the question, how is this done in Javascript ?

Traditional approach

The traditional approach to achieve this is installing some sort of validation library (ie Joi, Ajv etc).

The most common application for this is managing form inputs with user input data.

However, it doesn’t have to be only for forms, you can use run-time validation for anything.

It will make your code more robust because any sort of data not meeting a contract will be considered a failure.

There is not in between or edge cases. It makes the code very strict.

The trade off with these libraries is there is a lot of duplication - like A LOT in a large code base.

Not only do you have to define the Typescript types, you also have to define validation schemas.

Talk about doubling the work...

If you ever needed to do this, you know this pain. Also, let’s not even get into how much this bloats up the code base 😵.

Then next thing you know, you start doing this 👇

Well, is there a better way ?

What if I told you there is...

You can probably guess it. I’ll give you a hint, it start with a Z.

The Zod Way

Enter Zod.

Here is where Zod differs from all the other validation libraries.

How is it different from everything else ? Zod takes a schema first approach.

Meaning, you start with your validation schema (Zod schema).

Then, this Zod schema becomes your validations, and your types.

So, you get the best of both worlds!

Not only do you you get run-time validations from the schema but you also get the types by converting the schema into Typescript.

Neat huh ? Talk about super charging productivity and developer experience 😍⚡️

Simple example

Enough of the illustrations, I want to see some code!

Let’s go through a simple example.

Let’s say we’re a pizza shop, and we need to design some schemas for our website.

1. Defining the Zod schema



import { z } from 'zod';

// Zod schema

const pizzaSchema = z.object({

  sauce: z.string(),

  ingredients: z.array(z.string()),

});

Convert Zod schema into Typescript types




import { z } from 'zod';

// Zod schema

const pizzaSchema = z.object({

  sauce: z.string(),

  ingredients: z.array(z.string()),

});

// TypeScript type

export type IPizza = z.infer<typeof pizzaSchema>;

Create some pizzas




import { z } from 'zod';

// Zod schema

const pizzaSchema = z.object({

  sauce: z.string(),

  ingredients: z.array(z.string()),

});

// TypeScript type

export type IPizza = z.infer<typeof pizzaSchema>;

const pepperoniPizza: IPizza = {

  sauce: 'tomato',

  ingredients: [

    'cheese',

    'pepperoni',

  ],

};

console.log(pepperoniPizza);

// => { sauce: 'tomato', ingredients: [ 'cheese', 'pepperoni' ] }

const hawaiianPizza: IPizza = {

  sauce: 'tomato',

  ingredients: [

    'cheese',

    'pineapple',

    'ham',

  ],

};

console.log(hawaiianPizza);

// => { sauce: 'tomato', ingredients: [ 'cheese', 'pineapple', 'ham' ] }

Run-time validations




import { z } from 'zod';

// Zod schema

const pizzaSchema = z.object({

  sauce: z.string(),

  ingredients: z.array(z.string()),

});

// TypeScript type

export type IPizza = z.infer<typeof pizzaSchema>;

const pepperoniPizza: IPizza = {

  sauce: 'tomato',

  ingredients: [

    'cheese',

    'pepperoni',

  ],

};

console.log(pizzaSchema.parse(pepperoniPizza));

// => { sauce: 'tomato', ingredients: [ 'cheese', 'pepperoni' ] }

const hawaiianPizza: IPizza = {

  sauce: 'tomato',

  ingredients: [

    'cheese',

    'pineapple',

    'ham',

  ],

};

console.log(pizzaSchema.parse(hawaiianPizza));

// => { sauce: 'tomato', ingredients: [ 'cheese', 'pineapple', 'ham' ] }

console.log(pizzaSchema.parse(null)); // throws ZodError

Striking the right balance

Most libraries will force you to the right thing by sacrificing developer experience (DX).

That’s not the case with Zod, the team really got it ‘just right’.

When using Zod, you can do the right thing without any friction at all.

It works seamlessly with Typescript.

Now that’s a tool worth looking into.

Establishing a new standard - End-to-end Typesafety

Zod opens the door up to interesting tools like tRPC which takes the developer experience (DX) to the next level.

The big idea with tRPC is you can define a backend endpoint with a schema, then have automatically have autocompletion on the client side.

This raises the standard for all other frameworks to provide integrations with tRPC or create a “similar” experience.

I see tRPC, and “tRPC like experiences” being more prevalent in the future merely for the speed of development and developer experience (DX) it provides.

Conclusion

So, there you have it. That’s Zod.

A library that gives you this seamless experience for designing robust code using both run-time (schema) and static (types) validations.

Before we go, let’s do a recap.

And... that’s all for now, stay tuned for more!

If you found this helpful or learned something new, please do share this article with a friend or co-worker 🙏❤️ (Thanks!)

Also published at - jerrychang.ca

⚠️ Note: Yup also supports the ability to infer types from the data schema defined. You can do something like yup.InferType in order to get your Typescript type. Just throwing it out there as another great library that allows you to do similar things as Zod.