Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Kaledros

Menudo drama

draz1c
#43087desu:

tengo pensado hacer una serie comentado decisiones tecnicas de backend

pero no se que formato es el mejor

Tomes la decisión que tomes sobre el formato yo creo que lo más interesante puede ser el ver el proceso mental que llevas para llegar al resultado final y no tanto el resultado obtenido (que también, pero lo más importante bajo mi punto de vista es el razonamiento).

1 respuesta
pantocreitor

#43110 eso suena a "busco subvención"

JuAn4k4

#43112 Hombre un Twitch de system design no estaría mal la verdad. Pones una votación para el siguiente y lo haces continuamente todos los Viernes por ejemplo. Tiene pegada yo creo, yo no tengo ni carisma, ni voz, aunque por lo menos no soy feo. Podría animarme.

6 1 respuesta
draz1c

#43114 Si si, yo estaba hablando con dase porque parece que estaba interesado en hacer un reto de programacion 1v1 o algo asi, pero cualquiera que se anime a hacer directos o videos de youtube tiene todo nuestro apoyo. Yo al menos me lo veria entero para aprender lo maximo posible.

2
desu

El problema es que no creo en el system design, me parece una muestra de arquitectura de software y yo estoy en contra de la arquitectura de software por motivos que ya he explicado en el pasado.

Lo que necesito son casos de uso de producto concretos a resolver a modo de ejemplo, requerimientos de carga y una simulacion de distintos escenarios en el tiempo.

  • Todo debe empezar desde el producto que quieres construir y resolver. Donde producto = ganar dinero = ayudar a la gente.

  • Los requerimientos tecnicos de req/s, balanceo, delivery garantees, CPU y MEM entre otros determinaran el "sistema". Donde hay asociado un COSTE y un SLA.

  • Y la simulacion de distintos escenarios donde cambian o se deben modificar los casos de uso y/o cambian los requerimientos tecnicos.

Por ejemplo. caso de uso. tengo Un producto que es una todo list y quiere borrar elementos.

  • Caso de uso, añadir un endpoint de DELETE de algun modo, supongamos api rpc o http rest-like

  • Requerimientos tecnicos iniciales? Es un MVP, pocas peticiones. Por tanto podemos obtar por un DELETE a una id. Este caso de uso no debe escalar horizontalmente de manera individual y puede por tanto la logica para ello formar parte de otro servicio. Aqui debemos analizar tema metricas, logs y costes de esta solucion.

  • Simulacion en el tiempo, pues que el sistema aumenta el numero de req/s. Que haces y porque? Extraer funcionalidad a microservicio propio y escalar horizontalmente para tener mas throughput? Necesitaras balancear, como afecta eso a tu sistema? Como afecta el throughput al coste y a la carga de la DB, das a algun rate limit? y asi. Lo mas dificil es entender como un escalado afecta a tu sistema, por ejemplo el rate limiting a la DB no es algo super obvio y necesita ser monitoreado.

Jardineria de software, centrados en producto, buenas practicas de ingenieria y pragmatismo.

Lo cual es muy distinto al mundo de yupi de la arquitectura de software donde solo se construye sobre mundos ideales de "negocio" sin tener en cuenta las realidades tecnicas de la igenieria. Un buen jardinero, sabe podar sus arboles y arrancar malas hierbas.

r2d2rigo

Venga chavales que va a venir musk a ense;aros a programar

2
_Rpv

return tweet.own === "elonmusk"

isvidal

Gracias @_Rpv por el report del bug en https://foodieninjas.app

https://css-tricks.com/annoying-mobile-double-tap-link-issue/

Que grandes los de Apple, los mas listos del barrio

2 respuestas
PaCoX

el secreto del delete es no hacer delete meme+negro+pensando

PiradoIV

Pues poca broma con el borrado lógico :P

desu

Mi equipo se reia de que managament quiere que los equipos dejen de "centrarse tanto en el code coverage"

