diff --git a/.obsidian/plugins/obsidian-omnivore/data.json b/.obsidian/plugins/obsidian-omnivore/data.json index ee79d18..6025581 100644 --- a/.obsidian/plugins/obsidian-omnivore/data.json +++ b/.obsidian/plugins/obsidian-omnivore/data.json @@ -2,10 +2,10 @@ "dateHighlightedFormat": "yyyy-MM-dd HH:mm:ss", "dateSavedFormat": "yyyy-MM-dd HH:mm:ss", "apiKey": "ec3bba50-4770-471b-99b1-9953ca523d8c", - "filter": "ADVANCED", - "syncAt": "2023-11-03T07:52:14", - "customQuery": "in:archive has:highlights", - "template": "# {{{title}}}\n\n{{# note }}\n## Notes\n\n{{{ note }}}\n{{/ note }}\n{{#highlights.length}}\n## Highlights\n\n{{#highlights}}\n> [!quote] ㅤ\n> {{{text}}} \n> \n> [source]({{{highlightUrl}}}) {{#labels}} #{{name}} {{/labels}}\n> {{#note}}\n>\n>> [!info] ㅤ\n>> {{{note}}}\n\n{{/note}}\n{{/highlights}}\n{{/highlights.length}}\n\n---\n## Original\n\n{{{ content }}}", + "filter": "HIGHLIGHTS", + "syncAt": "2023-11-05T12:56:15", + "customQuery": "", + "template": "# {{{title}}}\n\n{{# note }}\n## Notes\n\n{{{ note }}}\n{{/ note }}\n{{#highlights.length}}\n## Highlights\n\n{{#highlights}}\n> [!quote] ㅤ\n> {{{text}}} \n> \n> [source]({{{highlightUrl}}}) {{#labels}} #{{name}} {{/labels}}\n> {{#note}}\n>\n>> [!info] ㅤ\n>> {{{note}}}\n\n{{/note}}\n{{/highlights}}\n{{/highlights.length}}\n---\n## Original\n\n{{{ content }}}", "highlightOrder": "LOCATION", "syncing": false, "folder": "Read Later/", diff --git a/Read Later/Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir-.md b/Read Later/Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir-.md new file mode 100644 index 0000000..e6987f8 --- /dev/null +++ b/Read Later/Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir-.md @@ -0,0 +1,28 @@ +--- +id: fc51bf82-66d3-451f-8f64-17d6add50f92 +title: | + Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir? +status: ARCHIVED +tags: + - read-later + - Youtube +date_added: 2023-11-04 14:14:49 +url_omnivore: | + https://omnivore.app/me/https-www-youtube-com-watch-pp-yg-ukz-2-l-0-ih-nxd-w-fza-a-253-d-18b9b548407 +url_original: | + https://www.youtube.com/watch?pp=ygUKZ2l0IHNxdWFzaA%253D%253D&v=HlmZLXMOpEM +--- + +# Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir? + +## Notes + +- Merge commit: Se crea un commit que tiene 2 padres, el último commit de main y la feature branch, se mantiene la trazabilidad hacia la feature branch pero el historial queda visualmente más complejo ^5df1b4 +- Rebase: Se copian los commits de la feature branch a main como nuevos commits, se pierde la trazabilidad hacia la feature branch pero queda un historial lineal en main +- Squash commit: Se juntan todos los commits en uno solo con un squash que queda en main, se pierde la trazabilidad hacia la feature branch pero queda un historial lineal en main +--- +## Original + +[Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir?](https://www.youtube.com/watch?pp=ygUKZ2l0IHNxdWFzaA%253D%253D&v=HlmZLXMOpEM) + +By [CodelyTV - Redescubre la programación](https://www.youtube.com/@CodelyTV) \ No newline at end of file diff --git a/Read Later/How Game Reviews Actually Affect You.md b/Read Later/How Game Reviews Actually Affect You.md index c27bbdb..f5ed85b 100644 --- a/Read Later/How Game Reviews Actually Affect You.md +++ b/Read Later/How Game Reviews Actually Affect You.md @@ -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 diff --git a/Read Later/Let's Get Webby! 🦀 🕸️.md b/Read Later/Let's Get Webby! 🦀 🕸️.md index 45fa71f..8309a5a 100644 --- a/Read Later/Let's Get Webby! 🦀 🕸️.md +++ b/Read Later/Let's Get Webby! 🦀 🕸️.md @@ -26,7 +26,6 @@ url_original: | >> [!info] ㅤ >> I can create front end web apps with this libraries - --- ## Original diff --git a/Read Later/Use cases for Rust.md b/Read Later/Use cases for Rust.md index a33fd56..387ab44 100644 --- a/Read Later/Use cases for Rust.md +++ b/Read Later/Use cases for Rust.md @@ -21,7 +21,7 @@ url_original: | > 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  @@ -50,7 +50,7 @@ Here are a few common types of applications built using Rust: **Server-side applications / Microservices** * Rust is a great choice for server-side applications and microservices because it is fast and efficient. -* Some popular server-side web frameworks written in Rust include Actix Web, Warp, and Axum. +* ==Some popular server-side web frameworks written in Rust include Actix Web, Warp, and Axum.== * Many companies are migrating their critical microservices to Rust because of its safety and performance guarantees. **WebAssembly** diff --git a/Read Later/What the Rust Book didn't tell you about testing....md b/Read Later/What the Rust Book didn't tell you about testing....md index b2c2e5e..491715c 100644 --- a/Read Later/What the Rust Book didn't tell you about testing....md +++ b/Read Later/What the Rust Book didn't tell you about testing....md @@ -25,8 +25,7 @@ url_original: | > 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 @@ -45,14 +44,14 @@ We can use mocking to substitute real objects for mock objects and assert certai What's that? You want an example? Consider the following code… -trait Database { - fn execute_query(&self, query: String); -} - -fn get_user(db: impl Database, id: i32) { - let query = format!("SELECT * from Users where id={}", id); - db.execute_query(query); -} +trait Database { + fn execute_query(&self, query: String); +} + +fn get_user(db: impl Database, id: i32) { + let query = format!("SELECT * from Users where id={}", id); + db.execute_query(query); +} We want to test _get\_user_ without making real database queries. The solution is to mock the _Database_ trait and assert _execute\_query_ is called with the correct query. But how? @@ -61,34 +60,34 @@ We can use the [mockall crate](https://letsgetrusty.us6.list-manage.com/track/cl Here is how we would test _get\_user_… -#[cfg(test)] -use mockall::{automock, predicate::*}; - -#[cfg_attr(test, automock)] -trait Database { - fn execute_query(&self, query: String); -} - -fn get_user(db: impl Database, id: i32) { - let query = format!("SELECT * from Users where id={}", id); - db.execute_query(query); -} - -#[cfg(test)] -mod tests { - use super::*; - - #[test] - fn get_user_executes_correct_query() { - let mut mock_database = MockDatabase::new(); - mock_database.expect_execute_query() - .with(eq("SELECT * from Users where id=22".to_owned())) - .once() - .returning(|_x| ()); - - get_user(mock_database, 22); - } -} +#[cfg(test)] +use mockall::{automock, predicate::*}; + +#[cfg_attr(test, automock)] +trait Database { + fn execute_query(&self, query: String); +} + +fn get_user(db: impl Database, id: i32) { + let query = format!("SELECT * from Users where id={}", id); + db.execute_query(query); +} + +#[cfg(test)] +mod tests { + use super::*; + + #[test] + fn get_user_executes_correct_query() { + let mut mock_database = MockDatabase::new(); + mock_database.expect_execute_query() + .with(eq("SELECT * from Users where id=22".to_owned())) + .once() + .returning(|_x| ()); + + get_user(mock_database, 22); + } +} Boom! Now we have a unit test that's fast, reliable, and deterministic! If you haven't seen my [intro to testing in Rust video](https://letsgetrusty.us6.list-manage.com/track/click?u=9f28b35c1658c447f3b962a54&id=90d4167901&e=d0eb971086) make sure to check it out! diff --git a/Read Later/Why Signals Are Better Than React Hooks.md b/Read Later/Why Signals Are Better Than React Hooks.md index d143a5e..d60060f 100644 --- a/Read Later/Why Signals Are Better Than React Hooks.md +++ b/Read Later/Why Signals Are Better Than React Hooks.md @@ -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 diff --git a/books/Book/Caballo de troya.md b/books/Book/Caballo de troya.md new file mode 100644 index 0000000..195d5f2 --- /dev/null +++ b/books/Book/Caballo de troya.md @@ -0,0 +1,5 @@ +--- +status: Wishlist +kind: Book +author: J.J. Benítez +--- diff --git a/books/Book/En el nombre de la rosa.md b/books/Book/En el nombre de la rosa.md new file mode 100644 index 0000000..5885440 --- /dev/null +++ b/books/Book/En el nombre de la rosa.md @@ -0,0 +1,5 @@ +--- +status: Wishlist +kind: Book +author: Umberto Eco +--- diff --git a/notes/coping mechanisms/Good Enough.md b/notes/coping mechanisms/Good Enough.md new file mode 100644 index 0000000..e69de29 diff --git a/notes/utils/Crear una nueva funcionalidad.md b/notes/utils/Crear una nueva funcionalidad.md index 81629ba..6b7f4fe 100644 --- a/notes/utils/Crear una nueva funcionalidad.md +++ b/notes/utils/Crear una nueva funcionalidad.md @@ -1,6 +1,3 @@ -# Cómo crear una nueva funcionalidad - -Los siguientes pasos son una breve guía sobre como implementar cualquier funcionalidad al momento de desarrollar, es agnóstica a cualquier tecnología, lenguaje y complegidad. Además podemos pensar en ella como una estrategia recursiva en donde vamos realizando funcionalidades atómicas para producir una funcionalidad más compleja. ## TLDR @@ -16,6 +13,15 @@ Los siguientes pasos son una breve guía sobre como implementar cualquier funcio - [[#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. diff --git a/notes/utils/Git.md b/notes/utils/Git.md new file mode 100644 index 0000000..59fee39 --- /dev/null +++ b/notes/utils/Git.md @@ -0,0 +1,25 @@ +## Merge strategies + + + +## 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. \ No newline at end of file diff --git a/notes/utils/React.md b/notes/utils/React.md index 7250932..cf97b49 100644 --- a/notes/utils/React.md +++ b/notes/utils/React.md @@ -1,3 +1,5 @@ +## 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 @@ -50,3 +52,33 @@ useEffect(() => { ``` [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 ( +