Feda /dev/ - No Javascript allowed

#59818 No tenéis alertas y peña de SRE de guardia? eso debería haberse detectado antes de que petara, aparte de que no debería haber llegado a prod, pero eso es otro cantar

Lo bueno es que ahora seguro que acabáis teniendo una alerta para que no se vuelva a ocurrir (si tenéis a alguien encargado de eso claro)

#59825 Algo de concurrencia, por ejemplo, pero no se me ocurre el qué en algo tan sencillo como una app de notas. También le metería aquello que comentamos hace tiempo de que el mismo test apuntase a distintos entornos (local, pre, pro) cambiando sólo las variables de entorno.

#59825 creo que ya tenías por ahí un traefik con grafana y prometheus, en vez de meterle cosas a eso, podrías aprovecharlo, dockerizar tu app, comunicar los servicios y desplegarlos a través del docker compose. Y ya si eso haces lo mismo con el frontend, con alguna librería de componentes de JavaScript que odies. Así sales un poco de tu zona de confort.

#59828laZAr0:

dockerizar tu app, comunicar los servicios y desplegarlos a través del docker compose

no quiero usar docker xq no lo necesito, es una mala practica desplegar con docker-compose

#59828laZAr0:

Y ya si eso haces lo mismo con el frontend, con algún framework de JavaScript que odies. Así sales un poco de tu zona de confort.

tengo uno a medias en swift nativo mac/ios. no hay javavascript q no sea mi zona de comfort.

no me parece nada de esto pueda usar para enseñar nada

#59829 no importa mucho, yo uso los packages solo para tener namespaces en el codigo.

de hecho aun se puede mejorar: https://github.com/vrnvu/go-todo/pull/5/files

lo puedes tener todo en la root del proyecto en el mismo modulo.

go.mod
go.sum
main.go
handler.go
handler_test.go
sqlite.go
sqlite_test.go

pero claro, si todo esta en el package main pues puedes tener colisiones de nombres. si tuivese dos handles no podria tener NewHandler. Deberia tener NewHandlerTodo y NewHandlerList y NewHandlerFoo... en cambio puedes tener todos.NewHandler, list.NewHandler, foo.NewHandler...

ahora lo convencion es cmd para los binarios, package modulos que exportas, intenternal modulos que no exportas.

go.mod
go.sum
cmd/binario/main.go
pkg/modulo_que_quieres_exportar/modulo.go
internal/modulo_interno/blah.go

pero vamos, cuestion de gusto:

todos, err := t.todosDB.GetAll(r.Context())

vs

todos, err := t.repo.GetTodos(r.Context())

si vas a tener multiples modulos prefiero usar este naming, me parece mejor a lo que la gente suele hacer.

si no vas a reutilizar los modulos pues es mas fino tener todo mas declarativo y explicito.

lo puedes tener todo en package main, o todo en un package todos por ejemplo, a la DDD, y cuando añadas otros handlers pues vas scando funcionalidades a internal para re-utilizar.

https://github.com/vrnvu/go-todo/pull/6/files

da bastante igual en general, mientras sea consistente

Buenos dias, quería haceros una pregunta a las personas que sabéis o habéis tocado docker, tengo el siguiente comando ->
clear && docker-compose down && docker-compose build --no-cache && docker-compose up -d --build && docker logs -f node_app
Que lo que hace es que me para todos los container y los buildea y luego me enseña los logs de node_app

Mi pregunta es la siguiente, existe algún comando o alguna forma de por ejemplo hago un cambio en una de las apps en especifico lo subo a produccion y luego hacer el compose SOLO sobre esa app sin que el resto de las apps tenga que hacerles un compose? Es que me pasa que a veces necesito modificar algunos parametros que me pide el cliente sobre una app en concreto pero para hacerlo tengo que parar todas las apps y que se recomponga, muchas gracias por adelantado!

#59837 Es decir yo en mi docker-compose.yml tengo :
version: '3'
services:
node_app:
build:
context: ./nodeapp
container_name: node_app
expose:
- "8081"
volumes:
- pepito11volume:/app/prisma/database
networks:
- app_net
restart: always

warehouse_app:
build:
context: ./warehouseapp
container_name: warehouse_app_container
expose:
- "8082"
volumes:
- warehousevolume:/app/prisma/database
networks:
- app_net
restart: always

Lo que dices es que en ese docker-compose.yml deje una y luego cree un docker-compose-2.yml y meta exclusivamente

warehouse_app:
build:
context: ./warehouseapp
container_name: warehouse_app_container
expose:
- "8082"
volumes:
- warehousevolume:/app/prisma/database
networks:
- app_net
restart: always

Y así con todas las apps que tenga?

#59838 Si.

A no ser que sean mierdas como varios nodos de Elastic que trabajen juntos, siempre es más cómodo tener cada contenedor en su lugar. Aunque Compose se ponga a llorar por contenedores huérfanos

Y ya que estamos, haría el build por separado, y que lo actualice Watchtower. De esa manera no se para nada.

#59839 justo estaba leyendo el articulo en HN, bastante impresionante
https://phys.org/news/2022-10-solar-gravitational-lens-humanity-powerful.html

#59811 display: flex; align-items: center; justify-content: center

Son 60 euros mas IVA, de nada.

#59847 low code, apps y generative AI. La trifecta de "coge la pasta y corre".

#59849 el low code lleva buscandose como el santo grial minimo desde principios de los 90s, y aqui estamos 30 años despues.