:root {
overscroll-behavior: none;
}
A codepen demo https://codepen.io/michellebarker/pen/vYbrpbX
This is a list of things you’re allowed to do that you thought you couldn’t, or didn’t even know you could. I haven’t tried everything on this list, mainly due to cost. But you’d be surprised how cheap most of the things on this list are (especially the free ones).
Split into categories:
- Learning & Decision making
- Interpersonal
- Support and accountability
- Making the most of your resources
- Professional
Write on a post-it note affixed to a greeting card rather than on the greeting card itself, so the recipient can throw away the post-it and reuse your card.
The author shares many other lists.
It is possible to display the temperature and the CPU frequency with htop. Simply press F2 and enable both in the display options.
Notes stow metadata about anything tracked by git—any object: commits, blobs, and trees.
The git project itself offers an example of git notes in the wild. They link each commit to its discussion on their mailing list.
Other folks are using notes for things like:
- Tracking time spent per commit or branch
- Adding review and testing information to git log
- And even fully distributed code review
Review notes are used by Gerrit (Wikimedia) and many google projects. For example:
commit d1d17908d2a97f057887a4afbd99f6c40be56849
Author: User <user@example.com>
Date: Sun Mar 27 18:10:51 2022 +0200
Change the thing
Notes (review):
Verified+1: SonarQube Bot
Verified+2: jenkins-bot
Code-Review+2: Reviewer Human <reviewerhuman@wikimedia.org>
Submitted-by: jenkins-bot
Submitted-at: Tue, 14 Jun 2022 21:59:58 +0000
Reviewed-on: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/774005
Project: mediawiki/core
Branch: refs/heads/master
There is also an extension from Google to git notes dedicated to code review: https://github.com/google/git-appraise. Request review, comment and review and merge are included.
Its authors have declared it a “fully distributed code review”—independent of GitHub, GitLab, or any other code forge.
Git notes are however a pain to use. Mhmhmhm #idea #project on top of the git note commands?
For commits, you can make viewing and adding notes easier using fancy options in your gitconfig3. But for storing notes about blobs or trees? Forget it. You’d need to be comfortable rooting around in git’s plumbing first.
Much of the value of git repos ends up locked into forges, like GitHub. Git notes are a path toward an alternative and it could make it possible to distribute the history of an entire project.
with the UX tips https://www.uidesign.tips/ux-tips
En résumé: 7-zip avec le format d'archive 7z :)
Dernière modif à la lecture de la page: mars 2023.
How to launch a program without network access?
firejail --noprofile --net=none <program-name>
We can use css (attributes) selectors to style external links, and I think it is a great idea.
If spam is detected, then make his life harder :p
Add snippets to get statistics from Core Web Vitals
The "About config" is not available in the menu anymore since versions.
The recommanded way to get the Firefox version is from "Open Application Menu" > Help > More troubleshooting information
Using aliases are powerful to navigate in the terminal.
The author shares ad
function to add... aliases on the fly
The benefits of min-width: 0;
while overflowing with flexbox
Mastodon can support a wide variety of media files
- Plan your color use: avoid or limit white to pure black colors. Black can be used but dim the text slightly.
- Brand the dark color with a gradation of a brand color. Black and white only is also a kind of branding.
- Reduce color saturation
- Communicate depth through a scale of lighter colors to translate the elevation: the brighter the higher.
- Check dark mode contrasts.
- Design light mode first by default.
- Use bare colors to design dark mode: transparent color can help.
- Use the system default setting or user preference to set the mode.
These tips are related to academic papers, but it can be applied to every writings that should have an effective communication.
Some that can affect me:
- avoid passive tense
- use strong vers instead of lots of nouns: "make assumption" → assume, "had difference" → differed, "is an illustration" → illustrates
- if you find yourself saying "In other words," it means you didn't say it clearly enough the first time. Rewrite it.
- Avoid filler words, e.g., by converting sentences into simple actor-action-object phrasing.
- Each sentence in a paragraph must have some logical connection to the previous one. A new thought should get its own paragraph, but still clearly needs some logical connection to the paragraphs that preceded it.
- avoid scare quotes
- Numbers ten or less are spelled out: "It consists of three fields", not "3 fields".
- avoid in-line enumeration
- avoid itemization (bullets) as it takes extra space. Bullets can be used to emphasize key points
- name the author with its reference [1] instead of "[1] shows" only. Add "et al." if more authors exist. Cite in depth the section for example to accord the verb.
- more than two footnotes per page or a handful per paper is a bad sign.
- A part before a colon (":") must be a complete sentence.
- Avoid slash constructs: time/money, expand them such as "time and money".
- Avoid cliches like "recent advances in ..."
- Avoid symbols as they are only acceptable on slides.
- Uses uppercased words for acronyms only. Avoid it for technical terms.
- Expand all acronyms on first use, except acronyms that every reader is expected to know. For example, TCP in a research paper is not needed, but Yet Another Compiler Compiler (YACC) is.
- Divide powers of a 1 000 for readability. It can be adjusted by the locale used.
- Use "kb/s" or "Mb/s," not "kbps" or "Mbps" - the latter are not scientific units. Distinguish MB and Mb too.
- It is always kHz.
- It's Wi-Fi, not WiFi or wifi that are trademarks.
- Avoid "etc.", prefers "for example", "such as", "among others" or provide a complete list.
- "for example" or "like" and "etc." are in different phrases. It already indicate that there are more such items.
- Remember that "i.e." and "e.g." are always followed by a comma.
- Do not use ampersands (&) or slash-abbreviations (such as s/w or h/w) in formal writing; they are acceptable for slides.
- "Respectively" is preceded by a comma, as in "The light bulbs lasted 10 and 100 days, respectively."
- Therefore, however, hence and thus are usually followed by a comma, as in "Therefore, our idea should not be implemented."
- Use "in Figure 1" instead of "following figure" since figures may get moved during the publication or typesetting process.
- Figures show, depict, indicate, illustrate. Avoid "(refer to Fig. 17)".
- Often, it is enough to simply put the figure reference in parenthesis "Packetg droppers (Fig. 17) have a pipe to the bit bucket, ..."
- If you quote something literally, enclose it in quotation marks or show it indented and in smaller type ("block quote"). A mere citation is not sufficient as it does not tell the reader whether you simply derived your material from the cited source or copied it verbatim.
- Acknowledge your funding support.
- Integrate PostScript instead of GIF for images [in papers].
- Section titles are not followed by a period.
type BLetter = 'A' | 'B' | 'C';
type BNumber = '1' | '2' | '3';
type Board = `${BLetter}${BNumber}`;
// ^?
After the ^?
, type Board = "B1" | "B2" | "B3" | "C1" | "C2" | "C3" | "A1" | "A2" | "A3"
will be shown in the IDE.