Os comparto mi respuesta, vale para blog post simple creo:

well it can make sense if people write better testing and more effective code. If you spend a lot of time in testing you can improve in other areas…

there is a lot of cargo culting around code coverage.. which only focuses in code path.

I don’t see people writting static assertions at build time so test are run by your compiler, I don’t see any memory randomisation, fuzzy testing for inputs is not common, we dont use code mutation tools either…

And I don’t think having a complete testing suite is a priority in our industry anyway as it is in other fields…

My biggest productivity suggestion would be to forbid some languages in the company for core services or after they pass N LOC. If you are using a dynamic lang like python or javascript for a core service when that could be a static linked binary.., with a compiler that removes the need for 99% of the unit tests you wrote… well. I don’t know how you passed the coding interview XD

our python cli for example I mentioned in the past id like a rewrite with something that is not python. we dont even use click for some reason. everytime i add a line of code in the business, i need to add 5 boiler plate lines, and 10 tests for the boiler plate… lol

El servicio que comento tiene mas lineas de codigo de test, que codigo de logica. 2k loc de codigo, 3k loc de test. si esto usase click, serian 500 loc de logica... para empezar. si esto fuese rust o go, que tienen buen tooling para cli, serian 150 loc que el compilador genera por ti....

En fin, si no sabes que usar python o javascript es malo, o que si estas testeando mil tonterias es porque no sabes programar... quizas el problema lo tienes tu.

Paga cacauetes => fperos => fperos escriben mierda => mierda se vuelve legacy => legacy causa toil... Ahora tengo que hacer mi trabajo y arreglar la mierda que ha causado el managament.

1 respuesta
Slowbro

#43122

When I wrote test for aerospace you would not prioritise code path as we do and it was only integration.

Tio, que en aerospace hay normas que te obligan a eso.

1 respuesta
desu

#43123 no lo que yo hacia XD

pero si hay normas para todo y tienen su sentido.

por ejemplo hay cosas que no pueden ser "software" deben ser "hardware". igual que en la automovil o maritima.

y hay tests que deben correrse ahi.

bueno, se entiende mi mensaje. quito esa frase para no perder el focus. los test unitarios y el code path es una tonteria y un cargo cult que la mayoria de fperos no sabe ni justificar sin que se le caigan los mocos. no habre hablado yo con autores de libros famosos y me ha dado la gente la razon a mi.

edit: @wei-yu este finde estoy trabajando, un par de horas ya te digo cuantas si quieres, por si quieres recordarmelo algun dia... supongo que la parte donde he estado de fallas no la contaras cuando te "quieras reir de mi"

1 1 respuesta
JuAn4k4

#43124 Yo contra más software llevan los coches más empiezo a desconfiar. He visto lo que hacen con el software de los coches en algunos sitios y es para echarse a la bicicleta para hacerse un Madrid - Barcelona.

1 1 respuesta
desu

#43125 Una de las industrias que me interesan. BMW, Mercedes... Me gustaria entrar y cambiar las cosas.

Para empezar haria revert de la moda de que no haya botones fisicos y todo sea haga por tablet. Volumen y climatizador de vuelta. Esto es tipico ejemplo de top-down decision making, no conozco a nadie a quien le guste esta moda de mierda.

Despues para el tema software, re-haria todo. No puede ser que las tablets de los coches vayan a pedales con el hardware actual.

Se nota que BMW y Mercedes lo controlan boomers. Si yo estuviese ahi, ganarian cientos de millones mas al año gracias a mi impacto.

Pero bueno, los boomers prefieren perder dinero que contratar a alguien joven con talento que les eclipse.

NEVER OUTSHINE THE MASTER

3 1 respuesta
Camp1

#43126 ya no hacen pantallas táctiles, gracias a Dios. Usan botones y una rueda de control, bastante cómoda la verdad.

Kaledros

