Forem: Oscar Lopez

🍽️ Obsidian: Restaurantes

Oscar Lopez — Mon, 24 Feb 2025 19:00:00 +0000

Yo soy una persona con muy mala memoria, es por eso que estoy tan obsesionado con tener sistemas que me faciliten el buscar información, porque muchas veces, si no estructuro muy bien esta, no recuerdo cómo la guardé y de igual forma la termino perdiendo. Esto mismo es gran parte del porqué me gusta tanto Obsidian como herramienta, me permite estructurar las cosas de forma muy similar a cómo lo hago mentalmente, es decir, en relaciones.

Por esta misma falta de memoria, he tenido situaciones en las que, por ejemplo, yo soy una persona que no tolera mucho el picante, entonces me ha tocado que voy a un restaurante, quiero pedir chilaquiles, pero no recuerdo si la vez pasada pedí los verdes y estos eran muy picantes, o si estaban bien, o si estaban mejor los rojos, etc. Para solucionar esto, como en muchas de las otras áreas de mi vida, tengo un sistema que me ayuda a organizar esta información de forma que pueda visitarla con facilidad la siguiente vez que vaya al restaurante, ver si algo me gustó, los detalles que tenía, cuánto me gustó, etc.

🧩 Partes

Mi sistema consta de 3 partes:

Restaurante: Como establecimiento o cadena.
Platillo: El platillo como tal que voy a calificar.
Journal: Normalmente esto se enlaza gracias a que en mi Journal escribo mis comidas.

🍽 El Restaurante

Creo una nota del restaurante, porque esta va a ser la nota que voy a visitar cuando vuelva a ir al lugar. Además, voy a utilizar esa nota para que, al crear un nuevo platillo, este se pueda enlazar con el restaurante al que pertenece.

La estructura es muy simple. Para el ejemplo, voy a utilizar mi nota sobre McDonald's.

🏗 Estructura general

---
tags:
    - lugar
    - restaurante
---
# 📌 McDonald's
## ⭐ Recomendaciones

```dataview
TABLE
calificacion as "Calificación"
FROM [[]]
WHERE calificacion
```

## 🎫 Última visita

```dataview
LIST WITHOUT ID link(dateformat(file.cday, "dd-MM-yyyy"))
FROM [[]]
SORT file.cday DESC
LIMIT 1
```

👀 Nota resultado

Ahora vamos a desglosar cada una de las partes de la nota.

🏷 Tags

Las notas de restaurante tienen los tags:

Lugar
Restaurante

Porque en mi sistema existen varios tipos de lugar, por ejemplo, empresas, por eso es necesario hacer la distinción de que es un restaurante.

⭐ Recomendaciones

Las recomendaciones no son nada más que una vista de Dataview que recopila todas las notas de Platillos que vamos a ver más adelante y me las muestra junto con la calificación que les puse. Como se puede apreciar en la imagen, yo soy muy fan de McDonald's.

🎫 Última visita

Por último, esta sección solo busca cuándo fue la entrada más reciente en la que se hizo referencia al establecimiento y me muestra la nota correspondiente a esa fecha.
Esta es una de las partes que menos me gusta, porque requiere que yo llame explícitamente al establecimiento en mi nota de Journal. Quiero mejorar la query de forma que se detecte cuando yo hago una referencia a un platillo que esté enlazado al establecimiento, pero no he tenido el tiempo para hacerlo.

🍕 El Platillo

Esta nota hace referencia al platillo en sí. Esta nota la utilizo desde el restaurante, enlazando la nota al restaurante en el título para después obtener la calificación, pero también para la información nutricional del platillo. Esto es más relacionado con la parte de nutrición, entonces no lo voy a abordar.

🏗 Estructura general

---
calificacion: 5
tags:
  - platillo
---
# 🥘 McMuffin normal de [[McDonald's]]
Mi opinión con respecto a la comida. Algún *detalle* que deba recordar.
## 📊 Información nutrimental
[Calorías:: 310 kcal]
[Proteínas:: 12 g]
[Grasas:: 13 g]
[Carbohidratos:: 20 g]
[Fibra:: 2 g]
[Azúcares:: 2 g]

El platillo tiene el tag platillo para poder filtrarlo rápidamente en las queries, pero además incluyo en la metadata la calificación que le doy en una escala del 1 al 5.

Y en el cuerpo de la nota puedo incluir cualquier información relevante, si la comida estuvo muy picante, si debía pedirlo sin jitomate, cualquier cosa que quiera recordar la siguiente vez que vaya al lugar.

✍ Journal

El journal no lo voy a enseñar, porque sería mostrar información privada, además de que no tiene mucha ciencia, simplemente es incluir en mi nota journal alguna mención que enlace a la nota del restaurante.
De nuevo, esta es la parte que menos me gusta del sistema, porque eso lo hago para tener la referencia de cuándo fue la última vez que fui, pero eso solo funciona si es la primera vez que voy y creo las notas de los platillos o si hago la mención explícita.
Si tú tienes una mejor idea de cómo hacer que cada vez que mencione la nota de platillos en mi sección de comidas, eso se "registre" como una visita, te estaría muy agradecido de que me lo dejaras en un comentario.

🏁 Conclusión

Este sistema en Obsidian me ha permitido mejorar mi organización y memoria con respecto a los restaurantes y platillos que he probado. Aunque tiene algunos puntos de mejora, como la automatización de la última visita, su estructura modular me ha sido bastante útil. Al final, lo importante es tener un sistema que se adapte a mis necesidades y que pueda evolucionar con el tiempo. Si tienes sugerencias sobre cómo mejorar esta metodología, me encantaría leerlas. ¡Gracias por tu tiempo! 😊

🍽️ Obsidian: Restaurant's rating

Oscar Lopez — Mon, 24 Feb 2025 19:00:00 +0000

I have a very bad memory, which is why I am so obsessed with having systems that make it easier for me to search for information. Many times, if I don't structure it very well, I won't remember how I saved it and will end up losing it anyway. This is a big part of why I like Obsidian so much as a tool; it allows me to structure things in a way very similar to how I do it mentally, meaning in relationships.

Due to this same lack of memory, I have encountered situations where, for example, I am someone who does not tolerate spicy food very well. So, when I go to a restaurant and want to order chilaquiles, I don't remember if last time I ordered the green ones and they were too spicy, or if they were fine, or if the red ones were better, etc. To solve this, as in many other areas of my life, I have a system that helps me organize this information so that I can revisit it easily the next time I go to the restaurant. This way, I can see if I liked something, what details it had, how much I liked it, etc.

🧩 Parts

My system consists of 3 parts:

Restaurant: The establishment or chain.
Dish: The specific dish I am going to rate.
Journal: This is usually linked thanks to the fact that in my Journal I log my meals.

🍽 The Restaurant

I create a note for the restaurant because this will be the note I visit when I return to that place. Additionally, I use this note so that, when creating a new dish, it can be linked to the restaurant it belongs to.

The structure is very simple. For this example, I will use my note about McDonald's.

🏗 General Structure

---
tags: 
- place 
- restaurant
---

# 📌 McDonald's
## ⭐ Recommendations

```dataview 
TABLE 
calificacion as "Rating" 
FROM [[]] 
WHERE calificacion 
```

## 🎫 Last Visit

```dataview
LIST WITHOUT ID link(dateformat(file.cday, "dd-MM-yyyy")) 
FROM [[]] 
SORT file.cday DESC 
LIMIT 1
```

👀 Example Note

Now let's break down each part of the note.

🏷 Tags

The restaurant notes have the following tags:

Place
Restaurant

Because my system includes various types of places, such as companies, it is necessary to make the distinction that it is a restaurant.

⭐ Recommendations

The recommendations are nothing more than a Dataview view that compiles all Dish notes, which we will see later, and displays them along with the rating I assigned. As shown in the image, I am a big fan of McDonald's.

🎫 Last Visit

Finally, this section simply searches for the most recent entry that references the establishment and shows me the corresponding note for that date.
This is one of the parts I like the least because it requires me to explicitly mention the establishment in my Journal note. I want to improve the query so that it detects when I reference a dish linked to the establishment, but I haven't had time to do so.

🍕 The Dish

This note refers to the dish itself. I use this note from the restaurant, linking the note to the restaurant in the title to later retrieve the rating, but also to store nutritional information about the dish. This is more related to the nutrition aspect, so I won’t cover it here.

🏗 General Structure

---
calificacion: 5
tags:
  - dish
---
# 🥘 McMuffin Regular from [[McDonald's]]
My opinion on the food. Any *detail* I should remember.
## 📊 Nutritional Information 
[Calories:: 310 kcal] 
[Proteins:: 12 g] 
[Fats:: 13 g] 
[Carbohydrates:: 20 g] 
[Fiber:: 2 g] 
[Sugars:: 2 g]

The dish has the tag dish to make it easier to filter in queries. Additionally, I include the rating in the metadata on a scale from 1 to 5.

In the body of the note, I can include any relevant information, such as whether the food was too spicy, if I should order it without tomato, or anything I want to remember for my next visit.

