Feda /dev/ - No Javascript allowed

https://vectorized.io/

By design, redpanda allocates all the available memory (aside for some small OS reservation) upfront, partitioning the allocated memory between all cores and pinning such memory to the specified NUMA domain (specific CPU socket).

Oftentimes, the default CPU configuration is prioritized for end-user-typical use cases such as non-cpu-intensive desktop applications and optimizing power usage. Redpanda disables all power-saving modes and ensures that the CPU is configured for predictable latency at all times. We designed redpanda to drive machines around _90% utilization and still give the user predictable low latency results.

https://vectorized.io/documentation/autotune/

La tengo en la mano. Ya comentaré algo porque creo que voy a hacer una locura en producción.

#14733 tenéis montado Kaftka? para que lo usáis?
#14736 y volver el lunes a que te pongan la cara roja, si, buena satisfacción xD

#14738 por el tema de data pero yo veo muy poco y he tocado -1 por eso tengo curiosidad de los casos de uso donde los usa la gente y para que, porque todo el mundo habla de ello y muchas veces no terminan de tener claro para que lo usan o ni si quiera si lo estan usando para lo que se supone que es y hacen que yo tampoco lo tenga claro xD

me fio de que si me cuenta eisen su caso de uso va a ser real y útil y no "porque lo lei en medium" o cualquier cosa de esas

Y esto es lo que pasa cuando programas la IA de tu coche en JS: https://www.thedrive.com/news/37366/why-that-autonomous-race-car-crashed-straight-into-a-wall

#14744 Una arquitectura orientada a eventos también tiene sus problemas. Si que es cierto que se desacoplan y volver los servicios reactivos hace más fácil la implementación.

Pero tienes el problema de los silos de conocimiento si no se comparte bien esa información y no está bien documentada y que a veces no sabes muy bien que está pasando (tienes que conocer bien el sistema). Vamos al final la carga cognitiva viene por otro lado y necesitas otro tooling distinto para poder seguir trazas, lo dicho antes de la consistencia eventual (si no hay problemas o no tienes pues eso que ganas), hacer análisis, etc. Vamos lo propio de sistemas distribuidos: cambias unos problemas (de aplicación) por otros probablemente más complejos y costosos (infraestructura) así que tienes que
ver si te compensa.

Luego está el diseño del sistema, es mucho más dificil diseñar una arquitectura de microservicios que un monolito, de hecho la mayoría d elo que he visto son monolitos distribuidos y al inicio del proyecto que dije antes, cuando comenzamos a pensarlo y plantear la arquitectura es lo que nos estaba pasando hasta que decidimos plantearlo con event-driven sin ni si quiera haber leido del tema pero fue a la conclusión que llegamos xD. Te hablo hace ya 6 o 7 años que no había tanta info sobre el tema, no se hablaba mucho de microservicios (aunque estos conceptos al final son los mismos que los de un SOA y tengo un par de libros por ahí que me sirvieron bastante para conceptos) y docker estaba en pañales xD. Suerte para nosotros que había bastante info del stack de twitter y de netflix. De hecho ese fue mi primer proyecto tocho en Scala.

A mi lo que no me gusta de la nueva ola (post 2015) de colas, DDD, eventos, CQRS y similares es la mierda de boilerplates y estructuras de ficheros que creáis como mongolos.

Es lo mismo que he visto que pasaba hace 10 años con JavaEE y demás mierdas. Que tenias que seguir unos patrones de interficies y implementar DAO y nose que mil historias mas.

Lo mismo ahora con tu carpetita domain tu carpetita infraestructura y todo con los nombres bien puesto, hay mas carpetitas que ficheros de código. Si quitas clases, getters y setters y demás boilerplate de lenguajes de pajeet te queda el 5% del código y te cabria en un fichero. El cual pondrías ordenadamente dentro de 10 subcarpetas.

Solo cambia el plato, sigues comiendo la misma comida de perro y siendo un perro.