No, pero lo de que la puta tablet de un coche de casi treinta mil pavos se quede 15 segundos calculando una ruta y tenga input lag cuando le das a la pantalla es para coger al responsable de semejante despropósito y colgarlo de los huevos. Me cabrea DE LA HOSTIA el estado lamentable de la UX en esas pantallas de navegación.

Eso, y quitar cualquier tipo de interacción necesaria mientras vas conduciendo. Si tienes que hacerlo con el coche en marcha, controles físicos. Punto. Ni comandos de voz ni hostias.

Slowbro

Solo comento que un buen cacho de los procesadores que vendemos son para el infotainment/adas de fabricantes top (automoción), y esos procesadores llevan gpu/npu dedicadas y el linux/android que damos está cuidadísimo.

Si va mal es paqueo a nivel aplicación y hasta ahí puedo leer xD

PD para cafeteros: en aerospace puedes delegar mucho en sw. Ahora bien, igual tienes que auditar el compilador (buena suerte con gcc), y demostrar con documentos firmados que no hay codigo muerto y tienes que probar que para cada test (minimo 1 por requisito, y suele ser requisito por línea, prácticamente) en ejecución has pasado ese set de instrucciones por el pipeline de la cpu (sacas las trazas).

Todo para cobrar la mitad que en el mundo web a no ser que seas el godemperor lead de 66 tacos al que la empresa suplica que trabaje porque es el unico que pilota del sistema al 100% y ha sobrevivido a los run for score de productos previos xD

1 respuesta
JuAn4k4

#43119 Pero lo has hecho tú ?

1 respuesta
Kaledros

#43119 ¿Por qué tenéis un footer si la página tiene scroll infinito?

2 respuestas
desu
#43129Slowbro:

Si va mal es paqueo a nivel aplicación y hasta ahí puedo leer xD

a ver, no habia una hecha en electron? XD

estan hechas por fperos, por lo que me han dicho y por alguna oferta de trabajo que he visto que era javascript imaginate

aero: yo como solo metia algoritmos dentro del os que me daban no tenia que auditar mucho, sobretodo el tema cpu y memoria que no petase nunca y luego eso fue revisado por otro team antes de meterlo
como las lentes que sacaban fotos que yo usaba, estaban auditas era facil luego hacer el algoritmo controlando cpu y mem... y luego el resto de mi codigo era para procesar estas imagenes en tierra que ahi eso no es "aero"

1 respuesta
Slowbro

#43132 En esa frase me refería a auto y no a aero, perdona.

1 respuesta
desu

#43133 Tranquilo. Entiendo que tus 3 neuronas no den para tener una conversacion funcional de mas de 3 posts con alguien. Bastante has hecho escribiendo sin faltas ese mensaje enhorabuena. Dile a tu cuidadora que progresas adecuadamente.

1 1 respuesta
aren-pulid0

#43131 seo

Slowbro

#43134 Además de a la cuidadora, te tendría que pagar. Menudo entretenimiento mientras espero vuelos.

Eres el ignatius de la programación. Cada post tuyo hace dudar entre retraso absoluto o genialidad. A seguir así titán xD

1 respuesta
desu

#43136 Ingatius es un puto subnormal. Yo soy un puto genio.

Kaledros

Estaba viendo un vídeo sobre corrutinas y el cabrón va y suelta "¿en qué se diferencia una corrutina de un hilo? Una corrutina puede suspenderse". Y se queda así de ancho, el hijo de puta...

1 respuesta
desu

#43138 cierto blogero de este hilo, uno de los mejores del mundo, tiene un post explicando las corrutinas, async vs sync, block vs non blocking y scheduling.

una corrutina no tiene absolutamente nada que ver con un thread (edit: ya me entendeis espero). y un thread puede suspenderse sin problema.

edit: entendiendo thread como task, donde una task puede ser thread o proceso.

https://arnaudiaz.com/blog/what-is-async/

1 respuesta
isvidal

#43131 no todas las paginas tienes scroll infinito.

#43130 si, nextjs, sus api como backend y prisma + postgresql