name: tufte-viz description: | Ideate and critique data visualizations using Edward Tufte's principles from "The Visual Display of Quantitative Information." Use this skill when: (1) Designing new data visualizations or charts (2) Critiquing or improving existing visualizations (3) Reviewing dashboards or reports for graphical integrity (4) Deciding between visualization approaches (5) Reducing chartjunk or improving data-ink ratio (6) Planning small multiples or high-density displays
🗣️ this is a useful guide to help you memorize + better understand how Jujutsu works, but it's not a replacement for learning the mental model or deeper strategies!
- No staging area — all changes in the working copy are automatically part of the current “change”
- Changes vs commits — jj tracks “changes” (mutable) that become “commits” (immutable) when pushed
@— a symbol pointing to the current working copy change (likeHEAD, but for changes)@-— the parent of@
| // 1. Log in to your Amazon account | |
| // 2. Go to your Content Library > Books - https://www.amazon.com/hz/mycd/digital-console/contentlist/booksAll/dateDsc/ | |
| // 3. Open your browser's Javascript console | |
| // 4. For each page of books, paste this script into the console | |
| (async function () { | |
| // Close the notification if it appears | |
| function closeNotification() { | |
| const notifClose = document.querySelector("span#notification-close"); | |
| if (notifClose) { |
I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.
I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:
| #!/usr/bin/env bash -x | |
| # TO USE: | |
| # 1. MAKE A CONFIG FILE AT ~/.go-to-bed | |
| # it should look like this (don't include hashes in file, this will nag you starting at 12:16 AM until 6:00 AM) | |
| # START_TIME:0.16 | |
| # END_TIME:6.0 | |
| # HUSHED_UNTIL:2023-11-23T1:40:00 | |
| # | |
| # 2. SAVE THIS SCRIPT SOMEWHERE, maybe ~/bin/go-to-bed |
| #!/bin/bash | |
| # Change the date under CUTOFF_DATE to change how far back you want to delete | |
| # Install the GitHub CLI tool by following the instructions in the official documentation: https://cli.github.com/manual/installation | |
| # Make sure you auth first to github with 'gh auth login' | |
| REPO_OWNER="OWNER" | |
| REPO_NAME="REPO_NAME" | |
| CUTOFF_DATE=$(date --date='30 days ago' +'%Y-%m-%dT%H:%M:%SZ') | |
| PAGE=1 |
| This is free and unencumbered software released into the public domain. | |
| Anyone is free to copy, modify, publish, use, compile, sell, or | |
| distribute this software, either in source code form or as a compiled | |
| binary, for any purpose, commercial or non-commercial, and by any | |
| means. | |
| In jurisdictions that recognize copyright laws, the author or authors | |
| of this software dedicate any and all copyright interest in the | |
| software to the public domain. We make this dedication for the benefit |
In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.
After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.
But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.
And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?
In dark rooms, in hushed tones, we speak of colours.
| ### | |
| ### [2023-06-19] UPDATE: Just tried to use my instructions again on a fresh install and it failed in a number of places. | |
| ###. Not sure if I'll update this gist (though I realise it seems to still have some traffic), but here's a list of | |
| ###. things to watch out for: | |
| ### - Check out the `nix-darwin` instructions, as they have changed. | |
| ### - There's a home manager gotcha https://github.com/nix-community/home-manager/issues/4026 | |
| ### | |
| # I found some good resources but they seem to do a bit too much (maybe from a time when there were more bugs). | |
| # So here's a minimal Gist which worked for me as an install on a new M1 Pro. |