Forem: Vincent Tang

Lessons learned from Junior to Senior Developer

Vincent Tang — Tue, 18 May 2021 19:54:12 +0000

3 years ago, I decided to change careers and become a software developer. I had no formal training in software development and decided to learn on my own. Through countless youtube and Udemy tutorials, and hackathons, I landed my first job working on construction management software.

Fast forward to today. I'm a senior frontend developer in charge of delegating & delivering features affecting millions of users at a time. I've come a long way since then and I'm writing this post reflecting on what I learned along the way.

This isn't an exhaustive list but just lessons I learned along the way

Working with stakeholders

If you demo to stakeholders, record a video of the demo in advance as a backup.
Live coding/testing has a high chance of failure
The frontend is always highly scrutinized by non-tech stakeholders since it's visual and easier to understand
When you demo, talk slow and move your mouse slow. Things that are obvious to you are this way since you spent several weeks on a feature. Stakeholders are seeing your work for the first time

Working with management

If you need to estimate a task, assume it's way harder than it is
Deliver bad news early and good news frequently
If your PM is messaging you directly for updates frequently, either there's an issue with the process or you are doing things wrong.
Push back deadlines as far back as possible during planning phases. You'll thank yourself later. It's better to underpromise and overdeliver

Working with engineers

Create living documentation upfront and do it regularly, it saves everyone time. Google docs is your friend
If you get stuck on a problem for more than 3 hours, ask for help.
Make your teammates look good and give credit where it's due. The analogy is if you hang out with awesome friends chances are you are awesome as well
Make an ADR (Architectural Decision Record) when you implement big changes to a codebase. It prevents you (and others) from 2nd guessing why certain things were done 6 months ago

Code Reviews

For code reviews, critique the code, not the person
Make your code reviews awesome by explaining every question a person might come up with

Leading a team

Mentoring developers can be fun and enjoyable, but you need to spend time and effort on it
Plan out your ticket action plan for the team over several days to iterate and improve
Spend time onboarding newer developers on the project, and write documentation on questions they have. They're looking at things from a fresh perspective
Always give good candid feedback to your teammates when possible
Emphasize the big picture and give room for others to be creative/ take ownership of features
When you pair program, one person is the driver, the other is the instructor

Time Management

Plan large focus periods of work where you won't get interrupted
Don't forget we're all people too. Plan your vacation and sick days
Think win-win and lump related tasks together and get them done in one go

Reducing Technical Debt

Don't over-engineer things unless it's warranted
If you use two booleans that conflict with each other, use an enumerable instead
Type safety is effective at reducing technical debt.
Always use pure functions when possible. This makes the app reusable and obvious at a glance
Write more tests against iterative and less obvious code
Use undefined instead of sentinel values. Sentinel values are checks on seemingly random values in the codebase
Always use a linter. It saves you time and effort
Don't have competing sources of truth. Use as few scoped variables as possible, and use as few derived/computed variables as possible
If you need to tackle legacy debt, migrate one feature at at time

Architectural Rules

Most systems use soft deletes. This means companies don't actually delete your data, it's just marked as inactive
Use caching to reduce amount of work service-layers need to make. But don't treat it as the source of truth if possible.
Never trust the frontend. The backend should handle the vast majority of business logic. Avoid database business logic if possible, it's hard to maintain.
If you don't need high scalability on your project, just ship it out and don't worry about it until needed
Don't put too many shiny things in the app. It increases the risk of failure. Pick preferably popular libraries with good documentation
Feature flagging helps you deploy and deliver features to other teams while still deploying regularly

Database Rules

Keep your database designs as simple as possible to reduce complex JOIN SQL statements
NoSQL datastores don't have ACID requirements, so it's great when you design a system where users don't talk to each other

Summary

Let me know what you learned over the years and add it in a comment :)

My personal 2020 reflections

Vincent Tang — Mon, 04 Jan 2021 02:27:03 +0000

Every year I write a blog post reflecting what I've learned and accomplished. And whether or not I met my goals for this year. It's a great way to see how far I've come since I started my coding journey.

Without further ado, here's my 2021 version!

I started a coding podcast, and released 7 episodes!

I didn't plan on building a coding podcast this year. It all started when I was invited to the backend-bears coding podcast. I spoke with Marko about what it's like for a frontend developer to learn backend development. It was a blast reliving what it was like working at my first job, and the challenges I overcame to be where I am today. I had such a positive experience on this show that I decided to create my own, so I could invite my own guests too!

I reached out to one of my closest coding friends, German Gamboa to cohost with me. Thus Code Chefs was born. We've been steadily releasing content every week, and have air'd 7 episodes so far:

I challenged myself to build the entire thing from scratch. Read about how it was built here. This coding podcast is the first real side project I've built since starting my coding journey.

I wrote 10 blog articles

One of my goals this past year is to write more frequently. I wrote a few different articles reflecting upon my career, and things I learned while building code chefs.

I did my first paid freelancing gig!

I've never done a paid freelancing gig before. Granted, I've helped in numerous startups when I first started programming, some spinning off from hackathon applications I wrote. I had the opportunity to work through a web agency on a VR project with Verizon.

Read about it here

I dropped 35 lbs in 6 months!

At the start of this year, before Covid hit, I started to become overweight. Namely, I just moved to a new city and found myself constantly eating out at new restaurants every day. I drew up a plan around January to drop weight for the first time in my life. This was done through a recipe tracker I made on google spreadsheet in which I tracked how many calories I ate every day and measured my weight progress over time. The biggest challenges for me here was adjusting to the new diet and discovering what things I did and didn't like eating.

I furnished my first apartment!

Every apartment I've lived in before this had been furnished. Before this, I had been couch surfing for several months in Tampa as I didn't know which area in town I wanted to live in. I settled in the old downtown district and have loved it ever since!

However, furnishing my first apartment was more difficult than I'd imagine. I never realized how many different combinations of styles and genre of interior decor exist out there. From chic, to country, to minimalistic - the combinations were endless. I ended up spending several weeks sleeping on Ikea sofas and couches nearby to find out what suits me best, an ungodly amount of time shopping online, and learning about something called focal points.

Here's what my place looks like, after throwing my first house warming Pre-Covid:

I adopted my first cat

I've always wanted a furry companion. I never had one growing up. Although, one time my dad called me on my 12th birthday, proudly exclaiming he adopted a new dog. I was coming home from school when I got the news. I felt a rush of excitement as I couldn't wait to meet him! Upon arriving home, I didn't find a new dog dashing forward to meet me at the door. Confused, I called my dad and he told me to check near the staircase. I ended up finding a dog statue. I later found out we never had pets because my dad was allergic to them.

This past month I adopted my first cat companion, Monty. Prior to this, I had recently been laid off, so I used the free time I had to visit various animal shelters. Monty was actually one of the first cats I met at the first animal shelter I went to! I adopted him, and I later found out my entire team at my new job had cats.

Here's a picture of Monty:

I redesigned my website

Around Q3 2019, I got laid off from Covid. With that free time, I used it to redo my website!

It's still based on a fork off of another popular theme, but suffice to say I've added a lot of new features to the site. Including the ability to add comments, a new newsletter, amongst many other cool features

I learned musicality

This year I sought to explore personal skills over professional ones. I'm still trying to find myself, my identity, and how I'd like to be perceived by others. For that, I wanted to explore hobbies I never had done previously and skills I never was good at. So I focused on musicality - dancing, singing, and musical instruments.

Over the course of a few months, I learned how to play "Knocking on Heaven's Door" from ACDC/ Bob Dylan. Both a simple musical strum pattern and singing at the same time. It's a simple enough song and the lyrics aren't difficult, but I spent weeks learning about my voice, and what I could produce, given enough time and practice.

For dancing, I picked this up through a dance studio. I never thought it was something I'd enjoy, but I fell in love with how expressive it can be. You can tell a lot about someone's personality, just by the way they move. For instance, slower movements are associated with someone more relaxed, whereas someone who has style tends to be more expressive. Everyone has a different pattern and I'm still finding my own.

Goals this year

My goals last year were rather generic. This year I'm going to quantify what I'd like to achieve by the end of 2021

