Couldn't find the text of this for a while...
altwin:menu = +altwin(menu) | |
altwin:meta_alt = +altwin(meta_alt) | |
altwin:ctrl_win = +altwin(ctrl_win) | |
altwin:meta_win = +altwin(meta_win) | |
altwin:left_meta_win = +altwin(left_meta_win) | |
altwin:super_win = +altwin(super_win) | |
altwin:hyper_win = +altwin(hyper_win) | |
altwin:alt_super_win = +altwin(alt_super_win) | |
altwin:swap_lalt_lwin = +altwin(swap_lalt_lwin) | |
grp:switch = +group(switch) |
When times get tough and people get nasty, you’ll need more than a killer smile. You’ll need a killer contract.
Used by 1000s of designers and developers Clarify what’s expected on both sides Helps build great relationships between you and your clients Plain and simple, no legal jargon Customisable to suit your business Used on countless web projects since 2008
…………………………
NOTE: This guide has moved to https://github.com/bpierre/switch-to-vim-for-good
This guide is coming from an email I used to send to newcomers to Vim. It is not intended to be a complete guide, it is about how I switched myself.
My decision to switch to Vim has been made a long time ago. Coming from TextMate 1, I wanted to learn an editor that is Open Source (so I don’t lose my time learning a tool that can be killed), cross platform (so I can use it everywhere), and powerful enough (so I won’t regret TextMate). For these reasons, Vim has always been the editor I wanted to learn, but it took me several years before I did it in a way that works for me. I tried to switch progressively, using the Janus Vim distribution for a few months, then got back to using TextMate 2 for a time, waiting for the next attempt… here is what finally worked for me.
Original gist with comments: https://gist.github.com/bpierre/0a0025d348b6001394e0
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
/** | |
* Example to refresh tokens using https://github.com/auth0/node-jsonwebtoken | |
* It was requested to be introduced at as part of the jsonwebtoken library, | |
* since we feel it does not add too much value but it will add code to mantain | |
* we won't include it. | |
* | |
* I create this gist just to help those who want to auto-refresh JWTs. | |
*/ | |
const jwt = require('jsonwebtoken'); |
First of all, please note that token expiration and revoking are two different things.
- Expiration only happens for web apps, not for native mobile apps, because native apps never expire.
- Revoking only happens when (1) uses click the logout button on the website or native Apps;(2) users reset their passwords; (3) users revoke their tokens explicitly in the administration panel.
A JWT token that never expires is dangerous if the token is stolen then someone can always access the user's data.
Quoted from JWT RFC:
For an emulator that mimics a Pixel 5 Device with Google APIs and ARM architecture (for an M1/M2 Macbook):
-
List All System Images Available for Download:
sdkmanager --list | grep system-images
-
Download Image:
sdkmanager --install "system-images;android-30;google_atd;arm64-v8a"
I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr
Install, build and debug a react native app in WSL2 (Windows Subsystem for Linux) and Ubuntu.