Merge origin/main
This commit is contained in:
GitJournal-Phone
commit
09627060db
75 changed files with 15579 additions and 0 deletions
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
id: 23360258-5e55-4f51-ae84-83f073539aef
|
||||
title: |
|
||||
Using CSS custom properties like this is a waste - YouTube
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- Youtube
|
||||
date_added: 2023-10-14 20:11:15
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/using-css-custom-properties-like-this-is-a-waste-you-tube-18b30754bdc
|
||||
url_original: |
|
||||
https://m.youtube.com/watch?index=12&list=WL&pp=gAQBiAQB&v=_2LwjfYc1x8
|
||||
---
|
||||
|
||||
# Using CSS custom properties like this is a waste - YouTube
|
||||
|
||||
## Notes
|
||||
|
||||
Definir _"variables locales"_ en la clase más alta de un _componente_ (Ej: ˋ.cardˋ), esta variable se puede utilizar para hacer variantes del componente de manera más rápida y limpia y se puede utilizar en los decendientes de la clase.
|
||||
|
||||
Esto tiene la ventaja de:
|
||||
1. Para crear una variante de nuestro componente solo debemos crear una nueva clase y añadirla junto a la clase más alta (ˋ.card-successˋ), y ya solo debemos sobre escribir las variables en vez de tener que actualizar cada parte del componente (ˋ.card.card-success .buttonˋ & ˋ.card.card-success .card-header h3ˋ).
|
||||
2. Si tenemos propiedades complejas o animaciones donde solo varia una parte de ellas (Ej: ˋdrop-shadowˋ) no tenemos que re-escribir en cada variante la propiedad completa.
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
0:02 / 16:11•Watch full video
|
||||
|
||||
[](https://m.youtube.com/@KevinPowell)
|
||||
|
||||
45K views 2 days ago [#css](https://m.youtube.com/hashtag/css)
|
||||
|
||||
If you're interested in checking out ICodeThis, you can find it here: [https://icodethis.com/?ref=kevin](https://www.youtube.com/redirect?event=video%5Fdescription&redir%5Ftoken=QUFFLUhqbVZsbWpVZ3M1NUdacFdJSVZha3BFQ0ZIaTNoZ3xBQ3Jtc0ttWG5nU0ltOTdzSE9YSDQ3aWlsUVFGcEVoMlRFaVhLb0hrczRKRVgta3N0bXBIeC1Sc1ZtTWJHY2MycUpfdVN6OE5pWDlfTG9WQlhTMlRzcW1YX2p1MTY4bjVybTd1ZG02RV9zM1l0QkFWeTNybjBtcw&q=https%3A%2F%2Ficodethis.com%2F%3Fref%3Dkevin&v=%5F2LwjfYc1x8) and if you want to sign up for one of their premium plans, use KEVIN at checkout for an extra 10% off. Custom properties are amazing, but a lot of people don’t take advantage of how awesome they are. They set them up in the :root and that’s it, but they can be so much more useful than that! So, in this …
|
||||
|
||||
...more
|
||||
|
||||
...more
|
||||
|
||||
45,645 views • Oct 12, 2023 • #css
|
||||
|
||||
#### License
|
||||
|
||||
Shop the Kevin Powell store
|
||||
File diff suppressed because one or more lines are too long
|
|
@ -0,0 +1,349 @@
|
|||
---
|
||||
id: 512f7bbc-6ba0-11ee-be2a-83432433f852
|
||||
title: |
|
||||
Highlighting fold text, community fork of null-ls, leetcode integration, reduce ram usage of LSP servers, svelte inspector integration
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- RSS
|
||||
date_added: 2023-10-15 16:10:23
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/highlighting-fold-text-community-fork-of-null-ls-leetcode-integr-18b3533f57b
|
||||
url_original: |
|
||||
https://dotfyle.com/this-week-in-neovim/55
|
||||
---
|
||||
|
||||
# Highlighting fold text, community fork of null-ls, leetcode integration, reduce ram usage of LSP servers, svelte inspector integration
|
||||
|
||||
## Highlights
|
||||
|
||||
hinell/duplicate.nvim
|
||||
|
||||
> [!note]
|
||||
> Add to nvim config
|
||||
|
||||
[source](https://omnivore.app/me/highlighting-fold-text-community-fork-of-null-ls-leetcode-integr-18b3533f57b#5de369b4-f406-446f-b59a-358d59dd9eb1) #Todo
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
## Introduction
|
||||
|
||||
This week we have new features in Neovim Core, new plugins and new releases. Some new Neovim features include `:fclose` to close floating windows, support spaces in in directory names, treesitter highlighting in folds and NVIM\_APPNAME supports relative paths.
|
||||
|
||||
We have several new plugins, e.g. you can now grind LeetCode inside Neovim, mini.pick a new fuzzy finder + selector added to the mini.nvim library, and a plugin to start/stop LSP servers upon demand to keep RAM usage low etc..
|
||||
|
||||
Hope you enjoy!
|
||||
|
||||
## Neovim core
|
||||
|
||||
> Updates of Neovim itself, which are available on Neovim nightly.
|
||||
|
||||
> * [@neovim](https://twitter.com/neovim) on Twitter
|
||||
> * [Neovim news](https://neovim.io/doc/user/news.html)
|
||||
> * `:h news.txt` updates in Neovim directly
|
||||
> * [PR's on GitHub](https://github.com/neovim/neovim/pulls)
|
||||
|
||||
* [:fclose to close floating window](https://github.com/neovim/neovim/commit/fd39f5ce8c9bbda1b77ff6c03553148fadac5d57)
|
||||
* [Spaces can be used to separate directory names. To have a space in a directory name, precede it with an extra backslash, and escape the space](https://github.com/neovim/neovim/commit/f5eabaa9407ae3d1ccf6592337453c423eff3d9a)
|
||||
* [Ignore swapfile for running Nvim processes](https://github.com/neovim/neovim/commit/29fe883aa9166bdbcae3f935523c75a8aa56fe45)
|
||||
* [vim.lsp.util.parse\_snippet() will now strictly follow the snippet grammar defined by LSP, and hence previously parsed snippets might now be considered invalid input.](https://github.com/neovim/neovim/commit/eb1f0e8fcca756a00d287e23bf87554e0e7f6dfd)
|
||||
* [vim.treesitter.foldtext() applies treesitter highlighting to foldtext.](https://github.com/neovim/neovim/commit/9ce1623837a817c3f4f5deff9c8ba862578b6009)
|
||||
* [Better cmdline completion for string option value](https://github.com/neovim/neovim/commit/01c51a491330bd10202c73aff92c0978984c0692)
|
||||
* [Support toggling showing of float window](https://github.com/neovim/neovim/commit/4200a0f1678c06c6da4e4cfb0184c29c1174ed21)
|
||||
* [NVIM\_APPNAME now supports relative paths](https://github.com/neovim/neovim/commit/a66b0fdfaa35715c832b98b8941cc5673505e0c2)
|
||||
|
||||
### Highlighted folds on Neovim Nightly
|
||||
|
||||
|
||||
|
||||
* [PR](https://github.com/neovim/neovim/pull/25209)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16sqyjz/finally%5Fwe%5Fcan%5Fhave%5Fhighlighted%5Ffolds/)
|
||||
|
||||
## Neovim Plugin Community
|
||||
|
||||
> Neovim is full of active plugins. This section is about the community and what is going on.
|
||||
|
||||
---
|
||||
|
||||
### Resources & articles
|
||||
|
||||
#### Open Neovim From Your Browser - Integrating nvim with Svelte’s Inspector
|
||||
|
||||
* [Blog](https://theosteiner.de/open-neovim-from-your-browser-integrating-nvim-with-sveltes-inspector)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/177p9fj/open%5Fneovim%5Ffrom%5Fyour%5Fbrowser%5Fintegrating%5Fnvim/)
|
||||
|
||||
---
|
||||
|
||||
### New plugins
|
||||
|
||||
#### none-ls.nvim is a community fork of null-ls.nvim
|
||||
|
||||
> null-ls.nvim reloaded / Use Neovim as a language server to inject LSP diagnostics, code actions, and more via Lua.
|
||||
|
||||
null-ls.nvim fork, maintained by the community. Only the repository name has changed for compatibility reasons. All the API's will stay as is.
|
||||
|
||||
Migrate by replacing `jose-elias-alvarez/null-ls.nvim` with `nvimtools/none-ls.nvim` in your package manager.
|
||||
|
||||
* [GitHub](https://github.com/nvimtools/none-ls.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/nvimtools/none-ls.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16wystn/nonelsnvim%5Fis%5Fa%5Fcommunity%5Ffork%5Fof%5Fnulllsnvim/)
|
||||
|
||||
#### kawre/leetcode.nvim
|
||||
|
||||
|
||||
|
||||
> A Neovim plugin enabling you to solve LeetCode problems within Neovim.
|
||||
|
||||
* [GitHub](https://github.com/kawre/leetcode.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/kawre/leetcode.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/173ctlz/leetcodenvim%5Fsolve%5Fleetcode%5Fproblems%5Fwithin%5Fneovim/)
|
||||
|
||||
#### echasnovski/mini.pick
|
||||
|
||||
|
||||
|
||||
> pick anything. Interactive non-blocking picker with one window design, toggleable preview, fast default matching, built-in pickers, and more
|
||||
|
||||
* [GitHub](https://github.com/echasnovski/mini.pick)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/echasnovski/mini.pick)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/176yv8g/minipick%5Fpick%5Fanything%5Finteractive%5Fnonblocking/)
|
||||
|
||||
#### hinell/lsp-timeout.nvim
|
||||
|
||||
|
||||
|
||||
> Start/stop LSP servers upon demand; keeps RAM usage low
|
||||
|
||||
Some LSP servers are terribly inefficient at memory management and can easily take up gigabytes of RAM MBs if left unattended (just like VS Code huh?!). This plugin prevents excessive memory usage by stopping and restarting LSP servers automatically upon gaining or loosing window focus, keeping neovim fast.
|
||||
|
||||
* [GitHub](https://github.com/hinell/lsp-timeout.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/hinell/lsp-timeout.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16vkkj8/lsptimeoutnvim/)
|
||||
|
||||
---
|
||||
|
||||
#### luckasRanarison/clear-action.nvim
|
||||
|
||||
|
||||
|
||||
> Predictable LSP code actions
|
||||
|
||||
A simple Neovim plugin that enhances LSP code actions with fully customizable signs, personalized actions, and server-specific mappings, making code actions more predictable.
|
||||
|
||||
* [GitHub](https://github.com/luckasRanarison/clear-action.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/luckasRanarison/clear-action.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16v32p5/clearactionnvim%5Fmakes%5Flsp%5Fcode%5Factions/)
|
||||
|
||||
---
|
||||
|
||||
#### JMarkin/gentags.lua
|
||||
|
||||
> autogenerate tags for neovim
|
||||
|
||||
* [GitHub](https://github.com/JMarkin/gentags.lua)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/JMarkin/gentags.lua)
|
||||
|
||||
---
|
||||
|
||||
#### roobert/palette.nvim
|
||||
|
||||
|
||||
|
||||
> 🎨 Palette - A beautiful, versatile, systematic, Neovim theme system
|
||||
|
||||
Palette is a Neovim theme system to make creating and customizing themes easy.
|
||||
|
||||
Highlight groups are logically arranged to strike a harmonious balance between clarity and aesthetic appeal.
|
||||
|
||||
Caching ensures themes are performant.
|
||||
|
||||
Build easily distributable themes using the provided build script.
|
||||
|
||||
Generate application color schemes, such as for LS\_COLORS and iterm2 for matching terminal feel.
|
||||
|
||||
* [GitHub](https://github.com/roobert/palette.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/roobert/palette.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16smdr6/introducing%5Froobertpalettenvim%5Fa%5Fbeautiful/)
|
||||
|
||||
---
|
||||
|
||||
#### MunifTanjim/nougat.nvim
|
||||
|
||||
  
|
||||
|
||||
> 🍫 Hyperextensible Statusline / Tabline / Winbar for Neovim 🚀
|
||||
|
||||
* [GitHub](https://github.com/MunifTanjim/nougat.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/MunifTanjim/nougat.nvim)
|
||||
|
||||
---
|
||||
|
||||
#### trimclain/builder.nvim
|
||||
|
||||
|
||||
|
||||
> Simple building plugin for neovim
|
||||
|
||||
* [GitHub](https://github.com/trimclain/builder.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/trimclain/builder.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16qwcl7/buildernvim%5Fsimple%5Fbuild%5Fplugin%5Ffor%5Fneovim/)
|
||||
|
||||
---
|
||||
|
||||
#### niuiic/git-log.nvim
|
||||
|
||||
|
||||
|
||||
> Check git log of the selected code.
|
||||
|
||||
* [GitHub](https://github.com/niuiic/git-log.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/niuiic/git-log.nvim)
|
||||
|
||||
---
|
||||
|
||||
#### 2KAbhishek/nerdy.nvim
|
||||
|
||||
|
||||
|
||||
> Find Nerd Glyphs Easily 🤓🔭
|
||||
|
||||
Do you like Nerd fonts, but don't like going over to the site just to find a glyph? nerdy.nvim, is a super handy plugin that lets you easily search, preview and insert any nerd font glyph from Neovim!
|
||||
|
||||
* [GitHub](https://github.com/2KAbhishek/nerdy.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/2KAbhishek/nerdy.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16qr135/nerdynvim%5Feasily%5Ffind%5Fand%5Finsert%5Fnerd%5Ffont%5Fglyphs/)
|
||||
|
||||
---
|
||||
|
||||
#### David-Kunz/gen.nvim
|
||||
|
||||
|
||||
|
||||
> Neovim plugin to generate text using LLMs with customizable prompts
|
||||
|
||||
* [GitHub](https://github.com/David-Kunz/gen.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/David-Kunz/gen.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16x1zf7/local%5Fllms%5Fin%5Fneovim%5Fgennvim/)
|
||||
* [Youtube](https://www.youtube.com/watch?v=FIZt7MinpMY)
|
||||
|
||||
---
|
||||
|
||||
#### VidocqH/data-viewer.nvim
|
||||
|
||||
|
||||
|
||||
> Table view for data files, csv, tsv
|
||||
|
||||
Lightweight neovim plugin provides a table view for inspect data files such as csv, tsv
|
||||
|
||||
* [GitHub](https://github.com/VidocqH/data-viewer.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/VidocqH/data-viewer.nvim)
|
||||
|
||||
---
|
||||
|
||||
#### ==hinell/duplicate.nvim==
|
||||
|
||||
|
||||
|
||||
> Duplicate visual selection, lines, and textobjects
|
||||
|
||||
Duplicate lines in different directions (up/down) by specified offset Duplicate visual selection & line-wise blocks
|
||||
|
||||
* [GitHub](https://github.com/hinell/duplicate.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/hinell/duplicate.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16vkd4x/duplicatenvim/)
|
||||
|
||||
---
|
||||
|
||||
#### niuiic/remote.nvim
|
||||
|
||||
|
||||
|
||||
> Edit remote files locally.
|
||||
|
||||
Edit remote files with local neovim configuration.
|
||||
|
||||
Edit them as local directories.
|
||||
|
||||
No other dependencies required for remote machine except ssh.
|
||||
|
||||
* [GitHub](https://github.com/niuiic/remote.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/niuiic/remote.nvim)
|
||||
|
||||
---
|
||||
|
||||
#### niuiic/typst-preview.nvim
|
||||
|
||||
|
||||
|
||||
> Neovim plugin to preview typst document.
|
||||
|
||||
Generate pdf files by typst compile. Respond to subsequent file changes with typst-lsp. Redirect these pdf files to a fixed path when you switch buffer. Preview this pdf by a pdf viewer with the ability to respond to the file changes.
|
||||
|
||||
* [GitHub](https://github.com/niuiic/typst-preview.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/niuiic/typst-preview.nvim)
|
||||
|
||||
---
|
||||
|
||||
#### SalOrak/whaler.nvim
|
||||
|
||||
|
||||
|
||||
> Telescope extension to change between directories blazingly fast
|
||||
|
||||
Whaler is a Telescope extension to move between directories. It is based on the concept of [tmux-windowizer](https://github.com/ThePrimeagen/.dotfiles/blob/master/bin/.local/scripts/tmux-windowizer) which uses a set of directories and fzf to move to another directory whilst creating a new tmux session.
|
||||
|
||||
* [GitHub](https://github.com/SalOrak/whaler.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/SalOrak/whaler.nvim)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16wgw0b/whalernvim/)
|
||||
|
||||
---
|
||||
|
||||
#### gsuuon/note.nvim
|
||||
|
||||
|
||||
|
||||
> Notes in neovim
|
||||
|
||||
A simple Neovim note taking plugin with daily notes, task tracking and syntax highlighting.
|
||||
|
||||
note.nvim makes it easy to take working notes and track tasks. It adds commands to help manipulate task items, create daily notes, and navigate within (and between) notes.
|
||||
|
||||
* [GitHub](https://github.com/gsuuon/note.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/gsuuon/note.nvim)
|
||||
|
||||
---
|
||||
|
||||
#### A retrospective on why Nyoom is archived
|
||||
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16sk266/nyoom%5Fwhy%5Fim%5Fultimately%5Farchiving%5Fit%5Fa%5Fshort/)
|
||||
|
||||
#### indent-blankline.nvim v3 is released
|
||||
|
||||
* [GitHub](https://github.com/lukas-reineke/indent-blankline.nvim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/lukas-reineke/indent-blankline.nvim)
|
||||
* [Migration guide](https://github.com/lukas-reineke/indent-blankline.nvim/wiki/Migrate-to-version-3)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/16u5abl/indent%5Fblankline%5Fv3%5Fis%5Freleased/)
|
||||
|
||||
#### LazyVim 10.0.0 has been released!
|
||||
|
||||
* [GitHub](https://github.com/LazyVim/LazyVim)
|
||||
* [Dotfyle](https://dotfyle.com/plugins/LazyVim/LazyVim)
|
||||
* [Changelog](https://github.com/LazyVim/LazyVim/blob/main/CHANGELOG.md)
|
||||
* [Reddit](https://www.reddit.com/r/neovim/comments/1766fl1/lazyvim%5F1000%5Fhas%5Fbeen%5Freleased/)
|
||||
|
||||
---
|
||||
|
||||
## Contributing
|
||||
|
||||
Add your the plugin in either of the following to be featured in This Week in Neovim and Dotfyle:
|
||||
|
||||
* [rockerBOO/awesome-neovim](https://github.com/rockerBOO/awesome-neovim)
|
||||
* [SUBMITTED\_PLUGINS.md](https://github.com/codicocodes/dotfyle/blob/main/SUBMITTED-PLUGINS.md)
|
||||
|
||||
Contribute to the development of Dotfyle:
|
||||
|
||||
* File issues and submit pull requests on [GitHub](https://github.com/codicocodes/dotfyle)
|
||||
* Discuss ideas on [Discord](https://discord.gg/AMbnnN5eep)
|
||||
|
|
@ -0,0 +1,592 @@
|
|||
---
|
||||
id: 07f91eda-1940-4aaa-8e27-78b0bf176193
|
||||
title: |
|
||||
The Unreasonable Effectiveness Of Plain Text
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-10-18 10:01:51
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/noboilerplate-scripts-34-plain-text-team-md-at-main-0-atman-nobo-18b42e0d185
|
||||
url_original: |
|
||||
https://github.com/0atman/noboilerplate/blob/main/scripts/34-Plain-Text-Team.md
|
||||
---
|
||||
|
||||
# The Unreasonable Effectiveness Of Plain Text
|
||||
|
||||
## Highlights
|
||||
|
||||
## [Tie Yourself to the Mast](#tie-yourself-to-the-mast)
|
||||
|
||||
%%pron. oh diss e us%% In the Odyssey, Odysseus (confusingly called Ulysses in English literature) had to travel through siren-infested waters.
|
||||
|
||||
This was a well-understood problem in his world. Sailors would simply solve this by putting wax in their ears, so the sirens' tempting song wouldn't lure them to their deaths.
|
||||
|
||||
But Odysseus had a challenge: He WANTED to hear the Sirens' beautiful song. He certainly didn't want to drown, so he ordered his crew to tie him to the mast of the ship, and to ignore any of his pleas to let him go, until safety.
|
||||
|
||||
This way, he was able to guard against future bad decisions he knew he would make by setting up a framework to control his future self.
|
||||
|
||||
This is the Ulysses pact, and it's a very common trick:
|
||||
|
||||
* Leaving your credit card or car keys at home when going out drinking is a Ulysses pact.
|
||||
* Publishing a warrant canary on your company's website is a Ulysses pact,
|
||||
* and standardising all your tools on plain text is a Ulysses pact.
|
||||
|
||||
> [!note]
|
||||
> El pacto de Ulysses es una estrategia (o framework) en donde tomamos medidas tempranamente para prevenir malas desiciones en un futuro.
|
||||
|
||||
[source](https://omnivore.app/me/noboilerplate-scripts-34-plain-text-team-md-at-main-0-atman-nobo-18b42e0d185#7466a699-a115-4b9f-99fc-416852b5aef2) #frameworks
|
||||
|
||||
---
|
||||
|
||||
"The difference between science and screwing around is _writing it down_."
|
||||
|
||||
## [— Adam Savage](#-adam-savage)
|
||||
|
||||
> [!note]
|
||||
> This was just a cool quote...
|
||||
|
||||
[source](https://omnivore.app/me/noboilerplate-scripts-34-plain-text-team-md-at-main-0-atman-nobo-18b42e0d185#9a030eb7-6269-4863-8e5e-61b59a1704b6) #quotes
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
<style> :root {--r-code-font: "FiraCode Nerd Font";} .reveal .hljs {min-height: 50%;} </style>
|
||||
|
||||
!\[\[git-logo.png|500\]\]
|
||||
|
||||
## [Plain-Text Team](#plain-text-team)
|
||||
|
||||
notes: %%
|
||||
|
||||
* Tell them what you're going to tell them
|
||||
* Tell them
|
||||
* Tell them what you told them %% Hi friends my name is Tris and this is No Boilerplate, focusing on fast, technical videos.
|
||||
|
||||
All good teams are alike; each bad team is bad in its own way. %% to paraphrase Tolstoy %%
|
||||
|
||||
Software is an incredible thing, isn't it? Combined with the internet, a small team of friends can change the world overnight.
|
||||
|
||||
Every company, no matter what their industry, must now run a tech team, even if only to maintain their website.
|
||||
|
||||
So why are they all so bad at it?
|
||||
|
||||
---
|
||||
|
||||
!\[\[cc-logo.png\]\]
|
||||
|
||||
## [Public Domain Videos](#public-domain-videos)
|
||||
|
||||
<https://github.com/0atman/noboilerplate/>
|
||||
|
||||
notes: Everything you see in this video: script, links, and images are part of a plain-text markdown document available freely on GitHub under a public domain licence.
|
||||
|
||||
---
|
||||
|
||||
## [First World Problems](#first-world-problems)
|
||||
|
||||
notes: If you've worked in a web team, tech team or any digital creative team, you've likely felt the pain.
|
||||
|
||||
* Bad software,
|
||||
* constantly changing processes,
|
||||
* and lots and lots of meetings.
|
||||
|
||||
I discussed some of these problems in my Agile video that made me a lot of friends. But today, I want to go bigger. You can solve all these problems in a single blow.
|
||||
|
||||
The secret is, in order to do more, you must have the discipline to do LESS.
|
||||
|
||||
---
|
||||
|
||||
!\[\[rework-book.png|400\]\]
|
||||
|
||||
!\[\[remote-book.png|400\]\]
|
||||
|
||||
notes:
|
||||
|
||||
A lot of the ideas that I will mention today are not new. They've been well-understood in the startup and digital world for a long time.
|
||||
|
||||
But regression to the mean is prevalent.
|
||||
|
||||
It's not just enough to argue for good tools today, you must stop the future churn of new apps and processes that solve the same things in different, but equivalent ways.
|
||||
|
||||
And you do this with a Ulysses pact.
|
||||
|
||||
---
|
||||
|
||||
!\[\[ulysses-and-the-sirens-waterhouse.jpg\]\]
|
||||
|
||||
_"Ulysses and the Sirens"_ [John William Waterhouse](https://en.wikipedia.org/wiki/John%5FWilliam%5FWaterhouse)
|
||||
|
||||
notes:
|
||||
|
||||
## ==[Tie Yourself to the Mast](#tie-yourself-to-the-mast)==
|
||||
|
||||
==%%pron. oh diss e us%%
|
||||
In the Odyssey, Odysseus (confusingly called Ulysses in English literature) had to travel through siren-infested waters.==
|
||||
|
||||
==This was a well-understood problem in his world.
|
||||
Sailors would simply solve this by putting wax in their ears, so the sirens' tempting song wouldn't lure them to their deaths.==
|
||||
|
||||
==But Odysseus had a challenge: He WANTED to hear the Sirens' beautiful song. He certainly didn't want to drown, so he ordered his crew to tie him to the mast of the ship, and to ignore any of his pleas to let him go, until safety.==
|
||||
|
||||
==This way, he was able to guard against future bad decisions he knew he would make by setting up a framework to control his future self.==
|
||||
|
||||
==This is the Ulysses pact, and it's a very common trick:==
|
||||
|
||||
* ==Leaving your credit card or car keys at home when going out drinking is a Ulysses pact.==
|
||||
* ==Publishing a warrant canary on your company's website is a Ulysses pact,==
|
||||
* ==and standardising all your tools on plain text is a Ulysses pact.==
|
||||
|
||||
---
|
||||
|
||||
!\[\[the-fbi-has-not-been-here.png\]\]
|
||||
|
||||
An example of a warrant canary
|
||||
|
||||
notes:
|
||||
|
||||
In the future, you, or your successor, or your team might well be tempted to try the latest hot project management software, or documentation tool or scrum system.
|
||||
|
||||
While it might be good for a while, the act of changing tools constantly is an enormous overhead for your team, and one that gives the lasting impression that anything we write is likely to be legacy very soon, trapped in a deprecated app that "we just don't use any more", so why bother writing anything down.
|
||||
|
||||
Tying yourself to the mast by standardising on one tool, and not only that, but a plain text tool, means your data will live forever, and the network effect can make it more and more valuable over time, instead of less and less.
|
||||
|
||||
---
|
||||
|
||||
"The greatest problem in communication is the _illusion_ that it has been achieved."
|
||||
|
||||
## [— William H. Whyte](#-william-h-whyte)
|
||||
|
||||
[(not George Bernard Shaw, apparently)](https://quoteinvestigator.com/2014/08/31/illusion/)
|
||||
|
||||
notes:
|
||||
|
||||
## [Decoupled Organisation Through Plain Text](#decoupled-organisation-through-plain-text)
|
||||
|
||||
Teams of people need to be on the same page. Both literally and figuratively.
|
||||
|
||||
The natural way to do this is by talking to one another. But talking does not scale, and is extremely impermanent. After the sound waves have bounced off the walls and reverberated for a second... the words are gone, and what is left is our memory of them.
|
||||
|
||||
---
|
||||
|
||||
=="The difference between science and screwing around is== _==writing it down==_==."==
|
||||
|
||||
## ==[— Adam Savage](#-adam-savage)==
|
||||
|
||||
notes:
|
||||
|
||||
Human memory is extremely unreliable, subjective, and the root cause of many problems.
|
||||
|
||||
After a discussion, it is not apparent that everyone has agreed upon exactly the same thing. And you now need another meeting to double-check that.
|
||||
|
||||
The solution is documentation.
|
||||
|
||||
---
|
||||
|
||||
## [Documentation-First Teams](#documentation-first-teams)
|
||||
|
||||
notes: Communication is most reliable when it is in black and white.
|
||||
|
||||
Everyone understands this, from 10,000-page government specifications to an email sign-off from the client you're making a 3-minute track for.
|
||||
|
||||
Yes, have more immediate conversations, by video, or chat, but write down what you concluded, and get the other person to confirm it.
|
||||
|
||||
---
|
||||
|
||||
## [](#documenting-architecture-decisions)["Documenting Architecture Decisions"](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)
|
||||
|
||||
(aka the _ADR_ process)
|
||||
|
||||
— [Michael Nygard](https://cognitect.com/authors/MichaelNygard.html)
|
||||
|
||||
notes: You can improve every part of your team, business, or organisation by recording what decisions you have made, and WHY, in a system that allows for asynchronous discussion and improvements.
|
||||
|
||||
The ADR process is excellent for this, for example.
|
||||
|
||||
There are a thousand competing apps that claim to solve these problems for you.
|
||||
|
||||
---
|
||||
|
||||
!\[\[gdocs-screenshot.png|200\]\]
|
||||
|
||||
!\[\[jamboard-photo.png|200\]\]
|
||||
|
||||
!\[\[confluence-screenshot.png|200\]\]
|
||||
|
||||
!\[\[pivotal-tracker-screenshot.png|200\]\]
|
||||
|
||||
!\[\[notion-screenshot.png|200\]\]
|
||||
|
||||
!\[\[trello-screenshot.png|200\]\]
|
||||
|
||||
notes: These apps all re-invent the wheel in their own way, and new ones are being released every week. I've used most of them, perhaps you have too, and they're all rubbish.
|
||||
|
||||
But there is a group of people who are extremely practised at managing enormous distributed, concurrent, text projects:
|
||||
|
||||
_Programmers!_
|
||||
|
||||
As an example, if you use Google Docs, your small team can collaborate on a few files a day, in a drive of perhaps a hundred or two hundred. And just like in most other documentation systems, that won't scale.
|
||||
|
||||
Programmers simultaneously edit thousands of files a day, across repositories of data so numerous that we don't keep count.
|
||||
|
||||
What are programmers using, and can non-programmers use it too?
|
||||
|
||||
---
|
||||
|
||||
## [Enter Git](#enter-git)
|
||||
|
||||
* GitHub
|
||||
* GitLab
|
||||
* Bitbucket
|
||||
* SourceForge
|
||||
* Etc.
|
||||
|
||||
notes:
|
||||
|
||||
The answer is yes, yes we can.
|
||||
|
||||
I recommend you use the most popular distributed version control system on the planet: Git.
|
||||
|
||||
You'll use this through one of the many git web hosts, the largest of which is GitHub, which I recommend for most people.
|
||||
|
||||
---
|
||||
|
||||
## [Popularity Matters](#popularity-matters)
|
||||
|
||||
notes:
|
||||
|
||||
Though I mention GitHub primarily in this video, I'm not sponsored by them, or anything like that, I just acknowledge that popularity matters. Support, experience, and integrations with other services will all be far, far easier if you use the standard.
|
||||
|
||||
All these tools started as a web interface around the incredible tool: Git.
|
||||
|
||||
---
|
||||
|
||||
## [Aside:](#aside)
|
||||
|
||||
## [Linux & Git](#linux--git)
|
||||
|
||||
notes: By the way, the creator of Linux, Linus Torvalds, also later created git, to solve the problem that he created: that the Linux project had become SO LARGE that existing plain text collaboration tools were not scaling.
|
||||
|
||||
He jokes that he named his first project, Linux, after himself, and so it was natural to name the second one after himself too!
|
||||
|
||||
---
|
||||
|
||||
## [Github Et Al. Are Greater Than the Sum of Their Parts](#github-et-al-are-greater-than-the-sum-of-their-parts)
|
||||
|
||||
notes: From simple code-hosting beginnings, these git services have grown to be so much more than that, trusted by the largest projects in the world, built by the largest companies in the world.
|
||||
|
||||
The foundation of my ideal team uses the raw materials that GitHub has given us.
|
||||
|
||||
What are the raw materials?
|
||||
|
||||
I'll show you this with a demo: We're going to build a GitHub organisation for No Boilerplate.
|
||||
|
||||
This video is not sponsored by GitHub, my work is possible, thanks to viewers like you.
|
||||
|
||||
---
|
||||
|
||||
!\[\[nb-patreon-aug-23.png|700\]\]
|
||||
|
||||
<https://www.patreon.com/noboilerplate>
|
||||
|
||||
notes:
|
||||
|
||||
If you'd like to see and give feedback on my videos up to a week early, as well as get discord perks, and even your name in the credits, it would be very kind of you to check my Patreon.
|
||||
|
||||
I'm also offering a limited number of mentoring slots. If you'd like 1:1 tuition on Rust, Python, Web tech, Personal organisation, or anything that I talk about in my videos, do sign up and let's chat!
|
||||
|
||||
It's just me running this channel, and I'm so grateful to everyone for supporting me on this wild adventure.
|
||||
|
||||
Let's make our plain text team:
|
||||
|
||||
---
|
||||
|
||||
!\[\[repo.png\]\]
|
||||
|
||||
## [Repos](#repos)
|
||||
|
||||
notes: The foundational unit with any git host is the repo. This doesn't just correspond with one git repository, but one logical project or subproject. Organisational tools like the Wiki (for documentation), Projects (for project management) and more can sit here, right next to your project's files, right where you need them.
|
||||
|
||||
---
|
||||
|
||||
!\[\[wiki2.png\]\]
|
||||
|
||||
## [Wikis](#wikis)
|
||||
|
||||
notes: Each GitHub repository has a wiki, a folder of linked markdown files that anyone with access can edit, either in the friendly web editor, or, by cloning the wiki with git, on their own computer with whatever editor they like.
|
||||
|
||||
This is the minimum viable documentation tool, and it's useful for when git's full collaboration system isn't needed, and you just want to throw some linked markdown files together quickly.
|
||||
|
||||
---
|
||||
|
||||
## [\# This is a Heading](#-this-is-a-heading)
|
||||
|
||||
### [\### This is a Sub Heading](#-this-is-a-sub-heading)
|
||||
|
||||
_\_this is italic text\__
|
||||
|
||||
**\*\*this is bold\*\***
|
||||
|
||||
\[[this is a link](https://github.com/0atman/noboilerplate/blob/main/scripts)\]([http://example.com](http://example.com/))
|
||||
|
||||
_(learn more: [markdownguide.org/basic-syntax/](https://www.markdownguide.org/basic-syntax/))_
|
||||
|
||||
notes:
|
||||
|
||||
## [Aside: Markdown is Great](#aside-markdown-is-great)
|
||||
|
||||
Github, GitLab, and most of the Internet have standardised on Markdown. Just like Slack, Discord, many websites, and sometimes Facebook depending on the phase of the moon, they all format text using this lightweight standard called Markdown.
|
||||
|
||||
Markdown is my favourite text format, it's really simple to use, and is designed to look good both in plain text and rendered as rich text, unlike HTML, which is unreadable by most people unless rendered in a browser.
|
||||
|
||||
Here we've got a heading, denoted by the hash symbol, italic with underscores, bold with double asterisks, and links using this bracket pairing syntax.
|
||||
|
||||
There are a few more options available, which you can look up at markdownguide.org, but this is the overwhelming majority of formatting you'll need on a day-to-day basis.
|
||||
|
||||
---
|
||||
|
||||
!\[\[obsidian-kanban-paint.png\]\]
|
||||
|
||||
notes:
|
||||
|
||||
The genius of storing your data in this universal plain-text format is that should you wish to migrate from GitHub to another similar platform, your data is portable and under your control.
|
||||
|
||||
GitHub formats Markdown very nicely, but you can export it in any format you like, and edit it with any tool you like, present and future.
|
||||
|
||||
Including my favourite tool here, Obsidian.
|
||||
|
||||
Markdown keeps your team focussed on what is important by allowing you just enough formatting, but no rich customisation options. You're not making a beautiful client brochure, so you shouldn't use 90s desktop publishing tools to make your company's critical documentation.
|
||||
|
||||
Back to GitHub's features:
|
||||
|
||||
---
|
||||
|
||||
!\[\[issues.png\]\]
|
||||
|
||||
## [Issues](#issues)
|
||||
|
||||
notes:
|
||||
|
||||
Though not part of the git system, Issues are a natural addition that all git hosts have implemented: A simple task system for capturing work that needs doing. These could be new features, customer requests, bug reports, or ideas. They have a rich comment thread for discussion, can be assigned to team members, and tagged with custom tags.
|
||||
|
||||
This minimum viable project management system could be all you need. Certainly, for a solo or small team, capturing requirements in Issues might be enough.
|
||||
|
||||
But if you need more, you need Milestones.
|
||||
|
||||
---
|
||||
|
||||
!\[\[milestones.png\]\]
|
||||
|
||||
## [Milestones](#milestones)
|
||||
|
||||
notes: GH milestones are a grouping of issues with a deadline.
|
||||
|
||||
They typically represent a target, a release, or something the team is working towards. Milestones just have a title, a description, and a date. No burndown charts, no swim lanes, no complex statistics, just a progress bar.
|
||||
|
||||
This might be enough project management for you. If not, it is time for GH Projects.
|
||||
|
||||
---
|
||||
|
||||
!\[\[projects.png\]\]
|
||||
|
||||
## [Projects](#projects)
|
||||
|
||||
notes:
|
||||
|
||||
Each GitHub repo, team, and organisation can have a project board, a lightweight kanban board with customisable columns, allowing you to group your issues together, and observe their progress through your current iteration.
|
||||
|
||||
This represents the information radiator for your team, a bird's-eye view of what is happening with the project, and something you might gather around for your morning catchup meeting.
|
||||
|
||||
You don't need all the features of Trello, JIRA, or anything like that. You need the minimum viable board.
|
||||
|
||||
This bare-bones tool completely side-steps 'the JIRA effect', which is if you have a tool that is packed full of time tracking, velocity points, and so on, the temptation is to use all these features, even if they give no value, and complicate your processes.
|
||||
|
||||
---
|
||||
|
||||
## [Aside:](#aside-1)
|
||||
|
||||
## [Standups Are Great](#standups-are-great)
|
||||
|
||||
notes:
|
||||
|
||||
If you have one meeting a day, it should be a standup. Good standups replace other meetings and accelerate your project dramatically.
|
||||
|
||||
The way I like to do standups is not by asking everyone what they did yesterday and what they intend to do today.
|
||||
|
||||
That's a great way to find out at length what Dave did on his day off, but not a good way to find out what's happening with the project specifically.
|
||||
|
||||
I recommend walking your board, backwards, from right to left. Everyone is timeboxed, keeping the meeting tight. If you don't have an issue on the board, you don't speak yet. Perhaps you could write or pick up a task from the backlog and talk about it tomorrow.
|
||||
|
||||
At the end, the team member who is facilitating the meeting asks if anyone has any blockers, and we're done.
|
||||
|
||||
The most important part of this most important meeting is asking if you have any blockers. A good standup means that no-one can get lost or delayed by more than 24 hours.
|
||||
|
||||
Note I didn't say the PM or DM or scrum master or whoever facilitates. That person doesn't exist in my team. These are not roles, they are hats.
|
||||
|
||||
I don't know if your team needs any other meetings, but it is vital that you do a standup.
|
||||
|
||||
Back to GitHub.
|
||||
|
||||
---
|
||||
|
||||
!\[\[org-public.png\]\]
|
||||
|
||||
## [Organisations](#organisations)
|
||||
|
||||
notes: GitHub provides an umbrella group of users called an organisation. This is your company, and if you're building your products in the open, as I recommend you do, you won't pay GitHub a thing. Most git hosts provide their services for free for open-source companies. If you have too much money, you can pay GitHub for a plan to make your data closed.
|
||||
|
||||
If you require more subdivision, Organisations are divided into Teams.
|
||||
|
||||
---
|
||||
|
||||
!\[\[teams.png\]\]
|
||||
|
||||
## [Teams](#teams)
|
||||
|
||||
notes:
|
||||
|
||||
Teams on GitHub allow you to granularly scope repo, project, wiki, and other permissions to the different teams in your organisation.
|
||||
|
||||
I recommend allowing everyone to write and contribute to all projects, you want the network effect and low admin overhead. This pattern is called "internal open source".
|
||||
|
||||
But if you wish, perhaps for regulatory reasons, read and write access to repos can be restricted by team.
|
||||
|
||||
---
|
||||
|
||||
!\[\[PR.png\]\]
|
||||
|
||||
## [Pull Requests](#pull-requests)
|
||||
|
||||
notes:
|
||||
|
||||
Now we're getting into the detail of GitHub. I adore pull requests, sometimes called merge requests in other systems. PRs represent a change to the files in a repo, with an explanation of what you did, some links, and a discussion.
|
||||
|
||||
---
|
||||
|
||||
!\[\[PR diff.png\]\]
|
||||
|
||||
## [Pull Requests (diffs)](#pull-requests-diffs)
|
||||
|
||||
notes:
|
||||
|
||||
After the discussion is satisfied, perhaps as simply as a colleague saying "LGTM" or as heavy weight as a full change review with an audit trail that would satisfy a bank, the changes are merged into the repo.
|
||||
|
||||
PRs can have powerful automation, called Actions
|
||||
|
||||
---
|
||||
|
||||
!\[\[action.png\]\]
|
||||
|
||||
## [Github Actions](#github-actions)
|
||||
|
||||
notes:
|
||||
|
||||
PRs and actions can run your company for you if you let them. Though Actions were built for running tests on source code, with a little imagination, they can be used for anything:
|
||||
|
||||
* If you're uploading vector images, an action can build all the rasterised resolutions the client wants.
|
||||
* If you're uploading video or audio clips, an action can run them through plugins to remove noise, add a music track, and upload the draft to YouTube.
|
||||
* If you're checking in company documents, an action can simply spellcheck it.
|
||||
|
||||
Actions can run hundreds of times an hour, always adhere to best practice, and never make mistakes.
|
||||
|
||||
Automating your company gives you an enormous competitive speed and quality advantage.
|
||||
|
||||
---
|
||||
|
||||
!\[\[language-tool-on-premise.png\]\]
|
||||
|
||||
notes: You could also, for example, set up style guide enforcement, blocking the PR if the phrase "on premise" has been found.
|
||||
|
||||
---
|
||||
|
||||
!\[\[nvme.png\]\] notes:
|
||||
|
||||
## [Offline Work](#offline-work)
|
||||
|
||||
When your company's code, visual assets, and administration, are all in git repositories, you gain another huge superpower.
|
||||
|
||||
All of this becomes accessible offline. Every file, every photo, every design, and document can be on your computer. The magic of offline isn't necessarily that you don't need the internet (though that is a handy feature on a plane) But that it's FAST, the data is RIGHT HERE on your computer, and you can do ANYTHING with it. If you need to change the company's name across 10,000 files, it's trivial. It's find and replace.
|
||||
|
||||
If you, instead, had 5-15 different web services that you scattered all your team's data across, you'd have to log in to each one, and hope they had the feature to find and replace within their own walled garden.
|
||||
|
||||
Most, somehow, don't have this basic feature.
|
||||
|
||||
---
|
||||
|
||||
## [Who is flying this thing?](#who-is-flying-this-thing)
|
||||
|
||||
notes:
|
||||
|
||||
GOOGLE DOCS doesn't have this basic feature: you can't find and replace across a drive of files!?
|
||||
|
||||
And the reason for this, I suspect, is that would be TERRIFYING, wouldn't it? What if a new hire accidentally did that, you'd have to roll back all those files manually, that could take days!
|
||||
|
||||
But with git, it would be a PR, clearly showing what was happening, and mistakes are trivial to fix.
|
||||
|
||||
Plain-text files, with just enough Markdown syntax to convey meaning, allow you and your team to work with this data in the way that they want, not the way that google or Atlassian or WHOEVER thinks is best.
|
||||
|
||||
Doesn't this take up a lot of space on your disk? Not plain text. But even if you're storing large files, storage is cheap if you're smart. A topic for another video, perhaps.
|
||||
|
||||
---
|
||||
|
||||
## [Future-Proofing](#future-proofing)
|
||||
|
||||
notes: The benefits of git, especially for teams already using it for code and text collaboration, are that
|
||||
|
||||
1. you're already paying for it, and
|
||||
2. It's never going away.
|
||||
|
||||
It is impossible to imagine a management reshuffle that might decide on another tool just because it is the flavour of the month. Git and GitHub dominate the coding world, and I recommend GitHub not only because it is the biggest but also the most featureful.
|
||||
|
||||
---
|
||||
|
||||
!\[\[killed-by-google-10-23.png\]\]
|
||||
|
||||
[https://killedbygoogle.com](https://killedbygoogle.com/)
|
||||
|
||||
notes:
|
||||
|
||||
Even if you don't think git and plain text are the best option, I still suggest you use them because stability is far, far better than a constantly churning tool choice, as staff come, and go and fashions change, and Google decommission ANOTHER product.
|
||||
|
||||
RIP Jamboard :-(
|
||||
|
||||
---
|
||||
|
||||
## [Conclusion](#conclusion)
|
||||
|
||||
Click around my demo organisation for yourself:<https://github.com/noboilerplate>
|
||||
|
||||
notes:
|
||||
|
||||
You can't do all these utopian things in most companies, I'm painfully aware.
|
||||
|
||||
But you CAN do SOME of these things, even just in your immediate team, or only for yourself.
|
||||
|
||||
I'd be interested to know what other ways good teams buck the hype cycle in favour of sane, evidence-based improvements.
|
||||
|
||||
Thank you.
|
||||
|
||||
---
|
||||
|
||||
!\[\[tri-hex-moon-white-transparent.png|300\]\]
|
||||
|
||||
## [Thank You](#thank-you)
|
||||
|
||||
## [](#patreoncomnoboilerplate)[Patreon.com/NoBoilerplate](http://www.patreon.com/noboilerplate)
|
||||
|
||||
notes:
|
||||
|
||||
## [OUTRO](#outro)
|
||||
|
||||
If you would like to support my channel, get early ad-free and tracking-free videos, vip discord access or 1:1 mentoring, head to patreon.com/noboilerplate.
|
||||
|
||||
If you're interested in transhumanism and hopepunk stories, please check out my weekly sci-fi podcast, Lost Terminal.
|
||||
|
||||
Or if urban fantasy is more your bag, do listen to a strange and beautiful podcast I produce every full moon called Modem Prometheus.
|
||||
|
||||
Transcripts and compile-checked markdown source code are available on GitHub, links in the description, and corrections are in the pinned ERRATA comment.
|
||||
|
||||
Thank you so much for watching, talk to you on Discord.
|
||||
|
||||
%% NOW READ THE INTRO AGAIN %%
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
id: f07b145f-4fc5-4acf-99a4-4e3201c009b9
|
||||
title: |
|
||||
How Game Reviews Actually Affect You
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- Youtube
|
||||
date_added: 2023-10-21 16:01:08
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/how-game-reviews-actually-affect-you-18b539cd3a3
|
||||
url_original: |
|
||||
https://youtu.be/8LbLvi9llCI?si=7MMwTZTpCb-mHDH5
|
||||
---
|
||||
|
||||
# How Game Reviews Actually Affect You
|
||||
|
||||
## Notes
|
||||
|
||||
Según estudios, los jugadores se ven afectados por reviews que leen/ven, ya sean por críticos o por otros jugadores. Destacar que en ambos casos, pero principalmente en otros jugadores hay opiniones que pueden decir lo mismo pero con una altas carga emocional, lo que amplifica su impacto.
|
||||
|
||||
Estas críticas tienen un impacto inconciente en el jugador en forma de _"self fulfilling prophecy"_ ó _"probar lo contrario"_.
|
||||
|
||||
Esto nos afecta queramos o no, por lo que es mejor evitar opiniones lo más posible y solo disfrutar el juego por lo que es, podemos validar nuestras opiniones luego de terminar el juego.
|
||||
## Original
|
||||
|
||||
[How Game Reviews Actually Affect You](https://youtu.be/8LbLvi9llCI?si=7MMwTZTpCb-mHDH5)
|
||||
|
||||
By [Daryl Talks Games](https://www.youtube.com/@DarylTalksGames)
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
---
|
||||
id: bcb6f4ba-cb8e-4e8d-847f-911cda184b83
|
||||
title: |
|
||||
Study shows stronger brain activity after writing on paper than on tablet or smartphone | ScienceDaily
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-10-23 10:56:32
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/study-shows-stronger-brain-activity-after-writing-on-paper-than--18b5cd2abed
|
||||
url_original: |
|
||||
https://www.sciencedaily.com/releases/2021/03/210319080820.htm
|
||||
---
|
||||
|
||||
# Study shows stronger brain activity after writing on paper than on tablet or smartphone | ScienceDaily
|
||||
|
||||
## Highlights
|
||||
|
||||
"Our take-home message is to use paper notebooks for information we need to learn or memorize," said Sakai.
|
||||
|
||||
[source](https://omnivore.app/me/study-shows-stronger-brain-activity-after-writing-on-paper-than--18b5cd2abed#1c9a0a5a-c3a9-40d8-a6de-9e986dd27aec)
|
||||
|
||||
---
|
||||
|
||||
Researchers say that personalizing digital documents by highlighting, underlining, circling, drawing arrows, handwriting color-coded notes in the margins, adding virtual sticky notes, or other types of unique mark-ups can mimic analog-style spatial enrichment that may enhance memory.
|
||||
|
||||
[source](https://omnivore.app/me/study-shows-stronger-brain-activity-after-writing-on-paper-than--18b5cd2abed#85a6ad74-1b87-4f32-95b3-f0a549d32089)
|
||||
|
||||
---
|
||||
|
||||
Although the current research focused on learning and memorization, the researchers encourage using paper for creative pursuits as well.
|
||||
|
||||
"It is reasonable that one's creativity will likely become more fruitful if prior knowledge is stored with stronger learning and more precisely retrieved from memory. For art, composing music, or other creative works, I would emphasize the use of paper instead of digital methods," said Sakai.
|
||||
|
||||
[source](https://omnivore.app/me/study-shows-stronger-brain-activity-after-writing-on-paper-than--18b5cd2abed#aeb79efa-7582-4493-94e1-6a7004b5ed80)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
FULL STORY
|
||||
|
||||
---
|
||||
|
||||
A study of Japanese university students and recent graduates has revealed that writing on physical paper can lead to more brain activity when remembering the information an hour later. Researchers say that the unique, complex, spatial and tactile information associated with writing by hand on physical paper is likely what leads to improved memory.
|
||||
|
||||
"Actually, paper is more advanced and useful compared to electronic documents because paper contains more one-of-a-kind information for stronger memory recall," said Professor Kuniyoshi L. Sakai, a neuroscientist at the University of Tokyo and corresponding author of the research recently published in _Frontiers in Behavioral Neuroscience_. The research was completed with collaborators from the NTT Data Institute of Management Consulting.
|
||||
|
||||
Contrary to the popular belief that digital tools increase efficiency, volunteers who used paper completed the note-taking task about 25% faster than those who used digital tablets or smartphones.
|
||||
|
||||
Although volunteers wrote by hand both with pen and paper or stylus and digital tablet, researchers say paper notebooks contain more complex spatial information than digital paper. Physical paper allows for tangible permanence, irregular strokes, and uneven shape, like folded corners. In contrast, digital paper is uniform, has no fixed position when scrolling, and disappears when you close the app.
|
||||
|
||||
=="Our take-home message is to use paper notebooks for information we need to learn or memorize," said Sakai.==
|
||||
|
||||
In the study, a total of 48 volunteers read a fictional conversation between characters discussing their plans for two months in the near future, including 14 different class times, assignment due dates and personal appointments. Researchers performed pre-test analyses to ensure that the volunteers, all 18-29 years old and recruited from university campuses or NTT offices, were equally sorted into three groups based on memory skills, personal preference for digital or analog methods, gender, age and other aspects.
|
||||
|
||||
Volunteers then recorded the fictional schedule using a paper datebook and pen, a calendar app on a digital tablet and a stylus, or a calendar app on a large smartphone and a touch-screen keyboard. There was no time limit and volunteers were asked to record the fictional events in the same way as they would for their real-life schedules, without spending extra time to memorize the schedule.
|
||||
|
||||
After one hour, including a break and an interference task to distract them from thinking about the calendar, volunteers answered a range of simple (When is the assignment due?) and complex (Which is the earlier due date for the assignments?) multiple choice questions to test their memory of the schedule. While they completed the test, volunteers were inside a magnetic resonance imaging (MRI) scanner, which measures blood flow around the brain. This is a technique called functional MRI (fMRI), and increased blood flow observed in a specific region of the brain is a sign of increased neuronal activity in that area.
|
||||
|
||||
Participants who used a paper datebook filled in the calendar within about 11 minutes. Tablet users took 14 minutes and smartphone users took about 16 minutes. Volunteers who used analog methods in their personal life were just as slow at using the devices as volunteers who regularly use digital tools, so researchers are confident that the difference in speed was related to memorization or associated encoding in the brain, not just differences in the habitual use of the tools.
|
||||
|
||||
Volunteers who used analog methods scored better than other volunteers only on simple test questions. However, researchers say that the brain activation data revealed significant differences.
|
||||
|
||||
Volunteers who used paper had more brain activity in areas associated with language, imaginary visualization, and in the hippocampus -- an area known to be important for memory and navigation. Researchers say that the activation of the hippocampus indicates that analog methods contain richer spatial details that can be recalled and navigated in the mind's eye.
|
||||
|
||||
"Digital tools have uniform scrolling up and down and standardized arrangement of text and picture size, like on a webpage. But if you remember a physical textbook printed on paper, you can close your eyes and visualize the photo one-third of the way down on the left-side page, as well as the notes you added in the bottom margin," Sakai explained.
|
||||
|
||||
Researchers say that personalizing digital documents by highlighting, underlining, circling, drawing arrows, handwriting color-coded notes in the margins, adding virtual sticky notes, or other types of unique mark-ups can mimic analog-style spatial enrichment that may enhance memory.
|
||||
|
||||
Although they have no data from younger volunteers, researchers suspect that the difference in brain activation between analog and digital methods is likely to be stronger in younger people.
|
||||
|
||||
"High school students' brains are still developing and are so much more sensitive than adult brains," said Sakai.
|
||||
|
||||
Although the current research focused on learning and memorization, the researchers encourage using paper for creative pursuits as well.
|
||||
|
||||
"It is reasonable that one's creativity will likely become more fruitful if prior knowledge is stored with stronger learning and more precisely retrieved from memory. For art, composing music, or other creative works, I would emphasize the use of paper instead of digital methods," said Sakai.
|
||||
111
Read Later/2023-10-23 - Train Your Brain to Be More Creative.md
Normal file
111
Read Later/2023-10-23 - Train Your Brain to Be More Creative.md
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
---
|
||||
id: 6f1925bb-b86c-40d2-9363-6784aa2d402f
|
||||
title: |
|
||||
Train Your Brain to Be More Creative
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-10-23 10:56:30
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/train-your-brain-to-be-more-creative-18b5cd2a390
|
||||
url_original: |
|
||||
https://hbr.org/2021/06/train-your-brain-to-be-more-creative
|
||||
---
|
||||
|
||||
# Train Your Brain to Be More Creative
|
||||
|
||||
## Highlights
|
||||
|
||||
## **Engage with nature**
|
||||
|
||||
It’s been proven that [spending time in nature](https://greatergood.berkeley.edu/article/item/how%5Fnature%5Fmakes%5Fyou%5Fkinder%5Fhappier%5Fmore%5Fcreative) makes us more creative. Looking at trees and leaves — instead of our electronic devices — reduces our anxiety, lowers our heart rates, soothes us, and allows our brains to make [connections more easily](https://bjsm.bmj.com/content/49/4/272.abstract?sid=56b97a4c-0e75-46d0-a6ba-41c7f41a089c).
|
||||
|
||||
By spending time in nature, I’m not referring to a trek in the wilderness either. Walking in an urban green space for just 25 minutes can quiet our brains and help us switch into autopilot node. According to the [_British Journal of Sports Medicine_](https://bjsm.bmj.com/content/49/4/272?sid=56b97a4c-0e75-46d0-a6ba-41c7f41a089c), this state sparks our present awareness and fuels imagination. We are more easily able to connect existing notions, thoughts, and images to form a new, relevant, and useable concept.
|
||||
|
||||
[source](https://omnivore.app/me/train-your-brain-to-be-more-creative-18b5cd2a390#9190b653-c9fe-4438-b02d-10ac2095ecd1)
|
||||
|
||||
---
|
||||
|
||||
You may have heard that creativity uses your right brain while your left brain is triggered during more analytical tasks. Well, [neuroscientists have found](https://www.livescience.com/39671-roots-of-creativity-found-in-brain.html) that creativity actually draws on your _entire_ brain — and meditation can you give you access to it.
|
||||
|
||||
[source](https://omnivore.app/me/train-your-brain-to-be-more-creative-18b5cd2a390#6b9b547e-2d87-4b4e-8fb5-76c0fe82be37)
|
||||
|
||||
---
|
||||
|
||||
Try to add workout time on your calendar and make sure not to skip it. If you feel you don’t have time for a dedicated workout, block 20 minutes on your calendar and spend that time doing stretches at your desk.
|
||||
|
||||
[source](https://omnivore.app/me/train-your-brain-to-be-more-creative-18b5cd2a390#339a25cd-d9b8-4c5c-90bb-34f31965dea8)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
[  ](https://hbr.org/ascend)
|
||||
|
||||
Where your work meets your life.
|
||||
|
||||
|
||||
|
||||
Anastasia Usenko/Getty Images
|
||||
|
||||
Creativity isn’t inherent. You have to hone it. Here are a few ways to do that, based on neuroscience. Engage with nature: Looking at trees and leaves, instead of our electronic devices, reduces our anxiety, lowers our heart rates, soothes us, and allows our brains to...
|
||||
|
||||
[](https://hbr.org/insight-center/ascend)
|
||||
|
||||
Where your work meets your life. See more from Ascend [here](https://hbr.org/insight-center/ascend).
|
||||
|
||||
I don’t do ruts.
|
||||
|
||||
Not because I’m some brilliant creative, but because I’ve learned how my brain works. Your brain needs fuel, and it needs to be stretched to create those “OMG!” moments on demand.
|
||||
|
||||
Think about it. Great athletes train their bodies for days, weeks, and years to whip them into peak performance. Why, then, wouldn’t a creator do the same with their brain?
|
||||
|
||||
I’ve spent more than two decades (and counting) in the advertising industry, and contrary to popular belief, creativity isn’t inherent. You have to hone it. Over time, I’ve figured out what I need to do to get ideas flowing freely, and a lot of that insight comes from my interest in neuroscience. The more we learn about the workings of our gray matter, the better we can train it, control it, and make it do what we want.
|
||||
|
||||
Here a few things that have worked for me over the years.
|
||||
|
||||
## **==Engage with nature==**
|
||||
|
||||
==It’s been proven that== ==[spending time in nature](https://greatergood.berkeley.edu/article/item/how%5Fnature%5Fmakes%5Fyou%5Fkinder%5Fhappier%5Fmore%5Fcreative)== ==makes us more creative. Looking at trees and leaves — instead of our electronic devices — reduces our anxiety, lowers our heart rates, soothes us, and allows our brains to make== ==[connections more easily](https://bjsm.bmj.com/content/49/4/272.abstract?sid=56b97a4c-0e75-46d0-a6ba-41c7f41a089c)====.==
|
||||
|
||||
==By spending time in nature, I’m not referring to a trek in the wilderness either. Walking in an urban green space for just 25 minutes can quiet our brains and help us switch into autopilot node. According to the== [_British Journal of Sports Medicine_](https://bjsm.bmj.com/content/49/4/272?sid=56b97a4c-0e75-46d0-a6ba-41c7f41a089c)==, this state sparks our present awareness and fuels imagination. We are more easily able to connect existing notions, thoughts, and images to form a new, relevant, and useable concept.==
|
||||
|
||||
So make disconnecting a priority. Take a walk in your neighborhood park, stroll along the beach, or just add plants to your balcony and spend some time out there. For me, walking my dog — even when my name is not on the family schedule — works. You’ll feel the benefits of moving away from screens almost immediately.
|
||||
|
||||
## **Meditate**
|
||||
|
||||
I know, I know, you’ve heard this a million times: [Meditation](https://www.frontiersin.org/articles/10.3389/fpsyg.2013.01020/full) clears our minds of jumbled thoughts, and gives our brains the space to observe and reflect, improving task concentration and enhancing our ability to make smart decisions.
|
||||
|
||||
But did you know that meditation also puts the entire brain to work?
|
||||
|
||||
==You may have heard that creativity uses your right brain while your left brain is triggered during more analytical tasks. Well,== ==[neuroscientists have found](https://www.livescience.com/39671-roots-of-creativity-found-in-brain.html)== ==that creativity actually draws on your== _==entire==_ ==brain — and meditation can you give you access to it.==
|
||||
|
||||
This intentional practice can be as simple as closing your eyes and focusing on your breath. Headspace, the popular meditation app, even has guided meditations for inspiring creativity. The idea is that when we intentionally pause in awareness, [we allow our minds the freedom and space to be still and creative](https://www.headspace.com/meditation/creativity). I practice this between meetings. I find a quiet space, focus on my breathing, and get my brain into an alpha state, or a wakeful state of relaxation. This allows me to disconnect from my initial ideas (after all, the human brain is hardwired to take the path of least resistance) and create new pathways in my mind.
|
||||
|
||||
## **Get moving**
|
||||
|
||||
[Steve Jobs](https://financialpost.com/executive/c-suite/steve-jobs-was-right-about-walking) was a big advocate for walking meetings for a reason. Moving around [has been linked to increased performance](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1332529/pdf/brjsmed00003-0076.pdf) on creative tests. Exercising releases endorphins — chemicals our bodies produce to relieve stress and pain. When we are less stressed, our brains venture into more fruitful territory.
|
||||
|
||||
In fact, [a recent article](https://www.irishexaminer.com/lifestyle/healthandwellbeing/arid-40251431.html) compared the chemical that our brain releases during physical activity to Miracle-Gro, the water-soluble plant food that helps grow bigger, healthier plants. The good part is moving around is super simple to do, especially when you’re working at home. I often attend meetings while cycling on a stationary bike or plan short walks in between (and this can be done in an office too).
|
||||
|
||||
==Try to add workout time on your calendar and make sure not to skip it. If you feel you don’t have time for a dedicated workout, block 20 minutes on your calendar and spend that time doing stretches at your desk.==
|
||||
|
||||
Find a routine that works for you.
|
||||
|
||||
Ascend
|
||||
|
||||
Career and life advice for young professionals.
|
||||
|
||||
## **Connect with different kinds of people**
|
||||
|
||||
When consciously seeking inspiration, not enough can be said about diversity. Remember the brain and its predisposition to take the lazy way out? Diversity makes the brain work harder [by challenging stereotypes.](https://www.theguardian.com/lifeandstyle/2015/nov/01/diversity-good-for-your-brain-mind-multicultural) In addition, researchers at Johns Hopkins University [found](https://muse.jhu.edu/article/536530/summary) that “exposure to diversity experiences might foster the development of more complex forms of thought, including the ability to think critically.”
|
||||
|
||||
I make it a point to surround myself with people who come from different backgrounds than I do because their perspectives are a catalyst for creative thinking. Contrasting opinions sparks new possibilities, and allow us to make connections we hadn’t seen before, leading to better decisions. There was something to be said about Abraham Lincoln filling his cabinet with [a “team of rivals.”](https://bigthink.com/in-their-own-words/you-can-be-your-own-team-of-rivals) Productive discussions, brainstorms, and debates often result in wiser outcomes. At my agency, we’ve set up an “inspiration council,” which brings together our people from various regions, cultures, genders, and more, to initiate these kind of discussions.
|
||||
|
||||
Today, the distributed working model born out of the pandemic has made it even easier to bring people together. I recommend using social media channels like LinkedIn and Instagram to follow and connect with people who have backgrounds and experiences that diverge from your own. Don’t limit yourself by geography when you’re reaching out to someone or expanding your network. We are much better at creative problem-solving when we don’t have the comfort of knowing what to expect, which can happen if we only surround ourselves with people just like us.
|
||||
|
||||
Use these principles of neuroscience to give your brain the exercise that it needs. It will get you out of any rut. Or prevent you from getting into one in the first place.
|
||||
|
||||
#### Readers Also Viewed These Items
|
||||
|
||||
* [Bas Korsten](https://hbr.org/search?term=bas%20korsten&search%5Ftype=search-all) is the Global Chief Creative Officer at Wunderman Thompson.
|
||||
67
Read Later/2023-10-25 - Let's Get Webby! 🦀 🕸️.md
Normal file
67
Read Later/2023-10-25 - Let's Get Webby! 🦀 🕸️.md
Normal file
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
id: 46eadaec-733a-11ee-aae2-4b1c5b8d8405
|
||||
title: |
|
||||
Let's Get Webby! 🦀 🕸️
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- Newsletter
|
||||
date_added: 2023-10-25 10:27:43
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/let-s-get-webby-18b6705008a
|
||||
url_original: |
|
||||
https://omnivore.app/no_url?q=bec70357-3199-44e0-9c84-40dd5a7bf774
|
||||
---
|
||||
|
||||
# Let's Get Webby! 🦀 🕸️
|
||||
|
||||
## Highlights
|
||||
|
||||
...and front-end frameworks like [Yew](https://letsgetrusty.krtra.com/c/y9r3LFJzeRCp/OQKy) and [Seed](https://letsgetrusty.krtra.com/c/mN30voJhWLXc/OQKy) letting you write web apps in Rust!
|
||||
|
||||
> [!note]
|
||||
> I can create front end web apps with this libraries
|
||||
|
||||
[source](https://omnivore.app/me/let-s-get-webby-18b6705008a#7065ade5-765c-4d60-bd89-1ecb0d919389)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
Hey Alexander,
|
||||
|
||||
JavaScript isn't the fastest language out there.
|
||||
|
||||
In fact, it's **pretty dang slow** compared to C/C++!
|
||||
|
||||
Unfortunately, this limits the type of web apps we could build.
|
||||
|
||||
How great would it be if we could write code that runs **at native speeds** in the browser?
|
||||
|
||||
This would allow computationally intensive apps like video editors, AAA games, and IDEs to be run in the browser!
|
||||
|
||||
Great news... **this is possible today** with the help of WebAssembly.
|
||||
|
||||
WebAssembly or WASM for short, is a technology that allows code written in languages such as C/C++, Java, Swift, and Rust to run in the browser at native speeds!
|
||||
|
||||
**And Rust has first-class support for WASM!**
|
||||
|
||||
With crates such as [wasm-bindgen ](https://letsgetrusty.krtra.com/c/Fv1n9JiwhxdT/OQKy)facilitating high-level interactions between Rust and JavaScript...
|
||||
|
||||
==...and front-end frameworks like== ==[Yew](https://letsgetrusty.krtra.com/c/y9r3LFJzeRCp/OQKy)== ==and== ==[Seed](https://letsgetrusty.krtra.com/c/mN30voJhWLXc/OQKy)== ==letting you write web apps in Rust!==
|
||||
|
||||
Are you ready to give Rust + WASM a try?
|
||||
|
||||
Check out this video I made: **[\>> Building a Rust App with Yew! <<](https://letsgetrusty.krtra.com/c/6AUVThScIsa4/OQKy)**
|
||||
|
||||
Have you built any WASM projects in Rust? Let me know!
|
||||
|
||||
Stay Rusty my friend!
|
||||
|
||||
Bogdan, Let's Get Rusty
|
||||
|
||||
**[Website](https://letsgetrusty.krtra.com/c/FBKvcPOtTzlF/OQKy)** | **[YouTube](https://letsgetrusty.krtra.com/c/4KIGD3ocszdT/OQKy)**
|
||||
|
||||
© Copyrights by Let's Get Rusty. All Rights Reserved.
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
---
|
||||
id: ad8a0732-733a-11ee-b2ab-13f1d6012322
|
||||
title: |
|
||||
What the Rust Book didn't tell you about testing...
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- Newsletter
|
||||
date_added: 2023-10-25 10:30:35
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/what-the-rust-book-didn-t-tell-you-about-testing-18b6707a120
|
||||
url_original: |
|
||||
https://omnivore.app/no_url?q=1fed5fd7-7706-46cf-9947-927b26a77112
|
||||
---
|
||||
|
||||
# What the Rust Book didn't tell you about testing...
|
||||
|
||||
## Highlights
|
||||
|
||||
We want to test _get\_user_ without making real database queries.
|
||||
|
||||
The solution is to mock the _Database_ trait and assert _execute\_query_ is called with the correct query. But how?
|
||||
|
||||
We can use the [mockall crate](https://letsgetrusty.us6.list-manage.com/track/click?u=9f28b35c1658c447f3b962a54&id=00a07042b3&e=d0eb971086)!
|
||||
|
||||
[source](https://omnivore.app/me/what-the-rust-book-didn-t-tell-you-about-testing-18b6707a120#f9650419-c778-4974-9da2-aabce209609f)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
The Rust Book has an [entire chapter dedicated to testing](https://letsgetrusty.us6.list-manage.com/track/click?u=9f28b35c1658c447f3b962a54&id=a95a715235&e=d0eb971086), but it's missing a critical piece…
|
||||
|
||||
What happens when your code needs to make API calls or database queries?
|
||||
|
||||
Unit tests should be be fast, reliable, and deterministic.
|
||||
|
||||
We don't want to make expensive calls that might fail for various reasons.
|
||||
|
||||
|
||||
Well here is some good news… we don't have to!
|
||||
|
||||
We can use mocking to substitute real objects for mock objects and assert certain expectations…
|
||||
|
||||
What's that? You want an example? Consider the following code…
|
||||
|
||||
trait Database {
|
||||
fn execute_query(&self, query: String);
|
||||
}
|
||||
|
||||
fn get_user(db: impl Database, id: i32) {
|
||||
let query = format!("SELECT * from Users where id={}", id);
|
||||
db.execute_query(query);
|
||||
}
|
||||
We want to test _get\_user_ without making real database queries.
|
||||
|
||||
The solution is to mock the _Database_ trait and assert _execute\_query_ is called with the correct query. But how?
|
||||
|
||||
We can use the [mockall crate](https://letsgetrusty.us6.list-manage.com/track/click?u=9f28b35c1658c447f3b962a54&id=00a07042b3&e=d0eb971086)!
|
||||
|
||||
Here is how we would test _get\_user_…
|
||||
|
||||
#[cfg(test)]
|
||||
use mockall::{automock, predicate::*};
|
||||
|
||||
#[cfg_attr(test, automock)]
|
||||
trait Database {
|
||||
fn execute_query(&self, query: String);
|
||||
}
|
||||
|
||||
fn get_user(db: impl Database, id: i32) {
|
||||
let query = format!("SELECT * from Users where id={}", id);
|
||||
db.execute_query(query);
|
||||
}
|
||||
|
||||
#[cfg(test)]
|
||||
mod tests {
|
||||
use super::*;
|
||||
|
||||
#[test]
|
||||
fn get_user_executes_correct_query() {
|
||||
let mut mock_database = MockDatabase::new();
|
||||
mock_database.expect_execute_query()
|
||||
.with(eq("SELECT * from Users where id=22".to_owned()))
|
||||
.once()
|
||||
.returning(|_x| ());
|
||||
|
||||
get_user(mock_database, 22);
|
||||
}
|
||||
}
|
||||
Boom! Now we have a unit test that's fast, reliable, and deterministic!
|
||||
|
||||
If you haven't seen my [intro to testing in Rust video](https://letsgetrusty.us6.list-manage.com/track/click?u=9f28b35c1658c447f3b962a54&id=90d4167901&e=d0eb971086) make sure to check it out!
|
||||
|
||||
|
||||
Happy testing, and stay Rusty!
|
||||
76
Read Later/2023-10-31 - Use cases for Rust.md
Normal file
76
Read Later/2023-10-31 - Use cases for Rust.md
Normal file
|
|
@ -0,0 +1,76 @@
|
|||
---
|
||||
id: 7b7ae540-77ef-11ee-9aed-e318464fef5a
|
||||
title: |
|
||||
Use cases for Rust
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- Newsletter
|
||||
date_added: 2023-10-31 10:14:54
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/use-cases-for-rust-18b85df6f3a
|
||||
url_original: |
|
||||
https://omnivore.app/no_url?q=9e2f3a10-e4fd-4c33-85a3-ff3609f3c4d6
|
||||
---
|
||||
|
||||
# Use cases for Rust
|
||||
|
||||
## Highlights
|
||||
|
||||
Some popular server-side web frameworks written in Rust include Actix Web, Warp, and Axum.
|
||||
|
||||
[source](https://omnivore.app/me/use-cases-for-rust-18b85df6f3a#64793bd7-d3bd-4597-9f2c-9b4697217661)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
Hi Rustaceans,
|
||||
|
||||
Rust is fast, safe and hip.
|
||||
|
||||
But, what can you actually build with Rust?
|
||||
|
||||
…whether you want to use Rust professionally or as a hobbyist.
|
||||
|
||||
Here are a few common types of applications built using Rust:
|
||||
|
||||
**Blockchain**
|
||||
|
||||
* Rust is a great choice for blockchain applications because it is fast and secure.
|
||||
* You can write both smart contracts and entire blockchains using Rust.
|
||||
* Some popular blockchain projects written in Rust include Solana, Polkadot, and Near.
|
||||
|
||||
**Embedded programs**
|
||||
|
||||
* Rust is also well-suited for embedded programs, such as those used in cars, airplanes, and other devices.
|
||||
* This is because Rust is memory-safe, memory-efficient and can be compiled to run on a variety of platforms.
|
||||
|
||||
**Server-side applications / Microservices**
|
||||
|
||||
* Rust is a great choice for server-side applications and microservices because it is fast and efficient.
|
||||
* ==Some popular server-side web frameworks written in Rust include Actix Web, Warp, and Axum.==
|
||||
* Many companies are migrating their critical microservices to Rust because of its safety and performance guarantees.
|
||||
|
||||
**WebAssembly**
|
||||
|
||||
* Rust can be compiled to WebAssembly, which means that you can use Rust to build web applications.
|
||||
* Rust’s small runtime and first-class support for WebAssembly often make it the first contender for any WebAssembly projects.
|
||||
|
||||
This is only a small sample of what you can build in Rust.
|
||||
|
||||
In general, Rust is a great choice if you are looking for speed, safety and versatility.
|
||||
|
||||
If you want more details, here’s a YouTube video I made on the same topic.
|
||||
|
||||
**[\>>> What can you build in Rust?!](https://letsgetrusty.krtra.com/c/BgXaOx7YGua4/OQKy)**
|
||||
|
||||
Have fun building!
|
||||
|
||||
Bogdan
|
||||
|
||||
\---
|
||||
|
||||
PS - Looking for a Rust job? Apply here - [https://letsgetrusty.com/jobs](https://letsgetrusty.krtra.com/c/ysWbInNFr59c/OQKy)
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
id: e41b4086-963e-45e7-9ef7-2cfee7061047
|
||||
title: |
|
||||
Why Signals Are Better Than React Hooks
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-01 14:16:42
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-youtu-be-so-8-l-bvwf-2-y-8-si-zy-gl-ie-hl-ai-pg-w-5-xo-18b8be328e5
|
||||
url_original: |
|
||||
https://youtu.be/SO8lBVWF2Y8?si=zyGlIeHlAiPgW5Xo
|
||||
---
|
||||
|
||||
# Why Signals Are Better Than React Hooks
|
||||
|
||||
## Notes
|
||||
|
||||
Signals ayuda a la performance y legibilidad de una aplicación haciendo que la funcionalidades que normalmente se realizarían con los hooks `useState` y `useEffect` se realizen dentro de `signals`.
|
||||
|
||||
Esto permite compartir este _"estado"_ entre componentes pero solo actualizar los involucrados y no todos los desendientes del componente mayor.
|
||||
|
||||
Además, podemos extraer toda la lógica del estado a un archivo aparte que solo tenga código relevante, y en los componentes se mantiene solo la implementación.
|
||||
|
||||
Es obviamente más rápido de implementar y más limpio que hacer custom hooks, pero es añadir otra dependencia, habrá otras ventajas y desventajas??
|
||||
## Original
|
||||
|
||||
[Why Signals Are Better Than React Hooks](https://youtu.be/SO8lBVWF2Y8?si=zyGlIeHlAiPgW5Xo)
|
||||
|
||||
By [Web Dev Simplified](https://www.youtube.com/@WebDevSimplified)
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
---
|
||||
id: 24bd8d1e-b118-4930-a86d-3929f2dad34c
|
||||
title: |
|
||||
The First Rule of Comments in Code
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-02 23:25:19
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-youtu-be-hxsx-3-vbf-qq-si-c-5-qy-m-mg-8-j-yhc-bbq-18b92ffccf6
|
||||
url_original: |
|
||||
https://youtu.be/hxsx3vbf-QQ?si=-C5QyMMg8JYhcBBQ
|
||||
---
|
||||
|
||||
# The First Rule of Comments in Code
|
||||
|
||||
## Notes
|
||||
|
||||
Comments are bad by nature:
|
||||
- They get outdated pretty quickly, and you don't know if the comments is updated with the code.
|
||||
- A comments is most probably noise, because it's not gonna provide more information than the code itself.
|
||||
- Commented code is broken code, because it's probably outdated compared to it's context.
|
||||
|
||||
Some rules to evade writing comments:
|
||||
|
||||
**Code that needs a comment, needs to be rewritten**. Always try to put the information in the code. if it needs a comment, it's not good enough.
|
||||
|
||||
**Move information somewhere else**. this is similar to the previous, move to a variable name, or to a documentation file in the worst case.
|
||||
|
||||
**How quickly the information will goes out of date**. It's so simple that a comments goes out of sync with the code, to prevent that transform the comment in code.
|
||||
|
||||
**If a comment gives no more information than the code, delete it**.
|
||||
|
||||
**"I need to explain the complexity"**. No, you need to fix the complexity. If the complexity is so big, put in the documentation instead. A comment cannot fix complexity, and will require hard work to change that code.
|
||||
|
||||
**Don't comment out code, delete it**. Commented code goes quickly out of sync with it's context, is not tested in any way and the effort of updating it is almost the same if not higher that writing it over with better knowledge, so it's better to just delete it. If we need this code back, we can recover it with git.
|
||||
## Original
|
||||
|
||||
[The First Rule of Comments in Code](https://youtu.be/hxsx3vbf-QQ?si=-C5QyMMg8JYhcBBQ)
|
||||
|
||||
By [Bran van der Meer](https://www.youtube.com/@branvandermeer)
|
||||
|
|
@ -0,0 +1,266 @@
|
|||
---
|
||||
id: 88b1e080-79be-11ee-b19c-971f00999697
|
||||
title: |
|
||||
Web Accessibility Tips for Developers – A11y Principles Explained
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- RSS
|
||||
date_added: 2023-11-02 11:17:51
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5
|
||||
url_original: |
|
||||
https://www.freecodecamp.org/news/web-accessibility-for-devs/
|
||||
---
|
||||
|
||||
# Web Accessibility Tips for Developers – A11y Principles Explained
|
||||
|
||||
## Highlights
|
||||
|
||||
you can provide captions for audio and video materials.
|
||||
|
||||
[source](https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5#a243f9e5-2cf7-437b-afdb-725d69408fa5)
|
||||
|
||||
---
|
||||
|
||||
color contrast for text and background
|
||||
|
||||
[source](https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5#7da331b9-d92c-40b1-b9ff-03cd350b19e0)
|
||||
|
||||
---
|
||||
|
||||
it's a good idea to include descriptive alternative text (alt text) for images, explaining what they depict and their purpose.
|
||||
|
||||
[source](https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5#c2a6ebd3-44b3-4bac-b723-be08ec3191d3)
|
||||
|
||||
---
|
||||
|
||||
You should also describe your icon buttons.
|
||||
|
||||
[source](https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5#644def06-75fc-41b3-ad64-8b0eb34eb055)
|
||||
|
||||
---
|
||||
|
||||
First, make sure you use clear and consistent headings.
|
||||
|
||||
[source](https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5#5d22dea1-4451-4052-a211-ffbc432cb3be)
|
||||
|
||||
---
|
||||
|
||||
And make sure you think about [keyboard accessibility](https://www.freecodecamp.org/news/designing-keyboard-accessibility-for-complex-react-experiences/) so users can navigate and communicate using the keyboard, and not exclusively using a mouse.
|
||||
|
||||
[source](https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5#a6f33320-f395-41f2-92e4-7e5c70337377)
|
||||
|
||||
---
|
||||
|
||||
Organize content using headings, subheadings, and bullet points to enhance readability.
|
||||
|
||||
> [!note]
|
||||
> Use semantic HTML
|
||||
|
||||
[source](https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5#d6c8b9dc-b9e7-4ab7-8b53-0057246fea9a)
|
||||
|
||||
---
|
||||
|
||||
* Use [HTML5 semantic elements](https://www.freecodecamp.org/news/semantic-html-alternatives-to-using-divs/) like ``, ``, ``, and `` to enhance the document's structure.
|
||||
* Ensure that your [JavaScript code is efficient](https://www.freecodecamp.org/news/javascript-performance-async-defer/) and doesn't block the rendering process.
|
||||
* Utilize [browser developer tools](https://www.freecodecamp.org/news/learn-how-to-use-the-chrome-devtools-to-troubleshoot-websites/) and online testing services to identify and fix compatibility issues.
|
||||
* Conduct [usability testing](https://www.freecodecamp.org/news/10-best-ux-testing-software-tools/) with a diverse group of users, including those who rely on assistive technologies, to gather feedback and make improvements.
|
||||
* Optimize your website for fast loading times and low data usage using techniques like [caching](https://www.freecodecamp.org/news/a-detailed-guide-to-pre-caching/) and [tools like CDNs](https://www.freecodecamp.org/news/cdns-speed-up-performance-by-reducing-latency/) to reduce latency. This benefits both accessibility and user experience.
|
||||
* Document your code and accessibility features for future maintainers.
|
||||
* Test [website compatibility across various browsers](https://www.freecodecamp.org/news/cross-browser-compatibility-testing-best-practices-for-web-developers/). Testing website compatibility involves ensuring that your website functions correctly and looks good on a variety of devices, browsers, and assistive technologies.
|
||||
|
||||
[source](https://omnivore.app/me/web-accessibility-tips-for-developers-a-11-y-principles-explaine-18b91ba16e5#ade773c1-f3e3-499b-8b34-c9d8a2c084e3)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
Accessibility isn't just something you check off as done when you're building websites and web apps. It's a basic part of making the online world a better and fairer place for everyone.
|
||||
|
||||
In this article, you'll learn what accessibility means, and why it's important to make accessibility a part of your regular workflow. I'll also give you practical tips with examples to make your websites more accessible.
|
||||
|
||||
Let's explore the key parts of web accessibility together and help you make a website that includes everyone.
|
||||
|
||||
## What is Web Accessibility?
|
||||
|
||||
[Web accessibility](https://www.freecodecamp.org/news/accessibility-best-practices-to-make-web-apps-accessible/) refers to the practice of designing and developing websites, applications, and digital content in a way that ensures people with disabilities can perceive, understand, navigate, and interact with them effectively.
|
||||
|
||||
## Principles of Web Accessibility
|
||||
|
||||
To effectively enhance the accessibility of your websites and apps, you'll want to follow these fundamental principles outlined by the Web Content Accessibility Guidelines ([WCAG](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0)):
|
||||
|
||||
### Is it Perceivable?
|
||||
|
||||
Content should be displayed in a manner that all users can understand, regardless of their sensory abilities. Here are some ways you can make your content more perceivable:
|
||||
|
||||
First, ==you can provide captions for audio and video materials.== Adding captions to your website or application allows those with hearing disabilities to understand the information being shared, and make the content more accessible to everyone.
|
||||
|
||||
You can see an example of adding captions to a video in the image below:
|
||||
|
||||
|
||||
|
||||
Image of a video illustrating the use of captions.
|
||||
|
||||
Next, make sure you use proper ==color contrast for text and background== elements.
|
||||
|
||||
Colors are an important part of a website, and we can describe them in terms of hue, lightness, and saturation.
|
||||
|
||||
There are several categories of colors which include warm colors, cool colors, and neutral colors
|
||||
|
||||
**Warm Colors:** Warm colors include red, orange, and yellow, and variations of
|
||||
those three colors. These are the colors of fire, fall leaves, sunsets, and sunrises, and are generally energizing, passionate, and positive.
|
||||
|
||||
**Cool Colors:** Cool colors include green, blue, and purple, are often more
|
||||
subdued than warm colors. They are the colors of night, water, of nature, and are usually calming, relaxing, and somewhat reserved.
|
||||
|
||||
**Neutral Colors:** Neutral colors often serve as the backdrop in design. They’re
|
||||
commonly combined with brighter accent colors. But they can also be used on their own in designs and can create very sophisticated layouts. Neutral colors include black, white, gray, cream, and beige.
|
||||
|
||||
Examples of colors that will make good contrast are white and blue, purple and white, yellow and white, light purple and black, green and white, black and white, and so on – basically any colors that are different enough from each other to create that contrast.
|
||||
|
||||
Examples of colors that will make a bad contrast are gray and white, brown and orange, red and purple, and so on.
|
||||
|
||||
Here is an example that shows good color contrast that's easy to read:
|
||||
|
||||
|
||||
|
||||
Image illustrating good contrast using a dark blue background with white text
|
||||
|
||||
And here's an image with poor color contrast that's hard to read:
|
||||
|
||||
|
||||
|
||||
Image Illustrating bad contrast using a white background with light grey text
|
||||
|
||||
Also, ==it's a good idea to include descriptive alternative text (alt text) for images, explaining what they depict and their purpose.==
|
||||
|
||||
So for example, when you want to add an image to your website, you can add alt text to it explaining what it depicts.
|
||||
|
||||
Here is a markup description of how to add alt text to an image:
|
||||
|
||||
```routeros
|
||||
<img src="Dog.png" alt="Image of a dog">
|
||||
|
||||
```
|
||||
|
||||
Here is an example that shows an image of two (2) dogs:
|
||||
|
||||
|
||||
|
||||
Image of two dogs
|
||||
|
||||
And here's an example of an image that illustrates the use of alt text:
|
||||
|
||||
|
||||
|
||||
Image of dog with alt text displayed
|
||||
|
||||
==You should also describe your icon buttons.==
|
||||
|
||||
Icons can be easily understood most of the time. It's widely recognized that an x symbol, like this ❌, typically closes a window, a check mark ✅ signifies completion, a forward arrow ▶ signifies send (or play), and a plus sign ➕ represents addition.
|
||||
|
||||
But this is clear only for individuals with visual capabilities. For people who aren't able to see the buttons, you'll need to provide a description so they know what that button does.
|
||||
|
||||
Let's take a look at this HTML and CSS code that shows how to make buttons access:
|
||||
|
||||
Document
|
||||
|
||||
Here's the result of the code implemented above:
|
||||
|
||||
|
||||
|
||||
### Is it Operable?
|
||||
|
||||
Users should be able to navigate and interact with the interface quickly. Consider the following factors:
|
||||
|
||||
==First, make sure you use clear and consistent headings.==
|
||||
|
||||
This is what clear and consistent headings look like:
|
||||
|
||||
## I am a Title
|
||||
|
||||
## I am a Subtitle
|
||||
|
||||
### This is heading 3
|
||||
|
||||
#### This is Heading 4
|
||||
|
||||
##### This is Heading 5
|
||||
|
||||
###### This is heading 6
|
||||
|
||||
As you can see, these headings go from largest to smallest in order. We have an H1 heading first, followed by H2, H3, and so on.
|
||||
|
||||
Here are some headings that don't follow the proper hierarchy:
|
||||
|
||||
###### This is heading 6
|
||||
|
||||
##### This is Heading 5
|
||||
|
||||
#### This is Heading 4
|
||||
|
||||
### This is heading 3
|
||||
|
||||
## I am a Subtitle
|
||||
|
||||
## I am a Title
|
||||
|
||||
In this example, the headings go in reverse order, starting from H6 and moving up through H5, H4, and so on.
|
||||
|
||||
Just remember to use proper heading hierarchy – don't use an H2 and then jump straight to H4 for a subheading, for example, as this is visually jarring and doesn't convey the proper importance or hierarchy of the text.
|
||||
|
||||
Here's why heading hierarchy is important:
|
||||
|
||||
* A clear heading hierarchy helps readers easily navigate and understand the content of a document.
|
||||
* Heading hierarchy is crucial for accessibility, as it helps screen readers and assistive technologies interpret the structure of the content. This is important for individuals with visual impairments who rely on such tools to access information.
|
||||
* A well-organized heading hierarchy implement a logical flow of information, ensuring that topics are presented in a coherent order.
|
||||
|
||||
Also, refrain from using elements that might trigger physical discomfort, like bright flashing lights.
|
||||
|
||||
==And make sure you think about== ==[keyboard accessibility](https://www.freecodecamp.org/news/designing-keyboard-accessibility-for-complex-react-experiences/)== ==so users can navigate and communicate using the keyboard, and not exclusively using a mouse.==
|
||||
|
||||
### Is it Understandable?
|
||||
|
||||
Content and functionality should be presented clearly and understandably. Consider the following factors:
|
||||
|
||||
* ==Organize content using headings, subheadings, and bullet points to enhance readability.==
|
||||
* Provide instructions and error messages that are easy to understand.
|
||||
* Use simple and concise language, avoid complex terms.
|
||||
|
||||
### Is it Robust?
|
||||
|
||||
Websites should be built using robust and widely supported technologies to enable compatibility across devices and assistive technologies.
|
||||
|
||||
You'll want to maximize compatibility with current and future user agents, including assistive technologies.
|
||||
|
||||
Here are some of the ways you can maximize compatibility with current and future agents, including assistive tools:
|
||||
|
||||
* ==Use== ==[HTML5 semantic elements](https://www.freecodecamp.org/news/semantic-html-alternatives-to-using-divs/)== ==like== `==<====header====>==`==,== `==<====nav====>==`==,== `==<====main====>==`==, and== `==<====footer====>==` ==to enhance the document's structure.==
|
||||
* ==Ensure that your== ==[JavaScript code is efficient](https://www.freecodecamp.org/news/javascript-performance-async-defer/)== ==and doesn't block the rendering process.==
|
||||
* ==Utilize== ==[browser developer tools](https://www.freecodecamp.org/news/learn-how-to-use-the-chrome-devtools-to-troubleshoot-websites/)== ==and online testing services to identify and fix compatibility issues.==
|
||||
* ==Conduct== ==[usability testing](https://www.freecodecamp.org/news/10-best-ux-testing-software-tools/)== ==with a diverse group of users, including those who rely on assistive technologies, to gather feedback and make improvements.==
|
||||
* ==Optimize your website for fast loading times and low data usage using techniques like== ==[caching](https://www.freecodecamp.org/news/a-detailed-guide-to-pre-caching/)== ==and== ==[tools like CDNs](https://www.freecodecamp.org/news/cdns-speed-up-performance-by-reducing-latency/)== ==to reduce latency. This benefits both accessibility and user experience.==
|
||||
* ==Document your code and accessibility features for future maintainers.==
|
||||
* ==Test== ==[website compatibility across various browsers](https://www.freecodecamp.org/news/cross-browser-compatibility-testing-best-practices-for-web-developers/)====. Testing website compatibility involves ensuring that your website functions correctly and looks good on a variety of devices, browsers, and assistive technologies.==
|
||||
|
||||
Here are the steps you can follow to test website compatibility effectively:
|
||||
|
||||
1. **Device Testing**: Test your website on various devices, such as desktop computers, laptops, tablets, and smartphones. This includes both iOS and Android devices.
|
||||
2. **Browser Testing**: Check your website's performance and appearance on multiple browsers, including but not limited to Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge.
|
||||
3. **User Testing**: Conduct usability testing with real users. Ask them to use your website on different devices and browsers and collect feedback on compatibility issues.
|
||||
4. **Performance Testing**: Assess website loading times, and optimize for speed using tools like Google PageSpeed Insights, GTmetrix, or Lighthouse. Check for compatibility with slow internet connections.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Understanding web accessibility can enhance the user experience by creating a smooth and seamless interaction with websites and web applications.
|
||||
|
||||
Implementing these tips can improve the overall user-friendliness and navigability of your app. It'll help create a more enjoyable experience for all users, and will also allow people with disabilities to perceive, understand, navigate, and interact with your sites effectively.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. [Get started](https://www.freecodecamp.org/learn/)
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
---
|
||||
id: fc51bf82-66d3-451f-8f64-17d6add50f92
|
||||
title: |
|
||||
Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir?
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- Youtube
|
||||
date_added: 2023-11-04 14:14:49
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-www-youtube-com-watch-pp-yg-ukz-2-l-0-ih-nxd-w-fza-a-253-d-18b9b548407
|
||||
url_original: |
|
||||
https://www.youtube.com/watch?pp=ygUKZ2l0IHNxdWFzaA%253D%253D&v=HlmZLXMOpEM
|
||||
---
|
||||
|
||||
# Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir?
|
||||
|
||||
## Notes
|
||||
|
||||
- Merge commit: Se crea un commit que tiene 2 padres, el último commit de main y la feature branch, se mantiene la trazabilidad hacia la feature branch pero el historial queda visualmente más complejo
|
||||
- Rebase: Se copian los commits de la feature branch a main como nuevos commits, se pierde la trazabilidad hacia la feature branch pero queda un historial lineal en main
|
||||
- Squash commit: Se juntan todos los commits en uno solo con un squash que queda en main, se pierde la trazabilidad hacia la feature branch pero queda un historial lineal en main
|
||||
## Original
|
||||
|
||||
[Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir?](https://www.youtube.com/watch?pp=ygUKZ2l0IHNxdWFzaA%253D%253D&v=HlmZLXMOpEM)
|
||||
|
||||
By [CodelyTV - Redescubre la programación](https://www.youtube.com/@CodelyTV)
|
||||
|
|
@ -0,0 +1,402 @@
|
|||
---
|
||||
id: 616d5d08-7d04-11ee-8eaa-9f56108b78ec
|
||||
title: |
|
||||
How to Write Components that Work in Any Framework
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- RSS
|
||||
date_added: 2023-11-06 17:25:12
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/how-to-write-components-that-work-in-any-framework-18ba72d0079
|
||||
url_original: |
|
||||
https://www.freecodecamp.org/news/write-components-that-work-in-any-framework/
|
||||
---
|
||||
|
||||
# How to Write Components that Work in Any Framework
|
||||
|
||||
## Highlights
|
||||
|
||||
With Custom Elements you can author your own custom HTML elements that you can reuse across your site. They can be as simple as text, images, or visual decorations. You can push them further and build interactive components, complex widgets, or entire web applications.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-write-components-that-work-in-any-framework-18ba72d0079#bceef8c0-728e-422a-aed6-b047736cb395)
|
||||
|
||||
---
|
||||
|
||||
### Writing a web component requires understanding all of its underlying technologies
|
||||
|
||||
As we saw above, web components are made up of three technologies. You can also see in the hello world code snippet, that we explicitly need to know and understand these three technologies.
|
||||
|
||||
1. We’re creating a **template element** and setting its inner HTML
|
||||
2. We’re creating a **shadow root**, and explicitly setting its mode to ‘open’.
|
||||
3. We’re cloning our **template** and appending it to our **shadow root**
|
||||
4. We’re registering a new **custom element** to the document
|
||||
|
||||
[source](https://omnivore.app/me/how-to-write-components-that-work-in-any-framework-18ba72d0079#46fc130a-1549-40c8-b950-42035c227bc4)
|
||||
|
||||
---
|
||||
|
||||
As web component authors, we need to consider a lot of things:
|
||||
|
||||
* Setting up the shadow DOM
|
||||
* Setting up the HTML templates
|
||||
* Cleaning up event listeners
|
||||
* Defining properties that we want to observe
|
||||
* Reacting to properties when they change
|
||||
* Handling type conversions for attributes
|
||||
|
||||
[source](https://omnivore.app/me/how-to-write-components-that-work-in-any-framework-18ba72d0079#855f444c-49f1-4176-9537-aaeeb6a01355)
|
||||
|
||||
---
|
||||
|
||||
One such tool is called Lit, which is developed by a team at Google. [Lit](https://lit.dev/) is a lightweight library designed to make writing web components simple, by removing the need for the boilerplate we’ve already seen above.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-write-components-that-work-in-any-framework-18ba72d0079#385d9ef8-13fb-4799-bff5-ef767b3df67f)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
The browser has a built-in way of writing reusable components in the form of **web components**. They’re an excellent choice for building interactive and reusable components that work in any frontend framework.
|
||||
|
||||
With that said, writing highly interactive and robust web components isn’t simple. They require a lot of boilerplate and feel much less intuitive than the components you may have written in frameworks like React, Svelte, or Vue.
|
||||
|
||||
In this tutorial, I’ll give you an example of an interactive component written as a web component, and then refactor it using a library that softens the edges and removes heaps of boilerplate.
|
||||
|
||||
Don’t sweat it if you’re not familiar with web components. In the next section, I’ll do a (brief) overview of what web components are, and what they’re made out of. If you have some basic experience with them, you can skip the next section.
|
||||
|
||||
## What are Web Components?
|
||||
|
||||
Before web components, the browser didn’t have a standard way of writing reusable components. Many libraries solve this problem, but they often run into limitations like performance, interoperability, and issues with web standards.
|
||||
|
||||
Web components are a technology made up of 3 different browser features:
|
||||
|
||||
* Custom elements
|
||||
* Shadow DOM
|
||||
* HTML Templates
|
||||
|
||||
We’ll do a quick crash course covering these technologies, but it’s by no means a comprehensive breakdown.
|
||||
|
||||
### What are Custom Elements?
|
||||
|
||||
==With Custom Elements you can author your own custom HTML elements that you can reuse across your site. They can be as simple as text, images, or visual decorations. You can push them further and build interactive components, complex widgets, or entire web applications.==
|
||||
|
||||
You’re not just limited to using them in your projects, but you can publish them and allow other developers to use them on their sites.
|
||||
|
||||
Here are some of the reusable components from my library [A2K](https://a2000-docs.netlify.app/). You can see that they come in all shapes and sizes, and have a range of different functionalities. Using them in your projects is similar to using any old HTML element.
|
||||
|
||||
|
||||
|
||||
A small collection of web components from the A2K library
|
||||
|
||||
Here’s how you’d use the progress element in your project:
|
||||
|
||||
```xml
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Quick Start</title>
|
||||
<meta charset="UTF-8" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<!-- Use web components in your HTML like regular built-in elements. -->
|
||||
<a2k-progress progress="50" />
|
||||
|
||||
<!-- a2k web components use standard JavaScript modules. -->
|
||||
<script type="module">
|
||||
import 'https://cdn.jsdelivr.net/npm/@a2000/progress@0.0.5/lib/src/a2k-progress.js';
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
```
|
||||
|
||||
Once you’ve imported the third-party scripts, you can start using the component, `a2k-progress` in this case, just like any other HTML element.
|
||||
|
||||
If you’re building your own web components, there’s virtually no limit to how complex you can make your custom elements.
|
||||
|
||||
I recently created a web component that renders a CodeSandbox code editor in the browser. And because it’s a web component, you can use it in any framework you like! If you’d like to learn a little more about that, [you can read more here](https://component-odyssey.com/articles/00-sandpack-lit-universal).
|
||||
|
||||
### What is the Shadow DOM?
|
||||
|
||||
If you have a working knowledge of CSS, you’ll know that vanilla CSS is scoped globally. Writing something like this in your global.css:
|
||||
|
||||
```css
|
||||
p {
|
||||
color: tomato;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
will give all `p` elements a nice orange/red color, assuming that no other, more specific CSS selectors are applied to a `p` element.
|
||||
|
||||
Take this select menu, for example:
|
||||
|
||||
|
||||
|
||||
It has a distinct character which is driven by the visual design. You might want to use this component, but if your global styles affect things like the font family, the color, or the font size, it could cause issues with the appearance of the component:
|
||||
|
||||
```xml
|
||||
<head>
|
||||
<style>
|
||||
body {
|
||||
color: blue;
|
||||
font-size: 12px;
|
||||
font-family: system-ui;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<a2k-select></a2k-select>
|
||||
</body>
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
This is where the Shadow DOM comes in. The Shadow DOM is an encapsulation mechanism that prevents the rest of the DOM from interfering with your web components. It ensures that the global styles of the web application don’t interfere with any components that you consume. It also means that component library developers can author their components with the confidence that they’ll look and behave as expected across different web applications.
|
||||
|
||||
There’s a lot more nuance when it comes to the Shadow DOM, as well as other features that we’re not going to touch on in this article. If you’d like to learn more about web components though, I have an entire course ([Component Odyssey](https://component-odyssey.com/)) dedicated to teaching you how to build reusable components that work in any framework.
|
||||
|
||||
### HTML Templates
|
||||
|
||||
The last feature in our whistle-stop tour of web component features is HTML Templates.
|
||||
|
||||
What makes this HTML element different from other elements, is that the browser doesn’t render its content to the page. If you were to write the following HTML you wouldn’t see the text “I’m a header” displayed on the page:
|
||||
|
||||
```xml
|
||||
<body>
|
||||
<template>
|
||||
<h1>I'm a header</h1>
|
||||
</template>
|
||||
</body>
|
||||
|
||||
```
|
||||
|
||||
Instead of being used to render the content directly, the content of the template is designed to be copied. The copied template can then be used to render content to the page.
|
||||
|
||||
You can think of the template element much like the template for a 3D print. The template isn’t a physical entity, but it’s used to create real-life clones.
|
||||
|
||||
You would then reference the template element in your web component, clone it, and render the clone as the markup for your component.
|
||||
|
||||
I won’t spend any more time on these web component features, but you’ve probably already noticed that to write vanilla web components, there are a lot of new browser features that you need to know and understand.
|
||||
|
||||
You’ll see in the next section that the mental model for building web components doesn’t feel as streamlined as it does for other component frameworks.
|
||||
|
||||
## How to Build a Basic Web Component
|
||||
|
||||
Now that we’ve briefly covered the fundamental technologies powering a web component, here’s how to build a _hello world_ component:
|
||||
|
||||
```scala
|
||||
const template = document.createElement('template');
|
||||
template.innerHTML = `<p>Hello World</p>`;
|
||||
|
||||
class HelloWorld extends HTMLElement {
|
||||
constructor() {
|
||||
super();
|
||||
this.attachShadow({ mode: 'open' });
|
||||
this.shadowRoot.append(template.content.cloneNode(true));
|
||||
}
|
||||
}
|
||||
|
||||
customElements.define('hello-world', HelloWorld);
|
||||
|
||||
```
|
||||
|
||||
This is the most simple component you can write, but there’s already so much going on. For someone completely new to web components, and without the background knowledge I provided above, they’re going to be left with a lot of questions, and a lot of confusion.
|
||||
|
||||
For me, there are at least two key reasons why web components can be challenging to write, at least within the context of the hello world examples.
|
||||
|
||||
### The markup is decoupled from the component logic
|
||||
|
||||
In many frameworks, the markup of the component is often treated as a first-class citizen. It’s often the content that gets returned from the component function, or has direct access to the component’s state, or has built-in utilities to help manipulate markup (like loops, conditionals, and so on).
|
||||
|
||||
This isn’t the case for web components. In fact, the markup is often defined outside of the component’s class. There’s also no built-in way for the template to reference the current state of the component. This becomes a cumbersome limitation as the complexity of a component grows.
|
||||
|
||||
In the world of frontend, components are designed to help developers reuse markup in several pages. As a result, the markup and the component logic are inextricably linked, and so they should be colocated with one another.
|
||||
|
||||
### ==Writing a web component requires understanding all of its underlying technologies==
|
||||
|
||||
==As we saw above, web components are made up of three technologies. You can also see in the hello world code snippet, that we explicitly need to know and understand these three technologies.==
|
||||
|
||||
1. ==We’re creating a== **==template element==** ==and setting its inner HTML==
|
||||
2. ==We’re creating a== **==shadow root==**==, and explicitly setting its mode to ‘open’.==
|
||||
3. ==We’re cloning our== **==template==** ==and appending it to our== **==shadow root==**
|
||||
4. ==We’re registering a new== **==custom element==** ==to the document==
|
||||
|
||||
There’s nothing inherently wrong with this, since web components are supposed to be a “lower-level” browser API, making them prime for building abstractions on top of. But for a developer coming from a React or a Svelte background, having to understand these new browser features, and then having to write components with them can feel like too much friction.
|
||||
|
||||
## More Advanced Web Components
|
||||
|
||||
Let’s take a look at a more advanced web component, a counter button.
|
||||
|
||||
|
||||
|
||||
You click the button, and the counter increments.
|
||||
|
||||
The following example contains a few extra web component concepts, like lifecycle functions and observable attributes. You don’t need to understand everything going on in the code snippet. This example is really only used to illustrate how much boilerplate is required for the most basic of interactive interfaces, a counter button:
|
||||
|
||||
```kotlin
|
||||
const templateEl = document.createElement("template");
|
||||
|
||||
templateEl.innerHTML = `
|
||||
<button>Press me!</button>
|
||||
<p>You pressed me 0 times.</p>
|
||||
`;
|
||||
|
||||
export class OdysseyButton extends HTMLElement {
|
||||
constructor() {
|
||||
super();
|
||||
this.attachShadow({ mode: "open" });
|
||||
this.shadowRoot.appendChild(templateEl.content.cloneNode(true));
|
||||
this.button = this.shadowRoot.querySelector("button");
|
||||
this.p = this.shadowRoot.querySelector("p");
|
||||
this.setAttribute("count", "0");
|
||||
}
|
||||
|
||||
// Note: Web components have lifecycle methods,
|
||||
// If we're setting event listeners when the component is added to the DOM, it's our job to clean
|
||||
// them up when it gets removed from the DOM
|
||||
connectedCallback() {
|
||||
this.button.addEventListener("click", this.handleClick);
|
||||
}
|
||||
|
||||
disconnectedCallback() {
|
||||
this.button.removeEventListener("click", this.handleClick);
|
||||
}
|
||||
|
||||
// Unlike frameworks like React, Web Components don't automatically rerender when a prop (or attribute)
|
||||
// changes. Instead, we need to explicitly define which attributes we want to observe.
|
||||
static get observedAttributes() {
|
||||
return ["disabled", "count"];
|
||||
}
|
||||
|
||||
// When one of the above attributes changes, this lifecycle method runs, and we can
|
||||
// react to the new attribute's value accordingly.
|
||||
attributeChangedCallback(name, _, newVal) {
|
||||
if (name === "count") {
|
||||
this.p.innerHTML = `You pressed me ${newVal} times.`;
|
||||
}
|
||||
if (name === "disabled") {
|
||||
this.button.disabled = true;
|
||||
}
|
||||
}
|
||||
|
||||
// In HTML, attribute values are always strings. This means that it's our job to
|
||||
// convert types. You can see below that we're converting a string -> number, and then back to a string
|
||||
handleClick = () => {
|
||||
const counter = Number(this.getAttribute("count"));
|
||||
this.setAttribute("count", `${counter + 1}`);
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
==As web component authors, we need to consider a lot of things:==
|
||||
|
||||
* ==Setting up the shadow DOM==
|
||||
* ==Setting up the HTML templates==
|
||||
* ==Cleaning up event listeners==
|
||||
* ==Defining properties that we want to observe==
|
||||
* ==Reacting to properties when they change==
|
||||
* ==Handling type conversions for attributes==
|
||||
|
||||
And there are still so many other things to consider that I haven’t touched on in this article.
|
||||
|
||||
That isn’t to say that web components are bad and that you shouldn’t write them. In fact, I’d argue that you learn so much about the browser platform by building with them.
|
||||
|
||||
But I feel that there are better ways to write components if your priority is to write interoperable components in a much more streamlined and ergonomic way.
|
||||
|
||||
## How to Write Web Components with Less Boilerplate
|
||||
|
||||
As I mentioned earlier, there are a lot of tools out there to help make writing web components much easier.
|
||||
|
||||
==One such tool is called Lit, which is developed by a team at Google.== ==[Lit](https://lit.dev/)== ==is a lightweight library designed to make writing web components simple, by removing the need for the boilerplate we’ve already seen above.==
|
||||
|
||||
As we’ll see, Lit does a lot of heavy lifting under-the-hood to help cut down the total lines of code by nearly half! And because Lit is a wrapper around web components and other native browser features, all your existing knowledge about web components is transferable.
|
||||
|
||||
To start seeing how Lit simplifies your web components. Here’s the **hello world** example from earlier, but refactored to use Lit instead of a vanilla web component:
|
||||
|
||||
```scala
|
||||
import { LitElement, html } from "lit";
|
||||
|
||||
export class HelloWorld extends LitElement {
|
||||
render() {
|
||||
return html`<p>Hello World!</p>`;
|
||||
}
|
||||
}`
|
||||
|
||||
customElements.define('hello-world', HelloWorld);
|
||||
|
||||
```
|
||||
|
||||
There’s a lot less boilerplate with the Lit component, and Lit handles the two problems I mentioned earlier, a little bit differently. Let’s see how:
|
||||
|
||||
1. The markup is directly defined from within the component class. While you can define your templates outside of the class, it’s common practice to return the template from the `render` function. This is more in line with the mental model presented in other UI frameworks, where the UI is a function of the state.
|
||||
2. Lit also doesn’t require developers to attach the shadow DOM, or create templates and clone template elements. While having an understanding of the underlying web component features will help when developing Lit components, they’re not required for getting started, so the barrier for entry is much lower.
|
||||
|
||||
So now for the big finale, what does the counter component look like once we’ve migrated it over to Lit?
|
||||
|
||||
```typescript
|
||||
import { LitElement, html } from "lit";
|
||||
|
||||
export class OdysseyCounter extends LitElement {
|
||||
static properties = {
|
||||
// We define the component's properties as well as their type.
|
||||
// These properties will trigger the component to re-render when their values change.
|
||||
// While they're not the same, you can think of these "properties" as being
|
||||
// Lit's alternatives to "observed attributes"
|
||||
// If the value is passed down as an attribute, Lit converts the value
|
||||
// to the correct type
|
||||
count: { type: Number },
|
||||
disabled: { type: Boolean },
|
||||
};
|
||||
|
||||
constructor() {
|
||||
super();
|
||||
// There's no need to create a shadow DOM, clone the template,
|
||||
// or store references to our DOM nodes.
|
||||
this.count = 0;
|
||||
}
|
||||
|
||||
onCount() {
|
||||
this.count = this.count + 1;
|
||||
}
|
||||
|
||||
render() {
|
||||
// Instead of using the attributeChangedCallback lifecycle, the
|
||||
// render function has access to all of the component's properties,
|
||||
// which simplifies the process of manipulating our templates.
|
||||
return html`
|
||||
<button ?disabled=${this.disabled} @click=${this.onCount}>
|
||||
Press me!
|
||||
</button>
|
||||
<p>You pressed me ${this.count} times.</p>
|
||||
`;
|
||||
}
|
||||
}`
|
||||
|
||||
```
|
||||
|
||||
The amount of code we’re writing is cut down by almost half! And this difference becomes more noticeable when creating more complex user interfaces.
|
||||
|
||||
## Why am I going on about Lit?
|
||||
|
||||
I’m a big believer in web components, but I recognise that the barrier to entry is high for many developers. Writing complex web components requires understanding heaps of browser features and the education around web components isn’t as comprehensive as other technologies, like React or Vue.
|
||||
|
||||
This is why I think it’s important to use tools like Lit can make writing performant and interoperable web components much easier. This is great if you want your components to work within any frontend framework.
|
||||
|
||||
If you’d like to learn even more, this is the approach I teach in my upcoming course [Component Odyssey](https://component-odyssey.com/). This course is excellent for anyone who wants to understand how to write components that work in any framework.
|
||||
|
||||
I do this by covering the absolute basics of web components, before moving on to tools like Lit that simplify the process of writing web components without complicating your development environment. By the end, you’ll learn how to build and publish a component library that works across any frontend framework.
|
||||
|
||||
If you want early-bird discount codes for Component Odyssey, then head on [over to the site to get notified](https://component-odyssey.com/subscribe).
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. [Get started](https://www.freecodecamp.org/learn/)
|
||||
479
Read Later/2023-11-07 - How to Avoid Prop Drilling in React.md
Normal file
479
Read Later/2023-11-07 - How to Avoid Prop Drilling in React.md
Normal file
|
|
@ -0,0 +1,479 @@
|
|||
---
|
||||
id: aceac380-7e10-11ee-992a-432064e77190
|
||||
title: |
|
||||
How to Avoid Prop Drilling in React
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- RSS
|
||||
- react
|
||||
date_added: 2023-11-07 19:58:39
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2
|
||||
url_original: |
|
||||
https://www.freecodecamp.org/news/avoid-prop-drilling-in-react/
|
||||
---
|
||||
|
||||
# How to Avoid Prop Drilling in React
|
||||
|
||||
## Highlights
|
||||
|
||||
Prop drilling occurs when a parent component generates its state and passes it down as `props` to its children components that do not consume the props – instead, they only pass it down to another component that finally consumes it.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#05db3def-4e59-4cfe-b8dd-1044ce91a9d5)
|
||||
|
||||
---
|
||||
|
||||
First of all, **grouping static elements and dependent components** together to achieve an appealing UI design is the major cause of prop drilling. You can't avoid prop drilling when your UI groups static elements and dependent components together in a parent. The parent component clearly won't use the `prop`, as everything within it is a static element – except the component that needs a prop.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#fa2c28c0-1b7e-4416-8553-c1b5c7a59637)
|
||||
|
||||
---
|
||||
|
||||
Second of all, when a **component accepts `props` that it doesn't use but merely passes it down to its children**, this is a sign that you have prop drilling in your component:
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#6749a89e-a38c-4f4f-aa3f-c6455e6daf85)
|
||||
|
||||
---
|
||||
|
||||
Third, when a component that represents an independent section of a page is **forced to take props from its parent**, prop drilling is inevitable. It should ideally be self-contained with its state and operations.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#751d81de-62b7-444b-a2f0-a0b374f6ce45)
|
||||
|
||||
---
|
||||
|
||||
And finally, **the presence of elongated `props`** is a sure sign of prop drilling. Since an elongated prop is a fundamental element that's consistently present in every case of prop drilling, grasping this concept allows you to instinctively avoid prop drilling.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#90f807ca-03a3-4804-bcf1-c5df4e53a997)
|
||||
|
||||
---
|
||||
|
||||
Component composition is a good approach to fix prop drilling. If you ever find yourself in a situation where a component passes down a prop it neither creates nor consumes, you can use component composition to fix it.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#0112181f-34b7-4ca3-b941-f1c16303c6c0)
|
||||
|
||||
---
|
||||
|
||||
To avoid prop drilling in this case, any grandchildren components that require access to the same `props`, especially when their parent don't consume the data, should be passed as children ensuring that the data remains within the `App` context.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#c17f1d4e-8f5c-45d1-9078-fe8ab740e11e)
|
||||
|
||||
---
|
||||
|
||||
Prop drilling can also be fixed by moving state to where it is consumed. The example of prop drilling in this article has a component named `Content`. But the component is forced to receive a `prop` from its parent instead of having a state and be an independent component – and so we have prop drilling.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#9f94fd13-9558-4bd3-a60c-60074b3495d2)
|
||||
|
||||
---
|
||||
|
||||
It's essential to highlight what to avoid when dealing with prop drilling to prevent unnecessary challenges.
|
||||
|
||||
* **Avoid React Context, if possible, to fix prop drilling.** This approach ties your component to a specific context, restricting its usability outside of that context and hindering composition and reusability.
|
||||
* **Steer clear of redundant components by employing a children-parent replacement approach.** This approach naturally incorporates [component composition](https://www.codementor.io/@dinerismail/the-power-of-component-composition-in-react-21goassg4m) without introducing redundant components or states when resolving prop drilling.
|
||||
|
||||
[source](https://omnivore.app/me/how-to-avoid-prop-drilling-in-react-18bae0b4ca2#8ff7b79b-5503-4e1a-b7fe-1a07a46c578c)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
In order to write scalable, reusable, and maintainable applications with React, you'll need to go beyond the surface of using React components, useEffect, useContext, useState, and the like. It involves learning in detail how React works in more depth.
|
||||
|
||||
And if you don't properly understand these key React concepts, you can run into various issues, like [prop drilling](https://www.quora.com/What-is-prop-drilling-in-ReactJS).
|
||||
|
||||
In this tutorial, you'll learn what prop drilling is. I'll also teach you how to intuitively avoid it without relying on React context. In the end, you'll understand how to identify prop drilling without thinking and fix it with precision.
|
||||
|
||||
If you prefer a visual guide, here's a video version of this tutorial on my [YouTube channel](https://youtu.be/KZnQ5R8Kd4I) (approximately 15 minutes).
|
||||
|
||||
[](https://www.youtube.com/embed/ELZZnqHJhlw)
|
||||
|
||||
## What is Prop Drilling?
|
||||
|
||||
==Prop drilling occurs when a parent component generates its state and passes it down as== `==props==` ==to its children components that do not consume the props – instead, they only pass it down to another component that finally consumes it.==
|
||||
|
||||
Below is an example of prop drilling in React:
|
||||
|
||||
```xquery
|
||||
function App() {
|
||||
const [profile, setProfile] = useState({ame: 'John'});
|
||||
return (
|
||||
<div> <Header profile={profile} />
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function Header({ profile }) {
|
||||
return (
|
||||
<header>
|
||||
<h1>This is the header</h1>
|
||||
<Content profile={profile} />
|
||||
</header>
|
||||
);
|
||||
}
|
||||
|
||||
function Content({ profile }) {
|
||||
return (
|
||||
<main>
|
||||
<h2>Content Component</h2>
|
||||
<p>{profile.name}</p>
|
||||
</main>
|
||||
);
|
||||
}
|
||||
|
||||
export default App;
|
||||
```
|
||||
|
||||
If you check out the example above, you'll notice that `profile` is passed from the `App` component through the `Header` to the `Content` component, which eventually makes use of the `props`. This is commonly referred to as prop drilling as the `Header` component doesn't consume the `prop` but only passes it down to the `Content` component that finally consumes it.
|
||||
|
||||
Now that you understand what prop drilling is, the next challenge is to figure out how to avoid it because it's not always an intuitive process.
|
||||
|
||||
You'll need to start exploring methods to address it. While you can use component composition and React context to resolve it, the challenge lies in not always recognizing the issue until later.
|
||||
|
||||
To truly master the art of handling prop drilling intuitively, you must learn how to identify elongated props and contexts.
|
||||
|
||||
## What is an Elongated Prop?
|
||||
|
||||
|
||||
|
||||
Photo by [Emily Morter](https://unsplash.com/@emilymorter?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
|
||||
|
||||
An elongated prop is a `prop` that is not consumed but it is only passed down to another component. When a component receives a `prop` from its parent and doesn't consume the `prop`, it passes the prop down to another component. This prop is called elongated prop because it has been extended.
|
||||
|
||||
Whenever you see a `prop` being passed down by components that neither creates nor consumes the `prop`, you have an an elongated prop (as well as prop drilling) in your code. The code snippet below is an example:
|
||||
|
||||
```javascript
|
||||
function Profile({ user }) {
|
||||
return (
|
||||
<header>
|
||||
<h1>This is the header</h1>
|
||||
<Content user={user} />
|
||||
</header>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
`user`, in this example, is an elongated `prop` as it is neither created nor consumed by the `Profile` component. Instead, it is only passed down to the `Content` component. And that means we have extended `user` through a component that doesn't need it so that it can get to the one that does.
|
||||
|
||||
Now, let's revisit the example we used to illustrate prop drilling. Wait, are you thinking what I'm thinking? The `prop` that's being passed down in the prop drilling example is indeed an elongated prop, right? Yes, you've got it.
|
||||
|
||||
```xquery
|
||||
function App() {
|
||||
const [profile, setProfile] = useState({ame: 'John'});
|
||||
return (
|
||||
<div>
|
||||
<Header profile={profile} />
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function Header({ profile }) {
|
||||
return (
|
||||
<header>
|
||||
<h1>This is the header</h1>
|
||||
<Content profile={profile} />
|
||||
</header>
|
||||
);
|
||||
}
|
||||
|
||||
function Content({ profile }) {
|
||||
return (
|
||||
<main>
|
||||
<h2>Content Component</h2>
|
||||
<p>{profile.name}</p>
|
||||
</main>
|
||||
);
|
||||
}
|
||||
|
||||
export default App;
|
||||
```
|
||||
|
||||
In the code above, you can observe that the `prop` passed to `Header` is created in the `App` component. Then, `Header` passes it down to its child component named `Content`. As a result, the `profile` being passed down can be considered elongated because it is passed through a component (`Header`) that neither creates nor consumes it down to the one that does.
|
||||
|
||||
The `Header` component passing down the `prop` it doesn't create or need is unnecessarily stretching the context of the `prop`.
|
||||
|
||||
Now, the question is, how do elongated props help to intuitively avoid prop drilling in React? They make it easy for you to spot `props` being used where they're are neither created nor consumed.
|
||||
|
||||
Rather than focusing on how to solve prop drilling, elongated props enable you to avoid it. This is because it's intuitive to recognize when a component neither creates nor consumes `props`, and that helps you to know the component is irrelevant.
|
||||
|
||||
But before you learn how to quickly avoid prop drilling with your understanding of elongated props, it is important that you know the main causes of prop drilling. Then you'll truly know how to avoid it without thinking about it.
|
||||
|
||||
## What Causes Prop Drilling?
|
||||
|
||||
|
||||
|
||||
Photo by [Etienne Girardet](https://unsplash.com/@etiennegirardet?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
|
||||
|
||||
Prop drilling doesn't occur out of thin air. It's a consequence of inadequate component organization, and it is not a React problem. It is a thinking or design problem.
|
||||
|
||||
You won't encounter an instance of prop drilling without observing one of the following layout mistakes:
|
||||
|
||||
==First of all,== **==grouping static elements and dependent components==** ==together to achieve an appealing UI design is the major cause of prop drilling. You can't avoid prop drilling when your UI groups static elements and dependent components together in a parent. The parent component clearly won't use the== `==prop==`==, as everything within it is a static element – except the component that needs a prop.==
|
||||
|
||||
Here's an example:
|
||||
|
||||
```javascript
|
||||
function Header({ profile }) {
|
||||
return (
|
||||
<header>
|
||||
<h1>This is the header</h1>
|
||||
<Content profile={profile} />
|
||||
</header>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
In this case, static elements `<header> and <h1>` are grouped with a dependent component `Content` – and that's why we have prop drilling therein.
|
||||
|
||||
Provided that the `Content` component is independent or takes no `props`, it won't need `profile` and there won't be prop drilling in the first place. This is why forcing a component that should be independent to take `props` from its parent is a recipe for prop drilling in React.
|
||||
|
||||
==Second of all, when a== **==component accepts== `==props==` ==that it doesn't use but merely passes it down to its children==**==, this is a sign that you have prop drilling in your component:==
|
||||
|
||||
```php
|
||||
function App () {
|
||||
const [profile, setProfile] = useState({name: "Ayobami"})
|
||||
return (
|
||||
<>
|
||||
<Parent profile={profile} />
|
||||
</>
|
||||
);
|
||||
};
|
||||
|
||||
function Parent({ profile }) {
|
||||
return (
|
||||
<div>
|
||||
<Hero profile={profile} />
|
||||
<Features profile={profile} />
|
||||
</div>
|
||||
);
|
||||
};
|
||||
```
|
||||
|
||||
In this case there is prop drilling because the `Parent` component takes `profile` and it doesn't use it though it passes it down to its children.
|
||||
|
||||
==Third, when a component that represents an independent section of a page is== **==forced to take props from its parent==**==, prop drilling is inevitable. It should ideally be self-contained with its state and operations.==
|
||||
|
||||
The exception would be if it's intentionally tied to its parent for specific reasons. In such cases, prop drilling becomes a necessary trade-off.
|
||||
|
||||
If you revisit the example of prop drilling cited in this article, you will realize it has a prop drilling issue because the `Content` component which could have been an independent component by having a state is forced to receive props from its parent.
|
||||
|
||||
==And finally,== **==the presence of elongated== `==props==`** ==is a sure sign of prop drilling. Since an elongated prop is a fundamental element that's consistently present in every case of prop drilling, grasping this concept allows you to instinctively avoid prop drilling.==
|
||||
|
||||
When you spot an elongated prop, you can be certain that one of the other three mistakes is also in play. In short, an elongated prop is a prop that is not consumed and is also passed down to another component.
|
||||
|
||||
So grouping static elements with dependent components, forcing components to take props, elongated props, and receiving a prop without consuming it are the signs to recognize prop drilling in React.
|
||||
|
||||
## How to Fix Prop Drilling with Component Composition
|
||||
|
||||
==Component composition is a good approach to fix prop drilling. If you ever find yourself in a situation where a component passes down a prop it neither creates nor consumes, you can use component composition to fix it.==
|
||||
|
||||
But to use component composition, you need to understand a component context.
|
||||
|
||||
### What is a component context?
|
||||
|
||||
The context of a component encompasses everything that is visible within it, including state, props, and children. The following code further illustrates this concept:
|
||||
|
||||
```javascript
|
||||
function App() {
|
||||
const [profile, setProfile] = useState({name: 'Ayobami'});
|
||||
return (
|
||||
<div>
|
||||
<Header profile={profile} />
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
export default App;
|
||||
```
|
||||
|
||||
In this scenario, the context of `App` refers to everything we can see within the `App` component – including the `profile` prop, the `Header`, and other `App` content. Therefore, any data created in the `App` component should ideally be utilized within the `App` component itself, either as its own data or as `props` to its children.
|
||||
|
||||
Prop drilling always emerges when the children receiving the `props` doesn't consume it but only passes it down to its children.
|
||||
|
||||
==To avoid prop drilling in this case, any grandchildren components that require access to the same== `==props==`==, especially when their parent don't consume the data, should be passed as children ensuring that the data remains within the== `==App==` ==context.==
|
||||
|
||||
```javascript
|
||||
export function App() {
|
||||
const [profile, setProfile] = useState({name: 'Ayobami'});
|
||||
return (
|
||||
<div>
|
||||
<Header>
|
||||
<Content profile={profile} />
|
||||
</Header>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
**`Or`**
|
||||
|
||||
```javascript
|
||||
export function App() {
|
||||
const [profile, setProfile] = useState({name: 'Ayobami'});
|
||||
return (
|
||||
<div>
|
||||
<Header children={<Content profile={profile} />} >
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
As you can see, we have resolved the prop drilling issue in the previous example, even though we still have a redundant component, `<Header>`, right? We've successfully addressed prop drilling through component composition.
|
||||
|
||||
This process is quite straightforward because we concentrate on recognizing elongated props and repositioning them within appropriate contexts.
|
||||
|
||||
The concept of prop drilling is problem-focused, but prop elongation is solution-driven. When dealing with elongated props, our primary goal is to identify props that are not consumed but only passed down to another components.
|
||||
|
||||
## How to Fix Prop Drilling by Moving State to the Consumer
|
||||
|
||||
==Prop drilling can also be fixed by moving state to where it is consumed. The example of prop drilling in this article has a component named== `==Content==`==. But the component is forced to receive a== `==prop==` ==from its parent instead of having a state and be an independent component – and so we have prop drilling.==
|
||||
|
||||
We can fix the prop drilling in this case by moving the profile state to where it is consumed.
|
||||
|
||||
Let's revisit the example:
|
||||
|
||||
```xquery
|
||||
function App() {
|
||||
const [profile, setProfile] = useState({ame: 'John'});
|
||||
return (
|
||||
<div>
|
||||
<Header profile={profile} />
|
||||
<Footer profile={profile />
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function Header({ profile }) {
|
||||
return (
|
||||
<header>
|
||||
<h1>This is the header</h1>
|
||||
<Content profile={profile} />
|
||||
</header>
|
||||
);
|
||||
}
|
||||
|
||||
function Content({ profile }) {
|
||||
return (
|
||||
<main>
|
||||
<h2>Content Component</h2>
|
||||
<p>{profile.name}</p>
|
||||
</main>
|
||||
);
|
||||
}
|
||||
|
||||
export default App;
|
||||
```
|
||||
|
||||
We can fix prop drilling in this case by moving `profile` to where it is consumed:
|
||||
|
||||
```javascript
|
||||
function App() {
|
||||
return (
|
||||
<div>
|
||||
<Header />
|
||||
<Footer profile={profile />
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function Header() {
|
||||
return (
|
||||
<header>
|
||||
<h1>This is the header</h1>
|
||||
<Content />
|
||||
</header>
|
||||
);
|
||||
}
|
||||
|
||||
function Content({ profile }) {
|
||||
const [profile, setProfile] = useState({ame: 'John'});
|
||||
return (
|
||||
<main>
|
||||
<h2>Content Component</h2>
|
||||
<p>{profile.name}</p>
|
||||
</main>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
Now that we have lifted the profile to the `Content` component where it is consumed, the `App` component doesn't have a state, while the `Header` component doesn't receive a prop again as the `Content` component has its state.
|
||||
|
||||
But wait! There is a problem. The `Footer` component needs the state we moved away from `App`. There you are! That is the problem with lifting or moving state to where we think it is needed. In this case, if the `Footer` component doesn't need it, we won't have any issue – but `Footer` also needs the prop.
|
||||
|
||||
Now that `Footer` needs `profile` as a prop, we need to solve prop drilling with another method.
|
||||
|
||||
## How to Fix Prop Drilling with a Children-Replacing-Parent Strategy
|
||||
|
||||
Earlier in this article, we talked about how to use component composition and moving state to its consumer to solve prop drilling. But as you saw, they have some issues – duplicated components or states.
|
||||
|
||||
But using this children-replacing-parent approach fixes the problem effectively:
|
||||
|
||||
****Working but could be better:**
|
||||
|
||||
```xquery
|
||||
export function App() {
|
||||
const [profile, setProfile] = useState({name: 'Ayobami'});
|
||||
return (
|
||||
<div>
|
||||
<Header>
|
||||
<Content profile={profile} />
|
||||
</Header>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function Header({ profile }) {
|
||||
return (
|
||||
<header>
|
||||
<h1>This is the header</h1>
|
||||
<Content profile={profile} />
|
||||
</header>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
The example above shows a solution to the prop drilling example in this article. But as you can see, it has a redundant component, as `Header` does nothing.
|
||||
|
||||
**Here's a better version:**
|
||||
|
||||
```javascript
|
||||
export function App() {
|
||||
const [profile, setProfile] = useState({name: 'Ayobami'});
|
||||
return (
|
||||
<header>
|
||||
<h1>This is the header</h1>
|
||||
<Content profile={profile} />
|
||||
</header>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
In the above code, we enhance the component composition solution we previously implemented for the prop drilling example by replacing the redundant `Header` component with its content in its parent (`App`).
|
||||
|
||||
## What to Avoid
|
||||
|
||||
|
||||
|
||||
Photo by [Edwin Hooper](https://unsplash.com/@edwinhooper?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)
|
||||
|
||||
==It's essential to highlight what to avoid when dealing with prop drilling to prevent unnecessary challenges.==
|
||||
|
||||
* **==Avoid React Context, if possible, to fix prop drilling.==** ==This approach ties your component to a specific context, restricting its usability outside of that context and hindering composition and reusability.==
|
||||
* **==Steer clear of redundant components by employing a children-parent replacement approach.==** ==This approach naturally incorporates== ==[component composition](https://www.codementor.io/@dinerismail/the-power-of-component-composition-in-react-21goassg4m)== ==without introducing redundant components or states when resolving prop drilling.==
|
||||
|
||||
By avoiding elongated props, you pave the way for crafting maintainable, high-performing, reusable, and scalable React components. It simplifies the process of lifting states and components by removing the struggle of deciding where to place them.
|
||||
|
||||
With your understanding of elongated props, you can confidently position props and components within the right context without undue stress.
|
||||
|
||||
In short, you can now discover prop drilling intuitively by paying attention to any component that takes `props` it doesn't consume and only passes it down to another component.
|
||||
|
||||
Thanks for reading – cheers!
|
||||
|
||||
Hey wait! I am [Ayobami Ogundiran](https://twitter.com/codingnninja) and I am about to start showing how to build your own React, Redux, TypeScript, Zod or Ecommerce websites on my YouTube channel. [Click to subscribe](https://youtube.com/youtoocancode) to stay connected.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. [Get started](https://www.freecodecamp.org/learn/)
|
||||
293
Read Later/2023-11-10 - The Complete Guide to Time Blocking.md
Normal file
293
Read Later/2023-11-10 - The Complete Guide to Time Blocking.md
Normal file
|
|
@ -0,0 +1,293 @@
|
|||
---
|
||||
id: 04745848-2b0d-482d-802c-8872ac9043dd
|
||||
title: |
|
||||
The Complete Guide to Time Blocking
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-10 23:43:20
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-todoist-com-productivity-methods-time-blocking-18bbc432143
|
||||
url_original: |
|
||||
https://todoist.com/productivity-methods/time-blocking
|
||||
---
|
||||
|
||||
# The Complete Guide to Time Blocking
|
||||
|
||||
## Highlights
|
||||
|
||||
Time blocking is a time management method that asks you to divide your day into blocks of time. Each block is dedicated to accomplishing a specific task or group of tasks, and only those specific tasks. Instead of keeping an open-ended to-do list of things you’ll get to as you can, you’ll start each day with a concrete schedule outlining what you’ll work on and when.
|
||||
|
||||
[source](https://omnivore.app/me/https-todoist-com-productivity-methods-time-blocking-18bbc432143#6ca022ff-400a-4f70-8031-1a3caa0e7246)
|
||||
|
||||
---
|
||||
|
||||
With days that are time blocked in advance, you won’t have to constantly make choices about what to focus on.
|
||||
|
||||
[source](https://omnivore.app/me/https-todoist-com-productivity-methods-time-blocking-18bbc432143#21fb5ecc-b00e-4f14-8d60-84eec666e8a9)
|
||||
|
||||
---
|
||||
|
||||
Task batching is when you group similar (usually smaller) tasks together and schedule specific time blocks to complete all at once. By tackling similar tasks in a group, you’ll limit the amount of context switching you have to do throughout your day, saving precious time and mental energy.
|
||||
|
||||
[source](https://omnivore.app/me/https-todoist-com-productivity-methods-time-blocking-18bbc432143#ce3acd05-a296-4204-acfe-e0822f8a83d2)
|
||||
|
||||
---
|
||||
|
||||
Instead of setting aside time blocks for each area of responsibility each day, day theming dedicates a full day each week to each responsibility.
|
||||
|
||||
[source](https://omnivore.app/me/https-todoist-com-productivity-methods-time-blocking-18bbc432143#5d5543a9-0d8d-42ed-aa24-4ecfeb07d6ac)
|
||||
|
||||
---
|
||||
|
||||
time boxing asks you to limit how much time you'll dedicate to a specific task.
|
||||
|
||||
> [!note]
|
||||
> Is _"I'm gonna finish this in X time"_, instead of _"I'm gonna work on this for X time"_
|
||||
|
||||
[source](https://omnivore.app/me/https-todoist-com-productivity-methods-time-blocking-18bbc432143#e342c6ce-607b-4482-af54-4ffbf81ab7ab)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
...and its cousins task batching and day theming. Control your schedule so it doesn't control you
|
||||
|
||||
|
||||
|
||||
1. [What is time blocking?](#what-is-time-blocking)
|
||||
2. [Time blocking variations](#time-blocking-variations)
|
||||
3. [Why is time blocking so effective?](#why-is-time-blocking-so-effective)
|
||||
4. [But will time blocking work with my job?](#but-will-time-blocking-work-with-my-job)
|
||||
5. [Some common time blocking missteps and how to avoid them](#some-common-time-blocking-missteps-and-how-to-avoid-them)
|
||||
6. [Time blocking with Todoist](#time-blocking-with-todoist)
|
||||
|
||||
---
|
||||
|
||||
> "A 40 hour time-blocked work week, I estimate, produces the same amount of output as a 60+ hour work week pursued without structure."
|
||||
>
|
||||
> — Cal Newport, Author of _Deep Work_
|
||||
|
||||
If there's one thing that can be said about the modern workplace, it's this: If you don't control your schedule, it will control you.
|
||||
|
||||
How do you balance the necessary evils of meetings, email, team chat, and "busy work" with focused time for the things you truly care about? Since becoming a digital hermit isn’t an option for most of us, we need concrete strategies to help us focus in a world designed to distract us.
|
||||
|
||||
That’s where time blocking comes in.
|
||||
|
||||
Time blocking (and its close cousins, time boxing, task batching, and day theming) is a simple yet effective way to take back control of your time.
|
||||
|
||||
Try time blocking if you...
|
||||
|
||||
* Juggle many different projects/responsibilities (Jack Dorsey used day theming to run two major companies at the same time)
|
||||
* Spend too much time in “reactive mode,” responding to emails and messages
|
||||
* Find their day chopped up by meetings
|
||||
* Battle constant interruptions throughout the day
|
||||
* Struggle to find the time and mental space for big-picture thinking
|
||||
|
||||
This guide will give you an overview of what time blocking, task batching, and day theming are; how a combination of these strategies can help you reclaim your schedule, and the best way to use your calendar and task manager to start time blocking yourself.
|
||||
|
||||
==Time blocking is a time management method that asks you to divide your day into blocks of time. Each block is dedicated to accomplishing a specific task or group of tasks, and only those specific tasks. Instead of keeping an open-ended to-do list of things you’ll get to as you can, you’ll start each day with a concrete schedule outlining what you’ll work on and when.==
|
||||
|
||||
The key to this method is prioritizing your task list in advance — a dedicated weekly review is a must. Take stock of what’s coming up for the week ahead, and make a rough sketch of your time blocks for each day. At the [end of every workday](https://doist.com/blog/end-work-day/?itm%5Fcampaign=time%5Fblocking&itm%5Fmedium=referral&itm%5Fsource=productivity%5Fmethods%5Fguides), review any tasks you didn’t finish — as well as any new tasks that have come in — and adjust your time blocks for the rest of the week accordingly.
|
||||
|
||||
==With days that are time blocked in advance, you won’t have to constantly make choices about what to focus on.== All you need to do is follow your time blocked schedule. If you get off-task or distracted, simply look at your schedule and get back to whichever task you blocked off time for.
|
||||
|
||||
### Dig deeper
|
||||
|
||||
We've written a separate, comprehensive [guide to weekly reviews](https://todoist.com/productivity-methods/weekly-review) that will walk you through how to create a routine that works for you.
|
||||
|
||||
## Time blocking variations
|
||||
|
||||
Time blocking has a few close but distinct cousins that are worth considering: task batching, day theming, and time boxing.
|
||||
|
||||
| **Method** | **What is it?** | **Example** |
|
||||
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
|
||||
| Time Blocking | Dividing the day into blocks of time with each block dedicated to accomplishing a specific task or activity and only that specific task or activity. | "I will write every day from 9am to 11am." |
|
||||
| Task Batching | "I will answer all of my emails at 3pm." | |
|
||||
| Day Theming | "Every Monday, I will focus on content creation. Every Tuesday, I will focus on content promotion. Every Wednesday, I will focus on research and ideation. Etc." | |
|
||||
| Time Boxing | "I will write 1,000 words between 9am and 11am tomorrow." | |
|
||||
|
||||
### Task batching
|
||||
|
||||
==Task batching is when you group similar (usually smaller) tasks together and schedule specific time blocks to complete all at once. By tackling similar tasks in a group, you’ll limit the amount of context switching you have to do throughout your day, saving precious time and mental energy.== For example, scheduling two 20-minute blocks to process email during the day is more efficient than checking your inbox every 15 minutes.
|
||||
|
||||
Time blocking pairs well with task batching because it saves you from scheduling every individual task on your calendar. Just block off chunks of time each day or week for when you want to complete a certain batch of activities, e.g., email, invoicing, workouts, meetings, writing, coding, deep work, errands, meal prep.
|
||||
|
||||
### Day theming
|
||||
|
||||
Day theming is a more extreme version of task batching for people who have a lot of areas of responsibility competing for their attention. For example, an entrepreneur often has to pay attention to marketing, sales, product development, customer support, and HR all at the same time. ==Instead of setting aside time blocks for each area of responsibility each day, day theming dedicates a full day each week to each responsibility.==
|
||||
|
||||
Mike Vardy, founder of [Productivityist](https://productivityist.com/theming-days-made-better-dad/), uses day theming to set his overarching focus for each day. Here's how he themes his week:
|
||||
|
||||
Dedicating each day to a single theme creates a reliable work pattern and further limits the cognitive load of context switching. Vardy explains that theming offers mental clarity that allows him to focus on his family:
|
||||
|
||||
> “Knowing what the day ‘means’ to me allows me to get the things I need and want to accomplish without seeing undetermined ‘ought to do’ items on a to do list. As a result, I have less decision fatigue and even have more energy when I spend time with my kids.”
|
||||
|
||||
### Time boxing
|
||||
|
||||
Time blocking and time boxing are often confused as being synonymous, but there's an important difference. Time blocking asks you to set aside certain chunks of time to focus on a given task or activity. For example, "I will work on a first draft of my blog post from 9am to 11 am tomorrow."
|
||||
|
||||
In contrast, ==time boxing asks you to limit how much time you'll dedicate to a specific task.== Here's a time boxed version of the time blocking example above: "I will finish a first draft of my blog post tomorrow between 9am and 11am."
|
||||
|
||||
This self-imposed "time box" forces you to work efficiently because you have a limited amount of time in which to complete the task. It can be a fun way to challenge yourself and gamify your productivity.
|
||||
|
||||
## Why is time blocking so effective?
|
||||
|
||||
This technique seems simple on the surface, but has profound impacts on your capacity to get things done:
|
||||
|
||||
### It promotes focused “deep work”
|
||||
|
||||
Cal Newport, author of [Deep Work: Rules for Focused Success in a Distracted World](https://www.amazon.com/Deep-Work-Focused-Success-Distracted/dp/1455586692/ref=asc%5Fdf%5F1455586692/?tag=hyprod-20&linkCode=df0&hvadid=312741934517&hvpos=1o1&hvnetw=g&hvrand=7753978193869239626&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9019660&hvtargid=pla-421604508630&psc=1&tag=&ref=&adgrpid=64940825031&hvpone=&hvptwo=&hvadid=312741934517&hvpos=1o1&hvnetw=g&hvrand=7753978193869239626&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9019660&hvtargid=pla-421604508630), is a [big proponent of time blocking](http://www.calnewport.com/blog/2013/12/21/deep-habits-the-importance-of-planning-every-minute-of-your-work-day/). He dedicates 20 minutes every evening to scheduling out the next work day:
|
||||
|
||||
> “Sometimes people ask why I bother with such a detailed level of planning. My answer is simple: it generates a massive amount of productivity. A 40 hour time-blocked work week, I estimate, produces the same amount of output as a 60+ hour work week pursued without structure.”
|
||||
|
||||
When you schedule a chunk of time to work on a single project, problem, or task, you bring all of your mental resources to bear on one thing rather than spreading your attention thin across several tasks. The more you “single task”, the more you build the mental muscles required for deep work, and the easier it becomes to stay focused.
|
||||
|
||||
### Dig deeper
|
||||
|
||||
Learn more about Newport’s approach to meaningful productivity and how to incorporate more focus into your life with [The Complete Guide to Deep Work](https://doist.com/blog/deep-work/?itm%5Fcampaign=time%5Fblocking&itm%5Fmedium=referral&itm%5Fsource=productivity%5Fmethods%5Fguides).
|
||||
|
||||
### It helps you knock out “shallow work” more efficiently
|
||||
|
||||
Shallow work is the busy work that’s [urgent but not important](https://todoist.com/productivity-methods/eisenhower-matrix) to achieving your long-term goals — think paperwork or responding to (most) emails. When you time box shallow work, you’re setting clear limits on how much time you’ll dedicate to it. Plus, grouping similar tasks together reduces the cost of context switching. By batching all of your shallow tasks together in a dedicated time block or two, you’ll be able to power through them more efficiently and protect the rest of your workday for higher-impact work.
|
||||
|
||||
### It makes you aware of how you spend your time
|
||||
|
||||
Most people are bad at time management. We are [terrible at estimating](https://en.wikipedia.org/wiki/Planning%5Ffallacy) how much time tasks will take, and we have a tendency to [overcommit our future selves](https://doist.com/blog/neuroscience-achieving-long-term-goals/?itm%5Fcampaign=time%5Fblocking&itm%5Fmedium=referral&itm%5Fsource=productivity%5Fmethods%5Fguides). Time blocking forces you to confront your current priorities and commitments and get intentional about how you spend your finite time. For each new commitment you let into your life, you’re forced to find physical space on your calendar. As a result, the opportunity cost of saying “yes” becomes more concrete, and it becomes much easier to [say “no](https://doist.com/blog/how-to-say-no/?itm%5Fcampaign=time%5Fblocking&itm%5Fmedium=referral&itm%5Fsource=productivity%5Fmethods%5Fguides).”
|
||||
|
||||
### It counteracts perfectionism
|
||||
|
||||
Fuzzy timelines are a perfectionist’s worst enemy. There’s always something to be tweaked and improved. It can be difficult to know when an open-ended project is finished, especially if you are aiming for perfection. At some point, you need to be able to say “good enough” and move on. Time boxing can help by imposing time limits on your projects. If you often prolong tasks by trying to get everything just right, set a strict time box for finishing the task and stick to it.
|
||||
|
||||
### It helps you follow through on your goals
|
||||
|
||||
In the article “[Beyond good intentions: Prompting people to make plans improves follow-through on important tasks](https://scholar.harvard.edu/files/todd%5Frogers/files/beyond%5Fgood%5Fintentions%5F-%5Fprompting%5Fpeople.pdf)” researchers Dr. Todd Rogers and Dr. Katherine L. Milkman review several studies supporting the idea that “concrete plans help people follow through on their intentions.”
|
||||
|
||||
From following an exercise regimen to scheduling a flu shot, people were more likely to act on their intentions when they wrote down a specific place, date, and time for the activity. Yet most people rely on vague intentions rather than concrete plans:
|
||||
|
||||
> “Paradoxically, people frequently underplan when they begin with strong intentions. They mistakenly believe that their strong intentions are enough to propel them to perform desired behaviors, and that belief keeps them from using strategies that could help translate intentions into actions.”
|
||||
|
||||
The takeaway: When you schedule your tasks and goals, you’re more likely to follow through. Time blocking forces you to make concrete plans that ensure you’re working toward your goals every day. As William Faulkner famously quipped:
|
||||
|
||||
> “I only write when inspiration strikes. Fortunately, it strikes at nine every morning.”
|
||||
|
||||
## But will time blocking work with my job?
|
||||
|
||||
One of the biggest criticisms of time blocking is that it doesn’t account for reactive jobs where it’s impossible to anticipate what will come in at any given moment. Is time blocking really a realistic strategy for a customer support specialist whose job is to respond to tickets? Or an account manager who needs to be available to respond to client requests?
|
||||
|
||||
We’d argue yes — asserting even a small amount of control over your schedule can be helpful no matter your job. Cal Newport put it this way:
|
||||
|
||||
> “Periods of open-ended reactivity can be blocked off like any other type of obligation. Even if you’re blocking most of your day for reactive work, for example, the fact that you’re controlling your schedule will allow you to dedicate some small blocks (perhaps at the schedule periphery) to deeper pursuits.”
|
||||
|
||||
When your workday is run by external forces, it’s easy to lose sight of your own goals. Time blocking can help you gain a greater sense of control over even the most unpredictable of schedules.
|
||||
|
||||
## Some common time blocking missteps and how to avoid them
|
||||
|
||||
While time blocking is pretty straightforward in theory, it can be hard to stick to in practice. Here are some tips to help you apply the method successfully (and not become a slave to your calendar in the process):
|
||||
|
||||
### Underestimating your time
|
||||
|
||||
You’ll get better at estimating how long tasks take over time, but until you’ve honed your instincts, err on the side of blocking off too much time for tasks rather than too little. Pad your schedule with extra time to complete and transition between tasks. You can even create “conditional blocks” of time you can tap into if you fall behind.
|
||||
|
||||
### Try these tools
|
||||
|
||||
Improve your sense of how long you actually spend on tasks with time trackers like [RescueTime](https://www.rescuetime.com/ref/1403570) or [Toggl](https://toggl.com/).
|
||||
|
||||
### Being too rigid
|
||||
|
||||
Things will come up and ruin your plans. But remember that your plan is a guide to help focus your attention on what’s important, not a binding contract.
|
||||
|
||||
Even productivity expert Cal Newport edits his plans throughout the day by crossing out original time blocks and filling them with updated plans as circumstances demand:
|
||||
|
||||
Newport deals with changes in his schedule by seeing it as a game:
|
||||
|
||||
> “This type of planning, to me, is like a chess game, with blocks of work getting spread and sorted in such a way that projects big and small all seem to click into completion with (just enough) time to spare.”
|
||||
|
||||
See your time blocks as a flexible way to challenge yourself, not strict tools to punish yourself when you fall short.
|
||||
|
||||
### Overscheduling your leisure time
|
||||
|
||||
Though [Elon Musk and Bill Gates](https://www.businessinsider.com/bill-gates-elon-musk-scheduling-habit-2017-8) have been said to schedule their days down to 5-minute increments, overscheduling your leisure time can be a self-defeating exercise. [Studies](https://www.washingtonpost.com/news/inspired-life/wp/2018/07/31/want-to-be-happier-stop-scheduling-your-free-time/?noredirect=on&utm%5Fterm=.c7b6c4e1f8d1) have shown that scheduling leisure activities has a “unique dampening effect” on the overall enjoyment of the activity.
|
||||
|
||||
Instead, you can block out time to disconnect and relax without a set plan for how you’ll spend that time. It will give you the flexibility to decide more spontaneously what you want to do-- call friends to grab a drink? Check out that new Xbox game? Read? Whatever you decide, just remember to keep at least some of your free time free.
|
||||
|
||||
## Time blocking with Todoist
|
||||
|
||||
You can implement time blocking with any tool, but in this section, we'll focus on how to use Todoist alongside your favorite calendar app — or even good, old-fashioned pen and paper. We'll cover how to implement three different time blocking variations: task batching, day theming, and scheduling individual tasks.
|
||||
|
||||
### Task batching variation
|
||||
|
||||
Strict time blocking — dedicating a time block to each individual task — can be tedious and hard to maintain over time. We recommend combining time blocking and task batching for a more streamlined system. Instead of one time block per individual task, you’ll assign a time block for each category of task you batch together. Here’s how that looks in practice:
|
||||
|
||||
First, decide on which broad categories of work need to be reflected in your daily or weekly schedule. For example, a freelance writer might have the following category list:
|
||||
|
||||
* Email
|
||||
* Work admin
|
||||
* Sales
|
||||
* Meetings
|
||||
* Research
|
||||
* Writing
|
||||
* Professional Development
|
||||
* Yoga
|
||||
* Meal prep
|
||||
* Personal admin
|
||||
* Reading
|
||||
* Free time
|
||||
|
||||
Now, sit down with your favorite calendar app or paper planner and create time blocks for the coming week that reflect the times you’ll work on each category. Make sure all of your priorities and commitments are given enough space on your calendar. If you struggle to find room, you may need to start cutting down on your commitments. The end result will look something like this:
|
||||
|
||||
If you find it difficult to stick to your digital schedule, we recommend planning your day out on paper. A paper schedule forces you to start fresh each day and makes it easy to scribble things out and adapt as the day goes on. Plus, it's also easier to keep your paper schedule open on your desk as a visible reminder of what you had planned to focus on.
|
||||
|
||||
If you work at a company with shared calendars, you may find it helpful to publicly block off time for “Deep Work” to keep a sufficient chunk of the day meeting free. Khoi Vinh, a [Principal Designer at Adobe](https://doist.com/blog/how-khoi-vinh-gets-things-done/?itm%5Fcampaign=time%5Fblocking&itm%5Fmedium=referral&itm%5Fsource=productivity%5Fmethods%5Fguides), uses this strategy at his office:
|
||||
|
||||
> “I look for blocks of time on my calendar that I can cordon off for “deep work”. Sometimes I’ll move around meetings to create longer contiguous blocks, and then I’ll create a meeting called “Do Not Book” or, if I suspect someone will ignore that, I’ll name it something like “Collaboration Session” or “Research Review.” You have to get crafty.”
|
||||
|
||||
You now have time blocks for each category, but you still need to know which specific task — or group of tasks — to work on when the time comes. That’s where a task manager like Todoist comes in.
|
||||
|
||||
[Create a Todoist label](https://get.todoist.help/hc/en-us/articles/360000029000-How-to-best-use-labels?utm%5Fsource=dots%5Fblog&utm%5Fmedium=referral&utm%5Fcampaign=time%5Fblocking) for each batched category you came up with in step one, then review all of your current tasks and assign the appropriate label to each one.
|
||||
|
||||
Now, when you come to a time block, all you have to do is pull up the corresponding label list and choose from the relevant tasks. Tasks with dates will automatically be sorted at the top so you’ll know when something is due soon and needs your attention first.
|
||||
|
||||
### Todoist Tip
|
||||
|
||||
You can also [create a new filter](https://get.todoist.help/hc/en-us/articles/205248842-Filters?itm%5Fcampaign=time%5Fblocking&itm%5Fmedium=referral&itm%5Fsource=productivity%5Fmethods%5Fguides) with a query like “@personal\_admin & next 7 days” to see just the tasks due in the upcoming week with that specific label.
|
||||
|
||||
To make sure nothing slips through the cracks, every task should have a label. However, you’ll likely find that not every category needs to be tracked in Todoist. For example, you may want to keep track of your meetings or exercise classes in your calendar rather than in your task manager. And as we said before, you don’t want to overprogram your free time. Experiment with your setup to figure out what makes sense for your specific circumstances.
|
||||
|
||||
### Day theming variation
|
||||
|
||||
If you try time blocking and still feel too scattered and unfocused, you may want to try out day theming. We recommend this [free Skillshare course](https://www.skillshare.com/classes/Productivity-Habits-That-Stick-Using-Time-Theming/1216959000) by Mike Vardy. He walks you through setting up a day theming system, including detailed examples using both paper and Todoist.
|
||||
|
||||
### Scheduling time blocks for individual tasks
|
||||
|
||||
Of course, if you want to keep a more granular schedule, you can always create separate time blocks for each task. The easiest way to do that with Todoist is via the [2-way integration with Google Calendar](https://get.todoist.help/hc/en-us/articles/115003128085-How-can-I-use-Todoist-with-Google-Calendar?itm%5Fcampaign=time%5Fblocking&itm%5Fmedium=referral&itm%5Fsource=productivity%5Fmethods%5Fguides).
|
||||
|
||||
When setting up the integration:
|
||||
|
||||
* Create a new calendar for just your Todoist tasks so you can toggle them on and off inside your calendar as you need.
|
||||
* Choose to sync your entire Todoist account or create separate calendars for each of your Todoist projects.
|
||||
* Choose to sync tasks with just a due date in addition to tasks with a due date and time.
|
||||
|
||||
Any Todoist task with a date and time will automatically appear as an event in your new Todoist calendar. Any task with a date but no time will appear as a day-long event.
|
||||
|
||||
During your [weekly review](https://todoist.com/productivity-methods/weekly-review), give each task you want to accomplish a date and/or start time by typing something like “Monday at noon” or “Every Friday at 9am” into the task field. Todoist will automatically recognize and highlight the date and set it when you save the task.
|
||||
|
||||
Now, when you open your daily or weekly view in your calendar, you’ll see each of your tasks scheduled as separate events (aka your time blocks). You can extend, shorten, edit, and move your time blocks inside your calendar. Any changes you make in Google Calendar will automatically sync back to your Todoist (and vice versa).
|
||||
|
||||
---
|
||||
|
||||
Scheduling your days and weeks in advance can seem like a waste of precious time you could be using to actually get things done. But when you aren’t controlling your calendar, it’s easy to let distractions take over. By front-loading your decision-making on what to work on for the day or week, you’ll be saving time and mental energy when it comes to actually getting to work.
|
||||
|
||||
Give time blocking and task batching a try for a week and see how it feels to take back control over your time and attention.
|
||||
|
||||
### Todoist Tip
|
||||
|
||||
If you have a Pro or Business plan, you can supercharge your time blocking with [task durations](https://todoist.com/help/articles/whats-new#reclaim-your-schedule-with-task-durations-aug-30). Simply:
|
||||
|
||||
* Select your Due Date, then Time, to set the start time and duration of your task. This forms your time block.
|
||||
* You can also add a task’s duration via Todoist’s natural language recognition by typing “for” followed by the length of time you think the task will take. (e.g., “Team meeting today 4pm for 45min” or “Write first draft 9am for 2 hours 30 minutes”.)
|
||||
* If you’ve connected your Todoist to a calendar app, the task duration will sync to your calendar automatically (and, on Google Calendar, vice versa with 2-way sync so you can update your tasks from your calendar).
|
||||
|
||||
#### Laura Scroggs
|
||||
|
||||
[Laura](https://laurascroggs.wordpress.com/) is a freelance writer, PhD candidate, and pug mom living in Minneapolis, MN.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
id: b453f3fe-d74e-4a3a-b778-8e4f6450da30
|
||||
title: |
|
||||
The one thing you need to finish your game
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-14 22:58:47
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-youtu-be-b-6-au-n-gi-ue-m-si-ixu-ds-nh-t-2-k-5-b-3-jf-s-18bd0b3d045
|
||||
url_original: |
|
||||
https://youtu.be/B6auN-GIUeM?si=ixuDsNhT2k5b3JfS
|
||||
---
|
||||
|
||||
# The one thing you need to finish your game
|
||||
|
||||
## Notes
|
||||
|
||||
What you need... is a **plan**...
|
||||
|
||||
Because it makes the game feasible, realizable and gives it a scope, to see how "big" it's going to be. Also prevents burn out by all the stuff you _"need to do"_.
|
||||
|
||||
A plan is not a immovable wall, you can tweak it if you need to adjust to new discoveries or new inputs, this is better than wandering without a goal. But try to not increment the scope so you don't end up with an interminable project.
|
||||
|
||||
> The code is more of a guide than law...
|
||||
> Jack Sparrow
|
||||
## Original
|
||||
|
||||
[The one thing you need to finish your game](https://youtu.be/B6auN-GIUeM?si=ixuDsNhT2k5b3JfS)
|
||||
|
||||
By [Game Maker's Toolkit](https://www.youtube.com/@GMTK)
|
||||
|
|
@ -0,0 +1,313 @@
|
|||
---
|
||||
id: 49d7bfb2-8911-11ee-9b49-a315c7dbc2d7
|
||||
title: |
|
||||
Career Mistakes to Avoid as a Developer
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- RSS
|
||||
date_added: 2023-11-21 21:04:22
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/career-mistakes-to-avoid-as-a-developer-18bf626412f
|
||||
url_original: |
|
||||
https://www.freecodecamp.org/news/career-mistakes-to-avoid-as-a-dev/
|
||||
---
|
||||
|
||||
# Career Mistakes to Avoid as a Developer
|
||||
|
||||
## Highlights
|
||||
|
||||
Build authentic connections to get the best out of it. Then once you're connected, here are a few things you can do:
|
||||
|
||||
* Show interest in their posts.
|
||||
* Engage with discussions by commenting or sharing posts.
|
||||
* Repost with your thoughts
|
||||
* Exchange ideas, or even build things together!
|
||||
|
||||
A strong social connection may help you in getting information faster. You may learn about a new release of a library/framework/product, how an industry is moving, how certain technologies might impact your work, and so on.
|
||||
|
||||
[source](https://omnivore.app/me/career-mistakes-to-avoid-as-a-developer-18bf626412f#3d561a03-61e0-4ca6-8e70-81651abe90c1)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
What does the word `career` mean to you? To me, it is a roller coaster journey during which we find opportunities, progress, and growth in life. The journey involves learning objectives, work, and other personal and professional aspects.
|
||||
|
||||
A promising career is one where you enjoy most (if not all) of your daily work. You see your personal, professional, and financial growth and gradually define what success means to you.
|
||||
|
||||
A lousy career is just the opposite. It may pay your bills, but you need more work satisfaction, and measuring your progress and growth becomes hard.
|
||||
|
||||
Several factors define a career: promising versus lousy, good versus bad, and successful versus failed. A few of them we can not control – but, we can avoid some career mistakes to build a better career path.
|
||||
|
||||
I have spent more than 18 years in Software Engineering and have seen a lot of ups and downs, including in my own career and those of my colleagues. In this article, I will discuss ten career mistakes you should avoid.
|
||||
|
||||
Usually, I [share knowledge](https://www.freecodecamp.org/news/author/tapas/) on technical topics like JavaScript, web development, React, Node, Next.js, and so on. But this time, let's connect on essential tips for our Career Development.
|
||||
|
||||
If you like to learn from video content as well, this article is also available as a video tutorial here: 🙂
|
||||
|
||||
## A Few Things Before We Start
|
||||
|
||||
You may or may not agree with all the points. That's fine with me, because what I'm planning to share here is based on my own experiences.
|
||||
|
||||
You may strongly agree or disagree with my conclusions, but if there are any additional points that you think I still need to include, please let me know. You can contact me on the social handles I mention at the end of this article.
|
||||
|
||||
Also, this article is not only meant for working professionals. All these mistakes we will discuss are relevant for everyone, including students, people seeking jobs, or anyone getting ready for tomorrow in the software industry or any industry.
|
||||
|
||||
All set? Let's get started.
|
||||
|
||||
## 1\. You Don't Set Realistic Goals
|
||||
|
||||
|
||||
|
||||
One of the biggest mistakes most of us make in our careers is not having a goal. What exactly is a goal? It is something like a target.
|
||||
|
||||
Let's take an example. Let's say you're going shopping to buy something. You usually have a list of items that you want to get. You don't randomly pick things and come home and feel like, "Oh, it was a complete waste of time and money". So, if that list is your shopping goal, why not have something like this for your career?
|
||||
|
||||
Usually, we have a lot of short-term goals, for example,
|
||||
|
||||
* I have to fix this bug today.
|
||||
* I have to build this project this week.
|
||||
* I have to get a promotion this year.
|
||||
|
||||
These are great goals to have. But we need to have long-term goals as well. Like, what do you want to be in the long-term in your career. How do you plan every steps to achieve that goal?
|
||||
|
||||
Say you are in mechanical engineering, but your heart is in software engineering (mechanical engineering is excellent – I'm just taking this as an example). In that case, you should have a goal for the next few years to translate yourself into a software developer and try to seek more roles more opportunities in the software industry.
|
||||
|
||||
I can tell you my story, as I think it'll help give you some perspective. I set myself a long term career goal to transition from my regular multi-national corporation job and start my career full time as an independent teacher and content creator. It took me four years to realize it, but without that goal it would have been impossible for me to chase my passion.
|
||||
|
||||
You may ask, will I be able to fulfill all the goals in my life? Well, maybe not. Still, it's important to have some and prioritize the most important ones. That way, even if you can't achieve some, you may identify a few more new goals along the way.
|
||||
|
||||
You may have a different way of going about it. But, if you don't have a starting point, you do not have anything to work toward and chase. Your career may become stagnant.
|
||||
|
||||
If you don't have any career goals for yourself right now, take some time to come up with a couple realistic goals. Here's some advice on [how to set SMART goals you can actually achieve](https://www.freecodecamp.org/news/how-to-set-smart-goals-you-can-achieve/).
|
||||
|
||||
## 2\. You Fail to Recognize Your Potential
|
||||
|
||||
|
||||
|
||||
> **Human potential** is the capacity for humans to **improve** themselves through **studying**, **training**, and **practice**, to reach the limit of their ability to develop **aptitudes** and **skills**. – Definition of Human Potential from Wikipedia.
|
||||
|
||||
For us, the software developers, is about improving ourselves through practice, training, and study to reach the heights of our ability. But many of us do not know our potential at the start our careers. We figure it out gradually, and when we become aware of it, this helps us improve our careers.
|
||||
|
||||
When you know your potential, someone else will not dictate how to shape your career. Instead, you will be able to identify what would be good for you based on your strengths and where you need to bridge the gaps.
|
||||
|
||||
But you may ask, "How do I know my potential?". That's where having a goal and working towards it helps. Say you have a goal of mastering machine learning and data science to have a career as a data scientist. As you work towards this goal, you will find the areas where you excel, and other areas where you need to work especially hard. You figure out your potential as you work towards this goal.
|
||||
|
||||
Also, try not to settle for unimportant things. Constantly challenge yourself to produce better and more significant outcomes. When you do so, you discover your true potential in a much better way.
|
||||
|
||||
## 3\. You Don't Take the Time to Network
|
||||
|
||||
|
||||
|
||||
Hey, we're gonna talk about something other than computer networking here. We will focus on human-to-human networking. We are going to talk about socializing. But why?
|
||||
|
||||
Networking or socializing with like-minded people, talking to them, and getting inspired by their work are as important as learning to code in programming. You might be a great programmer and fantastic coder. But suppose you do it in a silo. In that case, no one knows you or what you're capable of, so you will most likely lose out on more significant opportunities in your career.
|
||||
|
||||
When you socialize and network with others in the tech space, you may find a meaningful community to join. You'll be able to discuss important topics with like-minded people who have interests similar to yours – and this can help you multiply your growth by many times.
|
||||
|
||||
This is one mistake I made in my career for several years, as I was unaware of its vast potential. Be active on platforms like LinkedIn, follow people you'd like to connect with on tech Twitter (now X), and make authentic connections with them. Spending mindful time on these platforms, and at in-person events as you're able, can really help boost your career.
|
||||
|
||||
Check out the `You Miss Out on Learning Opportunities` section below for some real-life tips on how to reach out and connect with people.
|
||||
|
||||
## 4\. You Waste Your Precious Time
|
||||
|
||||
|
||||
|
||||
"Wasting time" means not effectively utilizing your time. Would you agree that time is precious? Using and managing your time properly will help your career and life in general.
|
||||
|
||||
To clarify, watching a movie, going out with your friends and family, participating in festive activities, and so are not wasting time. You need these to balance out the time you spend working.
|
||||
|
||||
Rather, I'm more concerned about the tasks you may have to perform that take away from your "focus time" at work.
|
||||
|
||||
Let me walk you through a few situations:
|
||||
|
||||
You are working on a task, and here comes some notifications on your phone. You pause whatever you are doing and jump on your phone to see what's happening on that side of the world. The notification may take you 10-15 seconds to read, but you then spend 10 minutes browsing the phone.
|
||||
|
||||
This is a habit many of us have built in recent times. And then when you get back to your work, your brain has to recalculate and bring you back to the topic at hand – where you were, and what you were doing – and get you started with the task gain. This context switching is costly, and the same amount of focus may not be possible.
|
||||
|
||||
The best way of tackle a situation like this is,
|
||||
|
||||
* Switch off the phone's internet while you're working if you do not need it. You can switch it on when you take breaks, maybe at lunch time.
|
||||
* You can also set your phone in "Do Not Disturb" mode while your work needs your utmost attention. Just make sure you add some of your family and friend's contacts as emergency contacts so that only a limited set of people can reach out to you during those times in case of any emergencies.
|
||||
|
||||
Let's talk about another situation. Suppose you need to prepare and send a design doc to a senior dev for review. But instead, you spend time on something low priority or some little luxury that delayed preparing the doc. You keep postponing until it's become an urgent thing that you'll have to do within a limited time.
|
||||
|
||||
This act of delaying something knowingly is called `procrastination`, an ultimate way to kill time. There are some well-known and proven methods to tackle procrastination.
|
||||
|
||||
* The first step is to realize and admit to yourself that you procrastinate.
|
||||
* Then list out your distractors. This list may vary from person to person. Remove these distractors. It could be your phone, TV, novels, anything.
|
||||
* Break down your deliverables into smaller tasks. Achieve them one by one and give yourself a pat on your back once you've finished each small task.
|
||||
* Take small breaks and come back to the point where you left off on your task to continue with a fresh brain.
|
||||
|
||||
Instead of finding yourself in these types of situations, use your time wisely. If you have to get something done, get it done. When you're procrastinating, something that depends on one task may also get delayed, creating a cycle of time waste, frustrations, and complicated situations.
|
||||
|
||||
## 5\. You Neglect Upskilling
|
||||
|
||||
|
||||
|
||||
`Upskilling` means getting better at your current skill or acquiring relevant new skills. It is essential to upskill at any and all stages of your career.
|
||||
|
||||
One of the common mistakes we make is that we stop upskilling after a few years in our professional life. We get used to the projects, domains, technologies, and environments that create a comfort zone around us. Upskilling is always about coming out of that comfort zone.
|
||||
|
||||
Here are a few common excuses we give to ourselves when it comes to upskilling:
|
||||
|
||||
* I already have a lot of work at the office or assignments in university.
|
||||
* I need to have a personal life.
|
||||
* I am happy with whatever I know now, and my work only demands so much.
|
||||
* There is so much to learn and it is never ending (sigh!).
|
||||
|
||||
But you really don't need that much time in a week to up-skill. You just need to have a plan and to stay consistent in executing it. Set just 1 hour aside in your day. Fork it out from any non-urgent activities and plan your learning schedule in that one hour.
|
||||
|
||||
In this one hour, here are some things you can do:
|
||||
|
||||
* Assess the gaps, weaknesses, and strengths in your technical and non technical abilities.
|
||||
* List them out in a place where you can easily get back to them and make modifications.
|
||||
* Prioritize them based on your current needs and near future goals.
|
||||
* Time-box each of the items so that you can get something tangible within a specified duration. For example, you want to do a certification on cloud computing within a month, or the Responsive Web Design course from freeCodeCamp over the next few weeks, and so on.
|
||||
* Start working on these defined tasks. You may find many resources on internet. Glance over them to create an index of resources that you can understand easily and relate to well.
|
||||
* Read and watch tutorials, but also practice hard.
|
||||
* Finally, recognize your progress.
|
||||
|
||||
You may ask, is that one hour really enough? And I will tell you – it works like magic if you keep it up. Upskilling is not a race or sprint. It needs time, consistency, and perseverance to get from the one end to other.
|
||||
|
||||
Have you heard about the power of tiny gains?
|
||||
|
||||
|
||||
|
||||
Credit: James Clear
|
||||
|
||||
It is a strategy of being just 1% better every day. If you continue to do that for a year, you get almost 38% better at the end of the year. Being 1% worse does the opposite. The strategy was represented in mathematical graphs by James Clear in explanation of [Continuous improvements and how it works](https://jamesclear.com/continuous-improvement).
|
||||
|
||||
Upskilling can also help you out a lot if you're preparing for the job search. The way the tech industry is moving, we may not be able to avoid layoffs – but we can be better prepared to get our next job faster. And that becomes much more attainable when you stay relevant and continue learning new things.
|
||||
|
||||
## 6\. You Don't Ask for What You Want
|
||||
|
||||
|
||||
|
||||
Let me start by sharing an experience of mine. Back in the early 2000s when I was a fresher, I had to attend a meeting with some of the project leads and the manager. We were discussing how to modernize our product with HTML5 features.
|
||||
|
||||
I was aware of HTML5, and every time a discussion point was raised, I thought of adding to it, but I didn't. I thought of asking some valuable questions, but I didn't. I felt that in order to ask something in a meeting, I needed a lot of guts! I was wrong.
|
||||
|
||||
Oftentimes in your career journey, if you do not ask, you simply won't get what you want or deserve. If someone has some knowledge and you lack it, ask about it. If you have a questiona bout something, ask before you commit to the work. Ask about your promotion, a salary hike, career growth, and anything that is related to your career. There is no such thing as a silly question when it comes to your career growth.
|
||||
|
||||
## 7\. You Only Focus on the Money
|
||||
|
||||
|
||||
|
||||
Come on, money is important. But is it the only important thing, especially in the context of switching jobs or working towards your career goals? No, certainly not.
|
||||
|
||||
When you plan to switch jobs, you also need to look into other factors like work culture, the amount of time you need to spend at the office working, whether it's going to be more stressful compared to the compensation you'll be getting, and so on.
|
||||
|
||||
I would certainly look into the following factors along with the compensation (the money part) to make an informed decision about my job switching:
|
||||
|
||||
* What will be my technical growth and learning opportunities?
|
||||
* What will the work environment be like? Remote/Work From Office/Hybrid? How will that impact me?
|
||||
* What skills (both tech and soft) will I be able to learn in the new position?
|
||||
* What kind of employee benefits will I get compared to my current organization?
|
||||
* Will my work-life balance be impacted positively?
|
||||
* What are the company's vision, culture, and values?
|
||||
|
||||
Then when you're considering the salary, be careful and make sure you understand the breakdown. What percentage of the CTC comes from any bonus? Is it inclusive or exclusive of CTC? How does the bonus payout happen? If the company doesn't do well in a fiscal year, will you get paid less? Are there stock options or other benefits they pay out instead of cash? All this matters.
|
||||
|
||||
The mistake people often make is that they see only the `money` figure as the most important part of a job offer. Make sure you talk to someone from the company, do your research, and learn about what else they're offering as we mentioned above.
|
||||
|
||||
## 8\. You Neglect Work-Life Balance
|
||||
|
||||
|
||||
|
||||
Another mistake you might make is not balancing your work and life. The last thing you want is to `burn out` at the cost of things you love the most, like your friends, family, and long-term career.
|
||||
|
||||
We must learn to prioritize things, and this includes both work and personal life. Your priority list for the day should not have only work related items. While it's important to ship a bug fix, it is also essential to accompany your kids to their soccer games or school plays, or make time to go on a date with your partner, or do something nice for yourself.
|
||||
|
||||
Do not be afraid to say "No". At the same time, don't be arrogant when you accept or decline tasks. This is important to keep a healthy work-life balance. When you already have plenty on your plate, trying to accommodate more or do more will only spill over and negatively affect your work-life balance.
|
||||
|
||||
So say no when you need to, communicate your intentions ahead of time when possible, and proactively ask for what tasks you'd like to work on when your plate has room for more.
|
||||
|
||||
For a long time in my career, I attended meetings late at night to match the timezones of my customers and other colleagues. Then, slowly, it started affecting my health and productivity.
|
||||
|
||||
When I thought about it more carefully, I discovered a couple of things. First, I realized that I didn't have to attend all the meetings, and that I could request that they take place in my clients' evenings sometimes. That way we'd both be taking turns compromising. And it worked.
|
||||
|
||||
At times, our habits drive us towards the work-life imbalance. For example, staying late at office while the same work can wait till the next morning is a classic example of a habit that may lead to health issues and frustrations in a long run.
|
||||
|
||||
We all need to find a way to sustain both work and life. So plan ahead, and stick to your schedule as much as possible. There might be exceptions where you have to give one thing priority above another – but do not allow the exception to become the norm.
|
||||
|
||||
## 9\. You Miss Out on Learning Opportunities
|
||||
|
||||
|
||||
|
||||
If you have the opportunity to learn from a person who specializes in a particular field, grab it. If you use social media platforms like LinkedIn and X/Twitter wisely, it can lead you to the people who share great insights about subjects you're interested in.
|
||||
|
||||
A quick tip for you:
|
||||
|
||||
When you send someone a connection request on LinkedIn/X, take some time to introduce yourself. Things that you can mention briefly:
|
||||
|
||||
* What did you find unique about the person you want to connect to?
|
||||
* A bit about yourself, introducing some of your uniqueness, too.
|
||||
* Why do you want to connect?
|
||||
|
||||
==Build authentic connections to get the best out of it. Then once you're connected, here are a few things you can do:==
|
||||
|
||||
* ==Show interest in their posts.==
|
||||
* ==Engage with discussions by commenting or sharing posts.==
|
||||
* ==Repost with your thoughts==
|
||||
* ==Exchange ideas, or even build things together!==
|
||||
|
||||
==A strong social connection may help you in getting information faster. You may learn about a new release of a library/framework/product, how an industry is moving, how certain technologies might impact your work, and so on.==
|
||||
|
||||
Apart from learning a lot, you may also get to know about job openings, hirings, and references. After all, companies have also started recruiting talent from social media pages.
|
||||
|
||||
Also, being part of a forum like the [freeCodeCamp forum](https://forum.freecodecamp.org/) can be helpful for networking and learning as well. It is also a place for you to share solutions to a problem, talk about what you've learned, and make yourself visible gradually.
|
||||
|
||||
When we learn from someone, we not only come to understand what they've achieved or how they did it, but we also learn about the struggles, failures, and how they made the turnaround. Learning from someone else's experience can help accelerate your career journey. Don't make the mistake of living in a silo and missing out on these opportunities.
|
||||
|
||||
## 10\. You Can't See the Bigger Picture
|
||||
|
||||
|
||||
|
||||
By `Big Picture`(or Bigger Picture), I mean understanding and developing a wider perspective on your career as a whole. It is about your ability to consider and assess many different aspects of a situation, rather than focusing on just the minute details.
|
||||
|
||||
As developers, we're supposed to implement features, do bug fixes, maintain code, and deliver quality software to our end-users. That's great!
|
||||
|
||||
But, we need to think beyond the individual tasks assigned to us. Our understanding of the overall project goals, the user acceptance criteria, delivery mechanisms, and perspectives of other engineers is key. And so is judging the impact of our work, as it will help us get the big picture of a project.
|
||||
|
||||
Suppose your product manager wants your team to build user interfaces that also cater to the needs of specially-abled and visually challenged users. In this case, you and your team members must see the bigger picture around `Accessibility`.
|
||||
|
||||
If your designer doesn't define the site's colors accordingly, or the developers do not implement keyboard accessibility along with ARIA roles and attributes, then they're missing the bigger picture.
|
||||
|
||||
Another example could be over-optimizing performance while your users do not care about it. Your users may be waiting to get a feature ASAP so it can help them achieve their business goals. But by addressing unnecessary optimizations, you may be delaying that release and missing crucial deadlines.
|
||||
|
||||
Missing the bigger picture may lead to a lack of synergy in your organization. It can also result in software products that need multiple iterations to meet customer needs because those needs weren't understood at the beginning. This can cause you to miss deadlines and do more work, and can greatly increase the cost to your client.
|
||||
|
||||
Along with understanding "what" tasks you need to perform, also ask "why" your tasks are important and how they will impact the rest of the project or other people's work.
|
||||
|
||||
Irrespective of what you build, how big or small it is, how glorified or dull is the outcome, you need to know the impact of it on end users and your internal customers (like product/project managers, quality assurance team, documentation team, whoever).
|
||||
|
||||
Once you look at the bigger picture and act accordingly, your margin of error reduces automatically.
|
||||
|
||||
## Some More Advice and Wrapping Up
|
||||
|
||||
I wanted to share all this career advice with you because I have been on the other side and learned the hard way. Before I move on to write my next article or record my next video, one more quick tip for you: make sure you work to build up your finances.
|
||||
|
||||
Financial independence brings peace and the mental stability to think wildly about things you want to pursue in your career. But getting to the point of financial stability is not an overnight thing. You need to plan, save, and invest wisely such that your money grows faster than your age.
|
||||
|
||||
I am not a finance expert, but I relied on some good ones and took their suggestions early on. If you have the opportunity and mindset to build your finances for the future, the time is now.
|
||||
|
||||
That's all for now. I hope you found this article informative and insightful. I regularly publish meaningful posts on my [GreenRoots Blog](https://blog.greenroots.info/), you may find them helpful, too.
|
||||
|
||||
Let's connect.
|
||||
|
||||
* I am an educator on my YouTube channel, `tapaScript`. Please [SUBSCRIBE](https://www.youtube.com/tapasadhikary?sub%5Fconfirmation=1) to the channel if you want to learn JavaScript, ReactJS, Next.js, Node.js, Git, and all about Web Development in the fundamental way.
|
||||
* [Follow me on X (Twitter](https://twitter.com/tapasadhikary)) or [LinkedIn](https://www.linkedin.com/in/tapasadhikary/) if you don't want to miss the daily dose of Web Development and Programming Tips.
|
||||
* Find all my public speaking talks [here](https://www.tapasadhikary.com/talks).
|
||||
* Check out and follow my Open Source work on [GitHub](https://github.com/atapas).
|
||||
|
||||
See you soon with my next article. Until then, please take care of yourself, and stay happy.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. [Get started](https://www.freecodecamp.org/learn/)
|
||||
265
Read Later/2023-11-21 - Conventional Commits.md
Normal file
265
Read Later/2023-11-21 - Conventional Commits.md
Normal file
|
|
@ -0,0 +1,265 @@
|
|||
---
|
||||
id: 2a685647-d920-4ba6-b837-3ee29a2f7f10
|
||||
title: |
|
||||
Conventional Commits
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-21 16:36:37
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-www-conventionalcommits-org-en-v-1-0-0-18bf36268eb
|
||||
url_original: |
|
||||
https://www.conventionalcommits.org/en/v1.0.0/
|
||||
---
|
||||
|
||||
# Conventional Commits
|
||||
|
||||
## Highlights
|
||||
|
||||
The commit message should be structured as follows:
|
||||
|
||||
---
|
||||
|
||||
```fortran
|
||||
[optional scope]:
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer(s)]
|
||||
```
|
||||
|
||||
[source](https://omnivore.app/me/https-www-conventionalcommits-org-en-v-1-0-0-18bf36268eb#0a71a3f4-0b81-4ccf-849b-f45c65951d5b)
|
||||
|
||||
---
|
||||
|
||||
## Specification
|
||||
|
||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space.
|
||||
2. The type `feat` MUST be used when a commit adds a new feature to your application or library.
|
||||
3. The type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):`
|
||||
5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_.
|
||||
6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
|
||||
7. A commit body is free-form and MAY consist of any number of newline separated paragraphs.
|
||||
8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:` or `#` separator, followed by a string value (this is inspired by the[git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
|
||||
9. A footer’s token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token.
|
||||
10. A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
|
||||
11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
|
||||
12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g.,_BREAKING CHANGE: environment variables now take precedence over config files_.
|
||||
13. If included in the type/scope prefix, breaking changes MUST be indicated by a`!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
|
||||
14. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: update ref docs._
|
||||
15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
|
||||
16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.
|
||||
|
||||
[source](https://omnivore.app/me/https-www-conventionalcommits-org-en-v-1-0-0-18bf36268eb#5670099d-60fe-4b9c-82b9-814e423c0e61)
|
||||
|
||||
---
|
||||
|
||||
### What do I do if the commit conforms to more than one of the commit types?
|
||||
|
||||
Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs.
|
||||
|
||||
[source](https://omnivore.app/me/https-www-conventionalcommits-org-en-v-1-0-0-18bf36268eb#6ae81ced-efe6-464a-8026-c2f286faf4b7)
|
||||
|
||||
---
|
||||
|
||||
### How does this relate to SemVer?
|
||||
|
||||
`fix` type commits should be translated to `PATCH` releases. `feat` type commits should be translated to `MINOR` releases. Commits with `BREAKING CHANGE` in the commits, regardless of type, should be translated to `MAJOR` releases.
|
||||
|
||||
[source](https://omnivore.app/me/https-www-conventionalcommits-org-en-v-1-0-0-18bf36268eb#6876934a-5761-49f8-8905-3153e5d667b7)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
## [](#summary)Summary
|
||||
|
||||
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with [SemVer](http://semver.org/), by describing the features, fixes, and breaking changes made in commit messages.
|
||||
|
||||
==The commit message should be structured as follows:==
|
||||
|
||||
---
|
||||
|
||||
```fortran
|
||||
<type>[optional scope]: <description>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer(s)]
|
||||
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
The commit contains the following structural elements, to communicate intent to the consumers of your library:
|
||||
|
||||
1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [PATCH](http://semver.org/#summary) in Semantic Versioning).
|
||||
2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [MINOR](http://semver.org/#summary) in Semantic Versioning).
|
||||
3. **BREAKING CHANGE:** a commit that has a footer `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change (correlating with [MAJOR](http://semver.org/#summary) in Semantic Versioning). A BREAKING CHANGE can be part of commits of any _type_.
|
||||
4. _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `build:`, `chore:`,`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
|
||||
5. _footers_ other than `BREAKING CHANGE: <description>` may be provided and follow a convention similar to[git trailer format](https://git-scm.com/docs/git-interpret-trailers).
|
||||
|
||||
Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE).A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.
|
||||
|
||||
## [](#examples)Examples
|
||||
|
||||
### [](#commit-message-with-description-and-breaking-change-footer)Commit message with description and breaking change footer
|
||||
|
||||
```routeros
|
||||
feat: allow provided config object to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||
|
||||
```
|
||||
|
||||
### [](#commit-message-with--to-draw-attention-to-breaking-change)Commit message with `!` to draw attention to breaking change
|
||||
|
||||
```routeros
|
||||
feat!: send an email to the customer when a product is shipped
|
||||
|
||||
```
|
||||
|
||||
### [](#commit-message-with-scope-and--to-draw-attention-to-breaking-change)Commit message with scope and `!` to draw attention to breaking change
|
||||
|
||||
```routeros
|
||||
feat(api)!: send an email to the customer when a product is shipped
|
||||
|
||||
```
|
||||
|
||||
### [](#commit-message-with-both--and-breaking-change-footer)Commit message with both `!` and BREAKING CHANGE footer
|
||||
|
||||
```crmsh
|
||||
chore!: drop support for Node 6
|
||||
|
||||
BREAKING CHANGE: use JavaScript features not available in Node 6.
|
||||
|
||||
```
|
||||
|
||||
### [](#commit-message-with-no-body)Commit message with no body
|
||||
|
||||
```avrasm
|
||||
docs: correct spelling of CHANGELOG
|
||||
|
||||
```
|
||||
|
||||
### [](#commit-message-with-scope)Commit message with scope
|
||||
|
||||
```stylus
|
||||
feat(lang): add Polish language
|
||||
|
||||
```
|
||||
|
||||
### [](#commit-message-with-multi-paragraph-body-and-multiple-footers)Commit message with multi-paragraph body and multiple footers
|
||||
|
||||
```http
|
||||
fix: prevent racing of requests
|
||||
|
||||
Introduce a request id and a reference to latest request. Dismiss
|
||||
incoming responses other than from latest request.
|
||||
|
||||
Remove timeouts which were used to mitigate the racing issue but are
|
||||
obsolete now.
|
||||
|
||||
Reviewed-by: Z
|
||||
Refs: #123
|
||||
|
||||
```
|
||||
|
||||
## [](#specification)==Specification==
|
||||
|
||||
==The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in== ==[RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)====.==
|
||||
|
||||
1. ==Commits MUST be prefixed with a type, which consists of a noun,== `==feat==`==,== `==fix==`==, etc., followed
|
||||
by the OPTIONAL scope, OPTIONAL== `==!==`==, and REQUIRED terminal colon and space.==
|
||||
2. ==The type== `==feat==` ==MUST be used when a commit adds a new feature to your application or library.==
|
||||
3. ==The type== `==fix==` ==MUST be used when a commit represents a bug fix for your application.==
|
||||
4. ==A scope MAY be provided after a type. A scope MUST consist of a noun describing a
|
||||
section of the codebase surrounded by parenthesis, e.g.,== `==fix====(parser)====:==`
|
||||
5. ==A description MUST immediately follow the colon and space after the type/scope prefix.
|
||||
The description is a short summary of the code changes, e.g.,== _==fix: array parsing issue when multiple spaces were contained in string==_==.==
|
||||
6. ==A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.==
|
||||
7. ==A commit body is free-form and MAY consist of any number of newline separated paragraphs.==
|
||||
8. ==One or more footers MAY be provided one blank line after the body. Each footer MUST consist of
|
||||
a word token, followed by either a== `==:====<====space====>==` ==or== `==<====space====>====#==` ==separator, followed by a string value (this is inspired by the====[git trailer convention](https://git-scm.com/docs/git-interpret-trailers)====).==
|
||||
9. ==A footer’s token MUST use== `==-==` ==in place of whitespace characters, e.g.,== `==Acked-====by==` ==(this helps differentiate
|
||||
the footer section from a multi-paragraph body). An exception is made for== `==BREAKING== ==CHANGE==`==, which MAY also be used as a token.==
|
||||
10. ==A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer
|
||||
token/separator pair is observed.==
|
||||
11. ==Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the
|
||||
footer.==
|
||||
12. ==If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g.,==_==BREAKING CHANGE: environment variables now take precedence over config files==_==.==
|
||||
13. ==If included in the type/scope prefix, breaking changes MUST be indicated by a==`==!==` ==immediately before the== `==:==`==. If== `==!==` ==is used,== `==BREAKING== ==CHANGE:==` ==MAY be omitted from the footer section,
|
||||
and the commit description SHALL be used to describe the breaking change.==
|
||||
14. ==Types other than== `==feat==` ==and== `==fix==` ==MAY be used in your commit messages, e.g.,== _==docs: update ref docs.==_
|
||||
15. ==The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.==
|
||||
16. ==BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.==
|
||||
|
||||
## [](#why-use-conventional-commits)Why Use Conventional Commits
|
||||
|
||||
* Automatically generating CHANGELOGs.
|
||||
* Automatically determining a semantic version bump (based on the types of commits landed).
|
||||
* Communicating the nature of changes to teammates, the public, and other stakeholders.
|
||||
* Triggering build and publish processes.
|
||||
* Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
|
||||
|
||||
## [](#faq)FAQ
|
||||
|
||||
### [](#how-should-i-deal-with-commit-messages-in-the-initial-development-phase)How should I deal with commit messages in the initial development phase?
|
||||
|
||||
We recommend that you proceed as if you’ve already released the product. Typically _somebody_, even if it’s your fellow software developers, is using your software. They’ll want to know what’s fixed, what breaks etc.
|
||||
|
||||
### [](#are-the-types-in-the-commit-title-uppercase-or-lowercase)Are the types in the commit title uppercase or lowercase?
|
||||
|
||||
Any casing may be used, but it’s best to be consistent.
|
||||
|
||||
### [](#what-do-i-do-if-the-commit-conforms-to-more-than-one-of-the-commit-types)==What do I do if the commit conforms to more than one of the commit types?==
|
||||
|
||||
==Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs.==
|
||||
|
||||
### [](#doesnt-this-discourage-rapid-development-and-fast-iteration)Doesn’t this discourage rapid development and fast iteration?
|
||||
|
||||
It discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors.
|
||||
|
||||
### [](#might-conventional-commits-lead-developers-to-limit-the-type-of-commits-they-make-because-theyll-be-thinking-in-the-types-provided)Might Conventional Commits lead developers to limit the type of commits they make because they’ll be thinking in the types provided?
|
||||
|
||||
Conventional Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Commits allows your team to come up with their own types and change those types over time.
|
||||
|
||||
### [](#how-does-this-relate-to-semver)==How does this relate to SemVer?==
|
||||
|
||||
`==fix==` ==type commits should be translated to== `==PATCH==` ==releases.== `==feat==` ==type commits should be translated to== `==MINOR==` ==releases. Commits with== `==BREAKING== ==CHANGE==` ==in the commits, regardless of type, should be translated to== `==MAJOR==` ==releases.==
|
||||
|
||||
### [](#how-should-i-version-my-extensions-to-the-conventional-commits-specification-eg-jameswomackconventional-commit-spec)How should I version my extensions to the Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`?
|
||||
|
||||
We recommend using SemVer to release your own extensions to this specification (and encourage you to make these extensions!)
|
||||
|
||||
### [](#what-do-i-do-if-i-accidentally-use-the-wrong-commit-type)What do I do if I accidentally use the wrong commit type?
|
||||
|
||||
#### [](#when-you-used-a-type-thats-of-the-spec-but-not-the-correct-type-eg-fix-instead-of-feat)When you used a type that’s of the spec but not the correct type, e.g. `fix` instead of `feat`
|
||||
|
||||
Prior to merging or releasing the mistake, we recommend using `git rebase -i` to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.
|
||||
|
||||
#### [](#when-you-used-a-type-not-of-the-spec-eg-feet-instead-of-feat)When you used a type _not_ of the spec, e.g. `feet` instead of `feat`
|
||||
|
||||
In a worst case scenario, it’s not the end of the world if a commit lands that does not meet the Conventional Commits specification. It simply means that commit will be missed by tools that are based on the spec.
|
||||
|
||||
### [](#do-all-my-contributors-need-to-use-the-conventional-commits-specification)Do all my contributors need to use the Conventional Commits specification?
|
||||
|
||||
No! If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they’re merged—adding no workload to casual committers. A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.
|
||||
|
||||
### [](#how-does-conventional-commits-handle-revert-commits)How does Conventional Commits handle revert commits?
|
||||
|
||||
Reverting code can be complicated: are you reverting multiple commits? if you revert a feature, should the next release instead be a patch?
|
||||
|
||||
Conventional Commits does not make an explicit effort to define revert behavior. Instead we leave it to tooling authors to use the flexibility of _types_ and _footers_ to develop their logic for handling reverts.
|
||||
|
||||
One recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted:
|
||||
|
||||
```http
|
||||
revert: let us never again speak of the noodle incident
|
||||
|
||||
Refs: 676104e, a215868
|
||||
|
||||
```
|
||||
|
|
@ -0,0 +1,253 @@
|
|||
---
|
||||
id: 1996b6ce-9449-415d-8c18-609ddb9cd580
|
||||
title: |
|
||||
How to Write Better Git Commit Messages – A Step-By-Step Guide
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-21 12:10:32
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-www-freecodecamp-org-news-how-to-write-better-git-commit-m-18bf26ec55f
|
||||
url_original: |
|
||||
https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/
|
||||
---
|
||||
|
||||
# How to Write Better Git Commit Messages – A Step-By-Step Guide
|
||||
|
||||
## Highlights
|
||||
|
||||
To come up with thoughtful commits, consider the following:
|
||||
|
||||
* Why have I made these changes?
|
||||
* What effect have my changes made?
|
||||
* Why was the change needed?
|
||||
* What are the changes in reference to?
|
||||
|
||||
[source](https://omnivore.app/me/https-www-freecodecamp-org-news-how-to-write-better-git-commit-m-18bf26ec55f#b1693951-0a92-44f4-804d-7c5008bf3113)
|
||||
|
||||
---
|
||||
|
||||
See the differences below:
|
||||
|
||||
1. `git commit -m 'Add margin'`
|
||||
2. `git commit -m 'Add margin to nav items to prevent them from overlapping the logo'`
|
||||
|
||||
[source](https://omnivore.app/me/https-www-freecodecamp-org-news-how-to-write-better-git-commit-m-18bf26ec55f#a3c842a2-18b0-46b9-8131-c37ecd867c19)
|
||||
|
||||
---
|
||||
|
||||
Conventional Commit is a formatting convention that provides a set of rules to formulate a consistent commit message structure like so:
|
||||
|
||||
```fortran
|
||||
[optional scope]:
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer(s)]
|
||||
```
|
||||
|
||||
The commit type can include the following:
|
||||
|
||||
* `feat` – a new feature is introduced with the changes
|
||||
* `fix` – a bug fix has occurred
|
||||
* `chore` – changes that do not relate to a fix or feature and don't modify src or test files (for example updating dependencies)
|
||||
* `refactor` – refactored code that neither fixes a bug nor adds a feature
|
||||
* `docs` – updates to documentation such as a the README or other markdown files
|
||||
* `style` – changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on.
|
||||
* `test` – including new or correcting previous tests
|
||||
* `perf` – performance improvements
|
||||
* `ci` – continuous integration related
|
||||
* `build` – changes that affect the build system or external dependencies
|
||||
* `revert` – reverts a previous commit
|
||||
|
||||
[source](https://omnivore.app/me/https-www-freecodecamp-org-news-how-to-write-better-git-commit-m-18bf26ec55f#f3ea8f19-6480-43ac-a72f-2856ee003fb6)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
When first introduced to Git, it's typical for developers to feel uncomfortable with the process.
|
||||
|
||||
You might feel uncertainty when encountering the Git commit message, unsure how to properly summarize the changes you've made and why you've made them. But the earlier in your career you can develop good committing habits, the better.
|
||||
|
||||
Have you ever wondered how you can improve your Git commit messages? This guide outlines steps to elevate your commit messages that you can start implementing today.
|
||||
|
||||
This article assumes you already understand basic Git workflow. If not, I suggest reading through the [Git Handbook](https://guides.github.com/introduction/git-handbook/).
|
||||
|
||||
It is also important to note that you should follow your team's conventions first and foremost. These tips are based on suggestions based upon research and general consensus from the community. But by the end of this article you may have some implementations to suggest that may help your team's workflow.
|
||||
|
||||
> I think git enters a whole other realm the moment you start working in teams -- there are so many cool different flows and ways that people can commit code, share code, and add code to your repo open-source or closed-source-wise. — [Scott Tolinski, Syntax.fm](https://syntax.fm/).
|
||||
|
||||
## Why should you write better commit messages?
|
||||
|
||||
I challenge you to open up a personal project or any repository for that matter and run `git log` to view a list of old commit messages. The vast majority of us who have run through tutorials or made quick fixes will say "Yep... I have absolutely no idea what I meant by 'Fix style' 6 months ago."
|
||||
|
||||
Perhaps you have encountered code in a professional environment where you had no idea what it was doing or meant for. You've been left in the dark without code comments or a traceable history, and even wondering "what are the odds this will break everything if I remove this line?"
|
||||
|
||||
### Back to the Future
|
||||
|
||||
By writing good commits, you are simply future-proofing yourself. You could save yourself and/or coworkers hours of digging around while troubleshooting by providing that helpful description.
|
||||
|
||||
The extra time it takes to write a thoughtful commit message as a letter to your potential future self is extremely worthwhile. On large scale projects, documentation is imperative for maintenance.
|
||||
|
||||
Collaboration and communication are of utmost importance within engineering teams. The Git commit message is a prime example of this. I highly suggest setting up a convention for commit messages on your team if you do not already have one in place.
|
||||
|
||||
## The Anatomy of a Commit Message
|
||||
|
||||
#### Basic:
|
||||
|
||||
`git commit -m <message>`
|
||||
|
||||
#### Detailed:
|
||||
|
||||
`git commit -m <title> -m <description>`
|
||||
|
||||
|
||||
|
||||
## 5 Steps to Write Better Commit Messages
|
||||
|
||||
Let's summarize the suggested guidelines:
|
||||
|
||||
1. Capitalization and Punctuation: Capitalize the first word and do not end in punctuation. If using Conventional Commits, remember to use all lowercase.
|
||||
2. Mood: Use imperative mood in the subject line. Example – `Add fix for dark mode toggle state`. Imperative mood gives the tone you are giving an order or request.
|
||||
3. Type of Commit: Specify the type of commit. It is recommended and can be even more beneficial to have a consistent set of words to describe your changes. Example: Bugfix, Update, Refactor, Bump, and so on. See the section on Conventional Commits below for additional information.
|
||||
4. Length: The first line should ideally be no longer than 50 characters, and the body should be restricted to 72 characters.
|
||||
5. Content: Be direct, try to eliminate filler words and phrases in these sentences (examples: though, maybe, I think, kind of). Think like a journalist.
|
||||
|
||||
### How to Find Your Inner Journalist
|
||||
|
||||
I never quite thought my Journalism minor would benefit my future career as a Software Engineer, but here we are!
|
||||
|
||||
Journalists and writers ask themselves questions to ensure their article is detailed, straightforward, and answers all of the reader's questions.
|
||||
|
||||
When writing an article they look to answer _who_, _what_, _where_, _when_, _why_ and _how._ For committing purposes, it is most important to answer the what and why for our commit messages.
|
||||
|
||||
==To come up with thoughtful commits, consider the following:==
|
||||
|
||||
* ==Why have I made these changes?==
|
||||
* ==What effect have my changes made?==
|
||||
* ==Why was the change needed?==
|
||||
* ==What are the changes in reference to?==
|
||||
|
||||
Assume the reader does not understand what the commit is addressing. They may not have access to the story addressing the detailed background of the change.
|
||||
|
||||
Don't expect the code to be self-explanatory. This is similar to the point above.
|
||||
|
||||
It might seem obvious to you, the programmer, if you're updating something like CSS styles since it is visual. You may have intimate knowledge on why these changes were needed at the time, but it's unlikely you will recall why you did that hundreds of pull requests later.
|
||||
|
||||
Make it clear _why_ that change was made, and note if it may be crucial for the functionality or not.
|
||||
|
||||
==See the differences below:==
|
||||
|
||||
1. `==git== ==commit -m== =='Add margin'==`
|
||||
2. `==git commit -m 'Add margin== ==to== ==nav items== ==to== ==prevent them== ==from== ==overlapping== ==the== ==logo'==`
|
||||
|
||||
It is clear which of these would be more useful to future readers.
|
||||
|
||||
Pretend you're writing an important newsworthy article. Give the headline that will sum up what happened and what is important. Then, provide further details in the body in an organized fashion.
|
||||
|
||||
In filmmaking, it is often quoted "show, don't tell" using visuals as the communication medium compared to a verbal explanation of what is happening.
|
||||
|
||||
In our case, "**tell**, don't \[just\] show" – though we have some visuals at our disposal such as the browser, most of the specifics come from reading the physical code.
|
||||
|
||||
If you're a VSCode user, download the [Git Blame](https://marketplace.visualstudio.com/items?itemName=waderyan.gitblame) extension. This is a prime example of when useful commit messages are helpful to future developers.
|
||||
|
||||
This plugin will list the person who made the change, the date of the changes, as well as the commit message commented inline.
|
||||
|
||||
Imagine how useful this could be in troubleshooting a bug or back-tracing changes made. Other honorable mentions to see Git historical information are [Git History](https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory) and [GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens).
|
||||
|
||||
|
||||
|
||||
## Conventional Commits
|
||||
|
||||
Now that we've covered basic commit structure of a good commit message, I'd like to introduce Conventional Commits to help provide some detail on creating solid commit messages.
|
||||
|
||||
At D2iQ, we use Conventional Commit which is a great practice among engineering teams. ==Conventional Commit is a formatting convention that provides a set of rules to formulate a consistent commit message structure like so:==
|
||||
|
||||
```fortran
|
||||
<type>[optional scope]: <description>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer(s)]
|
||||
```
|
||||
|
||||
==The commit type can include the following:==
|
||||
|
||||
* `==feat==` ==– a new feature is introduced with the changes==
|
||||
* `==fix==` ==– a bug fix has occurred==
|
||||
* `==chore==` ==– changes that do not relate to a fix or feature and don't modify src or test files (for example updating dependencies)==
|
||||
* `==ref====actor==` ==– refactored code that neither fixes a bug nor adds a feature==
|
||||
* `==docs==` ==– updates to documentation such as a the README or other markdown files==
|
||||
* `==style==` ==– changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on.==
|
||||
* `==test==` ==– including new or correcting previous tests==
|
||||
* `==perf==` ==– performance improvements==
|
||||
* `==ci==` ==– continuous integration related==
|
||||
* `==build==` ==– changes that affect the build system or external dependencies==
|
||||
* `==revert==` ==– reverts a previous commit==
|
||||
|
||||
The commit type subject line should be all lowercase with a character limit to encourage succinct descriptions.
|
||||
|
||||
The optional commit body should be used to provide further detail that cannot fit within the character limitations of the subject line description.
|
||||
|
||||
It is also a good location to utilize `BREAKING CHANGE: <description>` to note the reason for a breaking change within the commit.
|
||||
|
||||
The footer is also optional. We use the footer to link the JIRA story that would be closed with these changes for example: `Closes D2IQ-<JIRA #>` .
|
||||
|
||||
#### Full Conventional Commit Example
|
||||
|
||||
```http
|
||||
fix: fix foo to enable bar
|
||||
|
||||
This fixes the broken behavior of the component by doing xyz.
|
||||
|
||||
BREAKING CHANGE
|
||||
Before this fix foo wasn't enabled at all, behavior changes from <old> to <new>
|
||||
|
||||
Closes D2IQ-12345
|
||||
```
|
||||
|
||||
To ensure that these committing conventions remain consistent across developers, commit message linting can be configured before changes are able to be pushed up. [Commitizen](https://commitizen-tools.github.io/commitizen/) is a great tool to enforce standards, sync up semantic versioning, along with other helpful features.
|
||||
|
||||
To aid in adoption of these conventions, it's helpful to include guidelines for commits in a contributing or README markdown file within your projects.
|
||||
|
||||
Conventional Commit works particularly well with semantic versioning (learn more at [SemVer.org](https://semver.org/)) where commit types can update the appropriate version to release. You can also [read more about Conventional Commits here](https://www.conventionalcommits.org/en/v1.0.0/).
|
||||
|
||||
## Commit Message Comparisons
|
||||
|
||||
Review the following messages and see how many of the suggested guidelines they check off in each category.
|
||||
|
||||
#### Good
|
||||
|
||||
* `feat: improve performance with lazy load implementation for images`
|
||||
* `chore: update npm dependency to latest version`
|
||||
* `Fix bug preventing users from submitting the subscribe form`
|
||||
* `Update incorrect client phone number within footer body per client request`
|
||||
|
||||
#### Bad
|
||||
|
||||
* `fixed bug on landing page`
|
||||
* `Changed style`
|
||||
* `oops`
|
||||
* `I think I fixed it this time?`
|
||||
* empty commit messages
|
||||
|
||||
## Conclusion
|
||||
|
||||
Writing good commit messages is an extremely beneficial skill to develop, and it helps you communicate and collaborate with your team. Commits serve as an archive of changes. They can become an ancient manuscript to help us decipher the past, and make reasoned decisions in the future.
|
||||
|
||||
There is an existing set of agreed-upon standards we can follow, but as long as your team agrees upon a convention that is descriptive with future readers in mind, there will undoubtedly be long-term benefits.
|
||||
|
||||
In this article, we've learned some tactics to level up our commit messages. How do you think these techniques can improve your commits?
|
||||
|
||||
I hope you've learned something new, thanks for reading!
|
||||
|
||||
Connect with me on Twitter [@ui\_natalie](https://twitter.com/ui%5Fnatalie).
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. [Get started](https://www.freecodecamp.org/learn/)
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
---
|
||||
id: f5956559-3eb2-4717-93bd-3f3a2f0c5549
|
||||
title: |
|
||||
The Life-Changing Magic of Tidying Up Your To-Do List
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-21 08:05:01
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-todoist-com-inspiration-life-changing-magic-tidying-todois-18bf18e00a2
|
||||
url_original: |
|
||||
https://todoist.com/inspiration/life-changing-magic-tidying-todoist
|
||||
---
|
||||
|
||||
# The Life-Changing Magic of Tidying Up Your To-Do List
|
||||
|
||||
## Notes
|
||||
|
||||
Before you even start looking at your tasks, write down what having a neatly organized and prioritized to-do list would mean for your life. Maybe you want to run a successful business, get in shape, be more present with your family, have closer relationships with friends, or lead a more adventurous life.
|
||||
|
||||
Find a medium that lets you truly envision the details. You can describe it in words, mind map it, draw it out, create a Pinterest board, collect YouTube videos, or brainstorm in whatever form suits you.
|
||||
|
||||
Why do you want to get in shape? The answer might be "to have more energy and feel more confident." Why do you want to have more energy and feel more confident? Maybe the answer is "to be more fully yourself and stop worrying about what other people think of you." Ask yourself "why" 3-5 times for every item in your vision.
|
||||
## Original
|
||||
|
||||
---
|
||||
|
||||
## Other readers also enjoyed...
|
||||
|
||||
|
||||
|
||||
## How to Vanquish Busywork and Spend More Time on What Matters
|
||||
|
||||
These tips for improving your focus and productivity will help you avoid getting sucked into busywork.
|
||||
|
||||
[Read more](https://todoist.com/inspiration/busywork-productivity-focus)
|
||||
* [Productivity](https://todoist.com/inspiration/category/productivity)
|
||||
|
||||
|
||||
|
||||
## How to Ask to Work From Home (With Exact Scripts & Email Templates to Aid Your Negotiation)
|
||||
|
||||
Follow these 9 steps to secure a remote work arrangement even in the most skeptical of organizations
|
||||
|
||||
[Read more](https://todoist.com/inspiration/how-to-ask-to-work-from-home)
|
||||
* [Remote Work](https://todoist.com/inspiration/category/remote-work)
|
||||
|
||||
|
||||
|
||||
## How to Complete Your Own Annual Review
|
||||
|
||||
Reflect on work, health, finances, and more with a personal year in review
|
||||
|
||||
[Read more](https://todoist.com/inspiration/annual-review)
|
||||
* [Goals](https://todoist.com/inspiration/category/goals)
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
id: 01b3b6c1-27ae-40a4-99fa-d297febc1e7c
|
||||
title: |
|
||||
tbaggery - A Note About Git Commit Messages
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-21 11:59:10
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-tbaggery-com-2008-04-19-a-note-about-git-commit-messages-h-18bf2646727
|
||||
url_original: |
|
||||
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
||||
---
|
||||
|
||||
# tbaggery - A Note About Git Commit Messages
|
||||
|
||||
## Notes
|
||||
|
||||
- Tratar de mantener el limite que muestra Treesitter
|
||||
- Utilizar la primera linea como "el asunto de un correo"
|
||||
- Escribir el cuerpo con una separación de una linea en blanco
|
||||
- Usar lenguaje imperativo, _"Fix bug"_ en vez de _"Fixes bug."_.
|
||||
## Original
|
||||
|
||||
I want to take a moment to elaborate on what makes a well formed commit message. I think the best practices for commit message formatting is one of the little details that makes Git great. Understandably, some of the first commits to rails.git have messages of the really-long-line variety, and I want to expand on why this is a poor practice.
|
||||
|
||||
Here’s a model Git commit message:
|
||||
|
||||
```livecodeserver
|
||||
Capitalized, short (50 chars or less) summary
|
||||
|
||||
More detailed explanatory text, if necessary. Wrap it to about 72
|
||||
characters or so. In some contexts, the first line is treated as the
|
||||
subject of an email and the rest of the text as the body. The blank
|
||||
line separating the summary from the body is critical (unless you omit
|
||||
the body entirely); tools like rebase can get confused if you run the
|
||||
two together.
|
||||
|
||||
Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
|
||||
or "Fixes bug." This convention matches up with commit messages generated
|
||||
by commands like git merge and git revert.
|
||||
|
||||
Further paragraphs come after blank lines.
|
||||
|
||||
- Bullet points are okay, too
|
||||
|
||||
- Typically a hyphen or asterisk is used for the bullet, followed by a
|
||||
single space, with blank lines in between, but conventions vary here
|
||||
|
||||
- Use a hanging indent
|
||||
|
||||
```
|
||||
|
||||
Let’s start with a few of the reasons why wrapping your commit messages to 72 columns is a good thing.
|
||||
|
||||
* `git log` doesn’t do any special special wrapping of the commit messages. With the default pager of `less -S`, this means your paragraphs flow far off the edge of the screen, making them difficult to read. On an 80 column terminal, if we subtract 4 columns for the indent on the left and 4 more for symmetry on the right, we’re left with 72 columns.
|
||||
* `git format-patch --stdout` converts a series of commits to a series of emails, using the messages for the message body. Good email netiquette dictates we wrap our plain text emails such that there’s room for a few levels of nested reply indicators without overflow in an 80 column terminal. (The current rails.git workflow doesn’t include email, but who knows what the future will bring.)
|
||||
|
||||
Vim users can meet this requirement by installing my [vim-git runtime files](http://github.com/tpope/vim-git), or by simply setting the following option in your git commit message file:
|
||||
|
||||
For Textmate, you can adjust the “Wrap Column” option under the view menu, then use `^Q` to rewrap paragraphs (be sure there’s a blank line afterwards to avoid mixing in the comments). Here’s a shell command to add 72 to the menu so you don’t have to drag to select each time:
|
||||
|
||||
```lsl
|
||||
$ defaults write com.macromates.textmate OakWrapColumns '( 40, 72, 78 )'
|
||||
|
||||
```
|
||||
|
||||
More important than the mechanics of formatting the body is the practice of having a subject line. As the example indicates, you should shoot for about 50 characters (though this isn’t a hard maximum) and always, always follow it with a blank line. This first line should be a concise summary of the changes introduced by the commit; if there are any technical details that cannot be expressed in these strict size constraints, put them in the body instead. The subject line is used all over Git, oftentimes in truncated form if too long of a message was used. The following are just a handful of examples of where it ends up:
|
||||
|
||||
* `git log --pretty=oneline` shows a terse history mapping containing the commit id and the summary
|
||||
* `git rebase --interactive` provides the summary for each commit in the editor it invokes
|
||||
* if the config option `merge.summary` is set, the summaries from all merged commits will make their way into the merge commit message
|
||||
* `git shortlog` uses summary lines in the changelog-like output it produces
|
||||
* `git format-patch`, `git send-email`, and related tools use it as the subject for emails
|
||||
* reflogs, a local history accessible with `git reflog` intended to help you recover from stupid mistakes, get a copy of the summary
|
||||
* `gitk` has a column for the summary
|
||||
* GitHub uses the summary in various places in their user interface
|
||||
|
||||
The subject/body distinction may seem unimportant but it’s one of many subtle factors that makes Git history so much more pleasant to work with than Subversion.
|
||||
|
|
@ -0,0 +1,182 @@
|
|||
---
|
||||
id: a82f2e4b-829e-48a5-9e5c-c152860743a7
|
||||
title: |
|
||||
Historias de usuario | Ejemplos y plantilla | Atlassian
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-12-24 18:35:22
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-www-atlassian-com-es-agile-project-management-user-stories-18c9dc0ecd1
|
||||
url_original: |
|
||||
https://www.atlassian.com/es/agile/project-management/user-stories
|
||||
---
|
||||
|
||||
# Historias de usuario | Ejemplos y plantilla | Atlassian
|
||||
|
||||
## Highlights
|
||||
|
||||
una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente.
|
||||
|
||||
[source](https://omnivore.app/me/https-www-atlassian-com-es-agile-project-management-user-stories-18c9dc0ecd1#d1988eb3-4939-4bf3-b932-44aad141c065)
|
||||
|
||||
---
|
||||
|
||||
Las historias encajan perfectamente en marcos ágiles como [scrum](https://www.atlassian.com/es/agile/scrum) y [kanban](https://www.atlassian.com/es/agile/kanban). En el scrum, las historias de los usuarios se añaden a los sprints y se van realizando a lo largo del sprint. Los equipos de kanban incorporan las historias de usuario en su backlog y las ejecutan siguiendo su flujo de trabajo.
|
||||
|
||||
[source](https://omnivore.app/me/https-www-atlassian-com-es-agile-project-management-user-stories-18c9dc0ecd1#3e9e29ab-43db-4c8f-b517-c2f3b8892432)
|
||||
|
||||
---
|
||||
|
||||
Las historias de usuario son también los componentes básicos de los marcos ágiles más grandes, como los epics y las iniciativas. Los epics son grandes elementos de trabajo divididos en un conjunto de historias, y varios epics constituyen una iniciativa.
|
||||
|
||||
[source](https://omnivore.app/me/https-www-atlassian-com-es-agile-project-management-user-stories-18c9dc0ecd1#8f41f654-4b72-4789-b848-b46c2d185291)
|
||||
|
||||
---
|
||||
|
||||
## Cómo escribir historias de usuario
|
||||
|
||||
Piensa en lo siguiente cuando escribas historias de usuario:
|
||||
|
||||
* **Definición de “Listo”**: la historia suele estar “lista” cuando el usuario puede completar la tarea descrita, pero debes asegurarte de definir lo que representa completarla.
|
||||
* **Describe tareas o subtareas**: decide qué pasos específicos deben completarse y quién es responsable de cada uno de ellos.
|
||||
* **Perfiles de usuario**: ¿para quién? Si hay varios usuarios finales, considera crear varias historias.
|
||||
* **Pasos ordenados**: escribe una historia para cada paso en un proceso más grande.
|
||||
* **Escucha el feedback**: habla con los usuarios y capta sus problemas o necesidades en lo que dicen. No es necesario tener que estar adivinando las historias cuando puedes obtenerlas de tus clientes.
|
||||
* **Tiempo**: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan hablar sobre el tiempo, y en su lugar confían en sus marcos de trabajo de estimación. Dado que las historias deberían completarse en un sprint, aquellas que puedan necesitar semanas o meses deberían dividirse en historias más pequeñas o considerarse un epic independiente.
|
||||
|
||||
[source](https://omnivore.app/me/https-www-atlassian-com-es-agile-project-management-user-stories-18c9dc0ecd1#536ca974-d30c-4d48-a02f-a9c16c469e01)
|
||||
|
||||
---
|
||||
|
||||
Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:
|
||||
|
||||
**“Como \[perfil\], \[quiero\] \[para\].”**
|
||||
|
||||
Desglosemos esta estructura:
|
||||
|
||||
* “Como \[perfil\]”: ¿para quién desarrollamos esto? No solo buscamos un puesto, buscamos el perfil de la persona. Max. Nuestro equipo debería comprender quién es Max. Con suerte hemos entrevistado a muchos Max. Comprendemos cómo trabaja esa persona, cómo piensa y cómo se siente. Sentimos empatía por Max.
|
||||
* “Quiere”: aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están intentando lograr realmente? Esta descripción debería realizarse con independencia de las implementaciones; si describes algún elemento de la IU y no el objetivo del usuario, estás cometiendo un error.
|
||||
* “Para”: ¿cómo encaja su deseo inmediato de hacer algo en la perspectiva general? ¿Cuál es el beneficio general que intentan lograr? ¿Cuál es el gran problema que debe resolverse?
|
||||
|
||||
[source](https://omnivore.app/me/https-www-atlassian-com-es-agile-project-management-user-stories-18c9dc0ecd1#74f6051c-6394-4c99-94c9-176857d9caf2)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
* [DevOps](#)
|
||||
* [Entrega continua](https://www.atlassian.com/es/continuous-delivery)
|
||||
* [Git](https://www.atlassian.com/es/git)
|
||||
* [Agile](https://www.atlassian.com/es/agile)
|
||||
* [Microservicios](https://www.atlassian.com/es/microservices)
|
||||
|
||||
Las historias de usuario son tareas de desarrollo que se suelen expresar como "persona + necesidad + propósito".
|
||||
|
||||
Resumen: _==una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente.==_
|
||||
|
||||
Es tentador pensar que las historias de usuario son, en pocas palabras, requisitos del sistema de software. Pero no lo son.
|
||||
|
||||
Un componente clave del desarrollo de software ágil es poner a las personas en primer lugar, y las historias de usuarios ponen a los usuarios finales reales en el centro de la conversación. Las historias utilizan un lenguaje no técnico para ofrecer contexto al equipo de desarrollo y sus esfuerzos. Después de leer una historia de usuario, el equipo sabe por qué está compilando lo que está compilando y qué valor crea.
|
||||
|
||||
Las historias de usuario son uno de los componentes centrales de un programa ágil. Ayudan a proporcionar un marco centrado en el usuario para el trabajo diario, lo que impulsa la colaboración y la creatividad y mejora el producto en general.
|
||||
|
||||
## ¿Qué son las historias de usuario ágiles?
|
||||
|
||||
Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es un objetivo final, no una función, expresado desde la perspectiva del usuario del software.
|
||||
|
||||
Una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final o cliente.
|
||||
|
||||
El propósito de una historia de usuario es articular cómo un elemento de trabajo entregará un valor particular al cliente. Ten en cuenta que los "clientes" no tienen por qué ser usuarios finales externos en el sentido tradicional, también pueden ser clientes internos o colegas dentro de tu organización que dependen de tu equipo.
|
||||
|
||||
Las historias de usuario son unas pocas frases en lenguaje sencillo que describen el resultado deseado. No entran en detalles, ya que los requisitos se añaden más tarde, una vez acordados por el equipo.
|
||||
|
||||
==Las historias encajan perfectamente en marcos ágiles como== ==[scrum](https://www.atlassian.com/es/agile/scrum)== ==y== ==[kanban](https://www.atlassian.com/es/agile/kanban)====. En el scrum, las historias de los usuarios se añaden a los sprints y se van realizando a lo largo del sprint. Los equipos de kanban incorporan las historias de usuario en su backlog y las ejecutan siguiendo su flujo de trabajo.== Es este trabajo sobre las historias de usuario lo que ayuda a los equipos de scrum a mejorar en la [estimación](https://www.atlassian.com/es/agile/project-management/estimation) y planificación de sprints, lo que conduce a un pronóstico más preciso y a una mayor agilidad. Gracias a las historias, los equipos de kanban aprenden a gestionar el trabajo en curso (WIP) y pueden perfeccionar aún más sus flujos de trabajo.
|
||||
|
||||
==Las historias de usuario son también los componentes básicos de los marcos ágiles más grandes, como los epics y las iniciativas. Los epics son grandes elementos de trabajo divididos en un conjunto de historias, y varios epics constituyen una iniciativa.== Estas estructuras más grandes garantizan que el trabajo diario del equipo de desarrollo contribuya a los objetivos de la organización incorporados en los epics y las iniciativas.
|
||||
|
||||
[Más información sobre epics e iniciativas](https://www.atlassian.com/es/agile/project-management/epics-stories-themes)
|
||||
|
||||
|
||||
|
||||
## ¿Por qué crear historias de usuario?
|
||||
|
||||
Para los equipos de desarrollo nuevos en la metodología ágil, las historias de usuario a veces parecen un paso más. ¿Por qué no dividir el gran proyecto ([el epic](https://www.atlassian.com/es/agile/project-management/epics)) en una serie de pasos y seguir adelante? Pero las historias dan al equipo un contexto importante y asocian las tareas con el valor que estas aportan.
|
||||
|
||||
Las historias de usuario tienen varios beneficios clave:
|
||||
|
||||
* **Las historias centran la atención en el usuario.** Una lista de tareas pendientes mantiene al equipo centrado en tareas que deben completarse, pero un conjunto de historias lo mantiene centrado en solucionar problemas para usuarios reales.
|
||||
* **Las historias permiten la colaboración.** Con el objetivo definido, el equipo puede colaborar para decidir cómo ofrecer un mejor servicio al usuario y cumplir con dicho objetivo.
|
||||
* **Las historias impulsan soluciones creativas.** Las historias fomentan que el equipo piense de forma crítica y creativa sobre cómo lograr mejor un objetivo.
|
||||
* **Las historias motivan.** Con cada historia el equipo de desarrollo disfruta de un pequeño reto y una pequeña victoria, lo que aumenta la motivación.
|
||||
|
||||
## Trabajar con historias de usuario
|
||||
|
||||
Una vez que se ha escrito una historia, es hora de integrarla en tu flujo de trabajo. Por lo general, una historia la escribe el propietario del producto, el gestor del producto o el gestor del programa, y la envía para su revisión.
|
||||
|
||||
Durante una reunión de planificación de sprint o iteración, el equipo decide qué historias afrontará en ese sprint. Los equipos discuten los requisitos y la funcionalidad que requiere cada historia de usuario. Esta es una oportunidad para ponerse técnico y creativo en la implementación de la historia por parte del equipo. Una vez acordados, estos requisitos se añaden a la historia.
|
||||
|
||||
Otro paso común en esta reunión es calificar las historias en función de su complejidad o tiempo hasta su finalización. Los equipos usan las tallas de las camisetas, la secuencia de Fibonacci o el Planning Poker para hacer las estimaciones adecuadas. Una historia debe ser de un tamaño que pueda completarse en un sprint; por lo tanto, cuando el equipo establezca las especificaciones de cada historia, se deben asegurar de dividir las historias que superen ese horizonte de finalización.
|
||||
|
||||
## ==Cómo escribir historias de usuario==
|
||||
|
||||
==Piensa en lo siguiente cuando escribas historias de usuario:==
|
||||
|
||||
* **==Definición de “Listo”==**==: la historia suele estar “lista” cuando el usuario puede completar la tarea descrita, pero debes asegurarte de definir lo que representa completarla.==
|
||||
* **==Describe tareas o subtareas==**==: decide qué pasos específicos deben completarse y quién es responsable de cada uno de ellos.==
|
||||
* **==Perfiles de usuario==**==: ¿para quién? Si hay varios usuarios finales, considera crear varias historias.==
|
||||
* **==Pasos ordenados==**==: escribe una historia para cada paso en un proceso más grande.==
|
||||
* **==Escucha el feedback==**==: habla con los usuarios y capta sus problemas o necesidades en lo que dicen. No es necesario tener que estar adivinando las historias cuando puedes obtenerlas de tus clientes.==
|
||||
* **==Tiempo==**==: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan hablar sobre el tiempo, y en su lugar confían en sus marcos de trabajo de estimación. Dado que las historias deberían completarse en un sprint, aquellas que puedan necesitar semanas o meses deberían dividirse en historias más pequeñas o considerarse un epic independiente.==
|
||||
|
||||
Una vez que las historias de usuario estén definidas de forma clara, debes asegurarte de que todo el equipo pueda verlas.
|
||||
|
||||
==Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:==
|
||||
|
||||
**==“Como [perfil], [quiero] [para].”==**
|
||||
|
||||
==Desglosemos esta estructura:==
|
||||
|
||||
* ==“Como [perfil]”: ¿para quién desarrollamos esto? No solo buscamos un puesto, buscamos el perfil de la persona. Max. Nuestro equipo debería comprender quién es Max. Con suerte hemos entrevistado a muchos Max. Comprendemos cómo trabaja esa persona, cómo piensa y cómo se siente. Sentimos empatía por Max.==
|
||||
* ==“Quiere”: aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están intentando lograr realmente? Esta descripción debería realizarse con independencia de las implementaciones; si describes algún elemento de la IU y no el objetivo del usuario, estás cometiendo un error.==
|
||||
* ==“Para”: ¿cómo encaja su deseo inmediato de hacer algo en la perspectiva general? ¿Cuál es el beneficio general que intentan lograr? ¿Cuál es el gran problema que debe resolverse?==
|
||||
|
||||
Por ejemplo, las historias de usuario pueden tener este aspecto:
|
||||
|
||||
* Como Max, quiero invitar a mis amigos, para que podamos disfrutar de este servicio juntos.
|
||||
* Como Sascha, quiero organizar mi trabajo, para poder sentir que tengo un mayor control.
|
||||
* Como gestor, quiero poder comprender el progreso de mis compañeros, para poder informar sobre nuestros éxitos y fallos.
|
||||
|
||||
Esta estructura no es obligatoria, pero resulta de ayuda para establecer una definición de "hecho". Cuando ese perfil puede alcanzar su valor deseado, la historia está completa. Recomendamos a nuestros equipos definir su propia estructura, y que no se desvíen de ella.
|
||||
|
||||
## Introducción a las historias de usuario ágiles
|
||||
|
||||
Las historias de los usuarios describen el por qué y el qué que hay detrás del trabajo diario de los miembros del equipo de desarrollo; a menudo las historias de usuario se expresan de la siguiente manera: _perfil + necesidad + propósito_. Entender su papel como fuente de verdad para lo que el equipo está entregando, pero también el por qué, es clave para un proceso sin problemas.
|
||||
|
||||
Empieza por evaluar el siguiente gran proyecto o el más apremiante (por ejemplo, un epic). Divídelo en historias de usuario más pequeñas y trabaja con el equipo de desarrollo para mejorarlo. Una vez que tus historias están fuera, donde todo el equipo puede verlas, ya tienes todo listo para empezar a trabajar.
|
||||
|
||||
.jpg?cdnVersion=1373)
|
||||
|
||||
Max Rehkopf
|
||||
|
||||
Como persona caótica que soy, confío en las prácticas de la metodología ágil y en los principios optimizados para poner orden en mi día a día. Me alegra compartir estas lecciones con otras personas a través de los muchos artículos, ponencias y vídeos que hago para Atlassian.
|
||||
|
||||
|
||||
|
||||
tutorial
|
||||
|
||||
#### Cómo crear historias de usuario en Jira Software
|
||||
|
||||
Descubre cómo los equipos pueden utilizar los tiques para realizar un seguimiento del trabajo que debe completarse.
|
||||
|
||||
[Probar el tutorial ](https://www.atlassian.com/es/agile/tutorials/issues)
|
||||
|
||||
|
||||
|
||||
artículo
|
||||
|
||||
#### ¿Qué son los puntos de historia y cómo se estiman?
|
||||
|
||||
Conoce por dentro los secretos de la estimación ágil y los puntos de historia. Una buena estimación ágil permite a los propietarios del producto optimizar sus procesos en términos de eficiencia e impacto.
|
||||
|
||||
[Leer el artículo ](https://www.atlassian.com/es/agile/project-management/estimation)
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
---
|
||||
id: 22bb5f59-fddb-4ab4-89dd-bb28fe723f4f
|
||||
title: |
|
||||
¿Qué son los puntos de historia en la metodología ágil y cómo se estiman?
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-12-24 18:36:25
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-www-atlassian-com-es-agile-project-management-estimation-18c9dc1e48a
|
||||
url_original: |
|
||||
https://www.atlassian.com/es/agile/project-management/estimation
|
||||
---
|
||||
|
||||
# ¿Qué son los puntos de historia en la metodología ágil y cómo se estiman?
|
||||
|
||||
## Highlights
|
||||
|
||||
Se trata de unidades de medida que permiten expresar una estimación del esfuerzo total que deberá hacer el equipo para implementar íntegramente un elemento del backlog del producto o cualquier otro trabajo. Los equipos asignan puntos de historia en función de la complejidad y del volumen del trabajo, así como del riesgo o de la incertidumbre.
|
||||
|
||||
[source](https://omnivore.app/me/https-www-atlassian-com-es-agile-project-management-estimation-18c9dc1e48a#4ddb962e-4ff6-44fa-8e72-b74db4a9b7a2)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
* [DevOps](#)
|
||||
* [Entrega continua](https://www.atlassian.com/es/continuous-delivery)
|
||||
* [Git](https://www.atlassian.com/es/git)
|
||||
* [Agile](https://www.atlassian.com/es/agile)
|
||||
* [Microservicios](https://www.atlassian.com/es/microservices)
|
||||
|
||||
## Puntos de historia y estimación
|
||||
|
||||
Una buena estimación ayuda a los propietarios de los productos a optimizar sus procesos en términos de eficiencia e impacto. Por eso es tan importante.
|
||||
|
||||
Hacer estimaciones es complicado. Para los desarrolladores de software, es uno de los aspectos más difíciles de su trabajo, por no decir el más difícil. Conlleva tener en cuenta un montón de factores que ayudan a los propietarios de los productos a tomar decisiones que afectan a todo el equipo, así como a la empresa. Con todo eso en juego, no es de extrañar que todos, desde los desarrolladores hasta la alta dirección, tiendan a perder los estribos sobre este tema. Craso error. La estimación ágil de los puntos de historia no es más que eso, un cálculo: no es un pacto de sangre.
|
||||
|
||||
No es obligatorio trabajar los fines de semana para compensar el tiempo de más que nos lleva un trabajo que habíamos subestimado. Dicho eso, veamos algunas maneras de realizar estimaciones con la mayor precisión posible.
|
||||
|
||||
## Colaboración con el propietario del producto
|
||||
|
||||
En un desarrollo ágil, el [propietario del producto](https://www.atlassian.com/es/agile/product-management) se encarga de priorizar el [backlog](https://www.atlassian.com/es/agile/scrum/backlogs), es decir, la lista ordenada de trabajo que contiene descripciones breves de todas las funciones y correcciones de un producto. Los propietarios del producto capturan los [requisitos](https://www.atlassian.com/es/agile/product-management/requirements) empresariales, pero no siempre entienden los detalles de la implementación. Por ello, una buena estimación puede informar al propietario del producto sobre el nivel de esfuerzo de cada elemento de trabajo, que a su vez sirve para evaluar la prioridad relativa de cada elemento.
|
||||
|
||||
Cuando el equipo de ingeniería empieza su proceso de estimación, normalmente surgen preguntas sobre los requisitos y las historias de usuario. Esto es algo positivo: las preguntas ayudan a todo el equipo a entender el trabajo mejor. Específicamente en el caso de los propietarios de los productos, la división granular de los elementos de trabajo y las estimaciones les ayudan a priorizar todas las áreas del trabajo, incluidas las que pueden estar ocultas. Con las estimaciones del equipo de desarrollo en la mano, no es extraño que un propietario del producto reordene los elementos del backlog.
|
||||
|
||||
## La estimación ágil de los puntos de historia es un trabajo en equipo
|
||||
|
||||
Involucrar a todo el mundo (desarrolladores, diseñadores, testers, deployers... todos) en el equipo es clave. Cada miembro del equipo aporta una perspectiva diferente sobre el producto y el trabajo necesario para entregar una historia de usuario. Por ejemplo, si la gestión de productos quiere hacer algo que parece sencillo, como admitir un nuevo navegador web, el desarrollo y el control de calidad deben dar su opinión también, ya que su experiencia les ha enseñado qué dragones pueden estar al acecho bajo la superficie.
|
||||
|
||||
Asimismo, los cambios de diseño requieren no sólo la aportación del equipo de diseño, sino también la del de desarrollo y la del de QA. Dejar a parte del equipo de producto más amplio fuera del proceso de estimación crea estimaciones de menor calidad, baja la moral porque los contribuyentes clave no se sienten incluidos y compromete la calidad del software.
|
||||
|
||||
No dejes que tu equipo sea víctima de las estimaciones poco precisas. Es un camino seguro al fracaso.
|
||||
|
||||
## Puntos de historia frente a horas
|
||||
|
||||
Los equipos de software tradicionales proporcionan estimaciones en un formato de tiempo concreto: pueden ser días, semanas o meses. Sin embargo, muchos equipos ágiles han decidido pasarse a los puntos de historia. ==Se trata de unidades de medida que permiten expresar una estimación del esfuerzo total que deberá hacer el equipo para implementar íntegramente un elemento del backlog del producto o cualquier otro trabajo. Los equipos asignan puntos de historia en función de la complejidad y del volumen del trabajo, así como del riesgo o de la incertidumbre.== Los valores se asignan para desglosar el trabajo de forma más eficaz en partes más pequeñas. De esta manera, se puede gestionar la incertidumbre. Con el tiempo, esto ayuda a los equipos a ser conscientes de lo que pueden llegar a conseguir en un período de tiempo concreto y genera un sentimiento de consenso y compromiso con la solución. Aunque pueda parecer contradictorio, esta abstracción es realmente útil, ya que obliga al equipo a tomar decisiones más complejas sobre la dificultad del trabajo. A continuación, se indican algunos motivos por los cuales es recomendable utilizar puntos de historia:
|
||||
|
||||
* Las fechas no tienen en cuenta el trabajo no relacionado con el proyecto que inevitablemente surge en nuestro día a día, como correos electrónicos, reuniones y entrevistas en las que un miembro del equipo puede participar.
|
||||
* Las fechas tienen una connotación emocional. La estimación relativa elimina este componente.
|
||||
* Cada equipo estima el trabajo en una escala ligeramente diferente, lo cual significa que su velocidad (medida en puntos) será diferente, como es natural. Asimismo, esto imposibilita que se politiquee usando la velocidad como arma.
|
||||
* Una vez que se llegue a un acuerdo sobre el esfuerzo relativo del valor de cada punto de historia, podrás asignar puntos rápidamente sin que haya lugar a demasiado debate.
|
||||
* Los puntos de historia recompensan a los miembros del equipo por resolver incidencias basándose en la dificultad, y no en el tiempo empleado. De esta forma, los miembros del equipo se mantienen centrados en entregar valor, no en el tiempo dedicado.
|
||||
|
||||
Lamentablemente, los puntos de historia se suelen utilizar de forma incorrecta; por ejemplo, cuando se emplean para juzgar a las personas o para asignar cronogramas y recursos detallados, o bien cuando se confunden con una medida de productividad. La auténtica función de los puntos de historia es que los equipos puedan hacerse una idea del volumen de trabajo y saber qué partes tienen prioridad. Para ver un debate en profundidad sobre los puntos de historia y las prácticas relacionadas con las estimaciones, échale un vistazo a esta [mesa redonda con expertos del sector](https://community.atlassian.com/t5/Agile-articles/Six-experts-sound-off-on-story-points-the-evolution-of-agile/ba-p/1553590). Si quieres más consejos sobre la estimación ágil, sigue leyendo.
|
||||
|
||||
[ ](https://www.youtube.com/watch?v=%5FN5gj9gzOjg)
|
||||
|
||||
## Puntos de historia y póker de planificación
|
||||
|
||||
Los equipos que se están iniciando en los puntos de historia usan un ejercicio llamado [Planning Poker](https://www.atlassian.com/blog/platform/a-brief-overview-of-planning-poker). En Atlassian, el Planning Poker es una práctica habitual en toda la empresa. Los miembros del equipo toman un elemento del backlog, hablan sobre él brevemente y cada uno fórmula mentalmente una estimación. A continuación, todos levantan una tarjeta con el número que refleje su estimación. Si todo el mundo está de acuerdo, ¡estupendo! De lo contrario, dedica algo de tiempo (no mucho, tan solo un par de minutos) para entender el motivo de las distintas estimaciones. Recuerda, sin embargo, que la estimación debe ser una actividad bastante general. Si el equipo se va por las ramas, respira hondo y deriva el debate a un superior.
|
||||
|
||||
**¿Listo para intentarlo?**
|
||||
|
||||
* Instala esta [Aplicación de póker de planificación](https://marketplace.atlassian.com/apps/1212495/planning-poker?hosting=cloud&tab=overview)
|
||||
* Obtén más información sobre el [póker de planificación](https://www.atlassian.com/blog/agile/planning-poker-sane-healthy)
|
||||
|
||||
## Estima con mayor inteligencia, no con mayor esfuerzo
|
||||
|
||||
Ninguna tarea individual debe superar las 16 horas de trabajo. (Si usas puntos de historia, puedes decidir que 20 puntos es el límite superior, por ejemplo). Sencillamente, es demasiado complicado estimar elementos de trabajo individuales de mayor duración con confianza. Esa confianza es especialmente importante para los elementos en la parte superior del backlog. Cuando algo se estima por encima del límite de 16 horas (o 20 puntos) del equipo, será una señal para dividirlo granularmente y volver a estimarlo.
|
||||
|
||||
Para los elementos que se encuentren más abajo en el backlog, basta con una estimación aproximada. Cuando el equipo empiece a trabajar en esos elementos, los requisitos podrían haber cambiado y la aplicación seguramente habrá cambiado también, de modo que las estimaciones no serán tan precisas. No pierdas tiempo estimando trabajo que posiblemente cambiará. Da al propietario del producto una cifra aproximada que pueda utilizar para priorizar la hoja de ruta del producto adecuadamente.
|
||||
|
||||
## Aprende de las estimaciones anteriores
|
||||
|
||||
Las retrospectivas constituyen un momento para que el equipo incorpore ideas de iteraciones anteriores, incluida la precisión de sus estimaciones. Hay muchas herramientas ágiles (como [Jira Software](https://www.atlassian.com/es/software/jira)) que realizan el seguimiento de los puntos de historia, cosa que facilita en gran medida el análisis y el recalibrado de las estimaciones. Prueba, por ejemplo, a comparar las cinco últimas historias de usuario que haya entregado el equipo con un valor de 8 puntos de historia. Estudia si cada uno de estos elementos de trabajo tuvo un nivel de esfuerzo similar. Si no, analizad por qué. Utilizad esta información en los siguientes debates de estimaciones.
|
||||
|
||||
Al igual que [el resto de los aspectos de un proceso ágil](https://www.atlassian.com/es/agile/project-management), la estimación es una cuestión de práctica. Irás mejorando con el tiempo.
|
||||
|
||||
|
||||
|
||||
Dan Radigan
|
||||
|
||||
La metodología ágil ha influido mucho en mí, tanto en el aspecto profesional como en el personal: he aprendido que las mejores experiencias se basan en el modelo ágil, tanto al programar como en la vida real. Mis intereses suelen moverse entre la tecnología, la fotografía y el motociclismo.
|
||||
|
||||
|
||||
|
||||
tutorial
|
||||
|
||||
#### Aprender a usar diagramas de trabajo pendiente con Jira Software
|
||||
|
||||
La guía completa sobre diagramas de evolución en Jira Software. Aprende a supervisar epics y sprints con diagramas de evolución.
|
||||
|
||||
[Probar el tutorial ](https://www.atlassian.com/es/agile/tutorials/burndown-charts)
|
||||
|
||||
|
||||
|
||||
artículo
|
||||
|
||||
#### Cinco métricas ágiles que no odiarás
|
||||
|
||||
¿Cómo usar métricas ágiles? Descubre las gráficas de trabajo pendiente de sprints, epics y publicaciones, los gráficos de control y velocidad, y el diagrama de flujo acumulado.
|
||||
|
||||
[Leer el artículo ](https://www.atlassian.com/es/agile/project-management/metrics)
|
||||
|
|
@ -0,0 +1,764 @@
|
|||
---
|
||||
id: c4ab379e-cc84-11ee-b3d0-afc69cc1061d
|
||||
title: |
|
||||
React Optimization Techniques to Help You Write More Performant Code
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
- RSS
|
||||
date_added: 2024-02-15 21:57:28
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2
|
||||
url_original: |
|
||||
https://www.freecodecamp.org/news/react-performance-optimization-techniques/
|
||||
---
|
||||
|
||||
# React Optimization Techniques to Help You Write More Performant Code
|
||||
|
||||
## Highlights
|
||||
|
||||
List visualization, or windowing, involves rendering only the items currently visible on the screen.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#9fb355ed-811d-44e7-aa61-12c0b18db7e2)
|
||||
|
||||
---
|
||||
|
||||
Lazy loading allows you to defer or delay the loading of images until they are needed or visible to the user instead of loading all the images on page load.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#f9c0a23a-9d66-4a80-bb4c-a4f2806ed1aa)
|
||||
|
||||
---
|
||||
|
||||
Another approach is to use the [intersection observer API](https://developer.mozilla.org/en-US/docs/Web/API/Intersection%5FObserver%5FAPI), which is a web API that allows you to detect when an element enters or exists the viewport efficiently.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#a44706c9-5cce-4765-ac78-77efdca40a30)
|
||||
|
||||
---
|
||||
|
||||
Memoization in React is a technique used to optimize the performance of functional components by caching the results of expensive computations or function calls. It's particularly useful when dealing with computationally intensive or frequently called functions with the same input values, as it helps avoid redundant calculations and improves the overall efficiency of the application.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#051f1544-65d2-4eae-87c6-bb7f226c4fa7)
|
||||
|
||||
---
|
||||
|
||||
Below is an example on how to use the `React.memo` with a functional component:
|
||||
|
||||
```javascript
|
||||
import React from 'react';
|
||||
|
||||
const Post = ({ signedIn, post }) => {
|
||||
console.log('Rendering Post');
|
||||
return (
|
||||
|
||||
{post.title}
|
||||
{post.content}
|
||||
{signedIn && Edit Post}
|
||||
|
||||
);
|
||||
};
|
||||
|
||||
export default React.memo(Post);
|
||||
|
||||
```
|
||||
|
||||
In the code above, `Post` (functional component) depends on the `signedIn` and `post` props. By wrapping it with `React.memo()`, React will only re-render the `Post` component if either `signedIn` or `post` changes.
|
||||
|
||||
> [!note]
|
||||
> You can memoize complete components to prevent re-renders if the props doesn't change, this use `React.memo()`, not the `useMemo()` hook
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#f0735f25-7bdf-4562-84cb-6f93f3a0b5a6)
|
||||
|
||||
---
|
||||
|
||||
The `useMemo()` hook optimizes performance by memoizing the result of a function call or an expensive computation. It caches the result and recalculates it only when the input values change.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#360c5717-251f-40d7-9dd8-24bccb26a59b)
|
||||
|
||||
---
|
||||
|
||||
The `useCallback()` hook in React is used to memoize a function instead of memoizing the function result. It is particularly useful when passing events as props to child components to prevent unnecessary re-renders.
|
||||
|
||||
`useCallback()` memoizes the function, ensuring it remains the same across re-renders as long as the dependencies haven't changed.
|
||||
|
||||
This is especially beneficial when passing functions as props to child components, preventing unnecessary re-renders.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#c01f0766-7401-44ae-9888-ee1da6d10ca7)
|
||||
|
||||
---
|
||||
|
||||
It's important to note that `useCallback` should be used sparingly and only for performance-critical parts of your application. Overusing `useCallback` can actually lead to worse performance due to the overhead of memoization itself. Always measure the performance impact before and after using `useCallback` to ensure it's having the desired effect.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#4292a582-b6cb-44e9-baff-3be6a127ed14)
|
||||
|
||||
---
|
||||
|
||||
Throttling in React is a technique used to limit the number of times a function or an event handler is invoked. It ensures that the function is called at a specified interval, preventing it from being executed too frequently.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#5e73fc50-7717-449d-a27f-f3bb87fd100f)
|
||||
|
||||
---
|
||||
|
||||
Debouncing, on the other hand, is also used to limit the number of times a function or an event handler is invoked. It ensures that the function is called only after a certain period of inactivity. Debouncing allows you to postpone the function call until the user has finished typing or a specific time has elapsed since the last event.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#2926578f-0a36-4acc-8c03-5d740981bb04)
|
||||
|
||||
---
|
||||
|
||||
// Debounce function to delay the searchAPI call const debounce = (func, delay) => {let timeoutId;return function (...args) { clearTimeout(timeoutId); timeoutId = setTimeout(() \=> { func(...args); }, delay); }; };
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#131255d3-029e-43c9-8c5e-0489e786e425)
|
||||
|
||||
---
|
||||
|
||||
Code splitting in React is a technique used to split a large JavaScript bundle into smaller, manageable chunks. It helps improve performance by loading only the necessary code for a specific part of an application rather than loading the entire bundle upfront.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#9f66f0bf-2185-499a-a4f1-591e5af60182)
|
||||
|
||||
---
|
||||
|
||||
In this example, `AsyncComponent` is a component that uses `lazy` and `Suspense` to perform code splitting. The `DynamicComponent` is dynamically imported using the import() syntax.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#aff44dd9-50f2-4ad2-8f93-d52e6ab0988d)
|
||||
|
||||
---
|
||||
|
||||
Web Workers serve as a solution to alleviate the burden on the main thread. They allow the execution of scripts in the background on a separate thread, distinct from the main JavaScript thread.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#16416227-0870-4503-a67d-76418223953a)
|
||||
|
||||
---
|
||||
|
||||
The `useTransition` hook in React plays a pivotal role in improving the performance of applications by allowing the marking of state updates as non-blocking transitions. This capability enables React to defer rendering for these updates, preventing UI blocking and enhancing overall responsiveness.
|
||||
|
||||
[source](https://omnivore.app/me/react-optimization-techniques-to-help-you-write-more-performant--18db03268c2#0622edf4-fa98-4848-aeee-174fa1cbde22)
|
||||
|
||||
---
|
||||
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
Performance optimization is a critical aspect of developing web applications. Users expect applications to load quickly and respond to their interactions smoothly.
|
||||
|
||||
In the React ecosystem, performance optimization techniques can significantly enhance the user experience by reducing load times and improving responsiveness.
|
||||
|
||||
In this article, we will discuss eight effective techniques for optimizing the performance of your React application.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Why Performance Optimization is Important](#why-performance-optimization-is-important)
|
||||
2. [List visualization](#list-visualization)
|
||||
3. [Lazy Loading Images](#lazy-loading-images)
|
||||
4. [Memoization](#memoization)
|
||||
5. [Throttling and Debouncing Events](#throttling-and-debouncing-events)
|
||||
6. [Code Splitting](#code-splitting)
|
||||
7. [React Fragments](#react-fragments)
|
||||
8. [Web Workers](#web-workers)
|
||||
9. [UseTransition Hook](#usetransition-hook)
|
||||
10. [Conclusion](#conclusion)
|
||||
|
||||
## Why Performance Optimization is Important
|
||||
|
||||
Optimizing the performance of your React application is crucial for several reasons:
|
||||
|
||||
* **Better User Experience:** A slow-loading or laggy application can lead to a poor user experience, negatively impacting your business. Users expect fast and responsive interactions, and performance optimization helps deliver that.
|
||||
* **Improved SEO:** Search engines like Google consider page load times and overall performance when ranking websites. A well-optimized application will rank higher in search results, making it more visible to potential users.
|
||||
* **Reduced Bounce Rates:** If your application takes too long to load or respond, users will likely leave and never return. By optimizing performance, you can reduce bounce rates and increase engagement.
|
||||
* **Cost Savings** A performant application requires fewer resources (like servers and memory) to handle the same workload. This means lower hosting costs and reduced infrastructure needs.
|
||||
* **Competitive Advantage:** A fast and efficient application sets you apart from competitors whose applications may be slower or less optimized. According to research by [Portent](https://www.portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm), a website that loads within one second has a conversion rate five times higher than a site that takes ten seconds to load. Therefore, ensuring your React applications perform well is crucial for retaining users and maintaining a competitive edge.
|
||||
|
||||
## 8 React Performance Optimization Techniques
|
||||
|
||||
Below are eight React performance optimization techniques you can use to speed up your applications.
|
||||
|
||||
### List visualization
|
||||
|
||||
==List visualization, or windowing, involves rendering only the items currently visible on the screen.==
|
||||
|
||||
When dealing with a large number of items in a list, rendering all the items at once can lead to slow performance and consume a significant amount of memory. List virtualization tackles this issue by rendering only a subset of the list items currently visible within the view, which conserves resources as the users scroll through the list.
|
||||
|
||||
The virtualization technique dynamically replaces rendered items with new ones, keeping the visible portion of the list updated and responsive. It efficiently allows you to render large lists or tabular data by only rendering the visible portion, recycling components as needed, and optimizing scroll performance.
|
||||
|
||||
There are different approaches to implementing list visualization in React, and one is using a popular library called [React Virtualized](https://www.npmjs.com/package/react-virtualized).
|
||||
|
||||
To install `react-virtualized`, you can use the following command:
|
||||
|
||||
```sql
|
||||
npm install react-virtualized --save
|
||||
```
|
||||
|
||||
After installing `react-virtualized`, you can import the required components and styles. Below is an example of how to use the `List` component to create a virtualized list:
|
||||
|
||||
```javascript
|
||||
import React from 'react';
|
||||
import { List } from 'react-virtualized';
|
||||
import 'react-virtualized/styles.css'; // Import styles
|
||||
|
||||
// Your list data
|
||||
const list = Array(5000).fill().map((_, index) => ({
|
||||
id: index,
|
||||
name: `Item ${index}`
|
||||
}));
|
||||
|
||||
// Function to render each row
|
||||
function rowRenderer({ index, key, style }) {
|
||||
return (
|
||||
<div key={key} style={style}>
|
||||
{list[index].name}
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
// Main component
|
||||
function MyVirtualizedList() {
|
||||
return (
|
||||
<List
|
||||
width={300}
|
||||
height={300}
|
||||
rowCount={list.length}
|
||||
rowHeight={20}
|
||||
rowRenderer={rowRenderer}
|
||||
/>
|
||||
);
|
||||
}
|
||||
|
||||
export default MyVirtualizedList;
|
||||
|
||||
```
|
||||
|
||||
In this example, `List` is the main component provided by `react-virtualized`. The `rowRenderer` function defines how each row should be rendered. The `width`, `height`, `rowCount`, `rowHeight`, and `rowRenderer` props are essential for configuring the list's behavior and appearance.
|
||||
|
||||
React applications can handle massive amounts of data by leveraging list virtualization without sacrificing performance or user experience.
|
||||
|
||||
### Lazy Loading Images
|
||||
|
||||
Similar to the list virtualization technique, lazy loading images prevents the creation of unnecessary DOM nodes, thereby boosting performance. Lazy loading allows you to defer or delay the loading of images until they are needed or visible to the user instead of loading all the images on page load.
|
||||
|
||||
The concept behind lazy loading is to initiate the load of a placeholder or a small low-resolution version of the image, typically a small-sized thumbnail or a blurred placeholder. As the user scrolls or interacts with the page, the actual image is loaded dynamically, replacing the placeholder when the user enters the viewport or when it becomes visible.
|
||||
|
||||
Lazy loading in React can be achieved using various libraries and techniques. One of the popular libraries is the [react-lazyload](https://www.npmjs.com/package/react-lazyload).
|
||||
|
||||
To install `react-lazyload`, you can use the following command:
|
||||
|
||||
```sql
|
||||
npm install --save react-lazyload
|
||||
```
|
||||
|
||||
Below is an example of a simple React component that uses `react-lazyload` to implement lazy loading for images:
|
||||
|
||||
```javascript
|
||||
import React from 'react';
|
||||
import LazyLoad from 'react-lazyload';
|
||||
|
||||
const MyLazyLoadedImage = ({ src, alt }) => {
|
||||
return (
|
||||
<LazyLoad height={200} offset={100}>
|
||||
{/* The height and offset props control when the image should start loading */}
|
||||
<img src={src} alt={alt} />
|
||||
</LazyLoad>
|
||||
);
|
||||
};
|
||||
|
||||
export default MyLazyLoadedImage;
|
||||
|
||||
```
|
||||
|
||||
In this example, `MyLazyLoadedImage` uses the `LazyLoad` component from `react-lazyload`. The `height` prop specifies the height of the placeholder, and the `offset` prop determines how far below the viewport the placeholder should start loading.
|
||||
|
||||
==Another approach is to use the== ==[intersection observer API](https://developer.mozilla.org/en-US/docs/Web/API/Intersection%5FObserver%5FAPI)====, which is a web API that allows you to detect when an element enters or exists the viewport efficiently.== Here's how we can use the Intersection Observer API along with the `useEffect` hook in React:
|
||||
|
||||
```javascript
|
||||
import React, { useEffect, useRef } from 'react';
|
||||
|
||||
const IntersectionLazyLoad = ({ src, alt }) => {
|
||||
const imageRef = useRef();
|
||||
|
||||
useEffect(() => {
|
||||
const options = {
|
||||
root: null, // Use the viewport as the root
|
||||
rootMargin: '0px', // No margin around the root
|
||||
threshold: 0.5, // 50% of the image should be visible
|
||||
};
|
||||
|
||||
const observer = new IntersectionObserver(handleIntersection, options);
|
||||
|
||||
if (imageRef.current) {
|
||||
observer.observe(imageRef.current);
|
||||
}
|
||||
|
||||
return () => {
|
||||
// Cleanup the observer when the component is unmounted
|
||||
observer.disconnect();
|
||||
};
|
||||
}, []);
|
||||
|
||||
const handleIntersection = (entries) => {
|
||||
entries.forEach((entry) => {
|
||||
if (entry.isIntersecting) {
|
||||
// Load the image when it becomes visible
|
||||
imageRef.current.src = src;
|
||||
imageRef.current.alt = alt;
|
||||
}
|
||||
});
|
||||
};
|
||||
|
||||
return <img ref={imageRef} style={{ height: '200px' }} alt="Placeholder" />;
|
||||
};
|
||||
|
||||
export default IntersectionLazyLoad;
|
||||
|
||||
```
|
||||
|
||||
In this example, `IntersectionLazyLoad` uses the Intersection Observer API to determine when the image becomes visible in the viewport.
|
||||
|
||||
By utilizing this API along with React `useEffect` hook, you can implement your custom lazy loading solution for images in React.
|
||||
|
||||
### Memoization
|
||||
|
||||
Memoization in React is a technique used to optimize the performance of functional components by caching the results of expensive computations or function calls. It's particularly useful when dealing with computationally intensive or frequently called functions with the same input values, as it helps avoid redundant calculations and improves the overall efficiency of the application.
|
||||
|
||||
In React, there are three techniques for memoization: `React.memo()`, `useMemo(),` and `useCallback().` Let's delve into the details for each:
|
||||
|
||||
#### How to use `React.memo()`
|
||||
|
||||
This higher-order component wraps purely functional components to prevent re-rendering if the received props remain unchanged.
|
||||
|
||||
By using `React.memo()`, the rendering result is cached based on props. If the props haven't changed since the last render, React reuses the previously rendered result instead of redoing the rendering process. This saves time and resources.
|
||||
|
||||
==Below is an example on how to use the== `==React====.====memo==` ==with a functional component:==
|
||||
|
||||
```javascript
|
||||
import React from 'react';
|
||||
|
||||
const Post = ({ signedIn, post }) => {
|
||||
console.log('Rendering Post');
|
||||
return (
|
||||
<div>
|
||||
<h2>{post.title}</h2>
|
||||
<p>{post.content}</p>
|
||||
{signedIn && <button>Edit Post</button>}
|
||||
</div>
|
||||
);
|
||||
};
|
||||
|
||||
export default React.memo(Post);
|
||||
|
||||
```
|
||||
|
||||
==In the code above,== `==Post==` ==(functional component) depends on the== `==signedIn==` ==and== `==post==` ==props. By wrapping it with== `==React====.====memo====()==`==, React will only re-render the== `==Post==` ==component if either== `==signedIn==` ==or== `==post==` ==changes.==
|
||||
|
||||
You can now use the memoized component like any other component in your application:
|
||||
|
||||
```javascript
|
||||
import React, { useState } from 'react';
|
||||
import Post from './Post';
|
||||
|
||||
const App = () => {
|
||||
const [signedIn, setSignedIn] = useState(false);
|
||||
const post = { title: 'Hello World', content: 'Welcome to my blog!' };
|
||||
|
||||
return (
|
||||
<div>
|
||||
<Post signedIn={signedIn} post={post} />
|
||||
<button onClick={() => setSignedIn(!signedIn)}>
|
||||
Toggle Signed In
|
||||
</button>
|
||||
</div>
|
||||
);
|
||||
};
|
||||
|
||||
export default App;
|
||||
|
||||
```
|
||||
|
||||
When you click the `Toggle Signed In` button, it will toggle the `signedIn` state. Since `Post` is wrapped with `React.memo()`, it will only re-render when the `signedIn` prop changes, thus saving rendering time and resources
|
||||
|
||||
#### How to use `useMemo()`
|
||||
|
||||
The `useMemo()` hook optimizes performance by memoizing the result of a function call or an expensive computation. It caches the result and recalculates it only when the input values change. Below is an example on how to use the `useMemo` hook in functional component:
|
||||
|
||||
```javascript
|
||||
import React, { useMemo } from 'react';
|
||||
|
||||
function App() {
|
||||
const [count, setCount] = React.useState(0);
|
||||
const [otherState, setOtherState] = React.useState('');
|
||||
|
||||
const expensiveComputation = (num) => {
|
||||
let i = 0;
|
||||
while (i < 1000000000) i++;
|
||||
return num * num;
|
||||
};
|
||||
|
||||
const memoizedValue = useMemo(() => expensiveComputation(count), [count]);
|
||||
|
||||
return (
|
||||
<div>
|
||||
<p>Count: {count}</p>
|
||||
<p>Square: {memoizedValue}</p>
|
||||
<button onClick={() => setCount(count + 1)}>Increase Count</button>
|
||||
<input type="text" onChange={(e) => setOtherState(e.target.value)} />
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
export default App;
|
||||
|
||||
```
|
||||
|
||||
In the code above, the `expensiveComputation` function simulates a resource-intensive operation, like squaring a number.
|
||||
|
||||
The `useMemo` hook is utilized to cache the result of this computation. The memoized value, stored in `memoizedValue`, is only recalculated when the `count` state changes, as `count` is specified as a dependency in the `useMemo` dependency array. Consequently, clicking the `Increase Count` button increments the `count` state, triggering a recalculation of the memoized value.
|
||||
|
||||
Conversely, changing the `otherState` via the input field does not prompt a recalculation, as `otherState` is not included in the `useMemo` dependency array.
|
||||
|
||||
#### How to use `useCallback()`
|
||||
|
||||
The `useCallback()` hook in React is used to memoize a function instead of memoizing the function result. It is particularly useful when passing events as props to child components to prevent unnecessary re-renders.
|
||||
|
||||
`useCallback()` memoizes the function, ensuring it remains the same across re-renders as long as the dependencies haven't changed.
|
||||
|
||||
This is especially beneficial when passing functions as props to child components, preventing unnecessary re-renders. It is often used with `React.memo()` to ensure child components do not re-render when unnecessary. Below is an exmple of how to use the `useCallback()` hook:
|
||||
|
||||
```javascript
|
||||
import React, { useState, useCallback } from 'react';
|
||||
|
||||
const ParentComponent = () => {
|
||||
const [count, setCount] = useState(0);
|
||||
|
||||
// Define a function that increments the count state
|
||||
const incrementCount = () => {
|
||||
setCount(count + 1);
|
||||
};
|
||||
|
||||
// Memoize the incrementCount function using useCallback
|
||||
const memoizedIncrement = useCallback(incrementCount, [count]);
|
||||
|
||||
return (
|
||||
<div>
|
||||
<p>Count: {count}</p>
|
||||
<ChildComponent onIncrement={memoizedIncrement} />
|
||||
</div>
|
||||
);
|
||||
};
|
||||
|
||||
const ChildComponent = React.memo(({ onIncrement }) => {
|
||||
console.log('Child component rendered');
|
||||
return (
|
||||
<div>
|
||||
<button onClick={onIncrement}>Increment Count</button>
|
||||
</div>
|
||||
);
|
||||
});
|
||||
|
||||
export default ParentComponent;
|
||||
|
||||
```
|
||||
|
||||
In the code above, the `ParentComponent` is responsible for managing a state variable named `count` and introduces a function called `incrementCount`, which handles the incrementation of the count. Utilizing the `useCallback` hook, the `incrementCount` function is memoized, guaranteeing its stability across renders unless any of its dependencies, in this case, `count`, undergo changes.
|
||||
|
||||
On the other hand, the `ChildComponent` is a component nested within the parent. It receives the memoized `onIncrement` function from the parent as a prop.
|
||||
|
||||
To optimize performance and prevent unnecessary re-renders when the props remain constant, the `ChildComponent` is wrapped with `React.memo()`. This ensures that the child component will only re-render when its props, specifically the memoized function, experience changes, contributing to a more efficient rendering process.
|
||||
|
||||
==It's important to note that== `==useCallback==` ==should be used sparingly and only for performance-critical parts of your application. Overusing== `==useCallback==` ==can actually lead to worse performance due to the overhead of memoization itself. Always measure the performance impact before and after using== `==useCallback==` ==to ensure it's having the desired effect.==
|
||||
|
||||
### Throttling and Debouncing Events
|
||||
|
||||
Throttling in React is a technique used to limit the number of times a function or an event handler is invoked. It ensures that the function is called at a specified interval, preventing it from being executed too frequently.
|
||||
|
||||
Throttling allows you to control the rate at which the function is called by setting up a minimum time interval between each function invocation. If the function is called multiple times within that interval, only the first invocation is executed, and subsequent invocations are ignored until the interval elapses
|
||||
|
||||
Now, let's illustrate throttling with a code example. First, without t==hrottling:==
|
||||
|
||||
```javascript
|
||||
// Without throttling, this function will be called every time the event is triggered
|
||||
function handleResize() {
|
||||
console.log('Window resized');
|
||||
}
|
||||
|
||||
window.addEventListener('resize', handleResize);
|
||||
|
||||
```
|
||||
|
||||
==With throttling, we can limit how often the== `==handleResize==` ==function is called:==
|
||||
|
||||
```actionscript
|
||||
// Throttling function
|
||||
function throttle(func, delay) {
|
||||
let lastCall = 0;
|
||||
return function(...args) {
|
||||
const now = new Date().getTime();
|
||||
if (now - lastCall < delay) {
|
||||
return;
|
||||
}
|
||||
lastCall = now;
|
||||
func(...args);
|
||||
};
|
||||
}
|
||||
|
||||
// Throttled event handler
|
||||
const throttledHandleResize = throttle(handleResize, 200);
|
||||
|
||||
window.addEventListener('resize', throttledHandleResize)
|
||||
|
||||
```
|
||||
|
||||
In this example, the `throttle` function wraps `handleResize` and ensures it's not called more often than every 200 milliseconds. If the `resize` event fires more frequently than that, the `handleResize` function will only be executed once every 200 milliseconds, reducing the potential for performance issues caused by rapid, repeated function calls
|
||||
|
||||
==Debouncing, on the other hand, is also used to limit the number of times a function or an event handler is invoked. It ensures that the function is called only after a certain period of inactivity. Debouncing allows you to postpone the function call until the user has finished typing or a specific time has elapsed since the last event.==
|
||||
|
||||
For example, imagine you have a search input field and want to trigger a search API request only when the user has finished typing for a certain duration, like `300ms`.
|
||||
|
||||
With debouncing, the search function will only be invoked after the user stops typing for` 300ms`. If the user continues typing within that interval, the function call will be delayed until the pause occurs. Without debouncing, the function will be called for every keystroke, potentially leading to excessive function calls and unnecessary computation. let's demonstrate with a code example:
|
||||
|
||||
```javascript
|
||||
import React, { useState, useEffect } from 'react';
|
||||
|
||||
const SearchComponent = () => {
|
||||
const [searchTerm, setSearchTerm] = useState('');
|
||||
|
||||
// Function to simulate a search API request
|
||||
const searchAPI = (query) => {
|
||||
console.log(`Searching for: ${query}`);
|
||||
// In a real application, you would make an API request here
|
||||
};
|
||||
|
||||
// Debounce function to delay the searchAPI call
|
||||
const debounce = (func, delay) => {
|
||||
let timeoutId;
|
||||
return function (...args) {
|
||||
clearTimeout(timeoutId);
|
||||
timeoutId = setTimeout(() => {
|
||||
func(...args);
|
||||
}, delay);
|
||||
};
|
||||
};
|
||||
|
||||
// Debounced search function
|
||||
const debouncedSearch = debounce(searchAPI, 300);
|
||||
|
||||
// useEffect to watch for changes in searchTerm and trigger debouncedSearch
|
||||
useEffect(() => {
|
||||
debouncedSearch(searchTerm);
|
||||
}, [searchTerm, debouncedSearch]);
|
||||
|
||||
// Event handler for the search input
|
||||
const handleSearchChange = (event) => {
|
||||
setSearchTerm(event.target.value);
|
||||
};
|
||||
|
||||
return (
|
||||
<div>
|
||||
<label htmlFor="search">Search:</label>
|
||||
<input
|
||||
type="text"
|
||||
id="search"
|
||||
value={searchTerm}
|
||||
onChange={handleSearchChange}
|
||||
placeholder="Type to search..."
|
||||
/>
|
||||
</div>
|
||||
);
|
||||
};
|
||||
|
||||
export default SearchComponent;
|
||||
|
||||
```
|
||||
|
||||
With this setup, the `searchAPI` function will only be invoked after the user stops typing for 300ms, preventing excessive API requests and improving the overall performance of the search functionality.
|
||||
|
||||
### Code Splitting
|
||||
|
||||
Code splitting in React is a technique used to split a large JavaScript bundle into smaller, manageable chunks. It helps improve performance by loading only the necessary code for a specific part of an application rather than loading the entire bundle upfront.
|
||||
|
||||
When you develop a new React application, all your JavaScript code is typically bundled together into a single file. This file contains all the components, libraries, and other code required for your application to function. But as your application grows, the bundle size can become quite large, resulting in slow initial load times for your users.
|
||||
|
||||
Code splitting ==allows you to divide a single bundle into multiple chunks, which can be loaded selectively based on the current needs of your application. Instead of downloading the entire bundle upfront,== only the necessary code is fetched and executed when a user visits a particular page or triggers a specific action.
|
||||
|
||||
Below is a basic example of code splitting:
|
||||
|
||||
```javascript
|
||||
// AsyncComponent.js
|
||||
import React, { lazy, Suspense } from 'react';
|
||||
|
||||
const DynamicComponent = lazy(() => import('./DynamicComponent'));
|
||||
|
||||
const AsyncComponent = () => (
|
||||
<Suspense fallback={<div>Loading...</div>}>
|
||||
<DynamicComponent />
|
||||
</Suspense>
|
||||
);
|
||||
|
||||
export default AsyncComponent;
|
||||
|
||||
|
||||
// DynamicComponent.js
|
||||
import React from 'react';
|
||||
|
||||
const DynamicComponent = () => (
|
||||
<div>
|
||||
<p>This is a dynamically loaded component!</p>
|
||||
</div>
|
||||
);
|
||||
|
||||
export default DynamicComponent;
|
||||
|
||||
```
|
||||
|
||||
==In this example,== `==AsyncComponent==` ==is a component that uses== `==lazy==` ==and== `==Suspense==` ==to perform code splitting. The== `==DynamicComponent==` ==is dynamically imported using the import() syntax.==
|
||||
|
||||
When `AsyncComponent` is rendered, React will load `DynamicComponent` only when it is needed, reducing the initial bundle size and improving the application's performance. The fallback prop in Suspense specifies what to render while waiting for the dynamic import to resolve, providing a better user experience during the loading process.
|
||||
|
||||
### React Fragments
|
||||
|
||||
React Fragments are a feature introduced in [React 16.2](https://legacy.reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html) that allows you to group multiple elements together without adding an additional DOM node. This is particularly useful when you need to return multiple elements from a component's render method, but you don't want to introduce unnecessary DOM elements that could affect the layout or styles of your application.
|
||||
|
||||
Imagine you are arranging books on a bookshelf. Each book represents a React component, and the bookshelf represents the DOM.
|
||||
|
||||
Normally, if you have multiple books, you might want to group them together under a category label (analogous to a DOM element like a `<div>`). But sometimes you just want to place the books side by side without a label because the label itself doesn't hold any value and only takes up physical space.
|
||||
|
||||
React Fragments are like the option to arrange the books without a label, saving space and making the arrangement cleaner.
|
||||
|
||||
Here's an example of how to utilize React fragments:
|
||||
|
||||
```actionscript
|
||||
import React from 'react';
|
||||
|
||||
function BookShelf() {
|
||||
return (
|
||||
<>
|
||||
<Book title="React for Beginners" />
|
||||
<Book title="Mastering Redux" />
|
||||
<Book title="JavaScript Essentials" />
|
||||
</>
|
||||
);
|
||||
}
|
||||
|
||||
function Book({ title }) {
|
||||
return <li>{title}</li>;
|
||||
}
|
||||
|
||||
export default BookShelf;
|
||||
|
||||
```
|
||||
|
||||
In this example, the `BookShelf` component returns a list of `Book` components without wrapping them in a `<div>` or other unnecessary DOM element. Instead, it uses the `<>` shorthand syntax for React Fragments.
|
||||
|
||||
This results in a cleaner DOM structure, which can improve the performance of your React application by reducing the number of elements that the browser has to process and render. Using fragments can also reduce unnecessary markup and contribute to a cleaner and more efficient render tree.
|
||||
|
||||
### Web Workers
|
||||
|
||||
JavaScript operates as a single-threaded application designed to handle synchronous tasks.
|
||||
|
||||
When a web page is being rendered, JavaScript executes multiple tasks, including manipulating DOM elements, managing UI interactions, handling API response data, and enabling CSS animations, all within a single thread. Despite its efficiency in managing these tasks, executing them in a single thread can sometimes lead to performance bottlenecks.
|
||||
|
||||
==Web Workers serve as a solution to alleviate the burden on the main thread. They allow the execution of scripts in the background on a separate thread, distinct from the main JavaScript thread.==
|
||||
|
||||
This separation enables the handling of computationally intensive tasks, execution of long-running operations, or management of tasks that might otherwise block the main thread. By doing so, Web Workers contribute to maintaining user interface responsiveness and overall application performance.
|
||||
|
||||
To use web worker in React, create a new JavaScript file that will contain the code for the worker thread:
|
||||
|
||||
```php
|
||||
// worker.js
|
||||
self.onmessage = function(event) {
|
||||
var input = event.data;
|
||||
var result = performHeavyComputation(input);
|
||||
postMessage(result);
|
||||
};
|
||||
|
||||
function performHeavyComputation(input) {
|
||||
// Insert your heavy computation logic here
|
||||
return input * 2; // Just a placeholder operation
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
In your React component, instantiate the Web Worker and establish a communication channel with it:
|
||||
|
||||
```javascript
|
||||
import React, { useEffect, useRef } from 'react';
|
||||
|
||||
function MyComponent() {
|
||||
const workerRef = useRef();
|
||||
|
||||
useEffect(() => {
|
||||
// Initialize the worker
|
||||
workerRef.current = new Worker('path-to-your-worker-file.js');
|
||||
|
||||
// Handle incoming messages from the worker
|
||||
workerRef.current.onmessage = (event) => {
|
||||
console.log('Message received from worker:', event.data);
|
||||
};
|
||||
|
||||
// Cleanup the worker when the component unmounts
|
||||
return () => {
|
||||
workerRef.current.terminate();
|
||||
};
|
||||
}, []);
|
||||
|
||||
// Function to send a message to the worker
|
||||
const sendMessageToWorker = (message) => {
|
||||
workerRef.current.postMessage(message);
|
||||
};
|
||||
|
||||
// Rest of your component
|
||||
return (
|
||||
// ...
|
||||
);
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
In this example, a Web Worker is initialized in the `useEffect` hook and stored in a ref for future use. Messages from the worker are handled with an `onmessage` event listener, and the worker is terminated when the component is unmounted to clean up resources. The `sendMessageToWorker` function demonstrates how to communicate with the worker using `postMessage`
|
||||
|
||||
### UseTransition Hook
|
||||
|
||||
==The== `==useTransition==` ==hook in React plays a pivotal role in improving the performance of applications by allowing the marking of state updates as non-blocking transitions. This capability enables React to defer rendering for these updates, preventing UI blocking and enhancing overall responsiveness.==
|
||||
|
||||
When utilizing `useTransition,` state updates within the `startTransition` function are treated as low-priority transitions, susceptible to interruption by higher-priority state updates. So if a high-priority update occurs during a transition, React may prioritize finishing the high-priority update, interrupting the ongoing transition.
|
||||
|
||||
This non-blocking transition mechanism is valuable in preventing UI blocking during intensive operations such as data fetching or large-scale updates. By deferring the rendering of components associated with transition updates, React ensures that the user interface remains responsive even in scenarios where the UI might otherwise become unresponsive.
|
||||
|
||||
This example demonstrates the use of `useTransition` in a React component:
|
||||
|
||||
```javascript
|
||||
import React, { useState, useTransition } from 'react';
|
||||
|
||||
function MyComponent() {
|
||||
const [state, setState] = useState(initialState);
|
||||
const [isPending, startTransition] = useTransition();
|
||||
|
||||
function handleClick() {
|
||||
startTransition(() => {
|
||||
setState(newState); // This state update is marked as a transition
|
||||
});
|
||||
}
|
||||
|
||||
return (
|
||||
<>
|
||||
{/* Your component JSX */}
|
||||
<button onClick={handleClick}>Update State</button>
|
||||
{isPending && <div>Loading...</div>}
|
||||
</>
|
||||
);
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
This example showcases how React avoids blocking the UI during transitions triggered by user actions, allowing for interruption if higher-priority state updates are detected.
|
||||
|
||||
Note that `useTransition` is part of the Concurrent Mode API, introduced in React 18 and later versions. As a powerful tool for altering the default behavior of state updates, make sure you use it with care, considering the specific implications of deferring rendering within the context of your application.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Optimizing the performance of a React application involves a combination of strategies, from the fundamental understanding of React's diffing algorithm to leveraging built-in features and third-party tools.
|
||||
|
||||
By applying these techniques judiciously, you can create applications that are not only visually appealing but also performant, leading to a better overall user experience.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. [Get started](https://www.freecodecamp.org/learn/)
|
||||
Loading…
Add table
Add a link
Reference in a new issue