Professional goals:

Build 1 side project that is primarily backend based
Build 1 tool for creating cutting edge user-experiences / assets
Build 1 fun hardware-based IoT project
Get AWS solution architect associates certified
Finish 1 computer science course, most likely NAND2Tetris
Finish 1 course on Cypress Testing and Web-Accessibility

Personal goals:

Increase overall strength by 30% by July, 135/175 bench/squat at 5x1 currently
Create a financial stock portfolio
Finish a course on improving charisma and be able to apply them to my life
Improve my writing ability through writing more blog posts

That's my reflection for 2020 and my goals for this coming year! Most of my accomplishments this year were personal. It's the year in which I wanted to discover more about myself, amidst a pandemic

Recommended Learning Path for a Self Taught Web Developer (React / NodeJS)

Vincent Tang — Sun, 06 Dec 2020 17:09:35 +0000

Back in 2016, I designed commercial kitchens for a living. This meant I consulted with restaurant owners who were starting their business for the first time. And made recommendations on how best to run their operation.

I found myself constantly needing new tools to manage these tasks. I would often times catalog the tools I use on alternativeto.net, and try a lot of software products in the startup space.

At one point, I asked one of the developers if they could implement a new feature that I wanted. They didn't have the bandwidth to build it and challenged me to write my first Javascript widget.

But, I didn't know anything about Javascript, CSS, or HTML. But I taught myself and built it.

And people started using the tool I made. And I got hooked. I wanted to become that developer who actually shipped web apps like the ones I relied on daily.

It's 2020 now and I've been hired on as senior frontend engineer, working in React/NodeJS primarily. I didn't go through a coding bootcamp, and just learned mostly everything through things I found online.

I remember how much of a struggle it was trying to find the best learning resources out there. And what things I should even learn as a webdeveloper. There's just so many tutorials out there that I didn't know where to begin, so I spent a great deal of time auditing many of the popular courses out there.

I'm writing the article I wish I had read, when I first started learning to become a web developer (React / NodeJS). What I should learn, in what order, to get that first job and start my coding career.

Here's that guide, and my impression of the learning resources I used as well:

Your First Job

You can learn only so much on your own, and real-world experience always trumps things you learn in a course. You should focus on getting a job ASAP in the software space, and figure out what you want to do after.

I always recommend any junior developer to get a frontend developer position. This is usually someone who makes a website pretty and functional for users. Like what the site looks like, how it talks to a backend, and cool little widgets that make the web fun.

It exposes you to the whole software development cycle and you learn many applicable skills to ship real-world products. Frontend developer roles usually don't have a huge barrier-to-entry and are junior developer-friendly.

Course Guide Overview & Criteria:

I recommend taking multiple courses in different related topics, and not to take a one-course fit-all plan. You learn much faster when you learn from multiple teachers and see different viewpoints on related topics.

At the same time, I also don't like over recommending too many overlapping courses either. You only have so much time throughout the day, so might as well make the best use of it.

Here's the guide:

Part 1 - Learn Computer Science Fundamentals

Before learning web development, you should take an intro course to computer science through Harvard's CS50. It's free.

My reasons as follows:

It teaches you a few different languages, C and python, so you'll be able to make comparisons to this and Javascript. It'll also teach you foundational backend programming when you build an image-decoder
You'll learn how to use the command line, which is useful when working with Git in team settings and working with webservers
It teaches you basic algorithms, which you'll need to know for writing optimal frontend code and backend code. As well as all the coding challenges you run into in interviews
It teaches you how memory addresses work, so you can debug things much easier

Most of the things you learn in Harvard's CS50 will pop up later on. When you learn the basics, learning everything else just becomes much easier. There are many patterns that emerge in programming, and they're usually tied to computer science.

Part 2 - Learn Javascript and CSS really well:

I recommend taking two courses in parallel:

FreeCodeCamp
Any foundational course on Javascript:

For (1), FreeCodeCamp is a free online platform for teaching frontend and backend development. Originally, it started as a way to teach frontend development (HTML, CSS, JS), so I recommend sticking with that.

The two certifications I suggest going for at this point are the "Responsive web design certifications (300 hours)" and "Javascript Algorithms and data structures (300 hours)". These two certifications teaches you the basics of Javascript, HTML, and CSS in a more learn at your own-pace hands-on fashion.

For (2), a foundational course will give you a video instructional overview from an instructor. I suggest taking either of these (or both):

Both teachers here tend to teach in a more gentle fashion. So it's an easier introduction to the topic:

Watch and code is from an ex-google engineer. He teaches you how to build a todo-app from the ground up, and more so how to think like a programmer. Taking this course taught me a lot of foundational design patterns, and how to properly write out the requirements of an app before building it

For watch and code, don't go past building the todo-app course, which is about 4-8 hours long. The other content is senior-level and great for doing later in your career.

Colt Steel's Bootcamp is a high level introduction of how the web works. How a backend talks to a frontend. It's a solid course covering all the fundamentals, but I still recommend watch-and-code though, since the next course will cover overlapping topics

Part 3 - Crash course on a full-stack application React NodeJS

After taking an instructor that takes a more gentle approach (bottoms-up), I recommend taking a course now that takes a hard-fast ball approach instead(top-down).

The course I recommend taking is "MERN stack front to back" from Brad Traversy on Udemy

MERN Stack front to back

Brad Traversy doesn't really explain how everything works, but just enough for you to understand what's going on. It'll teach you how everything is connected together using React and NodeJS so you can reference down the road later. It'll teach you just enough backend knowledge such that you can entirely focus on frontend afterward

Part 4 - Learn React, Bootstrap, and Sass

At this point, you have solid foundational knowledge on Javascript, HTML, and CSS and have built a few small projects through FreeCodeCamps certification challenges. And have an overview of how React, NodeJS, and MongoDB work together through Brad Traversy's course.

Now you just need to hone in on what employers actually hire for and the skills needed to build features in a codebase.

I suggest taking these two in parallel:

FreeCodeCamp - Frontend Libraries Certification (300 hours)
Any in-depth React Course

For (2), if you took Colt Steel's course early, I suggest taking a different instructor this time around. Any of the popular Udemy courses are good, but I personally recommend taking this one:

Max Schwartz - React the Complete Guide

After taking these courses, you'll have built a few React projects, have a solid understanding of react hooks, class components, lifecycles, and redux. Redux is a steep learning curve but once you get over that hump everything else is pretty easy.

There's also a second React course I recommend grokking over as well with Max's course, this one is from Stephen Grider.

Stephen Griders - Modern React Redux

He makes some of the best diagrams in my opinion for explaining concepts in React / Redux. And also the best analogy on the topic as well.

Part 5 - Learn to build things in a team setting

You have now a ton of useful skills. Now you should start applying it to build actual projects. You should learn a little bit about project management and team dynamics. This is all the things you would have learned at a coding boot camp but didn't because you're learning mostly on your own

I recommend taking these two paths:

Chingu cohorts is a place where you get together with other self-learning developers such as yourself, and build a project. You can either pick to build something unique or clone something that exists out there. I recommend cloning an application like Trello for instance, you can focus purely on problem-solving instead of generating ideas

Hackathons are great places to learn from others. It's a short 1 - 3 day event most times, where you get together and build a project. Covid makes things complicated, but I always recommend competing with ones local to your area as the learning experience will be much better.

Part 6 - Your portfolio capstone project

I don't really recommend the saying of "following your passion", but rather build something that you actually would want to use.

You should have one project you can talk about at great lengths with an employer. I suggest one, and not two, because it makes it easier for a potential employer to say "Oh he/she was that person that built X project". It's easier to remember than "Oh he/she was that person that built A,B, and C projects"

Also, if you're coming from a different career, consider building something related to that field. It tells a story of how you are transitioning from one career to the next.

But if you truly don't have any ideas, feel free to add new features to a tutorial project and make it unique. Or, check out these recommendations for ideas:

Github Idea Repo

Make sure the project you build looks really clean on the frontend, I suggest using a CSS framework like MaterialUI, Bootstrap, or Tailwinds. It's the first impression someone makes on your project if it's structured well. You could have an ugly frontend and a beautiful backend, but it won't be appreciated as much.

