Update from obsidian - thinkpad
Affected files: .obsidian/plugins/obsidian-omnivore/data.json Read Later/Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir-.md Read Later/How Game Reviews Actually Affect You.md Read Later/Let's Get Webby! 🦀 🕸️.md Read Later/Use cases for Rust.md Read Later/What the Rust Book didn't tell you about testing....md Read Later/Why Signals Are Better Than React Hooks.md books/Book/Caballo de troya.md books/Book/En el nombre de la rosa.md notes/coping mechanisms/Good Enough.md notes/utils/Crear una nueva funcionalidad.md notes/utils/Git.md notes/utils/React.md projects/personal-page-notes/List of Games.md projects/quests.md
This commit is contained in:
parent
c3e2778f4e
commit
784703b79b
15 changed files with 160 additions and 55 deletions
|
|
@ -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)
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,6 @@ url_original: |
|
|||
>> [!info] ㅤ
|
||||
>> I can create front end web apps with this libraries
|
||||
|
||||
|
||||
---
|
||||
## Original
|
||||
|
||||
|
|
|
|||
|
|
@ -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**
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue