alecodes/personal-page
2
0
Fork 0
Code Issues 17 Pull requests Projects 1 Releases Packages 1 Wiki Activity Actions

chore: add files from master-wiki repo

Browse source
This commit is contained in:
Alexander Navarro 2024-11-20 20:00:35 -03:00
parent f99a9ae2ac
commit 1847f6bf28
315 changed files with 1047341 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

130
_master_wiki/notes/Crear una nueva funcionalidad.md Normal file
View file

@ -0,0 +1,130 @@
## TLDR
- [[#Time Tracking|Time Tracking]]
- [[#Planear|Planear]]
- [[#Planear#Entradas|Entradas]]
- [[#Planear#Salidas|Salidas]]
- [[#Planear#Nombres|Nombres]]
- [[#Realizar un mock de la salida|Realizar un mock de la salida]]
- [[#¿Cómo genero la salida?|¿Cómo genero la salida?]]
- [[#Realizar la implementación|Realizar la implementación]]
- [[#Realizar pruebas|Realizar pruebas]]
- [[#Descansar y repetir|Descansar y repetir]]
- [[#Ejemplo de recursividad|Ejemplo de recursividad]]
## Cosas a tener en mente
- [Accept that Everything Is a Draft](The%20cult%20of%20done.md#Accept%20that%20Everything%20Is%20a%20Draft), siempre se puede volver a ello y mejorarlo. Por ahora, esto es un prototipo...
- Contrario al punto anterior, si algo fue lanzado al mundo, ya se fue, no quedarse modificando lo mismo para siempre.
- Concentrarse en una cosa a la vez:
1. Escribir algo que funcione.
2. Mejorar la implementación, performance y corregir bugs.
3. Limpiar y refactorizar, sólo si queda tiempo/energía y es necesario ([good enough](Good%20Enough.md)).
## Time Tracking
Esto no es con el objetivo de reportar lo realizado o de maximizar la productividad, si no con el de evitar la fatiga y la visión de túnel. Puedes utilizar la técnica, metodología y/o longitud que prefieras o sea más apta para la tarea, pero lo ideal es tomar descansos regulares. Esto ayudará fisiológicamente a nuestro cuerpo (ojos, espalda, cuello, etc) y a nuestra mente.
Algunas metodologías que pueden ser utilizadas incluyen:
- Pomodoro
- Flowtime
## Planear
Similar a la resolución de problemas en matemática, debemos asegurarnos de que entendemos lo que debemos realizar, con que datos contamos o necesitamos y que es lo que debemos entregar. Mientras mayor claridad tengamos sobre esto, más fácil será realizar la tarea. Con el tiempo este proceso se vuelve algo automático que hacemos mentalmente, pero es buena idea realizar el ejercicio concientemente para facilitar el trabajo.
En caso de lenguajes tipeados como Typescript, C++, Rust u otros, definir los tipos de datos es algo necesario durante el desarrollo, si bien podemos hacerlo durante o despues de escribir la funcionalidad, hacerlo antes tiene sus ventajas:
- Claridad de la información con la que contamos y lo que debemos producir, por lo que no necesitaremos modificar la definición del tipo de retorno multiples veces a medida que desarrollamos la funcionalidad, por ejemplo.
- Reduciremos la cantidad de código en rojo, alertas y errores de compilación que nos distraerán de desarrollar la funcionalidad.
En lenguajes no tipeados como Javascript, Python o Lua, también podemos aplicar definiciones de tipo para funciones, metodos, clases y otros mediante comentarios, que nos ayudarán tanto a definir nuestras entradas y salidas como al lector del código ya que el editor les dará información sobre como utilizarlo:
En caso de Javascript, se puede utilizar [JSDocs](https://jsdoc.app/)
### Entradas
Debemos definir que información necesitamos (o contamos) para realizar la tarea, definir esto en primera instancia nos ayudará en la etapa de ejecución a que ya sabemos que tenemos disponible y sus posibles variaciones, por lo que podemos correr los aplicar validaciones y asegurarnos de cumplir todos los posibles casos.
Algunas cosas que son buena idea considerar en este momento:
- Las entradas deben ser acotadas, Ej: no pasar parámetros demás a una función.
- Seguir estándares y buenas prácticas, Ej: La programación funcional dice que no debemos modificar un parámetro.
### Salidas
¿Cuál será la forma final de la funcionalidad? Debemos definir el tipo de dato que mejor se acomode a lo que vamos a realizar, ¿Es mejor un array o una tupla? ¿Quizá entregarlo como un hash-map?
### Nombres
Definir un buen nombre para los elementos utilizados en el algoritmo, esto puede incluir el nombre de la función o método que estemos creando, los parametros, el nombre de la clase, el archivo, módulo, etc.
Algunas recomendaciones:
- Usar un sustantivo para _datos_ ó _información_ (_variables_ ó _propiedades_), este debe ser descriptivo y puntual para describir lo que contiene.
- _userData_ es muy amplio y ambiguo, _userAddress_ es algo más acotado y aceptable
- Usar verbos para _funcionalidad_ (_funciones_ ó _métodos_), hay que describir lo que **hace**, no lo que es.
- _activateUserAccount_ en ves de _userAccountUpdater_
- Ajustarse a las convenciones definidas (Ej: Casing).
- Evitar nombres ambiguos o vagos (Ej: aux, util), estos nombres son aceptables si se pueden especificar más. Ej: una carpeta llamada _utils_ con archivos más especificos dentro.
- Usar palabras completas, evitar abreviaciones y **NO** usar una sola letra. Los editores de texto proveen autocompletado, por lo que no hay beneficio en escoger un nombre más corto para evitar escribir más, solo aumentamos la legibilidad del código.
- **NO** usar _magic numbers_ (números escritos en duro en el código), es mejor convertirlos en una variable para saber porqué es ese numero en especifico o en un ultimo caso, dejar un comentario.
Para mayor información, [este](https://www.youtube.com/watch?v=K9ohUuZhWnY) video es un buen recurso:
<iframe width="560" height="315" src="https://www.youtube.com/embed/K9ohUuZhWnY?si=hIc_uxB9XTttO__E" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
## Realizar un mock de la salida
En caso de tipos de datos simples, podemos simplemente devolver _0_ de una función por ejemplo, pero en caso más completos podemos devolver un json completo con la información que necesitamos de una REST API y así sabremos que tenemos que producir este resultado final. La idea es despejar nuestra mente sobre el _que_ entregar y así luego solo preocuparnos sobre...
## ¿Cómo genero la salida?
Con todos los actores definidos podemos hacer un outline del _"paso a paso"_ necesario para realizar obtener la salida o realizar la acción deseada, este puede ser un punteo simple y en orden de las cosas a realizar. Para mayor claridad podemos escribirlo como un comentario en el código para que podamos verlo a medida que desarrollamos la funcionalidad.
## Realizar la implementación
Finalmente realizamos el paso a paso que definimos para poder crear la funcionalidad deseada. Es importante que para este punto sigamos las normas de la estrategia de time tracking definidas para evitar la visión de túnel y la fatiga.
## Realizar pruebas
Una ves terminada nuestra funcionalidad, debemos realizar algunas pruebas para saber si funciona correctamente en distintos contextos, estas puedes ser a mano, con pruebas unitarias, pruebas end to end, etc. Sólo debemos aplicar las pruebas y no hacer un trabajo correctivo aún, pues debemos realizar el siguiente paso antes de corregir.
Algunas ideas para probar la funcionalidad son:
- Volver a leer el requerimiento y seguirlo paso a paso.
- Probar esta funcionalidad con todos los tipos de usuario que apliquen.
- Realizar casos extremos.
- Intentar hacer fallar la funcionalidad a propósito para ver el manejo de errores.
## Descansar y repetir
Una vez completada la funcionalidad (exitosamente o no) debemos descansar un momento, levantarse y realizar alguna acción completamente agena a lo que estábamos realizando, darle un tiempo a nuestro cerebro de descansar y así nuevamente evitar la visión de túnel y la fatiga. En caso de que la funcionalidad no haya pasado las pruebas exitosamente, o si tenemos tiempo de mejorar nuestra funcionalidad, podemos repetir todos este proceso, pasando más rápido o saltando los pasos que no sea necesario realizar tan en profundidad nuevamente.
## Ejemplo de recursividad
Podemos ver un ejemplo de como aplicar esta guía para realizar una tarea compleja y dividirla en sub tareas donde tambien aplicamos esta guía. Notar que en este ejemplo está simplificado y no se detallan las entradas y salidas como deberían.
Debemos producir un servicio para una REST API que guarde un campo en la base de datos:
1. Servicio POST:
- Entrada: JSON con datos.
- Salida: HTTP 201, como cuerpo un JSON con el mensaje "recurso creado con éxito" ó HTTP 422 con los errores adecuados en caso de fallo.
- Funcionalides:
1. Ruta en la aplicación:
- Entrada: JSON con datos.
- Salida: HTTP 201, como cuerpo un JSON con el mensaje "recurso creado con éxito" ó HTTP 422 con los errores adecuados en caso de fallo.
- Funcionalidad:
1. Controlador:
- Entrada: JSON con datos.
- Salida: HTTP 201, como cuerpo un JSON con el mensaje "recurso creado con éxito".
- Funcionalidad: Lógica del controlador.
2. Validaciones:
- Entrada: JSON con datos.
- Salida: Ninguna en caso de éxito, HTTP 422 con los errores adecuados en caso de fallo.
- Funcionalidad: validaciones especificas para los campos.
2. Documentación de API:
- Entrada: Ninguna.
- Salida: Documentación sobre como utilizar este servicio.
- Funcionalidad: Documentación sobre como utilizar este servicio.
En este simplificado ejemplo, podemos ver que para realizar la funcionalidad completa de crar un servicio POST que guarde un registro en la base de datos, podemos aplicar esta guía a cada funcionalidad, para segmentar su complegidad y poder concentrarnos en una sola tarea a la ves para realizarla bien.

10
_master_wiki/notes/Cypress.md Normal file
View file

@ -0,0 +1,10 @@
## Browsers on linux
The browsers needs to be with a **binary** name known to cypress in your path,
if the browser has other name, it's not gonna be able to open it. To see a list
of brewsers, check [this source file](https://github.com/cypress-io/cypress/blob/develop/packages/launcher/lib/known-browsers.ts).
| Browser | binary names |
| - | - |
| Firefox Dev | `firefox-developer-edition`, `firefox` |

11
_master_wiki/notes/Depression.md Normal file
View file

@ -0,0 +1,11 @@
Por mis propias características personales (ser muy funcional), me es más dificil caer en algunas enfermedades mentales (depresión), pero eso no quiere decir que esas cosas que hayan "salvado" a los demás no hayan echo nada por mi.
Siempre me sentí que me estaba apropiando de algo que no me pertenecía cuando intentaba sentirme parte de cosas como "Celeste me ayudó con mi depresión" o "Persona me hizo luchar por mi mismo", ya que yo no me sentía en esos "hoyos emocionales". Pero eso no quieren decir que no me hayan ayudado.
Porque según algunos comentarios como "no sé como has aguantado tanto", pues gracias a los que me dan fuerza he inspiran:
- Personas
- Personajes
- Juegos
- Historias
- Canciones

63
_master_wiki/notes/Design.md Normal file
View file

@ -0,0 +1,63 @@
---
created: 2024-03-12 13:49
updated: 2024-03-12 13:49
---
Diseñar está completamente fuera de mi zona de confort, así que estudiar como hacer, y hacer el esfuerzo de planear como diseñar la página antes de tirarme de hocico a hacerlo ha sido una experiencia bastante satisfactoria
Pensar que debo realizar, que quiero comunicar y como lo quiero comunicar ha enrutado el diseño y permitiendo que sea más facil
el feedback tambien ha sido satisfactorio, porque me ha hecho entender mejor que debo hacer y que no, tambien algúnos comentarios han contradecido completamente lo que yo creería que sería mejor, lo cuál ha enfocado mejor el diseño final en lo que realmente debe (y como debe) ser la página
## Cómo enfatizar un elemento
Para hacer que un elemento destaque del fondo, debemos ocupar _**Elevación**_,esto hará que el elemento parezca estar más cerca de la pantalla, haciendo que resalte de lo demás y atrapando la atención del usuario.
La manera de lograr esto depende del tema:
### Light Theme
Contrastar el contorno del elemento con su entorno, para esto podemos:
- Utilizar sombras, esto destaca el contorno de un elemento y su grado de elevación.
- sombras más pequeñas y definidas indican mayor proximidad al fondo.
- sombras más grandes y difuminadas indican mayor lejanía del fondo.
- Distintos colores diferencian elementos pero no proveen su grado de elevación.
- Opacidad muestra los contornos de los elementos y su solapamiento, pero no su grado de elevación.
- Podemos oscurecer el fondo para destacar un elemento sobre todo lo demás, esto ofrece una gran, pero no especifica cantidad de elevación.
### Dark Theme
- Utilizar colores claros para denotar el grado de elevación:
- Utilizar colores directamente. mientras más claro sea el color, más elevado estará un componente.
- Aplicar un _"overlay"_ de un color claro, con distintos grados de transparencia. Mientras menos transparente más elevado estará el componente. No aplicar este esto a los colores primarios o similares.
- _**NO**_ aplicar "light glows" en lugar de sombras oscuras para expresar elevación, porque no logran el mismo efecto.
### References of common elevations
| Component | Default elevation values (dp) | White overlay transparency |
| --------------------------------------------------------- | ----------------------------- | -------------------------- |
| Dialog | 24 | 16% |
| Modal bottom sheet Modal side sheet | 16 | 15% |
| Navigation drawer | 16 | 15% |
| Floating action button (FAB - pressed) | 12 | 14% |
| Standard bottom sheet Standard side sheet | 8 | 12% |
| Bottom navigation bar | 8 | 12% |
| Bottom app bar | 8 | 12% |
| Menus and sub menus | 8 | 12% |
| Card (when picked up) | 8 | 12% |
| Contained button (pressed state) | 8 | 12% |
| Floating action button (FAB - resting elevation) Snackbar | 6 | 11% |
| Top app bar (scrolled state) | 4 | 9% |
| Top app bar (resting elevation) | 0 or 4 | 0% - 9% |
| Refresh indicator Search bar (scrolled state) | 3 | 8% |
| Contained button (resting elevation) | 2 | 7% |
| Search bar (resting elevation) | 1 | 5% |
| Card (resting elevation) | 1 | 5% |
| Switch | 1 | 5% |
| Text button | 0 | 0% |
| Standard side sheet | 0 | 0% |
Reference:
- [Material Design - UI](https://m2.material.io/design/environment/elevation.html)
- [Material Design - Dark Theme](https://m2.material.io/design/color/dark-theme.html)

3
_master_wiki/notes/Dev Tools.md Normal file
View file

@ -0,0 +1,3 @@
## SMTP Dev Server
Podemos levantar un servidor temporal de SMTP para probar la funcionalidad de correos con `python -m smtpd -c DebuggingServer -n localhost:1025`

13
_master_wiki/notes/Devlog.md Normal file
View file

@ -0,0 +1,13 @@
---
id: 1ba323c1-27df-476a-b9d3-0ae7d9aaf785
created: 2024-02-05 22:06
updated: 2024-03-12 13:49
---
# Devlog
## ¿Cómo hacer un devlog?
- En la intro, copiar y pegar la parte relevante de un changelog de un proyecto.
- Comentar sobre los items del changelog.
- Hablar sobre dificultades y como se solucionaron.
-

3
_master_wiki/notes/Email.md Normal file
View file

@ -0,0 +1,3 @@
SMTP Dev server
https://realpython.com/python-send-email/#option-2-setting-up-a-local-smtp-server

29
_master_wiki/notes/Git.md Normal file
View file

@ -0,0 +1,29 @@
---
created: 2024-02-20 12:23
updated: 2024-03-12 13:49
---
## Merge strategies
![Notes](Git%20Merge%20vs%20Rebase%20vs%20Squash%20¿Qué%20estrategia%20debemos%20elegir-.md#Notes)
## Buscar cuando un bug se introdujo
Utilizar `git bisect`
## Fix messy commits
Ya que estas opciones sobre escriben el historial de git, solo deben aplicarse en local y no commits publicados a un remote.
### Last commit
Si solo necesitamos agregar un cambio pequeño al ultimo commit (typo o correr el formatter), podemos aplicarlo con `git commit --ammend`, se puede sobre escribir el mensaje con `-m`.
### Mutiple commits
Se pueden arreglar el historial de commits con un `git rebase -i [since commit or branch]` y utilizar las estratégias de pick, squash, reword y drop.
En caso de que sepamos que haremos un commit que luego no necesitaremos, podemos hacer:
- `git commit --fixup [commit hash]` -> descarta el commit message de este commit y mantiene el del commit de referencia
- `git commit --squash [commit hash]` -> git juntará los mensajes de todos los commits a hacer squash y el commit de referencia.
Finalmente podemos hacer `git rebase -i --autosquash` y git eligirá las opciones necesarias a tomar en vez de tener que hacerlo de manera manual.

16
_master_wiki/notes/How to build systems.md Normal file
View file

@ -0,0 +1,16 @@
# 1. Humanize
Do everything manually for many iterations
# 2. Organize
Nothing the patters (good and bad ones) that are crippling into your methods
# 3. Mechanize
Automatize the good patterns and try to cope with the bad ones
Automatize with:
- Checklists
- Flowcharts
- Software

67
_master_wiki/notes/Meditacion.md Normal file
View file

@ -0,0 +1,67 @@
## Técnicas de meditación
### Respiración - Susokukan
> Breath in the entire universe; breath out your entire self
Shinzan Rōshi, Practical Zen.
La respiración sirve al momento de meditar ya que ayuda a nuestra mente hacia **algo**, podemos usarla como anclaje de nuestra mente para evitar las distracciones.
En japón, la practica de la meditación contando la respiración es llamada _"susokukan"_. Esta emplea 2 practicas complementarias de meditación: _"rinkan"_ y _"naikan"_, estas dos practicas también pueden ser llamadas _"two wings of a bird"_.
- Meditación _Naikan_: se centra en el desarrollo y mejora de la salud, el bienestar, la fuerza interior y nuestra estabilidad mental y emocional.
- Mediatación _Rinkan_: Ayuda a ver en "el corazón de las cosas", en la realidad misma, como son las cosas realmente.
#### Broad and narrow focus:
Una manera de clasificar la meditación es el tipo de concentración y como actuamos ante los pensamientos que puedan aparecer durante la meditación:
- Narrow focus: nuestra concentración debe mantenerse en nuestra respiración, y tan pronto como notemos un pensamiento debemos cortarlo y volver a la respiración.
- Broad focus: el centro de la concentración sigue siendo la respiración, pero en vez de cortar inmediatamente los pensamientos, ideas o sentimientos, los dejamos pasar e irse, debemos suavemente volver a la respiración.
#### ¿Cómo emplearla?
- Realizar las preparaciones previas
- Concentrarse en la respiración
- Contar las respiraciones hasta 10, luego volver a empezar
- Siento mejor la respiración solo contando los "breath-in"
- Buscar el punto más bajo de la respiración, no cambiar como la hacemos
- dejar pasar los pensamientos/emociones pasajeros y volver a la respiración
- Si un pensamiento/emoción es insistente, darle atención y dejar que se desarrolle, pero no debemos alimentarlo ni ignorarlo, una vez se resuelva, volvemos a la respiración
## The unborn
> One story describes a man who attends a party, and gets well and truly drunk. His best friend wants to make sure he is taken care of, but has to leave early the next morning before the drunken man has emerged from his stupor.
> To ensure he has all he needs, the friend sews a precious jewel into the sleeping man’s cloak, and then he goes on his way. Finally waking alone, the now sober man sets off wandering through the world feeling absolutely abandoned and bereft.
> He struggles through a hand-to-mouth existence until, eventually, meeting the old friend again, he realises that all the while he has been carrying this priceless jewel. He has had absolutely everything he needed right from the beginning.
Dentro de los modelos de desarrollo espiritual, podemos mencionar 2 que a primera vista son contradictorios:
- Uno dice que uno compienza en un punto donde las cosas no son como deberían, hay un sentimiento de miseria o "alienación". Por lo que uno debe realizar un viaje espiritual para encontrar _"plenitud_".
- El otro dice que nosotros ya tenemos _"plenitud"_ dentro de nosotros, pero cuando nos perdemos en nuestros pensamientos, emociones, vistas y otras cosas que pasan y se van, nos alejan de esta _"plenitud"_. Esto está alinieado con la enseñanza del budismo del _"lotus sutra"_.
La practica de meditación de "Unborn" del maestro zen Bankei está basada en la segunda linea de pensamiento, la cual dice principalmente que _"we need to rest in the unborn"_. Esto se puede comparar a la practica del Soto Zen de _"shikan taza"_ (single-minded sitting).
> we don’t need to particularly change ourselves or try to make ourselves into something else. We don’t have to go on painful courses of practice or force ourselves in any way. This is about acknowledging the truth of who we are, who we were, and who we always will be.
El maestro zen Bankei llegó a esta técnica despues de pasar buena parte de su vida buscando una respuesta en todo japón, cuándo debió haberla buscado dentro de si mismo. Porque nosotros contamos con todo lo necesario para poder llegar a la _"plenitud"_ o _"iluminación"_, pero jamás la encontraremos si no buscamos dentro de nosotros.
Esto no quiere decir que la primera linea de pensamientos sea erronea, aunque parezca contradictoria, es también verdad, pero no en la manera de _"debo cambiar quien soy para ser feliz"_, _"Necesito realizar x cosa para que mi vida tenga sentido"_ o _"hay algo malo conmigo que me inpide alcanzar el éxito"_.
#### ¿Cómo emplearla?
- Realizar las preparaciones previas
- No centrar la concentración en nada en particular
- Estar presente con lo que te rodea
- Dejar pasar todo lo que se cruce, todo pensamiento, toda emoción, toda sensación
- No hay nada que hacer, nada que seguir
- The mirror never changes. Perhaps it reflects many things, perhaps only a few. None of them matter. All these arisings are born things and you rest in the Unborn.
- Cuando notemos que nos estamos identificando o aferrando con algo, inmediantamente volvemos a "rest in the unborn"
## Aclaraciones
> [!faq] Aterrizar terminos
> En la jerga espiritualista, se utilizan muchos los terminos de _"plenitud"_, _"iluminación"_, o _"fullfillness"_. Esto hace que parezcan conceptos abstractos y ajenos a nosotros que puede que no nos hayamos cuestionado nunca con anterioridad.
>
> Sin embargo hacen referencia a conceptos cercanos a nosotros, podemos entenderlos mejor o "aterrizarlos" de la siguiente forma:
>
> La pregunta de _"¿Cómo alcanzar iluminación divina?"_ pude presentarse en una persona como _"¿Cuál es el significado de la vida?"_ o _"'¿Cómo encuentro la felicidad?_.

23
_master_wiki/notes/Meditation.md Normal file
View file

@ -0,0 +1,23 @@
- Buscar un lugar cómodo y acolchado
- Posicionarse correctamente:
- Sentarse rectamente
- cabeza en linea con el cuerpo
- mentón elevado pero no mucho
- rodillas separadas
- manos sobre las piernas
- Moverse lentamente unos momentos para encontrar una posición natural
- Relajar el cuerpo, ir de arriba a abajo:
- Cabeza - cuello
- Hombros
- Brazos
- Pecho
- Cadera
- Piernas
- Pies
- Comenzar a respirar
- Siento mejor la respiración solo contando los "breath-in"
- Buscar el punto más bajo de la respiración, no cambiar como la hacemos
- En cuanto a los pensamientos/emociones:
- Concentrarse en la respiración
- dejar pasar los pensamientos/emociones pasajeros y volver a la respiración
- Si un pensamiento/emoción es insistente, darle atención y dejar que se desarrolle, pero no debemos alimentarlo ni ignorarlo, una vez se resuelva, volvemos a la respiración

9
_master_wiki/notes/Misc.md Normal file
View file

@ -0,0 +1,9 @@
Desde siempre me han etiquedato de _"gay"_ por mi comportamiento, gustos y forma de ser, me molestaban y eso igual acondicionó ciertas cosas sobre mi, como mi habla o como me comporto en público.
Además siempre tuve un recelo por las cosas de mujer, ellas siempre tenían más opciones en ciertas cosas que nosotros: más ropa, más colores, más intereses, más diseños. Los hombres debían caer en 2 posibles categorías: fútbol o autos.
Es por eso que cuando me regalaron un marca paginas con un diseño sakura con colores entre purpuras y rosados, significó mucho para mi.
No sé si era la primera vez que me regalaban algo así, probablemente no, pero si de alguien que no era de mi circulo cercano, y sin una razón particular, solo pensó en mi y me lo regaló.
Puede que haya tenido que ver con que venía en conjunto con un libro de mitología japonesa, pero aún así pudo haber elegido otro más "masculino" o simplemente no incluir ninguno, porque no parece ser un marca páginas barato que dan de regalo con un libro, pareciera ser que deliberadamente lo eligió para mi, y eso significó mucho

111
_master_wiki/notes/Neovim.md Normal file
View file

@ -0,0 +1,111 @@
## Config
### Formatters
Hay que añadirlos en `plugins/formatters.lua`, pueden ser instalados con mason.
### Linters
Hay que añadirlos en `plugins/linters.lua`, pueden ser instalados con mason.
### LSP
Hay que añadirlos en `plugins/lsp.lua`, son instalados automáticamente al ser agregados aquí con mason.
## Remember to use:
### Misc
- In visual mode, you can use `J` or `K` to move the selection
- With alt + hjkl I can resize the window, I can restore the size with `<C-w> =`
- `<Leader>r` tiene keymaps para search and replace
### LSP y code actions
- `<Leader>la` -> Code action by lsp
- `<Leader>lA` -> Node action by Treesitter
- `<Leader>lm` -> Toggle node join split (arrays, objects, etc)
- `<Leader>lr` -> rename symbol
- `<Leader>fd` -> See disagnostics in file
- `<Leader>fD` -> See disagnostics in workspace
- `gr` -> List reference of symbol in telescope
### Git
Puedo invocar comandos de git directamente desde neovim con `:Git ...`
### Harpoon
Fast navigation with `<Leader><Leader>[hjkl]`
### Buffers
Puedo hacer pin a ciertos buffers para no cerrarlos con `<Leader>bp` y cerrar todos los buffers no pineados con `<Leader>bP`
Puedo cerrar los otros buffers no activos con `<Leader>bO`
### Treesitter
TODO: Research movemet with Treesitter
### Text objects
Los text objects se utilizan en la forma de ==acción - motion==, Ej: `vi{` es `selecciona dentro de los { }`
Acciones:
- v -> visual selection
- d -> delete
- c -> change
- gc -> comment
Text objects available:
- f -> function
- t -> html tag
### Surround plugin
- Actions (all of them are dot-repeatable out of the box and respect `v:count` for searching surrounding) with configurable keymappings:
- Add surrounding with `sa` (in visual mode or on motion).
- Delete surrounding with `sd`.
- Replace surrounding with `sr`.
- Find surrounding with `sf` or `sF` (move cursor right or left).
- Highlight surrounding with `sh`.
- Change number of neighbor lines with `sn` (see |MiniSurround-algorithm|).
- Surrounding is identified by a single character as both "input" (in `delete` and `replace` start, `find`, and `highlight`) and "output" (in `add` and `replace` end):
- 'f' - function call (string of alphanumeric symbols or '_' or '.' followed by balanced '()'). In "input" finds function call, in "output" prompts user to enter function name.
- 't' - tag. In "input" finds tag with same identifier, in "output" prompts user to enter tag name.
- All symbols in brackets '()', '[]', '{}', '<>". In "input' represents balanced brackets (open - with whitespace pad, close - without), in "output" - left and right parts of brackets.
- '?' - interactive. Prompts user to enter left and right parts.
- All other alphanumeric, punctuation, or space characters represent surrounding with identical left and right parts.
### Text Object
works for:
- Comments (`gc`)
- Visual selection
### Telescope
[Browser plugins mappigns](https://github.com/nvim-telescope/telescope-file-browser.nvim#mappings):
|Insert / Normal|fb_actions|Description|
|---|---|---|
|`<A-c>/c`|create|Create file/folder at current `path` (trailing path separator creates folder)|
|`<S-CR>`|create_from_prompt|Create and open file/folder from prompt (trailing path separator creates folder)|
|`<A-r>/r`|rename|Rename multi-selected files/folders|
|`<A-m>/m`|move|Move multi-selected files/folders to current `path`|
|`<A-y>/y`|copy|Copy (multi-)selected files/folders to current `path`|
|`<A-d>/d`|remove|Delete (multi-)selected files/folders|
|`<C-o>/o`|open|Open file/folder with default system application|
|`<C-g>/g`|goto_parent_dir|Go to parent directory|
|`<C-e>/e`|goto_home_dir|Go to home directory|
|`<C-w>/w`|goto_cwd|Go to current working directory (cwd)|
|`<C-t>/t`|change_cwd|Change nvim's cwd to selected folder/file(parent)|
|`<C-f>/f`|toggle_browser|Toggle between file and folder browser|
|`<C-h>/h`|toggle_hidden|Toggle hidden files/folders|
|`<C-s>/s`|toggle_all|Toggle all entries ignoring `./` and `../`|
|`<Tab>`|see `telescope.nvim`|Toggle selection and move to next selection|
|`<S-Tab>`|see `telescope.nvim`|Toggle selection and move to prev selection|
|`<bs>/`|backspace|With an empty prompt, goes to parent dir. Otherwise acts normally|
## Plugins compatibility errors
Lazy.nvim tiene un `lazy-lock.json`, por lo que ante cualquier problema de compatibilidad, podemos volver a versión especificada aqui con `Lazy restore`. Es importante mantener este archivo en git y solo modificarlo cuando se esté seguro que no hay problemas de compatibilidad.

84
_master_wiki/notes/React.md Normal file
View file

@ -0,0 +1,84 @@
## Issues with useEffect dependency array
React use [shallow comparision](https://learntechsystems.com/what-is-shallow-comparison-in-js/) (values are equals in case of primitive types. In case of object it just check the reference) to check if the dependency changes between renders, this can conduce to bugs in the following situa
### Always use a depency array
```js
useEffect(() => {
setCount((count) => count + 1);
}, []);
```
### Function as dependency
React re defines functions on every render, so the dependency always changes, use `useCallback` to memoize the function so it doesn't change
```js
const logResult = useCallback(() => {
return 2 + 2;
}, []);
useEffect(()=> {
setCount((count) => count + 1);
}, [logResult]);
```
### Array as dependency
The reference to an array changes in every render, use `useRef` so it doesn't change
```js
const [count, setCount] = useState(0);
//extract the 'current' property and assign it a value
const { current: myArray } = useRef(["one", "two", "three"]);
useEffect(() => {
setCount((count) => count + 1);
}, [myArray]);
```
### Object as dependency
The reference to an object changes in every render, use `useMemo` so it doesn't change
```js
const person = useMemo(
() => ({ name: "Rue", age: 17 }),
[] //no dependencies so the value doesn't change
);
useEffect(() => {
setCount((count) => count + 1);
}, [person]);
```
[source](https://blog.logrocket.com/solve-react-useeffect-hook-infinite-loop-patterns/)
## Reset a component state
React utiliza la propiedad `key` para poder identificar un componente, esta propiedad puede ser omitida y react le asignará una en base a su posición en el Virtual DOM Tree.
Cuando la propiedad cambia, React entiende que el componente no es el mismo, por lo que destruye el componente actual y crea uno nuevo, lo que por ende, tiene el estado inicial.
Para esto tenemos dos opciones:
- Pasar alguna propiedad de los datos como key.
- Generar un valor único localmente.
Lo primero es como pasar el ID de un usuario. para lo segundo podemos usar lo siguiente:
```jsx
import { useRef } from 'react';
export default function Parent() {
const key = useRef(crypto.randomUUID());
const resetComponent = () => key.current = crypto.randomUUID();
return (
<div>
<Component key={key.current} />
<button onClick={() => resetComponent()}></button>
</div>
)
}
```

225
_master_wiki/notes/The cult of done.md Normal file
View file

@ -0,0 +1,225 @@
# The Cult Of DONE
### THE Cult Of DONE
1. There are three states of being: Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it $done$.
3. There is no editing stage.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things $done$.
7. Once you’re $done$ you can throw it away.
8. Laugh at perfection. It’s boring and keeps you from being $done$.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as $done$. So do mistakes.
11. Destruction is a variant of $done$.
12. If you have an idea and publish it on the internet, that counts as a ghost of $done$.
13. $done$ is the engine of more.
---
<i class="fas fa-quote-left fa-2x fa-pull-left"></i>
>_Dear Members of the cult of $done$,
>I present to you a manifesto of $done$.
>This was written in collaboration with [Kio Stark](http://municipalarchive.wordpress.com/) in 20 minutes because we only had 20 minutes to get it $done$._
[Bre Pettis, 2009](https://medium.com/@bre/the-cult-of-done-manifesto-724ca1c2ff13)
notes:
The Cult of Done manifesto was written by maker, Bre Pettis and writer, Kio Stark in 2009, and they released it under a creative commons licence.
## There Are Three States of Being
The first principle is that there are three states of being:
1. Not Knowing
2. Action
3. Completion
1. Not Knowing is the initial stage where you are unaware or lack knowledge about something. It could be a problem, a task, a skill, or any situation. This stage is characterized by ignorance, uncertainty, and curiosity.
2. the next phase is action. This is where you learn, explore, work, or take steps to change your state of not knowing. It involves effort, struggle, practice, and nearly always, mistakes.
3. Completion is the final stage where the task or process is finished or the problem is solved. The state of not knowing has been transformed into knowledge or skill through your action.
These three states are cyclical and continuous: after completion, you have a better understanding of the problem, and you very likely have ideas about how to do it again better next time.
---
## Accept that Everything Is a Draft
It Helps to Get it DONE
Prototypes make it to production, quick sketches become long-term plans, and things you write down to get them out of your head end up in the final, published book.
This is as true for a painting as it is for a YouTube channel.
What you're doing is just a draft, it doesn't have to be perfect, it never will be, even after it's done.
> _I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)_
Linus Torvalds, at age 21, changing the world
Some of the biggest community projects in the world started off with just an idea and a draft.
---
## There is no Editing Stage
Painting has no editing, if you make a mistake YOU START AGAIN.
Performing music has no editing, if you make a mistake you keep going and hope the audience didn't notice.
And Pottery has no editing, if it comes out of the kiln and you don't like it, smash it to pieces and start again.
> I call it my billion-dollar mistake. It was the invention of the null reference in 1965.
Tony Hoare
This principle models the way the world actually works.
When you release something into the world, be it a book or a program language, you've lost control of it, in a very big way.
Learn to accept this. Don't tweak what you've got, make another one.
---
## Pretending You Know what you’re Doing Is Almost the Same as Knowing what You Are Doing
So just Accept that You Know what you’re Doing even if You don’t
And Do it
This is the age-old advice to "fake it till you make it".
I completely agree, this is how I do all my projects, and you should too!
---
## If You Wait More than a Week to Get an Idea DONE, **Abandon it**
You don't necessarily have to throw it away, but you DO have to try something else.
When creativity strikes, it flows out of your fingers into your keys, or your paintbrush, or your guitar.
But sometimes the muses don't sing.
If you write a song a week for a whole year, like my hero Jonathan Coulton here did in 2005, you can't procrastinate!
If the end of the week comes without a good finished song, you have to abandon the idea that didn't work, and try the next one.
Ideas in your brain are like a pipe, full of random stuff.
Some of it will be good, some not so good.
If you're not feeling it, don't try to make a bad idea better, try the NEXT idea.
This is the principle that NANOWRIMO encourages its writers with.
Write 1600 words every single day in November, and by October you will have a novel's worth of raw material.
It might be good or it might be bad, but you will have brought out your creativity into the world, and can start editing, or start the next thing.
### The point of Being $DONE$ is not to Finish, But to Get other Things $DONE$
Because the point is not to finish, but to move on to the next one.
You'll be one project better, one project wiser, one project closer to your breakout hit, or viral video, or a beautiful rug that will finally tie the room together.
---
## Once you’re DONE, You Can Throw it away
Once you're done, you can throw it away.
You don't have to keep working on it!
You're done!
Smash the pots! Burn the paintings!
The art isn't the art.
The art is never the art.
The art is the thing that happens inside you when you make it and the feeling in the heart of the beholder.
---
## Laugh At Perfection, It’s Boring and Keeps You from Being $DONE$
I'm not saying have low standards.
I'm saying "you're done".
Let it go.
> _No piece of writing is ever finished...It's just due._
Bill Condon
Your final goal, your end of the project, your deliverable - the thing you're going to get paid to do, comes after you're finished.
The 80/20 rule comes into play here too, don't obsess over the final details, make 4 more.
---
## People without Dirty hands Are Wrong, Doing Something Makes You Right
Life is full of small-minded people with narrow horizons.
And they're all trying to kill you.
They'll kill you with words like "be reasonable", "play it safe", and the worst, "stay in your lane".
You don't have to listen to these people, you don't have to listen to anyone.
I recommend listening to the people who are building the things you love, painting the paintings you love, and writing the music or stories you love.
---
## Failure Counts as DONE, So Do Mistakes
Failure is good.
if you don't try you can't fail
It took me a long time to realise this.
But failure shows you tried.
And you know what NOT to do next time.
An entrepreneur who succeeds with their first company has learned NOTHING.
Someone who fails a few times, has had much better lessons.
> _"Taylor Swift telling you to follow your dreams is like a lottery winner saying,_
> _"Liquidise your assets! Buy powerball tickets! it works!"_
Bo Burnham, on Conan
And no-one knows what they're doing.
Especially those who haven't failed.
Bo Burnham here understands this, success teaching us nothing.
---
## Destruction is a Variant of DONE
When you're done you can move on to other things.
If you destroy the thing, either intentionally or unintentionally, you're still done.
Sometimes experimentation requires destruction.
You've not failed, says Thomas Edison, famously, you've found 10,000 ways in which it doesn't work.
---
## If You Have an Idea and Publish it on the Internet, That Counts as a Ghost of DONE
The muses send some ideas to the wrong mind, I think.
Or the right mind, but with the wrong experience, or skills, or tools.
That idea isn't yours to hide if you can't build it.
Send it out into the world in a post, or a video, and you're done.
You've done your part this time round.
Don't hold on it, imagining you'll do it.
Be honest with yourself, and let others build it for you!
Ideas are worthless, give them away.
---
## DONE Is the Engine Of More
Being done is wonderful.
Being done is addictive.
Being done is the only way to find out what's next.
---

86
_master_wiki/notes/Tiding up the todos list.md Normal file
View file

@ -0,0 +1,86 @@
## TLDR
1. Create or update a task/note as your _"True North"_.
2. Delete old task that doesn't align with your current _"True North"_, Also rephrase/separate hard, un-actionable, un-enjoyable, or complex task.
3. Orginize:
1. Group and move task to projects / tags.
2. Sequence tasks
3. Give priority to tasks
4. Give each tasks a due date and duration estimation
## 1. Before you start, visualize your destination
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.
But don't stop there. "Your next step is to identify why you want to live like that."
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.
> As you continue to explore the reasons behind your ideal lifestyle, you will come to a simple realization. The whole point in both discarding and keeping things is to be happy. It may seem obvious, but it is important to experience this realization for yourself and let it sink into your heart. Before you start tidying, look at the lifestyle you aspire to and ask yourself, “Why do I want to tidy?”
Keep your "why" top-of-mind as you tidy and after by creating task/note that represents your final vision. If you have an accompanying document or image, link to it from your task or attach it to your task/note comments. This is the _"True North"_ that will help you determine whether a task is worth doing. If you’ve written out an all-encompassing vision, break it down into [several goals for each area of your life](https://todoist.com/inspiration/goals-todoist/), and create a task for each.
You may want to give your task a recurring due date to review the vision you set out for yourself at the start of each day.
## 2. Finish discarding first
Right now, your todo's may be stuffed with half-baked ideas, empty projects, and tasks you forgot to check off.
You need to do a full cleanup of the task and cut out the non essential things that doesn't align with your _"True North"_. And yes, you need to let some stuff go so you can focus on the stuff you **actually want/need to do**.
Letting go of old tasks and projects teaches you how to create space for what’s important to you now. As you go through your old tasks, acknowledge that there was a purpose when you added it, but it’s no longer relevant to the life you’re striving for today.
You’re going to run into tasks that you _want_ to delete, but let’s face it, grunt work is necessary for any significant achievement. Try reframing the tasks that don’t excite you. While “run every day” may feel like a chore, “try to run a 10-minute mile today” may be a more specific and motivating challenge.
For work like taking out the trash or doing your taxes, create a separate project called “responsibilities” and pare it down to the things that, while they don’t bring you joy, you just have to do anyway. This is a good exercise to check in on and see how much of your to-do list is things you _get_ to do vs. things you _have_ to do.
## 3. Give every task a place
Now is time to organize the tasks, use any method that makes sense to you, this can be:
- Move tasks to projects
- Group tasks within a list inside a project
- Use a kanban board to organize the status
- Add a tag to a task
### Some stuff to keep in mind while orginizing
#### Keep your projects visible
At this point, it’s tempting to start creating a bunch of sub-projects that you can hide from view. Just as seeing every physical object you own keeps you from accumulating too much stuff, seeing every project you’ve committed to can be a helpful reminder to stay focused on what’s important and not let new tasks and projects clutter up your list.
#### Sequence your tasks
A great way to stay in the flow of a project is to finish one task and immediately move on to the next. Take the time to sequence your tasks in a logical order before you get to work.
#### Add priorities
There are some tasks that are more essential to your goal than others. Set task priorities to keep track of which is which is a must.
Task can be categorized with the folliwing priorities
| Level | Name | Meaning |
| - | - | - |
| 0 | non-processed | The only task with no priority should be the non processed, if they exist for too long, they are not important, delete them. |
| 1 | **High** | Must finish ASAP. |
| 2 | **Medium** | Needs to be done, the default. |
| 3 | Low | Finish if there is time available, can wait. |
#### Give each task a due date
Finally, set a date to complete each task. A handy tip is to make an estimate for how long a task will take to complete and then double it. It’s better to overestimate and finish early than to underestimate and finish late. Give each task a due date and schedule repeating tasks with a recurring due date.
## Make sure your to-do list “sparks joy”
Aesthetics affect our mindset. Give your todo's a style that will put you in a positive mindset whenever you open it. Here are a few tips:
- Write clear, specific, and motivating project and task titles. For example, instead of naming your task “Go for a jog,” try “Take a morning jog through the forest” or “Explore a new running route today”
- Add text formatting and emojis to give them life: “Take a morning jog through the forest 🌅🏃🌲”
- Use a color theme that matches your style or mood
- Arrange your projects in an intuitive way
- Continually let go of the projects and tasks that don't excite you
## Resources
- [The Life-Changing Magic of Tidying Up Your To-Do List](https://todoist.com/inspiration/life-changing-magic-tidying-todoist)

28
_master_wiki/notes/Work.md Normal file
View file

@ -0,0 +1,28 @@
Hoy me quedé atrapado en un issue que no sabía como resolver, gasté har tas horas intentando solucionarlo hasta que me di por hoy ya que no se me ocurrían soluciones nuevas
Qué pude hacer diferente??
- Utilizar el debugger, lo intenté pero el proyecto no estaba configurado para ser usado así y no recordé como tenía que configurarlo
- Haber realizado un controlador de prueba para probar ese código en especifico, pudiendo eliminar posibles causales
- Esto es lo mismo que comentar código??
- esto tambien elimina contexto
- No soluciona o ayuda en el problema, pero evitar queries tan complejas en sequelize creo que hubiera servido, nuevamente pareciera que es mejor hacer las queries a la DB directamente si es que son muy complejas
>ORM's para tareas simples, Queries a la DB cuando son tareas complejas, sin excepciones
Nota del día despues:
La solución era en sequelize, estaba excluyendo los attributos de todas las relaciones, porque solo quería las relaciones para aplicar filtros, pero había una que no estaba excluyendo los atributos. Lo que tenía que hacer era **agregar algo, no quitar algo**.
Así que lo que podría haber ayudado a encontrar este problema es **listar que he hecho y de que maneras podría abordarlo de manera distinta**, incluso si estas suenan estúpidas.
---
algunas cosas para cuestionarse al momento de buscar un issue relacionado a datos:
- Es correcto que este dato aparezca aqui?
- Porqué aparece este dato? que provoca que aparezca??
- Está incluido en la query de la base de datos?? tiene las restricciones (where, inner or outter joins, etc) correspondientes??
- El frontend lo agrega?? desde donde??
- Ok, el dato está guardado así y eso no es correcto, quien le dice que se guarde así??
- lo manda el front de esta manera??
- El front está mandando los datos que le pasa el back?? los modifica?? se están solicitando bien??
- Lo añade el back como parte de la lógica de negocios??

70
_master_wiki/notes/conventional_commits.md Normal file
View file

@ -0,0 +1,70 @@
---
created: 2023-12-17 18:30
updated: 2024-03-17 12:01
---
# Conventional Commits
## 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, by describing the features, fixes, and
> breaking changes made in commit messages.
The commit message should be structured as follows:
```gitcommit
<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:
- fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
- feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
- 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 in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
- 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) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
- footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.
## Type Meaning and Descriptions
- **feat**: A new feature
- **fix**: A bug fix
- **perf**: A code change that improves performance
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- **test**: Adding missing tests or correcting existing tests
- **docs**: Documentation only changes
- **revert**: Revert a commit, the header should have the original header of the reverted commit and the body should have `This reverts commit <hash>.`
- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
---
## Full 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).
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.

17
_master_wiki/notes/free time.md Normal file
View file

@ -0,0 +1,17 @@
```mermaid
flowchart TB
A([Free time]) --> B{Energy level?}
B-- Low --> C{Mentally fatigue?}
B-- Middle --> D{Want to be productive?}
B-- High ---> E(["`Work on _doing_ of some project`"])
C-- Yes --> G([Watch something])
C-- No --> F([Read])
C-- A little --> H
D-- No -->H([Play])
D-- Yes -->I([Update docs])
D-- Yes -->J(["ˋTackle _read later_ˋ"])
```

5
_master_wiki/notes/testo.md Normal file
View file

@ -0,0 +1,5 @@
---
id: e82fe007-77cd-48fb-8fbf-8307af10d7ed
created: 2024-01-31 20:05
updated: 2024-01-31 20:05
---

2
_master_wiki/notes/ulysses pact.md Normal file
View file

@ -0,0 +1,2 @@
![the ulysses pact](The%20Unreasonable%20Effectiveness%20Of%20Plain%20Text.md#^047296)