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?
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)
But there are more things you can do.
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
There are two ways to provide fallbacks for CSS features:
- Property fallbacks
- Feature queries
We use Git tags to create releases. In this video, you’ll learn how to tags manually without Git Flow.
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.
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.
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.
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.
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