Migrating to a new Mac

Setting up a new Mac is painful. Here are some of the things I have to do:

1. Install all 47 applications I use every day.
2. Provide the right credentials for each application.
3. Change macOS default settings to the ones I like.
4. Set up coding configurations.
5. Move files from the old Mac to the new one.

I estimate at least a three day's worth of work (downloading things and waiting for them to download 😴) if I have to install everything manually.

But I was able to set my computer up in hours (automatically) thanks to dotfiles.

Setting up my new Mac (Part 1—the apps I use)

My first task in 2019 is to get a new computer. I didn't want to change computers, but my old one gave way and I had no choice 😭.

Since I'm already switching computers, I thought it'll be interesting to share the apps I use on a daily basis.

I hope you find some of them interesting!

RSS and Tags are here!

Many people wanted two things at Zellwk.com:

1. An RSS feed (to get updates without going through emails).
2. An easier way to browse the articles I created.

I finally found the chance to provide these features!

Zellwk.com is now open source!

Good news!

I decided to open source my blog. You can see the source code (for almost everything, except credentials) over at this [Github repo][1].

It's okay to write dirty code

Many developers feel they need to write clean code. They're good developers only if they write clean code. They're lousy developers if they don't.

I feel the same way too. And I try to make my code as clean as possible.

But this attempt to write clean code actually slows most of us down. We learn slower. We make fewer things. And as a result, we contribute lesser to this world.

I want to make a point that it's okay to write dirty code. I want to give permission for myself and for you to write dirty code in this article.

Sit down and figure it out

Many people try to learn code this way:

1. Watch a video
2. Follow along with the video
3. Expect they'll be able to code

But they fail. They can't build things on their own. They panic when they stare into a blank file.

Well, that's because they missed a critical step in the learning process. They didn't sit down and figure things out.

Using small pockets of idle time

Let's say you finish a task before the time is up. You have another 5 to 15 minutes more. What do you do with this time?

If you get distracted during work, you may also end up with this 5 to 15 minutes left. What do you do with it?

If you find yourself in a distracting situation, like having to take care of a baby who cries every now and then. You probably have 5 to 15 minutes pockets of time very often. How do you use this time?

I think you can use it in four possible ways:

1. Use it do errands
2. Use it to learn
3. Start the next thing
4. Use it to chill

Year end review—2018

We're already at the end of 2018. This year passed by so quickly. To be honest, 2018 is a weird year for me because it's filled with great success, but at the same time, I feel like nothing special has happened.

Checking if an input is empty with JavaScript

Last week, I shared how to [check if an input is empty with CSS][1]. Today, let's talk about the same thing, but with JavaScript.

It's much simpler.

Here's what we're building:

<Image src="/assets/2018/empty-input-validation-js/check.gif" alt="When input is filled, borders should turn green" />

Checking if an input is empty with CSS

Is it possible to know if an input is empty with only CSS?

I had that question when I tried to make an autocomplete component for Learn JavaScript. Basically, I wanted to:

1. Hide a dropdown if the input is empty
2. Show the dropdown if the input is filled

<Image src="/assets/2018/empty-input-validation-css/autocomplete.gif" alt="autocomplete demo from https://learnjavascript.today" />

I found a way to do it. It's not perfect. There are a few nuances involved, but I want to share it with you.

The Gitignore file

If you don't want to commit a file into a Git repository, it makes sense not to have the file show up in the staging area.

You can do this with a Gitignore file.

Why support older browsers?

Why you have to care about old browsers?

Who use old browsers? Probably, users with old computers?

If they use old computers, they probably don't have money to buy a new one.

If they don't have money to buy a new computer, they probably will not buy anything from you as well.

If they will not buy anything from you, why you have to care about supporting their browsers?

To a business person, that's a perfectly reasonable train of thought. But why do we developers still insist on supporting older browsers?

What not to save into a Git repository

You should not commit these four types of files into your Git repository.

1. Files that don't belong to the project
2. Files that are automatically generated
3. Libraries (depends on the situation)
4. Credentials

Supporting older browsers—Part 3: JavaScript

It's easy to provide JavaScript support for older browsers. Most of the time, you just need to use a polyfill.

But there are more things you can do.

Undoing changes in Git

Undoing with Git

At this point, you already know Git is like a save point system. What you've done so far is to learn to save. But how do you undo, and go back to a previous state?

That's what we're going to cover

Supporting older browsers—Part 2: CSS

There are two ways to provide fallbacks for CSS features:

1. Property fallbacks
2. Feature queries

Git Tags

We use Git tags to create releases. In this video, you'll learn how to tags manually without Git Flow.

Supporting older browsers with Polyfills

You don't have to worry much about supporting older browsers today. They've been decent ever since Internet Explorer 8 died.

But the question remains: How should you go about supporting Internet Explorer 9 and other browsers? In the first place, should you even be thinking about supporting Internet Explorer 9?

We'll look at a few things you'd want to consider.

Switching to Dvorak as a web developer

I'm invested in QWERTY. I don't want to change keyboards if I can, but I was forced to switch to Dvorak. My left-hand ached when I typed in QWERTY.

And I didn't like Dvorak.

(At first)

But I've grown to like it.

In this article, I want to share how I switched over to the Dvorak system. This process is the same as learning any other skill.

If you had problems learning how to code, you'll benefit from learning this process.

How to take a good break

When I wrote about my [productive routine](/blog/becoming-more-productive-while-working-less/ 'Becoming more productive while working less') in a previous article, I said I'd work for 1.5 hours and take a break 30 minutes. And I'll repeat this sequence four times a day.

In my experiments, I reduced my work hours to 4.5 hours (3 x 1.5-hour slots) and managed to get 40% more work done.

The key to this routine isn't simply sitting at my desk for 1.5 hours each sprint.

The key is 30-minute break.

If I don't rest properly, I'll waste the next 1.5 hours of work because I'm not focused. When I'm not focused, I can't get work done.

So today, I want to share how I take a proper break.