✍ Journal

I won’t show my journal because it contains private information, and besides, there isn’t much complexity to it. It simply involves mentioning the restaurant note in my journal entry.
Once again, this is the part of the system that I like the least because it only works if it’s my first time at the place and I create dish notes, or if I make an explicit mention.
If you have a better idea on how to ensure that each time I mention a dish note in my meals section, it gets "logged" as a visit, I would be very grateful if you left me a comment.

🏁 Conclusion

This system in Obsidian has allowed me to improve my organization and memory regarding restaurants and dishes I have tried. Although it has some areas for improvement, such as automating the last visit, its modular structure has been quite useful. In the end, the important thing is to have a system that adapts to my needs and can evolve over time. If you have suggestions on how to improve this methodology, I would love to hear them. Thanks for your time! 😊

🚫Notion vs Obsidian

Oscar Lopez — Thu, 16 Jan 2025 16:00:00 +0000

Antes de implementar todo mi sistema de productividad y de journaling en Obsidian, estuve experimentando con varias otras herramientas. Una de las más sonadas es Notion, una herramienta impresionante y altamente personalizable, pero que hoy voy a explorar el porqué yo creo que no es la mejor opción para sistemas de productividad o cosas como segundo cerebro.

💡 Organización de ideas y pensamientos

Desde que estaba en la escuela, siempre tuve complicaciones para tomar notas porque sentía que la forma en la que pensamos no está muy bien adecuada a cómo, muchas veces, tomamos notas. Cuando ves un tema en la escuela, un concepto a su vez se relaciona con otras cosas que probablemente ya sabes. Entonces, si tú veías las notas que tomaba, siempre veías muchas flechas que se cruzaban a través de la página, porque para mí era muy importante saber que el concepto 1 se relaciona o tiene que ver con el concepto A. Por eso, para mí, Obsidian es de las herramientas que más me gustan, porque la idea de relacionar conceptos está en su filosofía. Y creo que es el punto que más lo hace destacar sobre las otras apps de notas como Notion. A pesar de que en Notion también puedes lograr que las cosas se relacionen, es un hecho que no es tan sencillo como en Obsidian y que la propia filosofía de Notion no está orientada a crear relaciones entre las notas. Esto está bien, pero, por lo menos para mis propósitos, eso no era lo que quería. Por esta razón, creo que Notion no logra un buen desempeño a la hora de crear bases de conocimiento.

🔑 Propiedad de datos

Una de las mayores ventajas de Obsidian es que eres dueño de tu información. A pesar de que existen servicios como Sync para sincronizar tus datos entre dispositivos, todo el conocimiento, ideas, proyectos, etc., que tienes en Obsidian es un archivo que existe en tu dispositivo. Es por esto que, si mañana Obsidian decide cambiar su modelo de negocios y comienza a ser de paga, no tendrías que preocuparte por migrar tu información, pues ya la posees como archivos en formato Markdown dentro de tu dispositivo.

Esto te da mucha flexibilidad para probar otras herramientas que sigan la misma filosofía. También te da tranquilidad acerca del uso de tu información, ya que, a menos que utilices Obsidian Sync o algo similar, la información nunca deja tu computadora.

👨‍🎨 Formato de la información

Como ya mencioné, no solo eres dueño de la información, sino que tus notas ya están en un formato abierto que muchas otras herramientas pueden utilizar, en muchos casos sin tener que hacer ningún ajuste. Además, por sí solo, ya es un formato humanamente legible, no como si tuvieras tus notas en json o yml.

🔌 Extensibilidad para desarrolladores

Creo que uno de los puntos que más me encanta de Obsidian es el hecho de que tiene un gran sistema de plugins que permite que la comunidad cree extensiones para solventar las cosas que no tiene completamente resueltas Obsidian. Esto te da muchísimo poder para adaptar Obsidian a tu forma de pensar o trabajar. Te da mucha más libertad de pensar en cómo quieres estructurar tus cosas. Si eres desarrollador como yo, te va a ser mucho más sencillo implementar sistemas que te permitan mantener registros en orden, extraer información, etc. Las posibilidades son infinitas, pero creo que es mucho más sencillo lograr este tipo de sistemas con Obsidian que con Notion.

🫂 Colaboración

A pesar de que me he dedicado a hablar de las ventajas de Obsidian, creo que este es un punto en el que definitivamente flaquea, porque ni siquiera está integrado en su filosofía.

Si quieres compartir información entre tu equipo o tener algo que pueda ser colaborativo, es muy probable, por lo menos desde mi punto de vista, que tengas que explorar posibilidades distintas. Esto se debe a que es un punto que choca mucho con la naturaleza de Obsidian, al ser archivos y estar almacenados en tu computadora. Al querer utilizarlo como una solución colaborativa, te vas a encontrar con overlaps de cambios o cosas similares. Es para este tipo de casos donde creo que Notion reluce. Si quieres tener un CMS o un tablero kanban para tu equipo, ahí es donde sí te recomendaría utilizar Notion.

📃 Conclusión

En resumen, tanto Obsidian como Notion tienen sus fortalezas y debilidades dependiendo del caso de uso. Obsidian destaca por su filosofía centrada en la relación entre conceptos, la propiedad de los datos y su extensibilidad para desarrolladores. Sin embargo, carece de funcionalidades robustas para la colaboración en equipo. Por otro lado, Notion es una herramienta más orientada a entornos colaborativos, como tableros de equipo y sistemas tipo CMS. Por esta razón, mi elección entre ambas dependería del contexto y de las necesidades específicas del proyecto o sistema que quiera implementar.

🚫 Notion vs Obsidian

Oscar Lopez — Thu, 16 Jan 2025 16:00:00 +0000

Before implementing my entire productivity system and journaling in Obsidian, I experimented with several other tools. One of the most notable ones is Notion, an impressive and highly customizable tool. However, today I will explore why I believe it is not the best option for productivity systems or things like a second brain.

💡 Organization of ideas and thoughts

Since I was in school, I always had difficulties taking notes because I felt that the way we think is not well aligned with how we often take notes. When you study a topic in school, a concept is often related to other things you probably already know. So, if you looked at my notes, you would always see many arrows crossing the page because, for me, it was very important to know that concept 1 is related to or connected with concept A. That is why, for me, Obsidian is one of the tools I like the most, because the idea of linking concepts is part of its philosophy. And I think this is the aspect that makes it stand out the most compared to other note-taking apps like Notion. While in Notion, you can also link things, it is a fact that it is not as straightforward as in Obsidian. Moreover, the philosophy of Notion is not geared toward creating relationships between notes. That’s fine, but, at least for my purposes, it was not what I wanted. For this reason, I think Notion does not perform well when it comes to creating knowledge bases.

🔑 Data ownership

One of the greatest advantages of Obsidian is that you are the owner of your information. Even though there are services like Sync to synchronize your data across devices, all the knowledge, ideas, projects, etc., that you have in Obsidian are stored as files on your device. This means that if Obsidian decides to change its business model tomorrow and becomes a paid service, you would not need to worry about migrating your information since you already have it stored as Markdown files on your device.

This gives you a lot of flexibility to try other tools that follow the same philosophy. It also provides peace of mind regarding the use of your information since, unless you use Obsidian Sync or something similar, the information never leaves your computer.

👨‍🎨 Format of the information

As I already mentioned, not only are you the owner of the information, but your notes are also in an open format that many other tools can use, often without requiring any adjustments. Additionally, by itself, it is already a human-readable format. It’s not like having your notes in json or yml.

🔌 Extensibility for developers

One of the aspects I love the most about Obsidian is its excellent plugin system, which allows the community to create extensions to address things that Obsidian does not completely solve. This gives you tremendous power to adapt Obsidian to your way of thinking or working. It offers much more freedom to decide how you want to structure your content. If you are a developer like me, it will be much easier to implement systems that help you keep records organized, extract information, etc. The possibilities are endless, but I believe it is much easier to achieve these kinds of systems with Obsidian than with Notion.

🫂 Collaboration

Although I have focused on the advantages of Obsidian, I believe this is a point where it definitely falls short, as it is not even integrated into its philosophy.

If you want to share information with your team or have something that can be collaborative, it is very likely, at least from my point of view, that you will need to explore other possibilities. This is because it clashes with the nature of Obsidian, where files are stored on your computer. If you try to use it as a collaborative solution, you will face issues like overlaps in changes. For such cases, I think Notion shines. If you want to have a CMS or a kanban board for your team, that is where I would recommend using Notion.

📃 Conclusion

In summary, both Obsidian and Notion have their strengths and weaknesses depending on the use case. Obsidian excels due to its philosophy centered on linking concepts, data ownership, and developer extensibility. However, it lacks robust features for team collaboration. On the other hand, Notion is better suited for collaborative environments, such as team boards and CMS-like systems. For this reason, my choice between the two depends on the context and the specific needs of the project or system I want to implement.

🏗 Métodos `Is`

Oscar Lopez — Wed, 18 Dec 2024 18:00:00 +0000