Part 7 - Be a part of a tech community

I recommend listening to podcasts during your drive to work or commutes. This should be done in parallel in my experience from parts 1 to 6. You'll gain a huge amount of insight on how experienced developers communicate with each other, and pick up knowledge you wouldn't have otherwise gotten anywhere else.

Podcasts I recommend:

code chefs - My personal podcast
syntax.fm - Heavily frontend focused
coding blocks - A really good friend of mine runs this, it's computer science + backend heavy focused
tech jr - Lots of career related topics

Also, I recommend joining your local tech community. If you live in the middle of nowhere, there are still options for you!

First check out a list of slack channels out there: Github city slack channels

And join your local tech meetups in town

And I also recommend writing about what you learn along the way on dev.to, or your own personal blog. Feel free to use my site as an example and fork the source code here.

Blogging is a good way to reflect on what you learn and to show a potential employer what you know

Recap Summary

Here's a quick recap summary for courses I recommend to take in that order:

Learn basic computer science - Harvard's CS50
Learn Javascript and CSS well - FreeCodeCamp - Do these certifications: "Responsive web design certifications (300 hours)" and "Javascript Algorithms and data structures (300 hours)". In parallel, take Watch and Code course on building a todo-app
Get a grasp on a full-stack app built - MERN Stack front to back
Get good at React - FreeCodeCamp - Frontend Libraries Certification (300 hours). And this course in parallel: Max Schwartz - React the Complete Guide. I would also watch the introductory topics from here, but you don't need to finish this one: Stephen Griders - Modern React Redux
Apply skills in a team setting - Chingu cohorts and Hackathons
Showcase your work - Build your capstone project
Pick up everything else you missed - Be a part of your local tech scene, podcasts, and meetups

Everyone has a different learning style, but this is the learning path I would have told myself a few years ago. It covers the foundations really well, in a short time frame for a job skill that'll still be in demand years from now.

NOTE: Also if you're on a budget, always buy the Udemy courses when they're on sale. Don't get them for more than $10 to $15 each. Make a new account under a new email, clear your cookies, and you can always get the first course for that price. You shouldn't have to spend more than $50 on all these courses in total.

Feel free to follow me here if you'd like to follow and read more :D

WTF are JAMstack Apps and Static Site Generators (SSG)

Vincent Tang — Mon, 30 Nov 2020 02:14:22 +0000

JAMstack and Static Site Generators are tools often used for building blog and marketing sites, usually as a replacement for older tools like Wordpress. They provide huge performance gains to your site, don't require much maintenance, and makes scaling your content cheap and easy.

But where do such benefits come from?

In this article, I will breakdown how Static Site Generators (SSG) work. First, by describing the original problem that it was created to solve. Next, I'll describe what JAMstacks app is, and how they evolved from SSGs. Then, I'll cover some actual tools you can use to build your next JAMstack app, such as GatsbyJs. Finally, I'll summarize the similarities and differences between both JAMstack and SSG tools, and when to use each of these tools.

The Good Ol' Days of PHP and HTML files in the year 2000

Back in the good ol' days, the web used to be simple. You spun up an index.html site, pushed it to a server, and tada! You have a webpage! Maybe it's your own personal site. Or maybe it's a marketing site. Heck, maybe you just used Geocities or myspace back in the day which did this for you.

Sometimes you needed more than just basic HTML. Maybe it's an e-commerce site, and you want customers to buy things online. Usually, this meant you ran a backend language like PHP to handle this for you.

That PHP code would usually run on somebody's computer (server) and handle these interactions. It would also handle different parts of the site like:

https://website.com/about-us
https://website.com/category/t-shirts
https://website.com/products/awesome-t-shirt

And possibly 100+ other specific suburls, usually dedicated to products and category pages.

You could however opt and not use PHP or a server-side language, and just make 100+ index.html pages for each of these:

about-us.html
category/t-shirts.html
products/awesome-t-shirt.html

But here's the dilemma. All 100+ of these index.html pages use the same <header> and <footer> element on the page, amongst many other things. That means if you wanted to update one small thing, you have to do the same thing everywhere else!

Let's just say now, your site isn't an e-commerce site. It's a blog now! But it still has 100+ pages and articles you've written.

You don't need to charge money on these blog articles or have a cart/checkout page. Your site is basically a Read-only site with minimal updates. There are no dynamic prices, or sales/promos. It doesn't need fancy PHP or server-side languages, it can just be plain .html files

But we've discussed early the problems here, updating the header on one .html file means you have to do it for the other 99+ .html files! That's ALOT of maintenance

Here's where static site generators come in!

The coming of Static Site Generators in 2008

Static Site generators solve the maintenance issue of modifying so many .html files. The first major one that had a lot of traction was Jekyll in 2008 because you could deploy it on Github Pages. It was written in Ruby which is another backend language like PHP

NOTE: Jekyll was not the first Static Site generator, but the one that made SSGs popular

Jekyll took a unique approach to solve modifying so many .html files on a blogsite. Why not just create a reusable template for blogs and pages?

Post-template.html
Page-template.html

A post-template.html file might look something like this (link):

---
layout: default
---

{% include page-intro.html %}

<main id="main" class="page-content" aria-label="Content">
    <article class="entry-wrap">
        {{ content }}
    </article>
</main>

Basically, we specify what type of layout it is, and the {{content}} is where the actual stuff the reader reads gets rendered. Layout is the entire look and feel of the site

So now if you change your HTML/CSS for the Layout, it changes it for all blog posts! Likewise for pages too

And why not write content in an easier way? Such as markdown? And use that markdown to generate each of those pages for the {{content}}

look-at-me-ma-my-first-article.md
wtf-are-jamstackapps-and-ssgs.md

Example of the 2nd markdown file:

---
title: "Post: WTF are JAMstack Apps and SSGs?"
categories:
  - Post Formats
tags:
  - Post Formats
  - readability
  - standard
---

If you've ever read an article on JAMstack apps 
or Static Site Generators (SSG), sometimes you're left.............

Tada! That's a static site generator! It does all the boring, heavy lifting work for you so you can generate those 100 .html pages with ease! And modify all the styles for all the posts in one go if you had to!

Here's the kicker with Static Site Generators. It does run on a backend language like Ruby or PHP. BUT, it only runs every time you write a new article or modify CSS/HTML on the site. We call this "build time", and this is why it takes a while to see changes right away.

So because it needs to rebuild every time, it doesn't make a whole lot of sense to write an e-commerce site with it. I mean just imagine this, every time you add/remove a product from the site, you need to rebuild EVERYTHING! Even for product pages that didn't change! If you have 100,000+ products, it could take hours or even days to rebuild!

So to hit the point home, Static Site Generators work best for READ-ONLY websites. We're talking about things like marketing and informational sites, blog sites, podcast sites, etc. The rule of thumb for me is if you need to update content more than twice a day or some unknown amount of times after the site is stable, you probably shouldn't use a static site generator.

That's not to say you can't have a dynamic comments feature, or a place to gather emails. You can have this still! That's where Javascript comes in, and maybe a mini-backend living elsewhere that does all the heavy lifting for you!

Here's why JAMstack applications are so popular!

WTF is a JAMstack application?

So what is a JAMstack app? Well, it stands for Javascript API Markup. We covered the Markup (ironically, which usually uses markdown .md files). API refers to if you wanted to integrate a separate backend for dynamic comments on a blog, using HTTP fetch methods for instance. Javascript is actually really broad and encompassing here, and I have to expand on this.

NOTE: all JAMstack applications are also Static Site Generators (SSGs)! But the reverse is not true.

Javascript means you can use Javascript on each of your post pages. Like maybe you want to sprinkle a tiny jQuery widget on a specific page, such as something to read off how many likes you got on Twitter. Most SSGs did support this out of the box, but it becomes kind of cumbersome having all these jQuery widgets sprinkled everywhere.

But then we had a new kid on the block back in 2015. This was React, and React pretty much changed the way we wrote frontend applications.

