Update from obsidian - thinkpad
Affected files: .obsidian/plugins/dataview/data.json .obsidian/plugins/obsidian-omnivore/data.json Read Later/2023-10-14 - Using CSS custom properties like this is a waste - YouTube.md Read Later/2023-10-14 - You Don’t Actually Want Open World Games - YouTube.md Read Later/2023-10-15 - Highlighting fold text, community fork of null-ls, leetcode integration, reduce ram ....md Read Later/2023-10-18 - The Unreasonable Effectiveness Of Plain Text.md Read Later/2023-10-21 - How Game Reviews Actually Affect You.md Read Later/2023-10-23 - Study shows stronger brain activity after writing on paper than on tablet or smartph....md Read Later/2023-10-23 - Train Your Brain to Be More Creative.md Read Later/2023-10-25 - Let's Get Webby! 🦀 🕸️.md Read Later/2023-10-25 - What the Rust Book didn't tell you about testing....md Read Later/2023-10-31 - Use cases for Rust.md Read Later/2023-11-01 - Why Signals Are Better Than React Hooks.md Read Later/2023-11-02 - The First Rule of Comments in Code.md Read Later/2023-11-02 - Web Accessibility Tips for Developers – A11y Principles Explained.md Read Later/2023-11-04 - Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir-.md Read Later/2023-11-06 - How to Write Components that Work in Any Framework.md Read Later/2023-11-07 - How to Avoid Prop Drilling in React.md Read Later/2023-11-10 - The Complete Guide to Time Blocking.md Read Later/2023-11-14 - The one thing you need to finish your game.md Read Later/2023-11-21 - Career Mistakes to Avoid as a Developer.md Read Later/2023-11-21 - Conventional Commits.md Read Later/2023-11-21 - How to Write Better Git Commit Messages – A Step-By-Step Guide.md Read Later/2023-11-21 - The Life-Changing Magic of Tidying Up Your To-Do List.md Read Later/2023-11-21 - tbaggery - A Note About Git Commit Messages.md Read Later/2023-12-24 - Historias de usuario - Ejemplos y plantilla - Atlassian.md Read Later/2023-12-24 - ¿Qué son los puntos de historia en la metodología ágil y cómo se estiman-.md Read Later/2024-02-15 - React Optimization Techniques to Help You Write More Performant Code.md Read Later/How to Learn Rust.md Read Later/The Secret Power of ‘Read It Later’ Apps.md
This commit is contained in:
parent
1e55015bab
commit
7437d8e57c
30 changed files with 2578 additions and 561 deletions
|
|
@ -23,7 +23,6 @@ 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
|
||||
|
||||
|
||||
|
|
@ -41,7 +41,6 @@ Al igual que en otros casos, una buena idea mal implementada puede llevar al fra
|
|||
Juegos que han implementan esta idea son:
|
||||
- [TLOZ - Breath of the wild](games/the-legend-of-zelda-breath-of-the-wild)
|
||||
- [Metroid Dread](games/metroid-dread)
|
||||
---
|
||||
## Original
|
||||
|
||||
## Chapters
|
||||
|
|
@ -17,16 +17,15 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> hinell/duplicate.nvim
|
||||
>
|
||||
> [source](https://omnivore.app/me/highlighting-fold-text-community-fork-of-null-ls-leetcode-integr-18b3533f57b#5de369b4-f406-446f-b59a-358d59dd9eb1) #Todo
|
||||
>
|
||||
>
|
||||
>> [!info] ㅤ
|
||||
>> Add to nvim config
|
||||
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
|
||||
|
|
@ -244,7 +243,7 @@ Lightweight neovim plugin provides a table view for inspect data files such as c
|
|||
|
||||
---
|
||||
|
||||
#### hinell/duplicate.nvim
|
||||
#### ==hinell/duplicate.nvim==
|
||||
|
||||
|
||||
|
||||
|
|
@ -16,41 +16,40 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> ## [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.
|
||||
>
|
||||
> [source](https://omnivore.app/me/noboilerplate-scripts-34-plain-text-team-md-at-main-0-atman-nobo-18b42e0d185#7466a699-a115-4b9f-99fc-416852b5aef2) #frameworks
|
||||
>
|
||||
>
|
||||
>> [!info] ㅤ
|
||||
>> El pacto de Ulysses es una estrategia (o framework) en donde tomamos medidas tempranamente para prevenir malas desiciones en un futuro.
|
||||
## [Tie Yourself to the Mast](#tie-yourself-to-the-mast)
|
||||
|
||||
> [!quote] ㅤ
|
||||
> "The difference between science and screwing around is _writing it down_."
|
||||
>
|
||||
> ## [— Adam Savage](#-adam-savage)
|
||||
>
|
||||
> [source](https://omnivore.app/me/noboilerplate-scripts-34-plain-text-team-md-at-main-0-atman-nobo-18b42e0d185#9a030eb7-6269-4863-8e5e-61b59a1704b6) #quotes
|
||||
>
|
||||
>
|
||||
>> [!info] ㅤ
|
||||
>> This was just a cool quote...
|
||||
%%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>
|
||||
|
|
@ -121,21 +120,23 @@ _"Ulysses and the Sirens"_ [John William Waterhouse](https://en.wikipedia.org/wi
|
|||
|
||||
notes:
|
||||
|
||||
## [Tie Yourself to the Mast](#tie-yourself-to-the-mast)
|
||||
## ==[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.
|
||||
==%%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.
|
||||
==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.
|
||||
==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 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:
|
||||
==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.
|
||||
* ==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.==
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -169,9 +170,9 @@ The natural way to do this is by talking to one another. But talking does not sc
|
|||
|
||||
---
|
||||
|
||||
"The difference between science and screwing around is _writing it down_."
|
||||
=="The difference between science and screwing around is== _==writing it down==_==."==
|
||||
|
||||
## [— Adam Savage](#-adam-savage)
|
||||
## ==[— Adam Savage](#-adam-savage)==
|
||||
|
||||
notes:
|
||||
|
||||
|
|
@ -22,7 +22,6 @@ Según estudios, los jugadores se ven afectados por reviews que leen/ven, ya sea
|
|||
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)
|
||||
|
|
@ -16,21 +16,26 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> "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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> ---
|
||||
"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
|
||||
|
|
@ -45,7 +50,7 @@ Contrary to the popular belief that digital tools increase efficiency, volunteer
|
|||
|
||||
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.
|
||||
=="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.
|
||||
|
||||
|
|
@ -16,23 +16,28 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> ## **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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> ---
|
||||
## **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)
|
||||
|
|
@ -59,11 +64,11 @@ I’ve spent more than two decades (and counting) in the advertising industry, a
|
|||
|
||||
Here a few things that have worked for me over the years.
|
||||
|
||||
## **Engage with nature**
|
||||
## **==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).
|
||||
==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.
|
||||
==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.
|
||||
|
||||
|
|
@ -73,7 +78,7 @@ I know, I know, you’ve heard this a million times: [Meditation](https://www.fr
|
|||
|
||||
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.
|
||||
==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.
|
||||
|
||||
|
|
@ -83,7 +88,7 @@ This intentional practice can be as simple as closing your eyes and focusing on
|
|||
|
||||
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.
|
||||
==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.
|
||||
|
||||
|
|
@ -17,16 +17,15 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> ...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!
|
||||
>
|
||||
> [source](https://omnivore.app/me/let-s-get-webby-18b6705008a#7065ade5-765c-4d60-bd89-1ecb0d919389)
|
||||
>
|
||||
>
|
||||
>> [!info] ㅤ
|
||||
>> I can create front end web apps with this libraries
|
||||
...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
|
||||
|
||||
|
||||
|
|
@ -17,15 +17,16 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> 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)
|
||||
> ---
|
||||
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
|
||||
|
||||
|
||||
|
|
@ -17,11 +17,12 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> 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)
|
||||
> ---
|
||||
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
|
||||
|
||||
|
||||
|
|
@ -23,7 +23,6 @@ Esto permite compartir este _"estado"_ entre componentes pero solo actualizar lo
|
|||
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)
|
||||
|
|
@ -34,8 +34,6 @@ Some rules to evade writing comments:
|
|||
**"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)
|
||||
|
|
@ -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/)
|
||||
|
|
@ -17,10 +17,9 @@ url_original: |
|
|||
|
||||
## 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 ^5df1b4
|
||||
- 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)
|
||||
|
|
@ -17,37 +17,44 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> ### 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> ---
|
||||
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
|
||||
|
||||
|
||||
|
|
@ -18,47 +18,63 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
>
|
||||
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
|
||||
|
||||
|
||||
|
|
@ -16,32 +16,39 @@ url_original: |
|
|||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> 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)
|
||||
> > [!quote] ㅤ
|
||||
> time boxing asks you to limit how much time you'll dedicate to a specific task.
|
||||
>
|
||||
> [source](https://omnivore.app/me/https-todoist-com-productivity-methods-time-blocking-18bbc432143#e342c6ce-607b-4482-af54-4ffbf81ab7ab)
|
||||
>
|
||||
>
|
||||
>> [!info] ㅤ
|
||||
>> Is _"I'm gonna finish this in X time"_, instead of _"I'm gonna work on this for X time"_
|
||||
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
|
||||
|
|
@ -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/)
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
---
|
||||
id: 9f0419b3-2f89-4734-96b3-55aa984414ac
|
||||
title: |
|
||||
How to Learn Rust
|
||||
status: READING
|
||||
tags:
|
||||
- read-later
|
||||
- Youtube
|
||||
date_added: 2023-10-12 17:55:48
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/how-to-learn-rust-18b25ac93bb
|
||||
url_original: |
|
||||
https://www.youtube.com/watch?v=2hXNd6x9sZs
|
||||
---
|
||||
|
||||
# How to Learn Rust
|
||||
|
||||
---
|
||||
## Original
|
||||
|
||||
[How to Learn Rust](https://www.youtube.com/watch?v=2hXNd6x9sZs)
|
||||
|
||||
By [No Boilerplate](https://www.youtube.com/@NoBoilerplate)
|
||||
|
|
@ -1,316 +0,0 @@
|
|||
---
|
||||
id: 85f31880-6935-11ee-86f4-f7cb87ce263e
|
||||
title: |
|
||||
The Secret Power of ‘Read It Later’ Apps
|
||||
status: COMPLETED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-10-12 16:28:29
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/the-secret-power-of-read-it-later-apps-18b255ca194
|
||||
url_original: |
|
||||
https://fortelabs.co/blog/the-secret-power-of-read-it-later-apps
|
||||
---
|
||||
|
||||
# The Secret Power of ‘Read It Later’ Apps
|
||||
|
||||
## Highlights
|
||||
|
||||
> [!quote] ㅤ
|
||||
> > People who cling to paradigms (which means just about all of us) take one look at the spacious possibility that everything they think is guaranteed to be nonsense and pedal rapidly in the opposite direction. Surely there is no power, no control, no understanding, not even a reason for being, much less acting, in the notion or experience that there is no certainty in any worldview. But, in fact, everyone who has managed to entertain that idea, for a moment or for a lifetime, has found it to be the basis for radical empowerment. **If no paradigm is right, you can choose whatever one will help to achieve your purpose.**
|
||||
>
|
||||
> > It is in this space of mastery over paradigms that people throw off addictions, live in constant joy, bring down empires, get locked up or burned at the stake or crucified or shot, and **have impacts that last for millennia**.
|
||||
>
|
||||
> > In the end, it seems that mastery has less to do with pushing leverage points than it does with **strategically, profoundly, madly letting go.**
|
||||
>
|
||||
> [source](https://omnivore.app/me/the-secret-power-of-read-it-later-apps-18b255ca194#42edb9e2-3799-430e-bbff-db1170ebbad1)
|
||||
>
|
||||
>
|
||||
>> [!info] ㅤ
|
||||
>> Read again and understand it better
|
||||
|
||||
---
|
||||
## Original
|
||||
|
||||
|
||||
|
||||
Image via Nuno Cruz
|
||||
|
||||
_By Tiago Forte of_ [_Forte Labs_](http://fortelabs.co/)
|
||||
|
||||
At the end of 2014 I received an email informing me that I had read over a million words in the ‘read it later’ app Pocket over the course of the year.
|
||||
|
||||
|
||||
|
||||
This number by itself isn’t impressive, considering our daily intake of information is equivalent to [34 gigabytes](http://bits.blogs.nytimes.com/2009/12/09/the-american-diet-34-gigabytes-a-day/), 100,000 words, or [174 newspapers](http://www.nytimes.com/2014/08/10/opinion/sunday/hit-the-reset-button-in-your-brain.html?smprod=nytcore-iphone&smid=nytcore-iphone-share), depending on who you ask.
|
||||
|
||||
What makes this number significant (in my view) is that it represents 22 books’-worth of long-form reading that would not have happened without a system in place.
|
||||
|
||||
We’ve made a habit of filling those hundred random spaces in our day with glances at Twitter, Instagram, and Facebook. But those glances have slowly become stares, and those stares have grown to encompass a major portion of our waking hours.
|
||||
|
||||
The end result is the same person who spends 127 hours per year on Instagram (the [global average](http://www.businessinsider.com/people-spend-21-minutes-per-day-on-instagram-2014-10)) complains that she has “no time” for reading.
|
||||
|
||||
The fact is, **the ability to read is becoming a source of competitive advantage in the world**.
|
||||
|
||||
I’m not talking about basic literacy. What has become exceedingly scarce (and therefore, valuable) is the physical, emotional, attentional, and mental capability to sit quietly and direct focused attention for sustained periods of time.
|
||||
|
||||
A [recent article](https://hbr.org/2005/01/overloaded-circuits-why-smart-people-underperform) in the Harvard Business Review puts a name to this new neurological phenomenon: Attention Deficit Trait. Basically, the terms ADD and ADHD are falling out of use because effectively the entire population fits the diagnostic criteria. It’s not a condition anymore, it’s a _trait_ — the inherent and unavoidable experience of modern life characterized by “distractibility, inner frenzy, and impatience.”
|
||||
|
||||
|
||||
|
||||
Start Building Your Second Brain
|
||||
|
||||
Subscribe below to learn more about the next cohort of the Building a Second Brain course
|
||||
|
||||
### Read It. Later.
|
||||
|
||||
Before I explain the massive, under-appreciated benefits these apps provide, and how to use them most effectively, a quick primer in case you’re unfamiliar.
|
||||
|
||||
So-called “Read It Later” apps give you the ability to “save” content on the web for later consumption. They are essentially advanced bookmarking apps, pulling in the content from a page to be read or viewed in a cleaner, simpler visual layout.
|
||||
|
||||
On top of that core function they add features like favoriting, tags, search, cross-platform syncing, recommended content, offline viewing, and archiving. The most popular options are:
|
||||
|
||||
* [Instapaper](https://www.instapaper.com/)
|
||||
* [Pocket](https://getpocket.com/a/)
|
||||
* [Send to Kindle](https://chrome.google.com/webstore/detail/send-to-kindle-for-google/cgdjpilhipecahhcilnafpblkieebhea?hl=en) (for sending articles to your Kindle)
|
||||
* [Feedly](https://feedly.com/i/welcome) (for those RSS fans)
|
||||
* and [Safari’s built-in “Add to Reading List” feature](https://support.apple.com/en-us/HT200294).
|
||||
|
||||
The app I use, Pocket, adds a button to the Chrome toolbar that looks like this:
|
||||
|
||||
|
||||
|
||||
Chrome toolbar
|
||||
|
||||
_Note: at time of writing, I was using Pocket, but have recently switched to Instapaper because of Pocket’s “Share to Evernote” bug mentioned below._
|
||||
|
||||
Clicking the button while viewing a webpage turns the button pink, and saves the page to your “list.” Navigating to getpocket.com, or opening the Pocket app on your computer or mobile device shows you a list of everything you’ve saved:
|
||||
|
||||
|
||||
|
||||
Mac desktop client
|
||||
|
||||
You can also view your list in a “tile” layout on the web, making it into essentially a personalized magazine. Personalized, in this case, not by a cold, unfeeling algorithm, but by your past self:
|
||||
|
||||
|
||||
|
||||
Web browser “tile” view
|
||||
|
||||
Marking an item as read in one version of the app will quickly sync across all platforms. It will also save your current progress on one device, so you can continue where you left off on a different device (for those longer pieces).
|
||||
|
||||
### The highest leverage point in a system is in the intake — the initial assumptions and paradigms that inform its development
|
||||
|
||||
I’ve [written previously](https://medium.com/forte-labs/how-to-use-evernote-for-your-creative-workflow-f048f0aa3ed1) about how to use Evernote as a general reference filing system, not only to stay organized but to inspire creativity.
|
||||
|
||||
But I didn’t address a key question when creating any workflow: how and from where does information enter the system? The quality of a workflow’s outputs is fundamentally limited by the quality of its inputs. Garbage in, garbage out.
|
||||
|
||||
There are A LOT of ways we could talk about to improve the quality of the information you consume. But I want to focus now on the two that Read It Later apps can help with:
|
||||
|
||||
1. Increasing consumption of long-form content (which is presumably more substantive)
|
||||
2. Better filtering
|
||||
|
||||
### #1 | Increasing Consumption of Long-Form Content
|
||||
|
||||
In order to consume good ideas, first you have to consume many ideas.
|
||||
|
||||
This is the fundamental flaw in the “information diet” advice from Tim Ferriss and others: strong filters work best on a larger initial flow. Using your friends as your primary filter for new ideas ensures you remain the dumbest person in the room, and contribute nothing to the conversation.
|
||||
|
||||
The problem is that our entire digital world is geared toward snackable chunks of low-grade information — photos, tweets, statuses, snaps, feeds, cards, etc. To fight the tide you have to redesign your environment — you have to create affordances.
|
||||
|
||||
> Affordance (n.): a relation between an object and an organism that, through a collection of stimuli, **affords the opportunity for that organism to perform an action.**
|
||||
|
||||
Let’s look at the 4 main barriers to consuming long-form content, and the affordances that Read It Later apps use to overcome them:
|
||||
|
||||
#### 1\. App performance
|
||||
|
||||
We know that the most infinitesimal delays in the loading time of a webpage will dramatically impact how many people stay on the page. [Google found](https://blog.kissmetrics.com/speed-is-a-killer/) that increasing the number of results per page from 10 to 30 took only half a second longer, but **caused 20% of people to drop off**.
|
||||
|
||||
If you think your behavior is not affected by such trivialities, think again. Even on a subconscious level, you will resist even opening apps that don’t reward you with snappy response times. Which is a problem because the apps most people turn to for reading are either ebook apps like iBooks and Kindle, or web browsers like Chrome and Safari. I’m not sure which category is slower, but they’re both abysmal.
|
||||
|
||||
Meanwhile, your snaps and instas refresh at precog-like speeds.
|
||||
|
||||
Read It Later apps, by slurping in content (articles, videos, slideshows) into a clean interface, eliminate the culprits — ads, site analytics, popups — all the stuff you don’t care about.
|
||||
|
||||
A [recent analysis](http://www.nytimes.com/2015/10/01/technology/personaltech/ad-blockers-mobile-iphone-browsers.html) by The New York Times of 3 leading ad-blockers (which have the same effect) measured a **21% increase in battery life**, and in the most egregious case of Boston.com, a drop in loading time **from 33 seconds to 7 seconds**. Many other leading sites were not that far off.
|
||||
|
||||
|
||||
|
||||
Effect of ad-blocker on loading times of Boston.com, via [NYT](http://www.nytimes.com/2015/10/01/technology/personaltech/ad-blockers-mobile-iphone-browsers.html)
|
||||
|
||||
Yeah that’s pretty much an eternity in mobile behavior land.
|
||||
|
||||
#### 2\. Matching content with your context
|
||||
|
||||
|
||||
|
||||
My Pocket list on iPad
|
||||
|
||||
Much of the time when we pull out our phone, we’re looking for something to match our mood (or energy, or time available, or other context). We use our constellation of shiny apps as mood regulators and self-soothers, as time-fillers and boredom-suppressors, for better or worse.
|
||||
|
||||
So you need a little entertainment, and you open…an ebook? Yeah right. Monochrome pages don’t attract you. They don’t draw you in.
|
||||
|
||||
Pocket gives reading some of this stimulatory pleasure by laying out your list in a pleasing, magazine-style layout (at left). Not only is it generally attractive, but it gives you that same magazine-flipping pleasure of engaging with something that interests you _right in that moment_.
|
||||
|
||||
David Allen puts it this way:
|
||||
|
||||
> “It’s practical to have organized reading material at hand when you’re on your way to a meeting that may be starting late, a seminar that may have a window of time when nothing is going on, a dentist appointment that may keep you waiting, or, of course, if you’re going to have some time on a train or plane. Those are all great opportunities to browse and work through that kind of reading. People who don’t have their Read/Review material organized can waste a lot of time, since **life is full of weird little windows when it could be used.**”
|
||||
|
||||
You’re not fighting your impulses forcing yourself to read a dense tome after a long work day. Willpower preserved ✓
|
||||
|
||||
#### 3\. Asynchronous reading
|
||||
|
||||
This is one of the least understood barriers to reading in our fragmented timescape.
|
||||
|
||||
There is something deeply, deeply unsatisfying about repeatedly starting something and not finishing it. This is what we experience all day at work, being continuously interrupted by a stream of “emergencies.” The last thing we want after a stressful day starved of wins is to fail even at reading an article.
|
||||
|
||||
The [2015 revised edition (affiliate link)](https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity-ebook/dp/B00KWG9M2E/ref=as%5Fli%5Fss%5Ftl?ie=UTF8&linkCode=ll1&tag=fortelabs07-20&linkId=fe6db72d8e5bbb38b1ea43241924f7e9&language=en%5FUS) of _Getting Things Done_ [cites the work](http://users.wfu.edu/masicaej/MasicampoBaumeister2011JPSP.pdf) of Dr. Roy Baumeister, who has shown that “uncompleted tasks take up room in the mind, which then limits clarity and focus.” The risk of cognitive dissonance at not being able to finish a long article (much less a book) keep us from even beginning it.
|
||||
|
||||
Read It Later apps address this by simply saving your progress in a given article, allowing you to pick back up at a different time, or on a different device, and clearly marking items as “read” once you’re finished.
|
||||
|
||||
#### 4\. Focus
|
||||
|
||||
A common response when I recommend people adopt _yet another_ category of apps is “Why don’t I just use Evernote?” Or whatever app they’re using for general reference or task management. Evernote even makes a Chrome extension called [Clearly](https://evernote.com/clearly/) for reading online content and [Web Clipper](https://evernote.com/webclipper/?downloaded) for saving it.
|
||||
|
||||
It is a question of focus. Why don’t you use your task manager to keep track of content (i.e. “Read this article”)? Because the last thing you want to see when you cuddle up with your hot cocoa for some light reading is the hundreds of tasks you’re not doing.
|
||||
|
||||
Likewise, the last thing you want to see when you (finally!) have time to read is the thousands of notes you’ve collected from every corner of the universe, only some of which you haven’t read, only some of which you _want_ to read, only some of which are _meant_ to be read.
|
||||
|
||||
> Actionable info ≠ Reference info ≠ To Read pile
|
||||
|
||||
Ergo,
|
||||
|
||||
> Task manager ≠ Evernote ≠ Pocket
|
||||
|
||||
### #2 | Better filtering
|
||||
|
||||
Now you’ve got the funnel filled. It’s time to narrow it.
|
||||
|
||||
Most advice on this topic focuses on being more selective about your sources. Cutting out the email digests that just throw you off track, unfollowing people posting crap, or even [directly replacing ads with quality sources](https://chrome.google.com/webstore/detail/ad-replacer-turn-spammy-a/eckeeomlpacfhejaameopnmgipghaoam).
|
||||
|
||||
The problem is that this assumes you are always at your best, always at 100% self-discipline, totally aligned with your life values, priorities ship shape.
|
||||
|
||||
Yeah.
|
||||
|
||||
In the moment, with your blood sugar at a negative value and every fiber of your being screaming for a dopamine hit, _of course_ that Buzzfeed article seems like the best conceivable use of your time. If you think you can permanently seal off your life from the celebrity news, content marketing, and spammy friends that dominate the web, the NSA has a job for you.
|
||||
|
||||
Procrastination is the most powerful force in the universe. _It will find a way._
|
||||
|
||||
I have a different approach: **waiting periods**. Every time I come across something I may want to read/watch, I’m totally allowed to. No limits! The only requirement is I have to save it to Pocket, and then choose to consume it at a later time.
|
||||
|
||||
I’ve found that even just clicking a link to open the URL, in order to save it to Pocket, is too much of a temptation. The first glimpse of a cute GIF and I’m off to Reddit, completely forgetting my morning email session.
|
||||
|
||||
So instead I just **command-click** every link I’m interested in (or **right-click > Open link in new tab**), which opens each link in a separate tab _without taking me to that tab_.
|
||||
|
||||
Here’s what a typical Monday morning link-fest looks like, just from email:
|
||||
|
||||
|
||||
|
||||
Then, because I’m still in **collection mode**, not in read mode, I cycle through each tab one at a time (**shift-command-}** or **control-tab**), saving each one to Pocket using the shortcut I set up: **command-p** (chosen for irony and to avoid inadvertent printing).
|
||||
|
||||
There’s only one rule: **NO READING OR WATCHING!**
|
||||
|
||||
Bringing this back to filtering, not only am I saving time and preserving focus by batch processing both the collection and the consumption of new content, I’m **time-shifting the curation process** to a time better suited for reading, and (most critically) removed from the temptations, stresses, and biopsychosocial hooks that first lured me in.
|
||||
|
||||
I am always amazed by what happens: no matter how stringent I was in the original collecting, no matter how certain I was that this thing was worthwhile, I **regularly eliminate 1/3 of my list before reading**. The post that looked SO INTERESTING when compared to that one task I’d been procrastinating on, in retrospect isn’t even something I care about.
|
||||
|
||||
What I’m essentially doing is creating a buffer. Instead of pushing a new piece of info through from intake to processing to consumption without any scrutiny, I’m creating a pool of options drawn from a longer time period, which allows me to make decisions from a higher perspective, where those decisions are much better aligned with what truly matters to me.
|
||||
|
||||
> Remove any feature, process, or effort that does not directly contribute to the learning you seek. — Eric Ries, The Leader’s Guide
|
||||
|
||||
Here’s a visual of how this works, from my Pocket analytics:
|
||||
|
||||
|
||||
|
||||
You can see that I save more things toward the beginning of the week and the weekend, and then draw down the buffer more towards the end of the week.
|
||||
|
||||
**_/sidebar_**
|
||||
|
||||
Imagine for a second if we could do this with everything. On Saturday morning, well-rested and wise, you retroactively decide everything you _want to have done_ during the previous week. Anything you decide was not worthwhile, you _get that time back_.
|
||||
|
||||
I experienced this recently with email — after returning from a 10-day meditation course during which I was completely off the grid, I was surprised to notice it took only 1.9 hours to process almost 2 weeks’ worth of email (I track these things). I normally spend on average 2.19 hours on email **per week** — _what happened to those extra 2.48 hours?!_ Besides the gains from batch processing such a large quantity of emails at once, I believe the main factor was that I evaluated my emails from a longer time horizon and higher perspective, more correctly judging whether something was worth responding to or acting on.
|
||||
|
||||
If only this method would scale.
|
||||
|
||||
**/end\_sidebar**
|
||||
|
||||
### Mo’ apps, mo’ problems
|
||||
|
||||
There are drawbacks, which I’ve glossed over until now. The two main ones:
|
||||
|
||||
#### 1\. Formatting issues
|
||||
|
||||
Many sites, including popular ones, aren’t presented correctly within the Pocket app (and I imagine others). There’s always the option of opening the link in a web browser, but this eliminates all the positive affordances and then some. If there wasn’t so much value provided otherwise, this would be a deal breaker.
|
||||
|
||||
The worst part is that, sometimes, the article is cut off or links don’t appear _without any indication that something is amiss_. On Tim Ferriss’ blog, for example, links (of which there are many) are simply removed.
|
||||
|
||||
One solution is to tag problematic items with “desktop” so you know that these need to be read/viewed on your computer.
|
||||
|
||||
#### 2\. Dependence
|
||||
|
||||
Every productivity tool eventually becomes a victim of its own success. In this case, I’ve become so dependent on Pocket that bugs really affect me.
|
||||
|
||||
For example, the Share to Evernote feature, which I use to highlight and save key passages, has been broken for at least a month. My hysterical tweets to Pocket Support have been answered but not resolved.
|
||||
|
||||
You wouldn’t think such a minor feature within one app could be so disruptive, but it has been massively so. This simple workflow:
|
||||
|
||||
_Highlight > Share > Share to Evernote > Save_
|
||||
|
||||
…has been replaced with this:
|
||||
|
||||
_Highlight > Copy > Switch to Evernote > New note > Paste > Switch back to Pocket > Share > More > Copy URL > Switch back to Evernote > Paste URL > Switch back to Pocket_
|
||||
|
||||
Worse, I often forget to go back and grab the URL, so I have to hunt it down at some later date.
|
||||
|
||||
**/rant\_over**
|
||||
|
||||
### Progress Traps and Paradigms
|
||||
|
||||
The amount of information in the world is a [progress trap](https://en.wikipedia.org/wiki/Progress%5Ftrap). Too much stuff to read is just as limiting as too little.
|
||||
|
||||
As the inimitable Venkatesh Rao [has written](http://breakingsmart.com/season-1/), we’re moving from a world of **containers** (companies, departments, semesters, packages, silos) to a world of **streams** (social networks, info feeds, main streets of thriving cities, Twitter). Problems and opportunities alike resist having neat little boxes drawn around them. There’s way too much to absorb. Way too much to even guess what you don’t know.
|
||||
|
||||
As the pace of change in the world accelerates, we double down on all the methods that created the problems in the first place — more planning, more forecasting, more control and risk management. We’re left with massive institutions that nobody trusts, that are simultaneously brittle and too-big-to-fail, creating precarity at every level of the socioeconomic pyramid.
|
||||
|
||||
What would it look like instead to solve problems (and explore opportunities) in a way that gets better the faster we go?
|
||||
|
||||
I can’t do justice to Rao’s blog series linked above (it’s in 20 parts — may want to save it for later ;), but the first step he proposes is “exposing yourself to as many different diverse streams as possible.”
|
||||
|
||||
When you’re immersed in a stream, the faster it goes, the more novel perspectives and ideas you’re exposed to. You develop an [opposable mind](http://rogerlmartin.com/lets-read/the-opposable-mind) — the ability to juggle and play around with different perspectives on any issue, instead of seeing it through one lens.
|
||||
|
||||
Increasingly, the only metric that will matter in your journey of personal growth will be **ROL: Rate-of-Learning**. We’ve heard a lot in recent years about the importance of hands-on learning and practical experimentation. We get it. Burying your head in a book by itself gets you nowhere.
|
||||
|
||||
But the pendulum is swinging too far in that direction. Yes, you can be _too_ action-oriented. Ideas, while cheap when compared to effective execution, are still more valuable than many of the other things we spend time on.
|
||||
|
||||
There’s another way to learn faster: assimilate and build on the ideas of others. Sure, you won’t understand every tacit lesson their experience gave them, but you can incorporate many of them, and in a fraction of the time it would take you to make every mistake yourself.
|
||||
|
||||
Ideas are high leverage agents. They become more so when arranged in highly cross-referenced networks. The only tool we have available that is capable of both creating and accessing these networks on demand is the human brain.
|
||||
|
||||
I lied before. There is one form of leverage even more powerful than the initial assumptions and paradigms that inform a system’s development: the **ability to transcend paradigms**.
|
||||
|
||||
I can’t put it any better than Donella Meadows, in her [seminal piece](http://www.donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/) on complex systems:
|
||||
|
||||
> People who cling to paradigms (which means just about all of us) take one look at the spacious possibility that everything they think is guaranteed to be nonsense and pedal rapidly in the opposite direction. Surely there is no power, no control, no understanding, not even a reason for being, much less acting, in the notion or experience that there is no certainty in any worldview. But, in fact, everyone who has managed to entertain that idea, for a moment or for a lifetime, has found it to be the basis for radical empowerment. **If no paradigm is right, you can choose whatever one will help to achieve your purpose.**
|
||||
|
||||
> It is in this space of mastery over paradigms that people throw off addictions, live in constant joy, bring down empires, get locked up or burned at the stake or crucified or shot, and **have impacts that last for millennia**.
|
||||
|
||||
> In the end, it seems that mastery has less to do with pushing leverage points than it does with **strategically, profoundly, madly letting go.**
|
||||
|
||||
Reading is the closest thing we have to thinking another’s thoughts. It’s long and sometimes ponderous, but that work is required to wrap yourself in another person’s paradigm. Which is the first step in madly letting go of your own.
|
||||
|
||||
The amazing thing about ideas is that it takes zero time for one to change your paradigm. It happens in time, but takes no time, like an inter-dimensional wormhole, one entangled particle in your brain mirroring its twin across a chasm even more vast than the universe — the chasm between two minds.
|
||||
|
||||
And that is the secret power of Read It Later apps.
|
||||
|
||||
**P.S.** _My latest setup has 2 parts: 1) using_ [_this IFTTT recipe_](https://ifttt.com/recipes/182352-instpaper-to-evernote) _to automatically send “liked” articles in Instapaper to an Evernotebook called “Instapaper favorites” (for things I want to save in general but don’t have any particular notes on), and 2)_ [_this recipe_](https://ifttt.com/recipes/368728-send-instapaper-highlights-to-evernote-default-notebook) _that saves anything I highlight in Instapaper to a new note, and sends it to the Evernote default notebook where I can decide where it belongs later (for when I have specific passages I want to extract)_
|
||||
|
||||
---
|
||||
|
||||
_**Subscribe below to receive free weekly emails with our best new content, or follow us on [Twitter](https://twitter.com/fortelabs/), [Facebook](https://www.facebook.com/fortelabs/), [Instagram](https://www.instagram.com/fortelabsco/), [LinkedIn](https://www.linkedin.com/in/tiagoforte/), or [YouTube](https://www.youtube.com/user/simulacrumsquared/). Or become a [Praxis member](https://fortelabs.co/about-praxis/) to receive instant access to our full collection of members-only posts.**_
|
||||
|
||||
|
||||
|
||||
Join the Forte Labs Newsletter
|
||||
|
||||
Join 50,000+ people receiving my best ideas on learning, productivity & knowledge management every Tuesday. I'll send you my Top 10 All-Time Articles right away as a thank you.
|
||||
|
||||
* POSTED IN: [Building a Second Brain](https://fortelabs.co/blog/category/topics/building-a-second-brain/), [Curation](https://fortelabs.co/blog/category/topics/curation/), [Free](https://fortelabs.co/blog/category/types/free/), [Note-taking](https://fortelabs.co/blog/category/topics/note-taking/), [Technology](https://fortelabs.co/blog/category/topics/technology/), [Workflow](https://fortelabs.co/blog/category/topics/workflow/)
|
||||
Loading…
Add table
Add a link
Reference in a new issue