Últimamente he estado muy adentrado en la programación funcional con lenguajes como Typescript y en mucha menos medida con Haskell y más allá de las partícularidades de de la programación funcional como Monadas , me ha llamado la atención conceptos más relacionado al tipado, como los Union Types y las útilidades con la que viene.

Entre estas útilidades he aprendido el concepto de hacer que los estados inválidos sean irrepresentables, es decir evitar los métodos de la forma isX y en lugar de tener que estar verificando esas condiciones, saber por el simple tipado que tu estado está en un estado inválido.

Esto no es exclusivo de la programación funcional, de hecho incluso está muy relacionado con conceptos como Value Objects de la programación orientada a objetos, pero se lleva muy bien con los Tipos Algebraicos .

Make illegal states unrepresentable
- Yaron Minsky.

🚯 Hacer los estados inválidos irrepresentables

Estamos acostumbrados a que cuándo tenemos una entidad que puede estar en diferentes estados, utilizamos cosas como enums o constantes, que claro, es mejor que utilizar números o strings magicos, pero de cualquier forma tiene ciertos problemas.

Por ejemplo, el tener que estar verificando si la entidad está en el estado que necesitas para poder trabajar con ella.

❎ Alternativa con `is` o `enums`

Con esta alternativa los métodos que dependen de que el User esté en status verificado tienen que revisar el status antes de ejecutar su acción, además de que puede lanzar excepciones en runtime, obligandonos a tener una forma de controlar ese error.

type User = {
  id: string
  name: string
  email: string
  verified: boolean
}

const createUser = (name: string, email: string): User => ({
  id: crypto.randomUUID(),
  verified: false,
  name,
  email
});

const verifyUser = (user: User): User => ({
  ...user,
  verified: true
})

const sendPromoCode = (user: User): void => {
  if(!user.verified) throw new Error('Cannot send code to unverified user')
  console.log('Promo code sended')
}

const unverifiedUser = createUser('Oscar', 'oscareduardolp@gmail.com')

sendPromoCode(unverifiedUser) // No error & insecure at runtime

const verifiedUser = verifyUser(unverifiedUser)

sendPromoCode(verifiedUser) // No error

✅ Sin métodos `is` o `enums`

De esta forma haciendo que el método de sendPromoCode solo pueda recibir usuarios que ya estén verificados, este método solo tiene que preocuparse por hacer la lógica del envío y no tiene la responsabilidad de verificar si el Usuario está en un estado válido además de que la verificación está puesta en un punto más alto e incluso tenemos una verificación desde el sistema de tipado.

// Sin métodos is o enums 
type UnverifiedUser = {
  id: string
  name: string
  email: string
}

type VerifiedUser = UnverifiedUser & { verifiedAt: Date }

const createUser = (name: string, email: string): UnverifiedUser => ({
  id: crypto.randomUUID(),
  name,
  email
});

const verifyUser = (unverifiedUser: UnverifiedUser): VerifiedUser => ({
  ...unverifiedUser,
  verifiedAt: new Date()
})

const sendPromoCode = (verifiedUser: VerifiedUser): void => {
  console.log('Promo code sended')
}

const unverifiedUser = createUser('Oscar', 'oscareduardolp@gmail.com')

sendPromoCode(unverifiedUser) // Error: 'UnverifiedUser' is not assignable to parameter of type 'VerifiedUser'

const verifiedUser = verifyUser(unverifiedUser)
sendPromoCode(verifiedUser) // No error

📖 Conclusión

Adoptar el enfoque de hacer los estados inválidos irrepresentables nos permite construir sistemas más seguros, robustos y mantenibles. Al delegar la validación al propio sistema de tipos, no solo reducimos la carga de verificaciones redundantes en nuestro código, sino que también eliminamos una clase completa de errores en tiempo de ejecución, permitiendo que el compilador actúe como nuestra primera línea de defensa.

Además, esta práctica no está limitada a un paradigma específico, ya que encaja tanto en la programación funcional como en la orientada a objetos. Al combinar conceptos como Tipos Algebraicos, Value Objects o incluso técnicas inspiradas en Domain-Driven Design, podemos modelar nuestros dominios de manera más clara, legible y semántica.

En última instancia, el diseño basado en tipos no solo mejora la experiencia de desarrollo, sino que también nos obliga a pensar cuidadosamente en nuestros modelos, asegurándonos de que el código represente fielmente las reglas de negocio. Así, evitamos que estados inválidos existan incluso como una posibilidad en nuestro sistema.

💡 Te invito a reflexionar sobre tus prácticas actuales y experimentar con esta técnica en tus próximos proyectos. ¡Los beneficios pueden sorprenderte!

🗒 Referencias

Este artículo fue basado en la información de las siguientes fuentes:

Type First Development: Desarollo dirigido por tipos
Designing with types Desarrollando el dominio con tipos
BettaTech: Vídeo con ejemplo de servidores conectados y desconectados.

🏗️ `Is` Methods

Oscar Lopez — Wed, 18 Dec 2024 18:00:00 +0000

Lately, I’ve been deeply immersed in functional programming with languages like TypeScript and to a much lesser extent with Haskell. Beyond the specificities of functional programming like Monads, I’ve been fascinated by concepts related to typing, such as Union Types and the utilities they bring.

Among these utilities, I’ve learned the concept of making invalid states unrepresentable. This means avoiding methods like isX and, instead of having to constantly check those conditions, knowing through the simple type system that your state is valid or invalid.

This is not exclusive to functional programming. In fact, it’s closely related to concepts like Value Objects in object-oriented programming, but it integrates well with Algebraic Data Types.

Make illegal states unrepresentable

- Yaron Minsky

🚯 Making Invalid States Unrepresentable

We’re used to situations where entities can exist in multiple states, and we typically use tools like enums or constants. While this is certainly better than using magic numbers or strings, it still has some drawbacks.

For example, we often have to check if the entity is in the state we need before we can work with it.

❎ Alternative with `is` or `enums`

With this approach, methods that depend on the User being in the verified status must check the status before executing their logic. This can lead to runtime exceptions and forces us to implement ways to handle those errors.

type User = {
  id: string
  name: string
  email: string
  verified: boolean
}

const createUser = (name: string, email: string): User => ({
  id: crypto.randomUUID(),
  verified: false,
  name,
  email
});

const verifyUser = (user: User): User => ({
  ...user,
  verified: true
})

const sendPromoCode = (user: User): void => {
  if (!user.verified) throw new Error('Cannot send code to unverified user')
  console.log('Promo code sent')
}

const unverifiedUser = createUser('Oscar', 'oscareduardolp@gmail.com')

sendPromoCode(unverifiedUser) // No error & insecure at runtime

const verifiedUser = verifyUser(unverifiedUser)

sendPromoCode(verifiedUser) // No error

✅ Without `is` Methods or `enums`

By ensuring that the sendPromoCode method can only receive verified users, this method focuses solely on the logic of sending the promo code and doesn’t have the responsibility of validating if the User is in a valid state. Additionally, the validation is moved to a higher level, with type system verification providing additional safety.

// Without is methods or enums
type UnverifiedUser = {
  id: string
  name: string
  email: string
}

type VerifiedUser = UnverifiedUser & { verifiedAt: Date }

const createUser = (name: string, email: string): UnverifiedUser => ({
  id: crypto.randomUUID(),
  name,
  email
});

const verifyUser = (unverifiedUser: UnverifiedUser): VerifiedUser => ({
  ...unverifiedUser,
  verifiedAt: new Date()
})

const sendPromoCode = (verifiedUser: VerifiedUser): void => {
  console.log('Promo code sent')
}

const unverifiedUser = createUser('Oscar', 'oscareduardolp@gmail.com')

sendPromoCode(unverifiedUser) // Error: 'UnverifiedUser' is not assignable to parameter of type 'VerifiedUser'

const verifiedUser = verifyUser(unverifiedUser)
sendPromoCode(verifiedUser) // No error

📖 Conclusion

Adopting the approach of making invalid states unrepresentable allows us to build safer, more robust, and maintainable systems. By delegating validation to the type system itself, we reduce the burden of redundant checks in our code and eliminate an entire class of runtime errors, allowing the compiler to serve as our first line of defense.

Moreover, this practice is not limited to a specific paradigm. It fits well within both functional programming and object-oriented programming. By combining concepts such as Algebraic Data Types, Value Objects, or even techniques inspired by Domain-Driven Design, we can model our domains in a clearer, more readable, and semantic way.

Ultimately, type-driven design not only improves the development experience but also forces us to carefully consider our models, ensuring that our code faithfully represents business rules. In this way, we prevent invalid states from existing, even as a possibility, within our system.

💡 I invite you to reflect on your current practices and experiment with this technique in your next projects. The benefits might surprise you!

🗒️ References

This article is based on information from the following sources:

Type First Development: Type-Driven Development
Designing with types Domain Modeling with Types
BettaTech: Video example of connected and disconnected servers

✍️ Obsidian: Journaling

Oscar Lopez — Thu, 12 Dec 2024 15:00:00 +0000

