Articles
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.
- Files that don’t belong to the project
- Files that are automatically generated
- Libraries (depends on the situation)
- 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:
- Property fallbacks
- 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
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 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