Y entiendo perfectamente el beneficio de organizar el código cuando trabajas en equipo (no entiendo que TODO el mundo siga el mismo patrón que ha dictado alguien que ni ha puesto código en producción) pero estas añadiendo complejidad innecesaria como un subnormal porque en lugar de aprender lo que es un evento y una cola has aprendido donde poner el archivo para el Command, que interficie tienes que implementar y que nombres le tienes que poner a tus clases.

Cuando miro código open source no veo las mierdas que predican estos gurus modernos de youtube la verdad, y ese codigo open source de Netflix, Twitter, Google mueve más trafico y escala mas trafico que el codigo que han picado los primeros para sus cursos de udemy, además que en sus blog técnicos me hablan de lo malo, no todo es flores. Me hace preguntarme donde empieza la linea de equipos que siguen estas guías y donde termina. Imagino que cuando empieza la linea también empieza el Java.

Picas el mismo código funcional en 100 archivos menos y 10k LOC menos. Con las mismas propiedades incluyendo el beneficio de que hay menos código que mantener. Pero no es clean code porque no esta en la carpetita que toca kek.

Con este rant respondo a @fyn4r que me dijo un día que ya se me había pasado el gusto por el ddd o algo asi.

si condensas ese mensaje en menos de 10 líneas te queda un bait aceptable, pero te has liado demasiado

#14734 Siempre hay que romper algo, que luego te quieren bajar el rate del pager duty si todo está muy tranquilo.

#14737 Tenemos big data y todos los memes de moda pero casi toda la comunicación entre microservicios va también por Kafka, hasta los eventos de UI.

#14738 Te estás volviendo hipster por osmosis. Pronto estarás pensando en Smalltalk y programar en Java te causará síntomas de estrés postraumático. Aún estás a tiempo de tocar el piano en orquestas de pueblo.

#14742 Vaya puto horror fue usar <1.0 en producción. Bueno, miento, hasta 2.3 (KIP-354) y la pesadilla de GDPR. Ahora estamos todos esperando a KIP-500 pero parece que va para largo.

#14750 Por qué no usar FP+OOP? Así es más ilegible.

#14752 es que tampoco has dicho nada; muy generalista. Lo podría haber dicho alguien que no ha tirado una línea en su vida.

#14754 Pues estaba mirando los tutoriales que se han recomendado del canal del otro dia y los ejemplos de github.

https://github.com/CodelyTV/java-ddd-skeleton
https://github.com/CodelyTV/java-ddd-example

Y me los miraba con intención de aprender algo, pero es una perdida de tiempo que me he hecho escribir ese tochaco, imagínate la mierda que es. Paso de aprender un modelo mental y una estructura de ficheros para tirar 4 lineas de codigo.

En fin, buen finde gente.

#14756 Ellos solucionan problemas mas tochos, tienen equipos con mas altas y bajas que tu y proyectos mas largos. Y no hacen NADA (entiendase la exageracion) de lo que otros te dicen que NECESITAS para trabajar. Ese era mi mensaje. No lo necesitas.

#14755 Pues lo mismo se puede decir de un video tutorial de CodelyTV.

#14758eisenfaust:

Yo tengo una regla básica: si vas a implementar una abstracción de ese estilo en el código, tiene que tener YA MISMO un caso de uso en el propio commit. De lo contrario te comes la PR con patatas.

A los bosses no les gusta esto, ya que siempre están dando por culo con el "código flexible", sea lo que sea que signifique eso en sus cabezas, cada vez que digo que hay que hacer un refactor a X, porque ha llegado un nuevo caso de uso empiezan a resoplar con la misma cantinela.

Sin embargo, cuando pasa lo contrario, y hay en producción un código ultra-bloated, empiezan a llorar porque cuando intentan meterle mano no entienden una puta mierda y acaban llamandome para que se los resuelva.

Sinceramente, no veo el día de que les dé de una vez el infarto definitivo.