Since I was around 14 years old, I have found it very satisfying, relaxing, and therapeutic to keep a journal where I write down all sorts of things that happen to me throughout the day. At first, it was just about making a summary of what had happened during the day: important events, feelings, etc.

Over time, I’ve changed the way and the tools I use for it. At first, I did it in OneNote on a tablet I had when I was 14 years old. Then I switched to Journey, an app specialized in this that allowed you to add feelings and that kind of thing. Seeing that I was a bit tied to the platform and, at at the time, to the device (since it didn’t have a desktop version), I moved to Evernote. It was simpler there, but it gave me the advantage of being cross-platform. However, I felt that something was missing.

One day, while watching a video on YouTube, I came across Roam Research, an app that allowed you to organize your notes with links. I loved this idea, but at that time it was in beta, and I couldn’t get access. This left me feeling disappointed. I researched and looked for alternatives that offered the same capability: being able to link things in a graph-like manner. I struggled a lot to find a similar option; I even considered developing it myself (very enthusiastic thinking, XD). Finally, I found a solution that met all my needs: Obsidian.

What I’m going to show here is how, by leveraging all the capabilities of Obsidian, I’ve built a journaling system that works for me and allows me to keep control of many aspects of my life.

🧩 Parts

My journal consists of many parts, each dedicated to an important aspect of my life. In this article, I’ll touch on them briefly, but if there’s interest in any particular one, feel free to mention it, and I can go into more detail on that topic.

🟦 Meta Info

Since it’s written in Obsidian, and therefore in Markdown, my notes have a meta information section where I record relevant things about the day that would otherwise be more complicated to log naturally.

💙 Feelings

I think it’s good to be aware of how we feel throughout the day, beyond just good or bad. I like having this section to express with more precise words how I felt during the day: whether the day was stressful, if I felt overwhelmed, worried, excited, tired, etc.

This also allows me to notice patterns in my behavior, see what usually makes me feel overwhelmed, or how I feel in certain situations. Knowing this, I can better manage those situations. Moreover, it promotes being more specific in expressing our feelings.

---
feeling:
  - happy
  - proud

Having it in the note metadata, I can query which days I felt angry, happy, proud, etc.

😴 Sleep

A fundamental part of my life is sleeping. I enjoy it a lot. For a long time, I struggled to know how much time I needed to sleep since sometimes 8 hours would leave me tired, and with fewer hours, I’d feel refreshed. This section helps me track times and actions on the occasions when I sleep best. I log bedtime, wake-up time, and quality.

sleep:
  bedtime:
    hour: 23
    minute: 30
  wakeup:
    hour: 7
    minute: 30
  rating: 5

As with feelings, having this in metadata allows me to have a dashboard to average the sleep time during which I rest better.

🎆 Important Events

It’s happened to all of us: you’re chatting with a friend who asks what you’ve been up to, and you go blank. You’ve done a lot since you last saw each other, but right now, you’re not aware of it. For me, in this section, I log everything I think is worth mentioning in such situations: a small work achievement, progress toward an exercise goal, a new dish I cooked, etc.

With this, I can later have a dashboard to select a date range and see the type of things that happened in that range.

# Tablero de Logros / Eventos 
  ## 📆🏆 Mes

  ```dataview 
  TABLE evento
  FROM #bitacora 
  AND !"Plantillas"
  WHERE length(evento) > 0 
  AND date(file.name, "dd-MM-yyyy").month >= 12
  AND date(file.name, "dd-MM-yyyy").year = 2024
  SORT date(file.name, "dd-MM-yyyy") DESC
  ```

🏷 Tags

Lastly, the most important part: tags. These allow me, firstly, to know that the note I’m writing is part of my journal, thanks to the #journal tag. This way, no matter where I write the note, I know it will be considered part of the journal. Beyond that, there are many more tags, and you’re only limited by your needs, but for me, there are two main ones:

#nap: As part of my sleep tracking, it’s also important to note which days I needed a nap because the exhaustion was too much.
#pain_of_x: I tag whenever I feel unwell. It might be a headache, stomachache, backache. I like having this information in case an illness or discomfort evolves into something more serious. Additionally, it helps me find patterns regarding what I ate or what happened on the days I felt unwell that could have influenced the discomfort.

🟧 Main Information

This section is more like a standard journal, except for a few parts, but it’s mostly what I see when reviewing notes. It’s more like the content of the note and is written in a more natural style.

💪 Exercise

This section is not written naturally, especially because it’s not something I log in the journal note. All exercise-related information is a separate methodology/system that I plan to review in another article.

For now, what I see in the note is a summary of the exercises performed.

And in each individual note, I can find full information on repetitions, variations, etc.

🥪 Meals

In this section, I log my meals throughout the day to track the nutritional values of what I’ve eaten. Similarly, this system was reviewed in the Obsidian: Nutrition 🔗 article. There, you can see the full system.

In general, I log what I ate, and a table is displayed showing the total values of my macronutrients consumed.

🚀 Projects

How I manage my projects and document my progress was already reviewed in the Obsidian: Projects 🔗 article.

In summary, just like with exercise, here I only have a query showing the completed tasks during the day related to any of the projects I work on. It gives me greater visibility into how I’m progressing and how, bit by bit, I’m making substantial progress.

🙌 Gratitudes

I like to keep in mind the things I’m grateful for, not in a "magical" way, but in a way that allows me to appreciate things we sometimes take for granted or that once thrilled us and later forgot how lucky we are to have achieved them.

I make a big effort to fill this section as thoroughly as possible each day. Later, I can gather all the entries in a Gratitude Dashboard that reminds me, as a whole, of all the things I’m grateful for.

It’s very useful on hard days.

✅ Anti To-Do List

We’re used to having a to-do list to see what we need to accomplish during the day. I have mine. But also, at the end of the day, I like to review all the tasks I completed. It gives me a dose of satisfaction to see everything I advanced, even if it’s unrelated to projects, but still very valuable and important, like cleaning the house or doing the dishes.

Additionally (and this is just an idea), you can track something similar for the people you live with, not with the intent of counting who does more, but with the intent of being aware of everything others do, which we might not always appreciate enough.

🏆 Recognitions

I’m a big fan of the culture of recognizing others. I think we often wait for the right moment or the right instance to acknowledge people. Personally, I try to recognize as soon as possible and as specifically as possible to truly give value to the recognition. I really dislike dynamics where people are invited to give recognitions, and they "acknowledge" everyone because, at least in my *

conception*, vaguely and generally recognizing everyone is equivalent to recognizing no one.

So, if I can, I like to recognize the person as soon as possible. But in case I can’t, and also to have a record of valuable things about that person, I keep track of recognitions for people throughout the day.

Again, leveraging the power of dataview, I use these listings so that each recognition appears in the note for each person.

❤‍🔥 Entries

Here, I write about events of the day, but with much more detail: things I liked, how they made me feel, things that upset me, why they upset me, things that intrigue me. This is the most personal part, as the main purpose is to vent and clarify my thoughts.

Still, through Obsidian’s links and metadata annotations, I can add more data to the note. For example, I can write (feeling:: excited), and that will automatically add it to the feelings list I mentioned earlier.

Beyond that, it’s the part with the least technical purpose, but it holds the most emotional importance.

🧠 Thoughts and Things Learned

Every day, we learn something. This section shows me a summary of all the notes that are reflections or knowledge I wrote down during the day, giving me greater visibility into everything I learned that day and might not be as aware of.

📖 Conclusion

Keeping a journal in Obsidian has not only helped me better organize my daily life but also reflect on my experiences, learn from my patterns, and appreciate the small things that sometimes go unnoticed. The interesting thing about this system is that it’s not static; I can adapt it to my needs, add new sections, or even simplify it if necessary.

I’d love to know if you also keep some kind of journaling or if you have any tips or ideas that could complement this approach. Is there anything you would add or change in a system like this? I’d love to hear about it! 😊

✍️ Obsidian: Journaling

Oscar Lopez — Thu, 12 Dec 2024 15:00:00 +0000

Desde que tenía como 14 años, he encontrado muy satisfactorio, relajante y desahogante tener un journal donde anotar todo tipo de cosas que me ocurren a lo largo del día. Al principio, solo fue hacer un resumen de lo que había pasado en el día: eventos importantes, sentimientos, etc.

Con el tiempo, he ido cambiando la forma y las herramientas con las que lo hago. Primero lo hice en OneNote, en una tableta que tenía cuando tenía 14 años. Después me cambié a Journey, una app especializada en eso que te permitía agregar sentimientos y ese tipo de cosas. Al ver que estaba un poco atado a la plataforma y, en ese momento, al dispositivo (pues no tenía una versión para computadora), me cambié a Evernote. Ahí era más simple, pero me daba la ventaja de ser multiplataforma. Sin embargo, sentía que algo me faltaba.