In the first history lesson I gave about PHP and the year 2000s era, things were server-side rendered. Which meant, when a user went on different pages on the e-commerce site, the server would just send a new HTML, CSS, and JS that would be rendered on your browser like google chrome.

This is where React differs. It decouples the backend from the frontend, in that the client only talks to the backend via an API. This means you can have what's called client-side routing amongst many other benefits.

So that same e-commerce site example. Say you had these suburls:

about-us.html
category/t-shirts.html
products/awesome-t-shirt.html

When the user hits the site, you can preload where all these routes live! And when a user navigates to that page, maybe the <footer> and <header> on the page is the same. But it doesn't make sense to rerender those every time a user navigates to a different part of the page.

React does what is called tree-shaking, or diff-rendering. It figures out what actually needs to change, and only renders those changes. So you don't rerender the <footer> and <header> every time.

When you hear why JAMstack applications are so popular, that is what the Javascript portion is referring to! These are the benefits every JAMstack article is referring to! It uses React, which is a single-page-application framework that does all this magic for you.

There's also Vue which is like React, but I omitted talking about it because the concepts and benefits are exactly the same

So, what are some actually JAMstack tools?

So here's where I talk about Gatsby. Gatsby was built on React, BUT it's also built on NodeJS.

Remember when I talked a century ago about Static Site Generators? And how modifying 100+ .html files was a pain in the butt?. And how SSGs used a backend language like Ruby or PHP to take some markdown files to generate all these .html files for you?

Well, JAMstack applications do the same thing! Because all JAMstack apps are SSGs! And so is Gatsby too, because it's a JAMstack app!

Gatsby uses NodeJS instead of Ruby or PHP, and it builds that every time you make new markdown file changes. But wait Vincent, why does Gatsby (JAMstack and SSG) differ from Jekyll (SSG)?

Gatsby uses React, which has all the benefits mentioned previously! It renders only things that change, it decouples the backend, and can even preload different pages so it renders even faster! From the user's perspective, this just means the site is ooooooooohhhhh soooooo much faster, and that means better SEO and performance.

But wait there's more! I didn't mention this earlier, but SSGs and JAMstack apps also can optimize images for you too! Maybe your lazy and upload a fat 5Mb image to the site, and don't feel like compressing the files. Well, because SSGs and JAMstacks run a backend every time you upload a new markdown file, guess what! You can run image compression too and dump it into the public or dist folder, where the frontend gets rendered!

But it gets even better! Gatsby, since it's React and Javascript based, can do Javascript magic too! Instead of just pre-optimizing images, you can lazy-load images! What do I mean by this? A gif is a better explanation:

Check out my personal site here for the example! I use GatsbyJS on my personal blog, and what you see happening here is the following:

I hard refreshed the page
Before the image loads, a lower-res image loads first
When the actual image loads, it replaces the lower-res image

This is really only possible with JAMstack applications like Gatsby! Traditional SSGs don't support Javascript features like this out of the box and requires a lot of work to configure. Whereas Gatsby, which uses React, has access to all the wonderful React libraries out there! It makes it easy to plug and play.

Let's not forget how easy it is to integrate 3rd party APIs! I wrote an article about how to install blog comments in your Gatsby site, which uses an external API.

In summary

In summary, I wrote this article because I find there's a lot of misconceptions about what JAMstack and Static Site Generators (SSG) are. I myself found it very confusing what the differences were until I actually played around with Jekyll, Gatsby, and many other SSGs that I didn't mention.

To summarize:

Static Site Generators (SSG) solve the pain points of a blog, marketing, or read-only site with minimal updates. Instead of modifying 100 .html files, you modify a post-template and write markdown, and the SSG creates the .html files for you. Meaning, less maintenance work long term. An example of this is Jekyll
All JAMstack apps are SSGs, but the reverse is not true. What separates JAMstack apps from SSGs is the Javascript portion, in that it uses more recent frontend tools like React for better UX. A JAMstack tool example is Gatsby, which uses React and NodeJS

When it comes to when to, and when not to use a JAMstack app or SSG

JAMstack and SSGs are best for read-only sites. That means you don't want to build a dynamic and constantly updating e-commerce site with it, else you deal with crazy build times. If you're building a feature-rich web app or startup, you're actually better off building a separate backend (NodeJS) and a separate frontend (React) and not using JAMstack or SSGs.

Here's a list of popular JAMstack apps as of the end of 2020

Gatsby - which runs React
VuePress - which runs Vue
Gridsome - which runs Vue

Here's a list of popular SSGs, that are technically not JAMstack apps:

Hugo - It sometimes gets lumped in as a JAMstack app, but technically it's just an SSG since it just uses GO-lang to render files behind the scenes
Jekyll - Jekyll was the first popular SSG, as you could power it on githubpages since it's written in Ruby and Github is too!
Hexo - Hexo was the first major SSG written in NodeJS. It became popular in China before it came to the states, so you'll find a lot of theme authors are Chinese.

Check out some of the JAMstack apps I built (in Gatsby!)

vincentntang.com - My personal blog, source code is here
codechefs.dev - I run a podcast for junior to mid-level developers seeking to level up! Source code is here

On writing a custom RSS feed for GatsbyJS

Vincent Tang — Wed, 25 Nov 2020 23:01:06 +0000

We recently released a podcast site built in GatsbyJs called CodeChefs. I made a write up on how to build your own podcast site from scratch here.
Including how to generate the RSS that's consumed on different podcast platforms like Spotify and iTunes.

However, we've run into an issue. We couldn't get one of the podcast platforms, stitcher.com, to support our RSS feeds. During the submission process, it would just get held up:

I reached out directly to Stitcher for support, in hopes to resolve the issue. It just seemed weird that all other platforms but this one supported our RSS feeds. This was the support response I got back:

Not terribly helpful, I got the "reach out to the admin of the site for assistance". Unfortunately, that's me! I did a little digging and found that stitcher uses http://validator.w3.org for validating RSS feeds. Upon submitting the feed, we got this error:

Schema Error: XML document with no namespace; cannot determine any schema to use for validation.

Upon searching through this issue, I found NO solutions whatsoever for resolving this issue! It just became more questions and no answers.

Back to the drawing board

Instead of taking a top-down approach to the problem, I felt it would be best to understand how Gatsby is generating RSS feeds.

Through some digging, I found the plugin Gatsby uses for RSS feed generation is called Gatsby-plugin-feed. And through a separate issue I created on Gatsby's Github Page, I found out it uses node-rss behind the scenes to generate the XML for the RSS.

Upon looking through the repo, I was slightly disappointed. The repo is in maintenance mode, and the last PR merge to it was back in 2017. There were dozens of open/closed PR that were ignored and didn't pass TravisCI, which meant the author has since moved on with the project. Meaning if I open a PR and actually implement a fix, it probably would be ignored.

I decided to dig through the issue log regardless, curious as to what problems people were having. I stumbled upon this random comment:

Experiencing similar problem with VLC (for a podcast). 
Finally got it to work by removing the CDATA section from the title tag. 
Now the feed is being recognized by the reader.

A possible solution to the problem I'm having! I didn't know what CDATA was actually for, but upon searching Wikipedia, I found it's mostly used to support & characters. Which makes sense, our site was currently using that character for the <author> tag.

Now I checked the RSS our site was outputting:

<rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" version="2.0">
<channel>
<title>
<![CDATA[ Code Chefs - Hungry Web Developer Podcast ]]>
</title>
<description>
<![CDATA[ Looking to expand your skills as a Web Developer? Vincent Tang and German Gamboa break down topics in Javascript, NodeJS, CSS, DevOps, AWS, and career development! ]]>
</description>

Our site was outputting CDATA tags on the <title> and <description>. So this clued me in on a potential fix. So I needed to modify the RSS generator such that it no longer outputted those tags.

I scoured through the node-rss package to see if there were any details on how to set this up. RSS feeds couldn't be that difficult to make could they? I decided to inspect the source code instead, which ended up being a mere 189 lines of code:

