Feda /dev/ - No Javascript allowed

de perdón nada, a las minas de javascript de saturno

prepara el pico que aún usan jquery

Madre de dios el soporte que tiene Google en Play Console de Android Developers.

Madre mía, casi me explota la vena, que subnormal el que me ha atendido, parecía que estuviera hablando con un puto teleoperador inepto.

Resulta que la ultima update se ha procesado mal en los servidores de google o vete tu a saber que ha pasado, que los usuarios no pueden descargar la app de la tienda, salta un error, ni actualizar ni descargar por primera vez, la gente comprando la app pero no puede bajarla.

Pues contacto esta mañana con el soporte y me dicen que vuelva a subir la app con un codigo de version diferente, compilo la app otra vez con una nueva version (ningún cambio grande ni bug desde la ultima update que va bien) y la vuelvo a subir, me pongo en contacto para que den prioridad a la revisión de la app, ya que directamente ni se puede descargar y madre de dios, me ha faltado muy poco para faltarle al respeto, ha habido un punto que parecía que estuviera hablando con un puto bot.

Trabajar en Google es muy difícil? Después de lo que acabo de ver, cualquier nini le meten al soporte este.

He pedido que me mande la conversación al correo y no me ha llegado nada después de 10 minutos xDDD

#27281 prioridad de que, si google no revisa de forma manual las apps xd

#27283 Pues algo como en Apple
Expedited App Review
https://developer.apple.com/app-store/review/

#27288 SRE, la segunda

#27290 En teoria y sobre el ejemplo que pones el modulo que a;ade la columna deberia de chequear que el modelo que a;ade la tabla ha hecho su trabajo en condiciones antes de hacer nada.

Por poner un ejemplo, mi equipo gestiona el sistema de venta al publico de nuestras tiendas que se compone de X modulos. Pongamos que el modulo de pago con tarjeta falla, el resto del sistema puede seguir funcionando sin problema e incluso hay un plan B a nivel de negocio para anotar/realizar pagos aunque el modulo este caido. Lo que no tiene sentido es que falle el modulo de pago con tarjetas y acabe por afectar a la operativa de venta de toda la compa;ia...

En cualquier caso habra situaciones en los que te compense un modelo todo o nada y situaciones en las que los modulos/funcionalidades funcionen por separado.

#27291 En este caso de la forma de pago coincido en que la estrategia debe ser no impedir que se pueda cobrar de otras formas. Pero al final al funcionalidad "cobrar" no se ha visto comprometida. Pero mi pregunta va más enfocada a problemas puramente técnicos más que "funcionales".

#27292 Es una mera pregunta al aire... si, está claro que el script de migración no debe fallar, sobretodo por que no suelen/pueden tener la capacidad de ser idempotentes. Pero bueno, no me preocupa el script de migración... la cuestión es si ese modulo que añade una columna debería hacer que el sistema no se levante en caso de fallar... y en cuanto recupere su estado correcto lance este script o el mecanismo X.

Lo dicho... es mera pregunta por saber que camino optaríais vosotros en caso de hacer un sistema modular.

Te iba a decir lo que te ha dicho la Rata asquerosa (seguramente apestosa y otros adjetivos acabados en -osa) de operaciones atómicas pero usando la palabra transacción. Ya que para mi 1 transacción N operaciones, que pueden o no ser atómicas. Es mas fino y general, vas a resolver mas problemas con txs que con operaciones.

Otro punto de vista, negocio:

Si falla tienes una acción de recovery/retry/fallback?

• Si: Implementar.
• No: Panic, fallo rápido y fallo fuerte.

Si desde negocio no existe la solución, como programador no tiene sentido que la implementes. Es como resolver un problema que no tienes ni te han definido. Seguramente lo harás mal y lo tendrás que cambiar. Si no lo haces mal, tu decision de dise;o hecha a ciegas (no hay use case) va a afectar en cascada futuras decisiones de negocio. A la larga sale mal inventarte cosas.

Otro punto de vista, SRE:

Yo siempre lo hago petar todo rápido, así se detectan errores y bug antes, si haces caminos alternativos obviamente es mas complejo de implementar, pero tambien es mas complejo el logear y sacar metrics de valor que te sirvan para tomar decisiones. Es mas fácil detectar y medir problemas al saber que un comando tarda 2s de latencia y falla 2% de veces, que no un comando tarda 2s, falla 0.5% se recupera 0.5% se reintenta 1 vez 0.02% se reintenta 2 veces 0.04%....

Como comparas este ultimo caso con otros bugs/errores/problemas en tu codebase? Si las unidades son distintas no puedes comparar. Por tanto la idea de petar rápido y medir fallos inicialmente es la mas fina. Porque cuando a;ades ideas de SRE tienes que tener muy claro el caso de uso y como medirlo.

De nada cuencoarroncista, subscribe con Twitch Prime y empieza a disfrutar de estos bricoconsejos en mi canal de TikTok.

PS: Recuerda que si estas sacando el 95% o mierdas asi no tienes ni puta idea, tienes que sacar .999 minimo. Recuerda que si estas mediendo avg en tus percentiles tampoco tienes ni idea de SRE ni de matematicas.

Esta es una pregunta que hago a mis futuros empleadores, que percentiles miden y porque. Les jodo a todos. HAHAHAHAHAHAHAHAHA.