Un día, viendo un video en YouTube, me topé con la existencia de Roam Research, una app que te permitía organizar tus notas con enlaces. Esta idea me encantó, pero en ese momento estaba en beta y no pude obtener acceso. Eso me hizo sentir decepcionado. Estuve investigando y buscando alternativas que cumplieran con esa misma capacidad: el poder enlazar las cosas a forma de grafo. Me costó mucho trabajo encontrar una opción similar; incluso consideré desarrollarla yo mismo (un pensamiento muy entusiasta tenía XD). Hasta que por fin me encontré con una solución que cubría todo lo que necesitaba: Obsidian.

Lo que voy a mostrar aquí es cómo, aprovechando todas las capacidades que tiene Obsidian, he armado un sistema de journaling que funciona para mí y que me permite tener el control de muchos de los aspectos de mi vida.

🧩 Partes

Mi journal consta de muchas partes, cada una destinada a un aspecto importante en mi vida. En este artículo las voy a tocar por encima, pero si existe interés en alguna en particular, no duden en mencionarlo y puedo extenderme más en ese tema.

🟦 Meta Info

Al estar escrito en Obsidian, por lo tanto en Markdown, mis notas tienen una parte de meta información donde registro cosas relevantes al día, pero que de otra forma me sería más complicado ingresar de una forma más natural.

💙 Sentimientos

Creo que es bueno ser consciente de cómo nos sentimos a lo largo del día, más allá de bien o mal. Me gusta tener esta parte para expresar con palabras más precisas cómo me sentí a lo largo del día: si el día fue estresante, si me sentí abrumado, preocupado, emocionado, cansado, etc.

Esto, además, me permite notar patrones en mi comportamiento, ver en la mayoría de las veces qué es lo que me hace sentir abrumado o cómo me siento bajo ciertas situaciones. A su vez, sabiendo eso, gestiono mejor esas situaciones. Además, promueve ser más preciso al expresar nuestros sentimientos.

---
sentimiento: 
    - contento
    - orgulloso

Al tenerlo en la metadata de la nota, puedo hacer queries de qué días me sentí molesto, contento, orgulloso, etc.

😴 Sueño

Una parte fundamental de mi vida es dormir. Lo disfruto mucho. Por mucho tiempo batallé para saber cuánto tiempo dormir, pues algunas veces con 8 horas me levantaba cansado y, con menos horas, me levantaba fresco. Esta parte me permite llevar un registro de tiempos y cosas que hago en las ocasiones que mejor descanso. Registro hora de dormir y hora de despertar, además de la calidad.

sueno: 
    dormir: 
        hora: 23
        minuto: 30
    despertar: 
        hora: 7
        minuto: 30
    rating: 5

Al igual que con los sentimientos, el tenerlo en la metadata me permite tener un tablero para promediar con cuánto tiempo de sueño descanso mejor.

🎆 Eventos importantes

A todos nos ha pasado que alguna vez hablas con alguna amistad que te pregunta qué has hecho y te quedas en blanco. Has hecho muchas cosas en todo el tiempo que no se han visto, pero justo ahora no eres consciente de ello. Para mí, en esta parte anoto todas las cosas que creo que son dignas de contar en esas situaciones: un pequeño logro del trabajo, un avance en alguna meta de ejercicio, alguna comida nueva que hice, etc.

Con esto luego tengo un tablero en el que puedo seleccionar un rango de fechas y ver qué son ese tipo de cosas que han pasado en ese rango de tiempo.

# Tablero de Logros / Eventos 
  ## 📆🏆 Mes

  ```dataview 
  TABLE evento
  FROM #bitacora 
  AND !"Plantillas"
  WHERE length(evento) > 0 
  AND date(file.name, "dd-MM-yyyy").month >= 12
  AND date(file.name, "dd-MM-yyyy").year = 2024
  SORT date(file.name, "dd-MM-yyyy") DESC
  ```

🏷 Tags

Por último, la parte más importante: los tags. Estos me permiten, en primer lugar, saber que la nota que estoy escribiendo es parte de mi journal, gracias al tag #journal. De esta forma, no importa dónde escriba la nota, sé que será considerada dentro de lo que es el journal. Después de esa, hay varias etiquetas más y ahí estás limitado solo por lo que dicten tus necesidades, pero para mí son 2 las más importantes:

#siesta: Como parte de mi monitoreo de sueño, también es importante tener en cuenta qué días necesité tomar una siesta porque el cansancio fue mucho.
#dolor_de_x: Marco con un tag cada que me siento mal de algo. Puede ser que me haya dolido la cabeza, el estómago, la espalda. Me gusta tener esa información por si evoluciona de una forma más importante la enfermedad o el malestar. Además, también me permite encontrar patrones con respecto a qué comí o qué pasó los días que me sentí mal que podría haber influido en ese malestar.

🟧 Información Principal

Esta parte ya está más en forma de journal normal, salvo por algunas partes, pero es mucho más parte de lo que veo al revisar notas. Es más como el contenido de la nota y lo redacto de forma más natural.

💪 Ejercicio

Esta parte no es redactada de forma natural, sobre todo porque ni siquiera es algo que capturo en la nota del journal. Toda la información relacionada con mi ejercicio es una metodología/sistema aparte que tengo intenciones de revisar en otro artículo.

Por ahora, lo que veo en la nota es un resumen de los ejercicios realizados.

Y ya en cada nota individual puedo encontrar la información completa de repeticiones, variación, etc.

🥪 Comida

En esta parte anoto mis comidas a lo largo del día para llevar el track de los valores nutricionales de lo que he comido. De igual forma, este sistema ya lo revisé en el artículo de Obsidian: Nutrición 🔗. Ahí puedes ver el sistema al completo.

En general, anoto lo que comí y se me despliega una tabla con los valores totales de mis macronutrientes ingeridos.

🚀 Proyectos

La forma en la que gestiono mis proyectos y documento mis avances ya lo revisé en el artículo de Obsidian: Proyectos 🔗.

De forma resumida, al igual que con el ejercicio, aquí solo tengo una query que me muestra las tareas completadas en el día que estuvieron relacionadas con alguno de los proyectos en los que trabajo. Me da mayor visibilidad de cómo voy avanzando en las cosas y cómo, de poco en poco, voy avanzando bastante.

🙌 Agradecimientos

Me gusta tener presente las cosas por las que estoy agradecido, no de una forma "mágica", sino de una forma que me permita apreciar las cosas que algunas veces damos por hecho o que, en su momento, nos hacían mucha ilusión y después olvidamos lo afortunados que somos por haberlas logrado.

Me esfuerzo mucho en llenar esta parte lo mejor posible cada día. Además, después puedo recolectar todas las cosas en un Tablero de agradecimientos que me recuerda, en conjunto, todas las cosas por las que estoy agradecido.

Es muy útil para los días complicados.

✅ Anti Todo List

Normalmente acostumbramos tener una lista de tareas para ver qué es lo que tenemos que hacer a lo largo del día. Yo tengo la mía. Pero también, al final del día, me gusta revisar todas las tareas que logré. Me da una dosis de satisfacción ver todo en lo que avancé, que no está relacionado con proyectos, pero que también es muy valioso e importante, por ejemplo, limpiar la casa o lavar los trastes.

Como adición (y esto solo es una idea), puedes llevar algo similar de la gente con la que vives, no con el afán de contar quién hace más, sino con el afán de ser consciente de todo lo que los demás hacen, que tal vez no siempre apreciamos lo suficiente.

🏆 Reconocimientos

Soy muy fan de la cultura de reconocer a las personas. Creo que muchas veces esperamos a los momentos adecuados o la instancia adecuada para reconocer a la gente. Por mi parte, procuro reconocer lo más pronto y lo más específico posible, para de verdad darle valor al reconocimiento. No me gustan nada las dinámicas donde se da apertura para dar reconocimientos y la gente "reconoce" a todos porque, por lo menos para mi concepción, reconocer a todos de forma vaga y general es lo mismo que no reconocer a nadie.

Entonces, si puedo, me gusta reconocerle a la persona lo más pronto posible, pero en caso de que no, y además para yo tener un registro de las cosas valiosas de esa persona, voy registrando los reconocimientos a las personas a lo largo del día.

Otra vez, aprovechando el poder de dataview, utilizo estos listados para que cada reconocimiento aparezca en la nota de cada persona.

❤‍🔥 Entradas

Aquí escribo eventos del día, pero con mucho más detalle: cosas que me gustaron, cómo me hicieron sentir, cosas que me molestaron, por qué me molestaron, cosas que me intrigan. Esta es la parte más personal, pues el mayor propósito es desahogarme y poder aclarar mis ideas.

De cualquier forma, a través de los links de Obsidian y de anotaciones de meta información, puedo agregar más datos a la nota. Por ejemplo, puedo escribir (sentimiento:: emocionado) y eso automáticamente se agregará al listado de sentimientos que hablé al principio.

Más allá de eso, es la parte que menos propósito técnico tiene, pero es la que más importancia emocional tiene.

🧠 Pensamientos y cosas aprendidas

Todos los días aprendemos algo. Esta sección me muestra un resumen de todas las notas que son reflexiones o conocimientos que anoté a lo largo del día, dándome mayor visibilidad de todo lo que aprendí ese día y que tal vez no soy tan consciente.