function generateXML (data){

    var channel = [];
    channel.push({ title:           { _cdata: data.title } });
    channel.push({ description:     { _cdata: data.description || data.title } });

I found exactly what I was looking for! How the CDATA was being generated on our site. Unfortunately, the _cdata tag was hardcoded here for both the title and description, which meant there is no configuration for disabling it.

That just makes things so much more complicated. I didn't even know if this solution would even work! I'm basing all of these decisions just on a random comment I came across.

Therefore, I needed to validate if removing the _cdata tags would fix the RSS issues I was having.

Running a local MVP test

I needed a quick and dirty test. Since the gatsby-plugin-feed was already installed on our repo, and probably imported node-rss behind the scenes, I figured I could just modify the file directly. I removed the _cdata values here:

function generateXML (data){

    var channel = [];
    channel.push({ title: data.title });
    channel.push({ description: data.description || data.title});

and the new RSS feed worked! But I needed a way to test this out against https://validator.w3.org/. Unfortunately, using localhost doesn't cut it, as the site needs to be deployed.

I didn't want to run this through our CI/CD pipeline through Netlify until I was sure it worked. What I did instead was run ngrok, which tunnels information through a port of my choosing. So localhost:8000/rss.xml now just became accessible at https://cb996f9480ed.ngrok.io/rss.xml.

Great! Now we're in business! I submitted this publically available URL on stitcher.com to see if it worked:

And it did! This meant CDATA had to be removed on the <title> and <description> for the RSS to be accepted at this site

Making the solution permanent

Yet another dilemma. Even though I had a working solution, I still couldn't actually get this to run on our site. You aren't supposed to modify node_modules locally, as this means another computer can't duplicate the deployment process. This means I still can't deploy on Netlify.

I only had a few solutions at hand:

Modify the RSS package with a PR, and make another PR towards the Gatsby Plugin
Make a Gatsby Plugin with the forked RSS package

The 2nd option made more sense, so that's what I opted to do.

Through Gatsby Docs, I found you can create a local plugin here by running this command:

gatsby new gatsby-plugin-foo https://github.com/gatsbyjs/gatsby-starter-plugin

This generates a starter plugin that I could modify. Next thing I did was convert this starter template, and merging this through the source code for Gatsby-plugin-feed

I changed the dependency so instead of using node-rss here, it would use my custom modified package instead

There were numerous issues putting this all together. Gatsby for whatever reason used import statements on these backend files, which is Javascript syntax, not nodeJs syntax. So I modified accordingly, but this created several async/await issues that then had to be fixed.

The next set of issues I ran across was installing package.json in both a subfolder and a root folder. I did some research and found that npm ships with a default config called postinstall, which is a command that runs after npm install. So you can install subfolders of your choosing, or even do a rainbow match of folders to install

Once everything looked good, I made a PR against my development branch so Netlify can rebuild to these newest changes too.

And it worked!

Feel free to check out the source code and local plugin:

source code
rss
codechefs website
EDIT: I just realized the RSS issue we were having on stitcher podcast site was actually on stitcher's side! But we still modified our RSS successfully :)

Installing Blog Comments on your GatsbyJs/React Site using Utterances

Vincent Tang — Sat, 21 Nov 2020 17:37:39 +0000

Adding a commenting system into a blog platform is really useful. I wanted something that didn't require a lot of configuration, was open source, and had data stored in a visible way in the event I needed to move around blogging platforms. I also didn't want something externally controlled like Disqus, as they've been known to inject ads into your site.

Enter Utterances. It's based on Github's search API, so that means it's free and open-source!
It uses Github's issue tracker to create an entry, and all comments in that entry are tied directly to a blog post

How does it work?

So for instance, say I take my blog post on Building a Custom Podcast Site using Gatsby, ReactJs, Netlify, and AmazonS3

The article lives here:

https://www.vincentntang.com/custom-podcast-site-gatsby-react/

There is something called a "slug" or a "pathname". It's basically everything that is after the main website name, in this case, www.vincentntang.com. Here's the slug for the article:

/custom-podcast-site-gatsby-react

If I add a comment to that blog post, here's what it looks like on the page:

I have it configured so that the utterance bot creates an issue in this repo, tied to that "slug":

https://github.com/vincentntang/vincentntang.com-comments

This is the default out of the box setting with Utterances; the setting I used is Issue title contains page pathname

Also there's no code in this repo, it just has Utterances installed on the repo, per step 2 on installation on the utterances webpage. This means you install a widget on the repo and grant Utterances read/write permissions to create issues in there.

So Utterances creates an issue here, and each comment in this issue gets mapped directly into your blog post's comments.

You can check out the issue tracker created here:

https://github.com/vincentntang/vincentntang.com-comments/issues/1

The main benefit of using Utterances is you fully own the comments on your site since it lives in your repository. Its secondary benefit is it fights spam since users have to authenticate in Github first to make a comment. There are no anonymous comments, and it creates a trust system for both the commenter and the blogger

How do you configure this in GatsbyJs React?

It took me way too long to figure out this configuration. I'm writing the blog I wish I had read when I tried getting Utterances setup.

Utterances works by adding a script tag into your blog post template. What it does is it adds an iframe into your site, with the comments associated with your blog post.

In the installation readme, it suggests adding this script here:

<script src="https://utteranc.es/client.js"
        repo="[ENTER REPO HERE]"
        issue-term="pathname"
        theme="github-light"
        crossorigin="anonymous"
        async>
</script>

For the repo=[ENTER REPO HERE], this got me tripped up. I thought that it meant the full URL of the repo, in this case:

https://github.com/vincentntang/vincentntang.com-comments

But the actual configuration for the repo=[ENTER REPO HERE] is:

vincentntang/vincentntang.com-comments

So the full configuration for the script element looks like this for my current setup:

<script src="https://utteranc.es/client.js"
        repo="vincentntang/vincentntang.com-comments"
        issue-term="pathname"
        theme="github-light"
        crossorigin="anonymous"
        async>
</script>

Hold up a moment though! There's actually more to this, you need to reference a <div> for where this script tag injects it's <iframe> comments. This is where I had to read through a lot of obscure blogs to find out how to set this up in GatsbyJs and React.

The best way to handle this is to create a seperate React Component for installing Utterances. I called my component Comments.js and wrote it in React Class Components. Here's how I add the script configuration in React:

import React, {Component} from "react";
import ThemeContext from '../context/ThemeContext';
export default class Comments extends Component {
  static contextType = ThemeContext;

  constructor(props){ 
    super(props);
    this.commentBox = React.createRef(); // Creates a reference to inject the <script> element
  }
  componentDidMount () {
      const theme = this.context;
      const utteranceTheme = theme.dark ? "github-dark" : "github-light";
      let scriptEl = document.createElement("script");
      scriptEl.setAttribute("src", "https://utteranc.es/client.js");
      scriptEl.setAttribute("crossorigin","anonymous");
      scriptEl.setAttribute("async", true);
      scriptEl.setAttribute("repo", "vincentntang/vincentntang.com-comments");
      scriptEl.setAttribute("issue-term", "pathname");
      scriptEl.setAttribute( "theme", utteranceTheme);
      this.commentBox.current.appendChild(scriptEl);
  }

  render() {
    return (
        <div className="comment-box-wrapper container pt-7">
          <h1 className="mb-0">Comments</h1>
          <hr className="my-0"/>
          <div ref={this.commentBox} className="comment-box"/>
          {/* Above element is where the comments are injected */}
        </div>
    );
  }
}

This Comments class component uses React.createRef() to create a reference for how the Utterances <script> element is injected. There's a <div ref={this.commentBox}/> for the div element that adds the comment HTML from that <script> injection.

Also, I use both a dark, and a light theme mode in my blog. Utterances has a configuration for setting a theme, github-light and github-dark being the most common configurations. I use React's Context API to make this variable globally available, so I know when a user toggles the dark/light mode in my blog.

This is where the code in ComponentDidMount comes into play:

const theme = this.context;
const utteranceTheme = theme.dark ? "github-dark" : "github-light";
// .....
scriptEl.setAttribute( "theme", utteranceTheme);

If you don't have a dark/light theme in your app, feel free to modify the above code to a dark theme:

scriptEl.setAttribute( "theme", "github-dark");

or a light theme:

scriptEl.setAttribute("theme", "github-light");

That should be everything you need for setting up Utterances! You'll also need to call the <Comments> component too in your blog template. I put mine right below the information about the author

import React, {Component} from "react"

export default class PostTemplate extends Component {
  render(){
    return (
      <Layout>
        <article>
          <div
            className="post"
            dangerouslySetInnerHTML={{ __html: postNode.html 
           }}
          />
        </article>
      <UserInfo gatsbyImg={vincentBlue} />
      <Comments/>
    </Layout>
  }
}

Feel free to checkout out how I setup the <Comments> component in my codebase:

As a final note, there are some things you should know about themes in Utterances:

You can't change the comment theme when a user toggles light/dark mode, it's set depending on what theme is set when the user navigates to the page. You have to completely unmount the Comments Component and create a new seperate instance of it if you want to have toggleable dark/light modes.

How competing in hackathons helped me land my first job

Vincent Tang — Fri, 20 Nov 2020 21:52:27 +0000

I got my frontend certifications with FreeCodeCamp back in 2017. I remember how daunting it was applying to jobs and feeling ready for the workforce. Everytime I sent an application in, I felt like it went to the void, never to be heard from again.

I wanted a way to standout amongst other applicants, and coding bootcamp students. I challenged myself everyday to "level up" as quickly as possible, and ultimately I ended up competing in a lot of hackathons.

It taught me a lot of things that I wouldn't have traditionally have gotten learning on my own. I learned how to work with others in a team setting, use git, use 3rd party libraries, and had a lot of mentorship and help along the way from senior developers

When I started applying to jobs, one employer took a chance on me. I was far from qualified compared to other applicants applying to the position. But he could tell that I was eager to learn new things and picked up things rather quickly, thanks to competing in hackathons. So he took a chance, and the rest is history.

I'm hoping to give back to the community from where I started from. I recently launched a podcast with one of my really close coding friends. It's called Code Chefs.

We recently recorded a podcast about our experiences with Hackathons
https://codechefs.dev/hackathons

Hopefully this helps anyone looking to learn more about what a hackathon is and what you can learn from it!

Also writing out what I learned along the way helped too!
https://vincentntang.com

Building a Podcast Site using Gatsby, React, Netlify, and Amazon S3

Vincent Tang — Sun, 15 Nov 2020 19:44:35 +0000

6 months ago, I reached out to one of my best buddies to start a coding podcast! We wanted to reflect upon our journey as software developers thus far, and push ourselves to greater limits.

Only recently, we released our podcast to all the major platforms! It's here at Code Chefs

We decided to build everything from scratch! We wanted full control over the distribution. So we could customize how it gets pushed out to Spotify, how ads are controlled, etc. And a website that could also be a podcast player too!

Here's how it's done with GatsbyJs, React, Netlify, and Amazon S3

Overview of how the stack works

TL;DR

GatsbyJS hosts the website, markdown files, and generates RSS feeds for podcast platforms to consume
AmazonS3 hosts mp3 files
Netlify pushes the gatsby site to the frontend
ReactJS for a custom media player on the website

GatsbyJS is a popular JAMstack framework built in React. It's used often in the blogging world, and a podcast website isn't that terribly different. Where one episode = one blog post.

Most podcast platforms like Spotify, Apple Podcasts, etc are controlled by an RSS feed. Since GatsbyJS provides this out of the box too, this meant we could fine-tune it to different platforms.

Hosting mp3 files is a different issue entirely. It equates to about 1-2 mB post-processed for every minute of audio. Hosting these files within the same bandwidth as the static frontend site doesn't make sense, so we opted for amazon S3

AmazonS3 is a great place for deploying static assets like images, videos, or mp3 files. It doesn't cost a lot either, I don't have analytics yet but it comes up to a few cents every month.

We specify in our .md files within Gatsby, where the hosted mp3 files are located in S3. This is then pulled into the RSS feed created when Gatsby builds.

We push this code using Netlify where the site is hosted at https://codechefs.dev. Netlify has a CI/CD feature that lets you target a branch in your GitHub repo (in this case development), and anytime that branch is updated, the frontend site is too

The code for our podcast site is open source! Check it out on here on github

GatsbyJs and RSS Configuration

If you've used ReactJS before, GatsbyJS is actually quite confusing to learn. At least it was for me! It wasn't until I wrote a starter theme template that I understood how it all worked here. I'll break it down into the simplest explanation possible though, so bear with me!

GatsbyJS is both a backend and frontend system. It's built-in NodeJS and React. When a GatsbyJS site is hosted on Netlify or even your localhost, only static (frontend) contents are shown. You need to build the frontend! When you type in the command line $ gatsby build, it uses NodeJS to look through the contents of the repo. Then it generates SEO friendly posts and pages, and RSS feeds thereafter

This is why GatsbyJS works great as a blogging platform! The only changes you make to the site are generally when new blog posts, or in this case, new podcast episodes are released. It doesn't work well for applications that require frequent real-time updates, like a stock trading app.

GatsbyJS's backend build time is configured based on two files:

The above links are the actual files used for our podcasting site, Code Chefs!

If you read through those two files, it's hard to grasp what it's doing at a glance. That's because it built on top of GraphQL, and Gatsby has specific library helpers in the background doing a lot of heavy work.

Gatsby-node.js is the entry point for building the static frontend. It generates SEO friendly web pages, categories, tags, etc.

Most gatsby-node.js files look relatively the same, so I'll cover how gatsby-config.js configuration works for RSS feeds

Gatsby-config.js is all the plugins for generating markdown content to HTML, RSS feeds, amongst other things. If you ever used WordPress, they are just like WordPress plugins! It's libraries that you can just import to help do common tasks that you otherwise don't have to write

For gatsby-config.js, there's a plugin called gatsby-plugin-feed. This is how we generate RSS feeds to Spotify, Apple Podcasts, etc!

Here's the plugin configuration for gatsby-plugin-feed, which generates the RSS for all the platforms

{
  resolve: "gatsby-plugin-feed",
  options: {
    setup(ref) {
      const ret = ref.query.site.siteMetadata.rssMetadata;
      ret.allMarkdownRemark = ref.query.allMarkdownRemark;
      ret.generator = "GatsbyJS Advanced Starter";
      return ret;
    },
    query: `
    {
      site {
        siteMetadata {
          rssMetadata {
            site_url
            feed_url
            title
            description
            image_url
            copyright
          }
        }
      }
    }
  `,
  setup: options => ({
    ...options, // https://www.npmjs.com/package/rss#feedoptions to override any specs
    custom_namespaces: {
      itunes: 'http://www.itunes.com/dtds/podcast-1.0.dtd',
    },
    site_url: 'https://codechefs.dev',
    custom_elements: [
      { 'language': 'en'},
      { 'itunes:author': 'Vincent Tang & German Gamboa' },
      { 'itunes:explicit': 'clean'},
      { 'itunes:subtitle': "Hungry Web Developer Podcast"},
      { 'itunes:summary': "Looking to expand your skills as a Web Developer? Vincent Tang and German Gamboa break down topics in Javascript, NodeJS, CSS, DevOps, AWS, and career development!"},
      { 'itunes:owner': [
        {'itunes:name': "Vincent Tang"},
        {'itunes:email': "vincentntang@gmail.com"}
      ]},
      {'itunes:category': [
        {_attr: {
          text: 'News'
        }},
        {'itunes:category': {
          _attr: {
            text: 'Tech News'
          }
        }}
      ]},
      {'itunes:category': [
        {_attr: {
          text: 'Technology'
        }},
      ]},
      {'itunes:category': {
        _attr: {
          text: 'Education'
        }
      }},
      {'itunes:type': "episodic"},
      {'itunes:image': [
        {_attr: {
          href: 'https://codechefs.dev/logos/code_chefs_podcast_art.png'
        }},
      ]},
      {'image': [
        {'url':'https://codechefs.dev/logos/code_chefs_podcast_art.png'},
        {'title':'Code Chefs'},
        {'link': 'https://codechefs.dev'},
      ]},
      {
        'itunes:keywords':"javascript, webdevelopment,html,css,js, codechefs"
      },
    ],
  }),
    feeds: [
      {
        serialize(ctx) {
          const { rssMetadata } = ctx.query.site.siteMetadata;
          return ctx.query.allMarkdownRemark.edges.map(edge => ({
            categories: edge.node.frontmatter.tags,
            date: edge.node.fields.date,
            title: edge.node.frontmatter.title,
            description: edge.node.excerpt,
            url: rssMetadata.site_url + edge.node.fields.slug,
            guid: rssMetadata.site_url + edge.node.fields.slug,
            custom_elements: [
              { "content:encoded": edge.node.html },
              { "itunes:author":"Vincent Tang & German Gamboa"},
              { "itunes:subtitle": edge.node.excerpt},
              { "itunes:duration": edge.node.frontmatter.showLength},
              {"itunes:explicit": "no"},
              {'enclosure': [
                {_attr: {
                  url: config.s3bucket + edge.node.frontmatter.audioPath,
                  length: Number(edge.node.frontmatter.fileSize) * 1000 * 1000, // megabytes to bytes
                  type: "audio/mpeg",
                }},
              ]},
            ]
          }));
        },
        query: `
        {
          allMarkdownRemark(
            limit: 1000,
            sort: { order: DESC, fields: [fields___date] },
          ) {
            edges {
              node {
                excerpt
                html
                timeToRead
                fields {
                  slug
                  date
                }
                frontmatter {
                  title
                  cover
                  date
                  category
                  tags
                  shortDescription
                  episodeNumber
                  audioPath
                  showLength
                  fileSize
                }
              }
            }
          }
        }
      `,
        output: config.siteRss,
        title: config.siteRssTitle
      }
    ]
  }
}

This generates the XML RSS feeds at https://codechefs.dev/rss.xml upon deployment. It first outputs data about the site, then each episode is wrapped in an XML <item> tag

Feel free to check out the generate RSS feed for codechefs here

Amazon S3 Configuration

Amazon S3 hosts the raw mp3 files for different podcast distributions to consume. Everything on this bucket is public by default since any listener should be able to access it.

By enabling this setting, anytime you upload an mp3 to the s3 bucket, it is publically read-accessible

You may also have to make each mp3 file uploaded to be read-accessible by the public, to do this, click the file and go to Access Control List(ACL) and grant it read properties

Also, you can add cloudwatch on your amazonS3 bucket, and google analytics on your site to see stats related to your site

ReactJS Audio Player

ReactJS is used as the physical podcast player on the site. The default HTML audio player is rather limited, so we use React to build custom event handlers and custom UI to control those events.

Things like being able to control the playback speed of the file, volume levels, pausing the episode, etc

Here's the source code for the audio player

I'll write a separate blog post later for how this works!

Netlify + Github

Netlify is used to deploy the GatsbyJS site, whereas Github is used to host the code itself. We configure Gatsby to update based on the latest changes in the development branch in our repo.

Here's what the setup looks like:

Netlify also controls the custom domain. We point our name records from hosting provider, Namecheap, and point it Netlify. You can find more information about that here

The workflow process

Here's how everything comes together! How we go from brainstorming an episode, to getting it published on all the podcasting platforms:

First, we write a list of show notes on google docs, this is used to help brainstorm what we'll talk about before we record the episode
We warm up in the first 20 minutes talking about the content
Then we record on zencastr for the audio, and Zoom video so it feels more like a natural conversation
Afterwards, we download each audio track, combine it, and post-process it using Audacity

The file is then uploaded to AmazonS3 manually, and we create a blog markdown file in GatsbyJS with the metadata. It looks like this:

---
title: "React vs. Vue"
slug: "react-vs-vue"
cover: "code_chefs_podcast_art.png"
date: 2020-05-23
audioPath: 002_react_vs_vue.mp3
episodeNumber: 002
fileSize: 67.8
showLength: 49:23
category: "tech"
shortDescription: "How do these two popular frontend frameworks compare with each other?"
tags:
    - programming
    - react
    - vue
---

### How do these two popular frontend frameworks compare with each other?

In this episode, we discuss the similarities and differences between React and ..........

fileSize refers to how many megabytes the final recorded final size is. Apple in particular wants this data (and a lot of other data related to the podcast), so it's important to gather this information ahead of time. There are ways to automatically determine file sizes dynamically, but it's not that much effort though to check the mp3 file size contents. showLength refers to how long the mp3 file is. audioPath is the name of the file itself, we also prepend the s3 bucket to this location so Gatsby knows where that file is located

After this blog post is created, we push it to a development branch. Netlify then reads the changes against this branch and publishes the new RSS feeds.

It takes about 3 - 4 hours for each podcast platform to update from this feed.

Summary

Hopefully, this helps you in creating your own podcast site! We didn't find a huge amount of information on creating a GatsbyJS podcast site from scratch, so we made the guide we wish we had when we first started

Additional Links:

codechefs.dev - Our podcast site
code chefs source code - Source Code
vincentntang.com - Personal website

Learning Vue as a React Developer

Vincent Tang — Wed, 07 Aug 2019 00:42:02 +0000

React. The first major JavaScript framework I decided to learn coming from jQuery land.

My journey learning was painful. I had to watch three different Udemy tutorials to finally get it. Months were spent wrapping my head around this foreign way of coding.

I slowly and surely learned the basics, such how state management works and how the React lifecycle operates. These things came with time and eventually I learned to use this knowledge to build apps in hackathons and to build tools I would use in my daily life.

The time came to start my first development job as part of a team that used Vue. I didn't know anything about this framework and I felt like I had to learn JavaScript all over again.

This intense but interesting new journey where I transitioned from React to Vue left me with the following valuable lessons that I want to share with you.

Installation

Vue has a CLI like Create-React-App, but gives you more control with what settings you get out of the box. For instance, you can choose whether you want to include client-side routing or CSS Pre-processors like Sass.

Styling and Syntax

React uses JSX which lets you write HTML-like syntax.

Writing in Vue was like revisiting the good old days of EJS or any templating language. No longer did I have to write my HTML, and then convert it to JSX. I could just write HTML^TM and be on my way.

Here's an example of what a typical Vue file looks like:



<template>
  <div>
    <h1>{{message}}</h1>
  </div>
</template>

<script>
  export default {
    data() {
      return {
        message: "Hello World"
      }
    },
  }
</script>

<style lang="scss" scoped>
  .h1 {
    color: red;
  }
</style>

Assuming you declared your Vue component at the top level, this just outputs a "Hello World" string in red color.

In Vue, you write single file components. By convention, your component file will include the declaration of your template at the top, followed by a script definition with all the component logic, and it wii close with any necessary style declarations.

React, on the other hand, is less opinionated on file structure. You can still create single file components but instead of implementing the template in HTML and the styling in SCSS, for example, you would write everything in Javascript: template in JSX and styling in CSS-in-JS. This is demonstrated in this example:



import React, { Component } from 'react';

export default class MyFirstComponent extends Component {
  state = {
    message: 'Hello World',
  };
  render() {
    return (
      <div>
        <h1 style={styles.color}>{this.state.message}</h1>
      </div>
    );
  }
}

// CSS in JS
const styles = {
  header: {
    color: 'red',
  },
};

but you could also just import a .css or .scss file as well. The problem you run into though when using an import, is you pollute the global namespace. As your app and your team grows, chances are high your developer co-worker might name a class the same as yours.

You could opt to use a library like styled-components. This gives you a Sass-like syntax to tightly couple your styles with your JSX.

React brings another set of issues. Do you use a functional component or stateful component? By default, it's better to use only what you need, but this means potentially more refactoring down the road. This doesn't factor in that you can use React Hooks now instead of class components.

Props, State

React has something called props, which is data loaded in from the parent component. And something called state, data intrinsic to that component.

Here's an example of just rendering a "Hello World" message:



// React Parent Component
import React, { Component } from 'react';
import Child from './Child';

export default class Parent extends Component {
  state = {
    message: 'Hello World',
  };
  render() {
    return (
      <div>
        <Child message={this.state.message} />
      </div>
    );
  }
}



// React Child Component
import React from 'react';

const Child = props => {
  return <div>{props.message}</div>;
};
export default Child;

With Vue, the concepts were the same. But Vue prefers convention over configuration. Meaning, there are specific naming conventions. Child components declared in parent component are in camelCase. When the component is added to the HTML, the syntax is then kebab-case.

Example:



<!-- Vue Parent Component -->
<template>
  <div>
    <child-component :message="message"/>
  </div>
</template>

<script>
  import ChildComponent from './ChildComponent.vue';
  export default {
    data() {
      return {
        message: 'hello world',
      };
    },
    components: {
      ChildComponent,
    },
  };
</script>



<!-- Vue Child Component -->
<template>
  <div>
    {{message}}
  </div>
</template>

<script>
  export default {
    props: {
      message: {
        type: String,
        default: undefined,
      },
    },
  };
</script>

Vue requires you to declare a child component twice, once on import another on Components.

React differs in that there is one less step, you import the file then use it.

Type Enforcement

One thing I miss in static languages like C# or Java is type enforcement. Javascript is a dynamic scripting language. Meaning it doesn't care if a variable is a string, number, boolean, etc.

When you declare a string, you can always typecast it to a number after. This makes scaling large frontend apps difficult. Because you might not know what data type you're working with.

React natively solves this with PropTypes. Example in the <Child/> component we made earlier:



import React from 'react';
import PropTypes from 'prop-types';

const Child = props => {
  return <div>{props.message}</div>;
};

Child.propTypes = {
  message: PropTypes.string.isRequired,
};

export default Child;

There are a few issues with propTypes in React

It's really easy to misspell
It's optional
You have to declare an import

Because of these reasons, I find myself forgetting to use propTypes. You could opt to use Typescript instead with React, but this just means more additional time configuring your setup.

Vue requires the declaration of props, and propTypes are in the same location. Inside your <script> tag where all the other logic lives

Example of a child component:



<template>
  <div>
    {{message}}
  </div>
</template>

<script>
  export default {
    props: {
      message: {
        type: String,
        default: undefined,
      },
    },
  };
</script>

<style lang="scss" scoped>
</style>

This is a much better design overall and makes it so that Typescript is not necessary in Vue.

Data Reactivity

This was the concept that tripped me on Vue several times. In React, everything is reactive. Meaning you can add properties to objects, and React would call it's lifecycle when properties changed.

In Vue ... things don't work the same. In React, every time you modify state, you could pass a new entire state object.

Vue differed in that you mutated your state directly through methods. Because we're intrinsically adding side effects, you have to actually declare when new properties are being added to the object.

Namely using something called Vue.set().

A common example of when you would use this is if your loading data from the backend. And need to create new data to send back.

You also have to define a key value for components that have been iterated. React / Vue work the same way, it lets the library know what parts to rerender on data changes.

Watchers and Observables

I never quite understood design patterns that well. But the term "observable" finally made sense to me.

Vue has something called watchers. This lets you call a method every time a specific variable changes.

However, there's some caveats, because you could have watchers watching watchers. This causes circular referential issues.

The Vue docs warn against this. I myself have accidentally done this using inputs to watch over other inputs.

React's implementation of watchers is through the lifecycle method of componentDidUpdate. You select which items you wish to watch independently inside of here.

For the React Hooks implementation, useState is another implementation of an observable

Computed properties

This was a new concept to me, from the React world. In Vue, you can have variables that depend on other variables. Anytime a dependency changes, so does the computed property.

It seems useful at first, but computed properties are only good if you aren't modifying it at all directly.

When you start needing to, this is when you go away from computed properties entirely to the next item...

Methods

Methods in Vue worked the same as in React. These methods were called through event-directives that extend from HTML DOM events. Examples include putting @click events, or @input if a user typed text in an input field.

Methods are what you'll always fall back in Vue when computed properties and watchers don't fit your use-case.

Methods are like any function in javascript. The return statement is optional, you can just use it to mutate data in the background.

Asynchronous Gotchas

This is a gotcha that you find out later in Vue, and in React.
In React, there is a built-in method called setState(). When setState() gets called, it gets handled asynchronously in the background.

Vue is no different, you have a method called Vue.nextTick() that awaits the latest updated value to the data.

One lesson I learned is that it's best to set local variables within your methods, and only mutate data attributes as needed.

Templates

With Vue, there is something called templates. In your component, you have the ability to declare <template> slots. When that component gets called, you can inject HTML where those slots match.

This has been immensely useful when working in libraries. I could inject functionality as I saw fit, to get the feature I needed.

Templates do not get rendered as a <div> element in the DOM. React has a similar approach to templates called fragments, but the approach is limited to just the first element in your component.

Lifecycle methods

Lifecycle methods describe what components do during their lifetime.

Here are common ones you'll use in Vue:

mounted() - Similar to React's componentDidMount. This generally when making an Axios/fetch call to initialize data in your component from a backend.
updated() - Similar to React's componentDidUpdate. When you update data through your components, you want to send a POST request to your backend to keep things in sync
destroyed() - Similar to React's componentWillUnmount. You don't need to use this, but it helps clean up leftover event listeners.

Hooks

Hooks makes React an extremely powerful framework. No longer did you have to use redux for handling state, you could just use useState() instead. No longer did you have to deal with setState(), there were a slew of other new improved methods to use.

Vue has no equivalent to hooks, although there is an RFC at the time of writing this

Directives

Vue's built-in directives make development a breeze. You could create iterable directives right inside your HTML.

In React, this often meant making another component called "group(s)" and maybe one called "group".

Vue, you can just dump the v-for, v-if etc right inside your HTML. Your logic coherently just makes sense looking at it.

Alternatively, you can write your own directives! This lets you attach functionality to page if necessary, making it easier to develop faster

One great use case for startups is to develop a reporting system. If a user clicks on a feature that doesn't yet exist, you can add a popup modal saying "Sorry we're working hard on this new feature! Come back later". In the background, you can make Axios request to notify users really do want that feature.

Mixins

Some companies swear by these. It's a reusable code snippet library that can be implemented across multiple components. React out of the box does not have such a feature, you can alternatively use callback functions instead that are made globally available

Emitting Events

Props are passed from parent to child component, via one-way data binding. To handle business logic at the parent level, from the child component, you generally emit events.

With Vue, there are two different ways.

You can pass a reference to the function from parent to child
Emit an event from the child and capture the response in parent

Most applications generally use #2. Example from a button that triggers a method in the parent component



<!-- Parent Component -->

<template>

  <ChildComponent @event-emitted="_handleUpdatedEvent"/>

</template>

<script>

  import ChildComponent from './components/ChildComponent.vue';

export default {

    components: {

      ChildComponent,

    },

    methods: {

      _handleUpdatedEvent(val) {

        console.log('Button was clicked');

      },

    },

  };

</script>



<!-- Child Component -->

<template>

  <div class="hello">

    <button @click="$emit('event-emitted')">Click Me</button>

  </div>

</template>

Global State Management

Vue's CLI comes with the ability to add Vuex out of the box.

In React you pass a new set of state using setState(), Redux only extends this through global dispatches/flux architecture.

In Vue, you mutate objects behind the scene. Vuex is no different but at the global level.

Vue natively ships with the ability to create a global event bus, which is similar to React's context API.

Final Thoughts

Learning Vue has been a great way to learn new programming paradigms.

Many principles in React translate over to Vue. There are a few things that differ, namely:

You don't replace your state, you mutate it which creates data reactivity and async gotchas.
New constructs. There are computed properties, watchers, and mixins that don't exist in React out of the box
You write HTML and styles the way you would traditionally in a regular HTML page.
PropTypes are optional in Vue and React, but Vue requires less effort to enforce.
Styling. In Vue you just write Sass or CSS, it's super easy compared to React.

These are some of the differences from React to Vue. Some things that are similar include:

Lifecycle methods
Props/State
Assigning keys to iterated items
Methods / functions
Passing events upward

VueJS E-commerce Desk Configurator

Vincent Tang — Mon, 08 Jul 2019 01:47:05 +0000

I was shopping for a standing desk and stumbled upon this cool site: https://www.fully.com/standing-desks/jarvis/jarvis-adjustable-height-desk-bamboo.html

so I recreated it in codepen with some additions