Articles
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 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.
How to review and edit a pull request
When you submit a pull request, a collaborator will have the right to review your pull request. They’ll decide whether to accept your pull request. If they accept your pull request, your code will be merged into the branch you requested for.
You’re going to learn how a review process will look like from both points of view:
- The person who’s reviewing the process
- The person who’s submitting the review
Getting out of a productivity funk
It’s ironic. I became unproductive after releasing an article about increasing productivity while working less.
I got thrown into a situation where I couldn’t find space and time to work for about a month.
I want to share with you what happened, how I handled the situation, and the lessons I learned. This article will help if you found yourself in a productivity funk.
How to submit a pull request
Let’s say you wrote some code on the develop branch. You’re done with what you were working on, and you want to merge it to the master branch.
But you don’t know whether the code you’ve written is good enough. You want someone to review your code before you merge it into the master branch.
You can do that with a pull request
Creating a simple form with CSS Grid
You learned to create a simple form with Flexbox in the previous article. Today, you’ll understand how to create the same thing with CSS Grid.
Here’s what we’re building:
How to use Git stashes as a temporary storage
Let’s say you’re coding on your development branch. And you get a notice that there’s a bug on the production branch.
You want to check for the bug, but you don’t want to lose the work you’ve created on the development branch. You also don’t want to commit what you’ve written because they’re not done yet.
What do you do? You can’t commit and you can’t switch branches. If you switch branches, things that aren’t committed will flow over to the branch you switched to.
What you want to do is save the changes somewhere temporary while you switch over to another branch. **A Git stash is that temporary storage. **
Creating a simple form with Flexbox
The simplest form on the web contains an email field and a submit button. Sometimes, the email field and the submit button is placed on the same row, like this:
This UI looks simple! But it can be difficult to build if you’re using older methods like inline-block. The hard part is getting the email field and button to align visually.
The great news is: CSS Grid or Flexbox can help you build this form easily.
How I remember CSS Grid properties
The syntax for CSS Grid is foreign and hard to remember. But if you can’t remember CSS Grid’s syntax, you won’t be confident when you use CSS Grid.
To wield CSS Grid effectively, you need to remember its properties and values.
I want to share how I remember the most common CSS Grid properties today. This will help you use CSS Grid without googling like a maniac.
Semantic Versioning
We created numbers like 1.0.0 and 1.0.1 for releases and hotfixes when we worked on Git Flow. What do these numbers represent, and why do we use them?
These numbers represent the version number of the product we put out in the world. We use them because we’re following a best practice called Semantic Versioning.
When we use Semantic Versioning, developers will know whether a change will break their code. The numbers give a clue to the kind of changes that have occurred.
Many popular projects use Semantic Versioning. Examples are React and Vue.