📖 Conclusión

Llevar un journal en Obsidian no solo me ha ayudado a organizar mejor mi día a día, sino también a reflexionar sobre mis experiencias, aprender de mis patrones y apreciar más las pequeñas cosas que a veces pasan desapercibidas. Lo interesante de este sistema es que no es estático; puedo adaptarlo según mis necesidades, añadir nuevas secciones o incluso simplificarlo si lo necesito.

Me encantaría saber si tú también llevas algún tipo de journaling o si tienes algún truco o idea que podría complementar este enfoque. ¿Hay algo que agregarías o cambiarías en un sistema como este? ¡Me encantaría leerlo! 😊

🗺 Remote Work

Oscar Lopez — Wed, 04 Dec 2024 18:06:00 +0000

The Covid-19 pandemic marked a turning point in how many companies perceive work. Although it was a global tragedy with countless losses, it also forced organizations to explore alternative schemes, such as remote work, which previously seemed unfeasible for many sectors. This change not only transformed the workplace dynamics for companies but also had a significant impact on the lives of workers.

In my case, the shift to remote work arose out of necessity rather than choice. During the peak of the pandemic, I worked in an office, but after moving out of my parents' house, transportation difficulties became a significant obstacle. Without a car and with a limited salary, I depended on my parents' help to get to work, which made me question my independence. It was then that I found a remote job opportunity, which not only solved my transportation issues but also allowed me to achieve true autonomy.

This new setup gave me the freedom to choose where to live without worrying about proximity to the workplace. It also removed barriers that limited my ability to balance personal and professional needs. Since that experience, I have been certain that remote work is not just a preference but a lifestyle that has provided me with benefits that would be nearly impossible to achieve in a traditional in-person setup.

In this article, I will explore the many advantages of remote work, from the independence it provides to the opportunities it creates for improving quality of life.

✅ Advantages of Remote Work

🚗 No commute time: I don’t have to add the time spent commuting to and from the office to my workday. That time can be used for activities I truly value, like spending time with my partner, family, or friends, sleeping a little longer, exercising, or simply relaxing.
🖥️ Control over the setup: Having my office at home allows me to customize my workspace according to my needs. My chair and desk are the ones I find most comfortable, and I can constantly improve my setup because it’s mine. This not only improves my comfort but also indirectly benefits my employer since I use this personal infrastructure to work more efficiently.
⏳ Working more without commitment: If a special occasion demands it, I feel more willing to stay a little longer working since being at home doesn’t take me away from my loved ones or personal activities. In an in-person setup, this extra time would mean sacrificing much more, making me less likely to agree to it.
🌱 Better quality of life: Not spending time commuting allows me to dedicate myself to things that are more important to me, like eating healthier, exercising, sleeping better, learning something new, or simply enjoying activities that truly enrich my daily life.
🔒 Safer: In a country where insecurity is a constant problem, avoiding traveling around the city with a laptop gives me peace of mind. I prefer staying at home, where I feel safer and less exposed to unnecessary risks.
🤓 Better focus for introverts: Many engineers, myself included, work better without interruptions. At home, I can have focused lapses without the physical distractions of an office. While this reduces casual conversations, the impact on performance is clearly positive.
👨‍👩‍👧 Connection with family: Staying home allows me to be more present for my family. I can enjoy small moments, like having a meal together or simply spending time with them, which would be impossible in an in-person setup.
🥗 Better nutrition: Working from home gives me access to my kitchen, allowing me to prepare healthier meals and save on eating out. This positively impacts both my health and my budget.
💡 Trust in employees: As Spotify said, employees are not children. If a company doesn’t trust its team, the problem isn’t remote work; it’s the company culture. Physical control doesn’t ensure performance, but trust does.
🌍 Broader talent pool: An in-person setup limits the talent you can access since you can only hire those who live nearby or are willing to relocate. Companies that offer remote work have access to a global talent pool and don’t need to spend extra to compete with companies that already allow it.

❎ Disadvantages of Remote Work

🤝 Less team unity: Building a strong culture is harder because parallel cultures often arise: one for in-person employees and one for remote workers.

Solution: Create an inclusive culture that can be appreciated by both remote and in-office workers. This includes documenting processes, sharing important anecdotes with the entire team, and organizing virtual activities to foster camaraderie.
💬 Less spontaneous communication: The lack of casual interactions limits informal conversations that could spark ideas or quickly solve problems.

Solution: Encourage informal virtual communication spaces, such as dedicated channels on platforms like Slack, or quick, agenda-free meetings.
🏠 Difficulty disconnecting: Working from home makes it easy to fall into the habit of working extra hours or not setting clear boundaries.

Solution: Set strict schedules and, if possible, have a separate workspace to mark the difference between work and personal life.
📉 Feeling of isolation: Some employees may feel disconnected from the team or the organization.

Solution: Conduct regular check-ins with employees, prioritize meetings where the whole team is visible, and schedule integration activities that include everyone.
📡 Dependence on technology: Internet outages or technical problems can disrupt workflow.

Solution: Provide employees with necessary tools, such as backup connections (e.g., portable modems) and accessible tech support.
🧩 Difficulty integrating new employees: New hires may take longer to adapt without direct interaction with the team.

Solution: Develop a well-structured remote onboarding plan with assigned mentors and clear documentation to facilitate adaptation.
📊 Harder to supervise work progress: The lack of physical interaction can make some leaders insecure about their team’s activities.

Solution: Build a culture of trust based on rigorous selection processes and confidence in the employees’ capabilities. Recognize that employees are not children, and if someone abuses this trust, take immediate action to prevent it from affecting the rest of the team.
👩‍🏫 Less informal learning: In an office, it’s easier to learn by observing others, something that doesn’t happen naturally in remote work.

Solution: Organize virtual coworking sessions or share recordings of important meetings to encourage peer learning.
😓 Harder to handle conflicts: Discussions can be more challenging to resolve without face-to-face communication.

Solution: Train leaders in virtual conflict resolution and promote an environment of respect and clarity in written communication.
🔄 Resistance to change: Some companies or employees may struggle to adapt to remote work, creating initial friction.

Solution: Provide training on remote work tools and highlight the benefits this setup offers to both the team and the organization.

📖 Conclusion

Remote work is not just a passing trend; it represents a shift in how we understand and execute our responsibilities. While it has its challenges, these can be addressed with conscious strategies that strengthen trust, communication, and team culture, without losing sight of the benefits this setup offers.

The advantages are clear: greater flexibility, access to global talent, better quality of life for employees, and, in many cases, superior performance. Adapting to remote work is not just a way to meet modern expectations but also an opportunity to build stronger, more motivated, and productive teams.

What do you think about remote work? Have you experienced its benefits or faced its challenges? I’d love to hear your experiences and perspectives in the comments. Let’s talk about the future of work! 🌍✨

🗺 Trabajo remoto

Oscar Lopez — Wed, 04 Dec 2024 18:00:00 +0000

La pandemia de Covid-19 marcó un punto de inflexión en la manera en que muchas empresas conciben el trabajo. Aunque fue una tragedia global con innumerables pérdidas, también forzó a las organizaciones a explorar esquemas alternativos, como el trabajo remoto, que antes parecían inviables para muchos sectores. Este cambio no solo transformó la dinámica laboral de las empresas, sino que también tuvo un impacto significativo en la vida de los trabajadores.

En mi caso, el cambio al trabajo remoto surgió como una necesidad antes que como una elección. Durante el punto más alto de la pandemia, trabajaba de manera presencial en una oficina, pero al mudarme de casa de mis padres, las dificultades para transportarme se convirtieron en un obstáculo importante. Sin un coche y con un salario limitado, dependía del apoyo de mis padres para llegar al trabajo, lo que me hizo cuestionar mi independencia. Fue entonces cuando encontré una oportunidad de empleo remoto, lo que no solo resolvió mis problemas de transporte, sino que también me permitió alcanzar una verdadera autonomía.

Este nuevo esquema me dio la libertad de elegir dónde vivir sin preocuparme por la cercanía al lugar de trabajo. Además, eliminó barreras que limitaban mi capacidad de equilibrar mis necesidades personales con las laborales. Desde esa experiencia, tengo claro que el trabajo remoto no es solo una preferencia, sino un estilo de vida que me ha otorgado ventajas que difícilmente podría lograr en un esquema tradicional presencial.

En este artículo, exploraré las múltiples ventajas del trabajo remoto, desde la independencia que brinda hasta las posibilidades que abre para mejorar la calidad de vida.

✅ Ventajas del trabajo remoto

