There are LOTS of languages. Picking one (or two, or three! 😱) can be scary and overwhelming at first. In this article, I want to share three things:
What to consider when picking languages
What NOT to worry about when you pick languages
Recommendations for languages to learn
I’ve been styling
:active states the same way for years. I can’t remember when I started styling this way. Here’s the code I always use:
// Not the best approach. I'll explain why in this article
// Styles here
As I paid more attention to keyboard accessibility (and therefore paying more attention to focus), I began to think we should not style hover, focus, and active states the same way.
Hover, focus, and active states should be styled different.
There’s a simple reason: They’re different states!
Today, I want to show you a magical way to style all three states effortlessly.
When you create a custom focus style, you want to think about four things:
Adding an outline
Creating animations that contain movement
Changing the background color
Changing the text color
I wrote more about this in my article on
designing focus. During my research, I found three kinds of focus style I liked.
The one on Smashing Magazine
The one on WTF Forms
The one on Slack
Today, I want to show you how to create these focus styles and use them effortlessly across your website.
Focus is important. It tells us what element we’re currently focusing on. Most developers suggest keeping the default focus style.
there are problems with the default style. I tried searching for inspiration to design a better focus style, but I couldn’t find anything on this topic. So I did some quick research by visiting sites I use and paying attention to their focus styles.
I want to document my research and findings in this article. I hope it helps you:
Understand the problems with the default focus style
Give you some inspiration to
design your own focus styles
It’s easier to work with Promises (or Async/await) compared to callbacks. This is especially true when you work in Node-based environments. Unfortunately, most Node APIs are written with callbacks.
Today I want to show you how to convert callbacks to promises.
As I created applications with Express and Node, I learned about three useful middlewares:
Remove empty properties
Of these three, Morgan is an actual middleware. You can download
Morgan from npm directly. The other two are middlewares I created with camelcase-keys and omit-empty respectively.
I want to share what these three middlewares do, and how they make life easier for me when I’m creating applications.
I noticed browsers were inconsistent in how they handle a click on
<button>. Some browsers choose to focus on the button. Some browsers don’t.
In this article, I want to show you my test and findings. Then, I want to talk about a way to overcome these inconsistencies.
Fears and doubt often pop into my head when I work.
When I code, I wonder:
Am I using best practices?
Did I structure code in the best possible way?
Am I doing it correctly?
When I write, I wonder:
What makes me qualified to teach anything?
Will people understand what I’m trying to say?
THIS THING IS TOTALLY OFF-TOPIC. IT’S NOT TECH RELATED! OH MY GOD!
When I run my business, I wonder:
Should I reply to every single email?
Should I continue to focus on articles?
Can I see pre-orders for courses?
What if I can’t complete my courses on time?
Are my products and sales emails persuasive but not coming off too sales-y?
I hate having these thoughts because they make me hesitate. And I slow down in my work.
But I love these thoughts because they tell me I’m doing the right thing.
When you write tests for the backend, you need to test for four different kinds of operations:
Create (for adding things to the database)
Read (for getting things from the database)
Update (for changing the database)
Delete (for deleting things from the database)
The easiest type to test for is create operations. You put something into the database and test whether it’s there.
For the other three types of operations, you need to put something into the database
before you write the test.