Prettier is an opinionated tool that helps you format code. I love Prettier, but I don't like its opinions with JavaScript. I prefer using Standard for JavaScript because it doesn't have semicolons (which makes the code cleaner to read).
JavaScript contains many things — lots of different methods and ways to do things. How do you remember them all?
If you ask around the web, many people will say you don't have to remember everything since you can always google. But this answer doesn't help — you can't always Google everything, every time. If you forget absolutely everything and Google everything all the time, you're going to be real slow when you code!
So what's the alternative? What must you remember? What can you forget? That's what this article is for.
If you don't have a job as a developer, learning how to code becomes a much bigger challenge for a simple reason — developers can learn to code on the job.
I want to share with you 7 major challenges people face when learning, especially if they don't have a developer job. I'm also going to talk about how you can overcome each challenge.
I finally completed my JavaScript course — Learn JavaScript — two weeks ago. I spent 4 years writing this course (which is a long time!). Today, I want to reflect on this journey and complete it before I move onto the next one.
If you're interested in hearing the lessons I learned from dedicating 4 years of my life to building one course, then this article is for you!
This makes sense because Github is trying to help us keep the secret secret (ha!). But it doesn't help when we're trying to figure out whether there's something wrong with the secret we provided.
I wanted to use Github Actions to deploy zellwk.com — when I push a commit into Github, I want Github Actions to build my site and deploy to my Digital Ocean server.
The hardest part of this process is deploying to the server with SSH and rsync. I tried various Github actions like SSH Deploy and SSH Action, but I couldn't get the permissions to work for A LONG TIME.
I found most articles about Github actions and SSH didn't help me much. I got stuck with debugging for a few days before I finally figured out how to make the process work.
Today, I want to share the exact steps to deploy via rsync and SSH. This process works for any server, even if you don't use Digital Ocean.
Github Actions is a Continuous Integration (CI) + Continuous Deployment (CD) tool by Github.
CI and CD are bombastic terms, but they simply mean the following:
Continuous Integration: People push to a Git repository and the code gets tested automatically.
Continuous Delivery: The pushed code (ideally tested and bug-free) is then pushed into the server so it becomes live for users.
Although Github Actions is one of the many CI + CD Tools out there, it's probably the simplest one to use (in my experience). Unfortunately, the Github Actions docs is a complete mess — they keep pointing you to different pages, expecting you to read everything (and understand everything) when you're still trying to set up your first action.
Today I want to share the basics of using Github Actions so it becomes easy for you to use it.
A while back, I jumped onto the hype train and tried to host Learn JavaScript's marketing page on Netlify — I wanted to join the cool kids. After getting charged for it, I switched to Vercel and I got charged for it (again). I finally went back to good old Digital Ocean.
In this article I want to detail the differences between hosting on Netlify, Vercel, and Digital Ocean, along with what I experienced in the process.
Regular expressions are HARD! They look so complicated, they're turn me off completely most of the time. Sometimes I wished I was smarter so I can use them more effectively.
While working on Learn JavaScript, I noticed that using regular expressions effectively doesn't mean you need to write complicated regex. You can write super simple regex that solves a ton of problems.
Hello! I want to begin the year with a year-end review again. I like doing these because it gives me a solid sense of where I am today versus where I was last year.
I got fed-up searching Google for case conversion utilities. The useful ones I found (Voca and change-case) both require an environment that allows me to use npm.
But I was using Vanilla JavaScript. I did not want to include any toolchains in this project, and I'm reluctant to send an asynchronous request to download a module just for case-conversion.
So I decided to write a set of conversion utilities myself.
I bought the Moonlander ergonomic keyboard and I've been playing with it for a month. I want to share what I think of this keyboard in case you were thinking of getting an ergonomic keyboard as well.
<Image
src="/assets/2020/moonlander/split.jpg"
alt="Moonlander is a split keyboard."
/>
Normal keyboards create tension in the wrists, which eventually lead to backaches. In this article, I explain how that connection happens and why we should use ergonomic keyboards.
I used to think JavaScript doesn't have Interfaces because it doesn't have the Interface keyword, unlike Java.
<Image
src="/assets/2020/interface-vs-api/java-interface.png"
caption="Interface keyword in Java"
/>
But JavaScript DOES have interfaces. I found out about this when I tried Googling for the location API, which turned out to the location Interface 🤦♂️.
I was confused. What the hell is the difference between an interface and an API? I sat down and figured it out (as usual). I want to share my newfound understanding with you in this article.
I was curious about testing JavaScript performance and did some research on it.
When I talk about JavaScript performance here, I'm not talking about things like time-to-first-byte, time-to-interaction, etc.. I'm talking about raw computing speed – how long does function X run compared to function Y.
I discovered we can use two methods to test performance – performance.now and Date.now. I was curious about the difference between them, so I made some experiments to document my findings.
I often get requests from people who want me to look through their work and provide them with feedback. While asking for feedback is a praise-worthy thing – because you want to improve – I don't have the time and resources to give feedback to everyone.
I suspect that's the case for others too. We're all busy.
When I ask others for feedback, sometimes I don't get responses. Sometimes I get subpar responses. I found it hard to get specific, detailed, and actionable advice from people unless they have a skin in the game for helping me out.
For example: You're paying for their services, so they have an incentive to help you. Another example: You're in a project together with them; if you succeed they succeed.
If you get specific and helpful feedback, great! Use that feedback and improve. But the question remains: How can you improve if you don't get feedback?