🚗 No tiempos de traslado: No tengo que sumarle al horario laboral el tiempo que gasto yendo y viniendo de la oficina. Ese tiempo lo puedo invertir en actividades que realmente valoro, como pasar tiempo con mi pareja, familia o amigos, dormir un poco más, hacer ejercicio o simplemente relajarme.
🖥️ Control sobre el setup: Tener mi oficina en casa me permite personalizar mi espacio de trabajo según mis necesidades. Mi silla y escritorio son los que considero más cómodos, y puedo mejorar mi setup constantemente porque es mío. Esto no solo mejora mi comodidad, sino que indirectamente también beneficia a mi empleador, ya que aprovecho esta infraestructura personal para trabajar de forma más eficiente.
⏳ Trabajar más sin compromiso: Si alguna ocasión especial lo amerita, me siento más dispuesto a quedarme un poco más tiempo trabajando, ya que estar en casa no me aleja de mis seres queridos ni de mis actividades personales. En un esquema presencial, este tiempo extra implica sacrificar mucho más, lo que hace menos probable que acepte hacerlo.
🌱 Mejor calidad de vida: Al no gastar tiempo en transporte, puedo dedicarme a cosas más importantes para mí, como cuidar mi alimentación, hacer ejercicio, dormir mejor, aprender algo nuevo o simplemente disfrutar de actividades que realmente enriquecen mi día a día.
🔒 Más seguro: En un país donde la inseguridad es un problema constante, evitar transportarme con una computadora por la ciudad me da tranquilidad. Prefiero quedarme en casa, donde me siento más seguro y menos expuesto a riesgos innecesarios.
🤓 Mayor enfoque para los introvertidos: Muchos ingenieros, incluyéndome, trabajamos mejor sin interrupciones. En casa puedo tener lapsos de atención plena sin las distracciones físicas de una oficina. Aunque esto reduce las conversaciones casuales, a nivel de rendimiento el impacto es positivo.
👨‍👩‍👧 Conexión con la familia: Estar en casa me permite estar más presente para mi familia. Puedo disfrutar pequeños momentos, como una comida juntos o simplemente compartir tiempo, que serían imposibles en un esquema presencial.
🥗 Mejor alimentación: Al trabajar desde casa, tengo acceso a mi cocina, lo que me permite preparar comidas más saludables y ahorrar en alimentos fuera de casa. Esto impacta positivamente tanto mi salud como mi presupuesto.
💡 Confianza en los empleados: Como dijo Spotify, los empleados no son niños. Si una empresa no confía en su equipo, el problema no es el trabajo remoto, sino la cultura de la empresa. El control físico no asegura el rendimiento, la confianza sí.
🌍 Ampliación del talento disponible: Un esquema presencial limita el talento al que puedes acceder, ya que solo puedes contratar a quienes viven cerca o están dispuestos a mudarse. Las empresas que ofrecen trabajo remoto tienen acceso a una base de talento global y, además, no necesitan gastar más para competir con compañías que ya lo permiten.

❎ Contras

🤝 Menos unidad en el equipo: Es más difícil construir una cultura sólida porque suelen surgir dos culturas paralelas: la presencial y la remota.

Solución: Crear una cultura inclusiva que pueda ser apreciada tanto por quienes están en remoto como por quienes están en la oficina. Esto incluye documentar procesos, compartir anécdotas importantes con todo el equipo y realizar actividades virtuales que fomenten la camaradería.
💬 Menor comunicación espontánea: La falta de interacciones casuales limita las conversaciones informales que pueden generar ideas o resolver problemas rápidamente.

Solución: Fomentar espacios de comunicación informal virtual, como canales dedicados en plataformas como Slack o reuniones rápidas sin agenda para mantener esas interacciones.
🏠 Dificultad para desconectarse: Al trabajar desde casa, es fácil caer en el hábito de trabajar más horas o no establecer límites claros.

Solución: Definir horarios estrictos y tener un espacio de trabajo separado, si es posible, para marcar la diferencia entre el trabajo y la vida personal.
📉 Sensación de aislamiento: Algunos empleados pueden sentirse desconectados del equipo o de la organización en general.

Solución: Realizar check-ins regulares con los empleados, priorizar reuniones en las que se vea a todo el equipo y programar dinámicas de integración que incluyan a todos.
📡 Dependencia tecnológica: Si la conexión a internet falla o hay problemas técnicos, puede afectar el flujo de trabajo.

Solución: Proveer a los empleados de herramientas necesarias, como conexiones secundarias (por ejemplo, un modem portátil) y soporte técnico accesible.
🧩 Dificultad para integrar nuevos empleados: Los nuevos integrantes pueden tardar más en adaptarse sin una interacción directa con el equipo.

Solución: Crear un plan de onboarding remoto bien estructurado, con mentores asignados y documentación clara para facilitar la adaptación.
📊 Más difícil supervisar el progreso del trabajo: La falta de interacción física puede generar inseguridad en algunos líderes sobre las actividades del equipo.

Solución: Construir una cultura de confianza basada en el hecho de que los empleados pasaron por un proceso de selección riguroso y están capacitados para realizar su trabajo. Reconocer que los empleados no son niños y confiar en ellos es clave. Si alguien abusa de esa confianza, tomar acciones inmediatas para evitar que afecte al resto del equipo.
👩‍🏫 Menos aprendizaje informal: En la oficina es más fácil aprender al observar a otros, algo que no ocurre de forma natural en remoto.

Solución: Organizar sesiones de coworking virtual o compartir grabaciones de reuniones importantes para fomentar el aprendizaje entre compañeros.
😓 Más difícil manejar conflictos: Las discusiones pueden ser más complicadas de resolver sin comunicación cara a cara.

Solución: Capacitar a los líderes en resolución de conflictos virtual y promover un ambiente de respeto y claridad en la comunicación escrita.
🔄 Resistencia al cambio: Algunas empresas o empleados pueden tener dificultad para adaptarse al remoto, creando fricciones iniciales.

Solución: Ofrecer capacitación sobre las herramientas de trabajo remoto y aclarar los beneficios que este esquema aporta al equipo y a la organización.

📖 Conclusión

El trabajo remoto no es solo una tendencia pasajera; representa un cambio en la manera en que entendemos y ejecutamos nuestras responsabilidades laborales. Aunque tiene desafíos, estos pueden resolverse con estrategias conscientes que fortalezcan la confianza, la comunicación y la cultura del equipo, sin renunciar a los beneficios que este esquema ofrece.

Las ventajas son claras: mayor flexibilidad, acceso a talento global, mejor calidad de vida para los empleados y, en muchos casos, un rendimiento superior. Adaptarse al trabajo remoto no solo es una forma de estar a la altura de las expectativas modernas, sino también una oportunidad para construir equipos más fuertes, motivados y productivos.

¿Qué opinas tú sobre el trabajo remoto? ¿Has experimentado sus ventajas o enfrentado alguno de sus desafíos? Me encantaría conocer tus experiencias y puntos de vista en los comentarios. ¡Hablemos sobre el futuro del trabajo! 🌍✨

✍️ Code Comments

Oscar Lopez — Mon, 16 Sep 2024 03:00:00 +0000

Recently, I came across this other article where the author talks about when it’s appropriate to use comments in code, and when it’s not. It's a great article, and I recommend checking it out, even though I don’t fully agree with some of the points made.

In this article, I’ll try to give my take on using comments, when to use them, when not to, alternatives, and the reasoning behind each decision.

🗣 More Explicit Code

In my case, I think of comments as a way to give context to the people reading your code, but they should not be used to explain the way you implemented the logic. If the implementation of the logic requires comments, you’re likely not being expressive enough in your code. I believe it’s part of our responsibility to make sure the code "explains" itself, even if that means being overly explicit in some aspects.

For instance, if I have this code:

const calculateTaxes = (income: number, personType: number): number => {
    const taxRate = personType === 1 // Is Moral Person 
        ? 0.3 // Tax rate for moral person 
        : 0.2; // Tax rate for natural person 
    return income * taxRate; 
}

It has several comments that could easily be replaced by better variable naming and typing, rendering those comments useless.

A better approach might look like this:

const calculateTaxes = (income: number, personType: PersonTypeEnum): number => {
    const taxRate = personType === PersonTypeEnum.MoralPerson 
        ? TAX_RATE_MORAL_PERSON 
        : TAX_RATE_NATURAL_PERSON; 
    return income * taxRate; 
}

Looking at it now, our function might have more code, but it now explains itself.

🧰 Maintenance

Another advantage of writing code that explains itself is that it’s safer and easier to maintain. It’s very common, and actually happens often, that comments become outdated relative to the code, which means the explanation in the comment no longer makes sense in the context of the function or class.

🌍 Context

A good way to use comments is to explain why certain code is doing something, rather than what it does. For example:

const calculateDiscount = (product: Product): number => {
    if(product.category === 'smartphone') return 0; // Smartphones has 0 discount
    return product.price * 0.2;
}

❎ Good

In this example, even though the comment might seem "good", it actually doesn’t add any value. Simply by reading the code, we already know that smartphones have no discount, but the real question we have is why? This is important for respecting the business rule, but the comment doesn’t help with that. It just gives us the information we would already get from reading the code.

✔ Better

A better use of comments would be to explain why smartphones don’t get a discount, for example:

const calculateDiscount = (product: Product): number => {
    if(product.category === 'smartphones') return 0; // Since smartphones are now made to order, they cannot have any discounts 
    return product.price * 0.2;
}

