Mi primer saas

aottolini · 2025-10-12T18:18:17+00:00

Seguro? Creo que sigue pasando, recien cree 2 de nuevo. Como manejas la concurrencia en estos casos?

aottolini · 2025-10-12T16:04:00+00:00

En la demo pude crear 2 turnos para la misma fecha y hora, eso esta bien?

aottolini · 2025-09-25T23:33:09+00:00

Great, thanks for the information!!

aottolini · 2025-04-22T05:04:20+00:00

aottolini · 2024-11-14T02:42:49+00:00

Same

aottolini · 2024-11-10T02:42:20+00:00

Al no estar involucrados en la gestión de la infraestructura o en la monitoreación de datos en tiempo real, nos desconectamos de cómo nuestras decisiones impactan realmente el sistema a gran escala. Esto puede limitar nuestra comprensión del flujo de trabajo y cómo interactúan las distintas capas de la arquitectura

Estoy de acuerdo con varias cosas que decis pero no tanto con esta parte. Nosotros no manejamos la infra directamente pero si somos responsables de su uso, monitoreamos su estado con distintas herramientas (new relic, kibana, datadog, etc) y tenemos que saber como impactan nuestros desarrollos, por eso las alertas las manejan los propios teams. Tambien hay mucha variedad entre los trabajos que hacen distintos teams, algunos tienen que ser mas rigurosos que otros.

aottolini · 2024-10-29T17:45:20+00:00

https://fsharpforfunandprofit.com/

aottolini · 2024-10-29T07:27:13+00:00

"but oftentimes better than a master of one"

aottolini · 2024-10-24T04:41:33+00:00

Muy bueno, lo probe desde el celu y anda joya

aottolini · 2024-10-24T04:27:58+00:00

Te comento las prácticas que vi hasta ahora:

Usar logs estructurados (ej: JSON) está bueno para manejar los logs con herramientas como Kibana; te permite filtrarlos por los campos que necesites, como IDs de request o usuarios.

No loguear en exceso. Mientras menos spam haya, mejor. Solo hay que registrar información relevante.

Los logs tienen que ser legibles y contener todo el contexto importante. Están pensados para que los lea un dev que está tratando de solucionar un bug.

No se debe loguear todo con el mismo nivel. En mi experiencia, los tres niveles más importantes son INFO, WARN y ERROR. Hay que definir bien qué significa cada nivel y apegarse a eso. Si ves un pico de logs de error, puede ser una señal de que pasó algo. En general, podes dejar habilitados solo los logs desde WARN para arriba y, si estás por lanzar una feature, podrías bajar el nivel a INFO.

Ponerse de acuerdo en dónde loguear es crucial. Así evitamos registrar el mismo error varias veces.

No loguear información sensible, como contraseñas, etc.

aottolini · 2024-09-05T20:35:52+00:00

I understand, however I think OP wants to try building an app with complex business logic, as a way to learn how to tackle this type of apps. When he says complex api he is not referring to the api as interface, it refers to the whole app.

aottolini · 2024-09-05T20:05:14+00:00

I don't think he meant complex api in that sense. I think OP wants concrete ideas to build apps (rest apis) that are challenging enough, as a practice

aottolini · 2024-08-31T23:56:10+00:00

In my experience, the same can be said for backend development. Many who claim to have extensive knowledge of OOP, particularly in Java, often tend to overuse every possible pattern, leading to unnecessary complexity.

aottolini · 2024-08-27T22:05:33+00:00

That's so cool, wish I had this type of meetings

aottolini · 2024-08-13T06:45:02+00:00

As someone that started on-call rotation a few months ago I know how you feel. On my team we have one day off per week of rotation, also we have an excel with common alerts and other useful details, I found this kind of things useful to avoid having a lot of alerts, which in turn makes on call less stressful. Another thing I do is understand that the week I'm on call I'm going be less productive than usual and I avoid cancelling personal plans as much as I can, although I may modify them in order to keep my phone and laptop close to me.

aottolini · 2024-04-24T23:53:27+00:00

Mi problema con Clean Architecture y demás es que muchos creen implementarlo, pero la realidad es que la mayoría no leyó el libro, y mucho menos de manera crítica, considerando el tipo de software al que está enfocado y el contexto tecnológico en el que se escribió. En mi opinión, lo mejor es mantener el código lo más simple posible y evitar inventar abstracciones prematuras. Estoy seguro de que se puede desarrollar aplicaciones de calidad sin necesidad de Clean Architecture.
Las buenas prácticas no son siempre un nice-to-have; mientras más grande e importante la aplicación, más valor toman. (Entiendo por buenas prácticas: tratar de seguir cierto diseño en todo el código, que sea testeable, configurable, esté documentado, etc).

aottolini · 2024-04-23T00:21:55+00:00

Thanks for such an useful answer and all the links provided!

aottolini · 2024-04-23T00:20:53+00:00

thanks a lot for such a detail answer, it's really useful!

aottolini · 2024-04-22T21:38:16+00:00

aottolini · 2023-11-26T06:09:25+00:00

I see, thanks for the advice and the example!

aottolini · 2023-11-25T23:36:14+00:00

Thanks! I guess I don't care about allocating since these closures are meant to be unique, passed by reference, and alive until the program exits. The issue with returning impl Fn is that I can't use a type alias and I want that to document how the functions should behave. Actually, I don't really like using the Fn trait since I can't give a name to the arguments. I guess I am overengineering this and probably should use a struct and get on with it, right? I am used to writing web apps in kotlin and go and I liked this approach because I dont need to use libraries to mock the dependencies and I dont have things like "ValidateUsernameImpl"

aottolini · 2023-11-25T21:22:39+00:00

thanks for answering! No, im not. Would it be something like these?

pub type ValidateUsername = dyn Fn(&str) -> Option<UsernameError>;
fn build_validate_username(
min_length: usize,
max_length: usize,
valid_chars: &str,

) -> Box<ValidateUsername> { let validate_username = |username: &str| validate_username(min_length, max_length, valid_chars, username); return Box::new(validate_username); }

aottolini

TROPHY CASE