-
When writing a string of multiple utility classes, always do so in an order with meaning. The "Concentric CSS" approach works well with utility classes (i.e,. 1. positioning/visibility 2. box model 3. borders 4. backgrounds 5. typography 6. other visual adjustments). Once you establish a familiar pattern of ordering, parsing through long strings of utility classes will become much, much faster so a little more effort up front goes a long way!
-
Always use fewer utility classes when possible. For example, use
mx-2
instead ofml-2 mr-2
and don't be afraid to use the simplerp-4 lg:pt-8
instead of the longer, more complicatedpt-4 lg:pt-8 pr-4 pb-4 pl-4
. -
Prefix all utility classes that will only apply at a certain breakpoint with that breakpoint's prefix. For example, use
block lg:flex lg:flex-col lg:justify-center
instead ofblock lg:flex flex-col justify-center
to make it very clear that the flexbox utilities are only applicable at the
{ | |
"root": true, | |
"parser": "@typescript-eslint/parser", | |
"plugins": ["@typescript-eslint", "prettier"], | |
"extends": [ | |
"eslint:recommended", | |
"plugin:@typescript-eslint/recommended", | |
"prettier" | |
], | |
"rules": { |
- ES6 Katas
- Flexbox Froggy
- Haven’t used this one yet, but it’s TypeScript katas, https://mycodekatas.github.io/typescript.html
- Not a Kata per se, but still good, Flexbox Zombies
I work as a full-stack developer at work. We are a Windows & Azure shop, so we are using Windows as our development platform, hence this customization.
For my console needs, I am using Cmder which is based on ConEmu with PowerShell as my shell of choice.
Yes, yes, I know nowadays you can use the Linux subsystem on Windows 10 which allow you to run Ubuntu on Windows. If you are looking for customization of the Ubuntu bash shell, check out this article by Scott Hanselman.
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
Use case: You have repository A with remote location rA, and repository B (which may or may not have remote location rB). You want to do one of two things:
- preserve all commits of both repositories, but replace everything from A with the contents of B, and use rA as your remote location
- actually combine the two repositories, as if they are two branches that you want to merge, using rA as the remote location
NB: Check out git subtree
/git submodule
and this Stack Overflow question before going through the steps below. This gist is just a record of how I solved this problem on my own one day.
Before starting, make sure your local and remote repositories are up-to-date with all changes you need. The following steps use the general idea of changing the remote origin and renaming the local master branch of one of the repos in order to combine the two master branches.