This comment gives us much more information and helps us understand why that business rule exists.

This is just an example, I know this code could be improved in terms of semantics and clarity, but I’ll leave that as an exercise for the reader XD.

⚰ Dead Code

A very bad practice I’ve encountered in my work is commenting out code to remove it. In my opinion, this is not acceptable. In the long run, it makes the code much harder to read. Without proper syntax highlighting, it’s easy to lose track of where you’re working, and you might end up editing commented-out code. Plus, it just adds noise by showing old implementations that can interfere with new ideas.

Today, there’s no need to do this. If we need to recover a piece of code, we can rely on git or another version control system. So please, stop doing that.

✅ `TODO` Comments

The kind of comment you leave when there’s a missing functionality isn’t necessarily a bad comment per se, but it can cause problems if it’s forgotten and makes its way into production. Personally, I’d recommend having a CI/CD system that checks for all those TODOs and creates specific issues, so nothing gets left behind.

👀 Important Considerations

When I talk about comments, I’m referring to those we use to explain things or even to prevent certain parts of the code from being executed, but I’m not including comments that are part of the documentation.

📖 Conclusion

In general, there is no golden rule for comments; it all depends on what you’re working on. But I think these recommendations can help you get rid of bad habits you may not even be aware of, and overall improve the way you write code.

If you have any thoughts, questions, or feedback, feel free to leave them in the comments, and I’d be happy to discuss them.

✍️ Comentarios

Oscar Lopez — Sun, 15 Sep 2024 15:00:00 +0000

Recientemente me topé con este otro artículo en el que habla acerca de cuándo es adecuado y cuándo no utilizar comentarios en el código, es un gran artículo y recomiendo que vayan a echarle un vistazo, a pesar de eso, aunque no coincido con algunos de los puntos que describe.
En este artículo intentaré dar mi versión de los hechos acerca de utilizar comentarios, cuándo sí, cuándo no, alternativas y el porqué de cada de una de estas decisiones.

🗣 Código más explícito

En mi caso, yo pienso en los comentarios como una forma de dar contexto a la gente que lee tu código, más no debe de ser una forma de explicar la forma en la que implementaste la lógica, si la implementacion de la lógica requiere agregar comentarios, lo más probable es que no estás siendo lo suficientemente expresivo en tu código, ya que creo que parte de nuestra responsabilidad es que el código se "explique" a sí mismo, incluso si esto implica ser excesivamente explícito en algunos aspectos.

Es decir, si tengo este codigo:

const calculateTaxes = (income: number, personType: number): number => {
    const taxRate = personType === 1 // Is Moral Person 
        ? 0.3 // Tax rate for moral person 
        : 0.2; // Tax rate for natural person 
    return income * taxRate; 
}

Tiene varios comentarios que fácilmente podrían ser reemplazados por un mejor nombramiento de variables y tipado, dejando inútiles a esos comentarios.

Un mejor enfoque sería algo como esto:

const calculateTaxes = (income: number, personType: PersonTypeEnum): number => {
    const taxRate = personType === PersonTypeEnum.MoralPerson 
        ? TAX_RATE_MORAL_PERSON 
        : TAX_RATE_NATURAL_PERSON; 
    return income * taxRate; 
}

Viéndolo así, es posible que nuestra función ahora tenga más código pero ahora se explica a sí mismo.

🧰 Mantenimiento

Otra ventaja de hacer que el código se explique a sí mismo, es que es más seguro y fácil de mantener, ya que es muy sencillo y de hecho ocurre mucho, que los comentarios queden desactualizados con respecto al código de forma que lo que explique el comentario no tenga mucho sentido con respecto a la función o clase.

🌍 Contexto

Una buena manera de usar los comentarios es no explicar el qué hace cierta parte del código sino el porqué lo hace, por ejemplo.

const calculateDiscount = (product: Product): number => {
    if(product.category === 'smartphone') return 0; // Smartphones has 0 discount
    product.price * 0.2;
}

❎ Bien

En este ejemplo, aunque el comentario podría parecer que está "bien", la realidad es que no nos aporta nada, simplemente leyendo el código nosotros ya podemos saber que los smartphones tienen cero descuento, pero la pregunta que tenemos es el porque, para también respetar esa regla de negocios, pero el comentario no nos ayuda con eso, se limita a darnos la información que obtendríamos leyendo el código.

✔ Mejor

Una mejor forma de utilizar los comentarios, sería para explicar el porqué los smartphones no tienen descuento, por ejemplo:

const calculateDiscount = (product: Product): number => {
    if(product.category === 'smartphones') return 0; // Since smartphones are now made to order, they cannot have any discounts 
    return product.price * 0.2; 
}

Este comentario nos da mucha más información y nos da mucho más idea de el porqué esa regla de negocio.
Esto es parte del ejemplo, sé que este código podría mejorar en semántica y claridad , pero eso se queda como ejercicio para el lector XD.

⚰ Código muerto

Una muy mala práctica que me he encontrado en mi trabajo es el comentar el código para eliminar código, por mi parte, esto no es nada considerable, a la larga hace mucho más complicado de leer el código, sin el adecuado resaltado de sintaxis es muy sencillo de perder la concepción de dónde estar trabajando y puede que estés editando código comentado, y solo agrega ruido pudiendo ver viejas implementaciones de algo y dejando que estas se cuelen a las nuevas ideas.
Hoy en día ya no es necesario hacer ese tipo de cosas, si necesitamos recuperar una pieza de código podemos recurrir a git o algún sistema de control de versiones, así que por favor dejen de hacer eso.

✅ Comentario `TODO`

El tipo de comentario que dejas cuándo te falta implementar una funcionalidad, no es un comentario malo per se, pero sí que puede desencadenar cosas muy malas si se olvida que se puso y llega a producción, en lo personal yo recomendaría tener un sistema de CI/CD que se encargue de revisar todos esos TODO y crear los issues especificos, para que nada se quede en el olvido.

👀 Consideraciones importantes

Cuándo hablo de comentarios, me refiero a los comentarios que utilizamos para explicar o incluso para evitar que cierta parte del código sea ejecutado, pero no incluye los comentarios que forman parte de la documentación del código.

📖 Conclusión

En general, no existe una regla de oro acerca de los comentarios, todo a va a depender mucho de lo que estés haciendo, pero creo que estas recomendaciones te pueden servir si quieres irte quitando malas prácticas de las que tal vez no eres consciente y de forma transversal, mejorar la forma en la que escribes tu código.

Si tienes alguna consideración, duda o reclamos, dejala en los comentarios y con gusto podremos hablar de ello.

Forem: Oscar Lopez

🍽️ Obsidian: Restaurantes

🧩 Partes

🍽 El Restaurante

🏗 Estructura general

👀 Nota resultado

🏷 Tags

⭐ Recomendaciones

🎫 Última visita

🍕 El Platillo

🏗 Estructura general

✍ Journal

🏁 Conclusión

🍽️ Obsidian: Restaurant's rating

🧩 Parts

🍽 The Restaurant

🏗 General Structure

👀 Example Note

🏷 Tags

⭐ Recommendations

🎫 Last Visit

🍕 The Dish

🏗 General Structure

✍ Journal

🏁 Conclusion

🚫Notion vs Obsidian

💡 Organización de ideas y pensamientos

🔑 Propiedad de datos

👨‍🎨 Formato de la información

🔌 Extensibilidad para desarrolladores

🫂 Colaboración

📃 Conclusión

🚫 Notion vs Obsidian

💡 Organization of ideas and thoughts

🔑 Data ownership

👨‍🎨 Format of the information

🔌 Extensibility for developers

🫂 Collaboration

📃 Conclusion

🏗 Métodos `Is`

🚯 Hacer los estados inválidos irrepresentables

❎ Alternativa con is o enums

✅ Sin métodos is o enums

📖 Conclusión

🗒 Referencias

🏗️ `Is` Methods

🚯 Making Invalid States Unrepresentable

❎ Alternative with is or enums

✅ Without is Methods or enums

📖 Conclusion

🗒️ References

✍️ Obsidian: Journaling

🧩 Parts

🟦 Meta Info

💙 Feelings

😴 Sleep

🎆 Important Events

🏷 Tags

🟧 Main Information

💪 Exercise

🥪 Meals

🚀 Projects

🙌 Gratitudes

✅ Anti To-Do List

🏆 Recognitions

❤‍🔥 Entries

🧠 Thoughts and Things Learned

📖 Conclusion

✍️ Obsidian: Journaling

🧩 Partes

🟦 Meta Info

💙 Sentimientos

😴 Sueño

🎆 Eventos importantes

🏷 Tags

🟧 Información Principal

💪 Ejercicio

🥪 Comida

🚀 Proyectos

🙌 Agradecimientos

❎ Alternativa con `is` o `enums`

✅ Sin métodos `is` o `enums`

❎ Alternative with `is` or `enums`

✅ Without `is` Methods or `enums`

✅ `TODO` Comments

✅ Comentario `TODO`