From gvm2121 en gmail.com Wed Apr 15 08:35:03 2020 From: gvm2121 en gmail.com (Gonzalo V) Date: Wed, 15 Apr 2020 08:35:03 -0400 Subject: [Python-es] CARACTERES ESPECIALES Message-ID: Buenos días muchach en s: Quería solicitarles una guía, Hay alguna forma de crear un caracter especial en python?, hay alguna librería para eso?. Tengo que hacer una especie de arroba con otra letra dentro. muchísimas gracias y encerrados vencemos al coronavirus. Saludos desde Chile. Gonzalo ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From goinnn en gmail.com Sat Apr 18 12:44:30 2020 From: goinnn en gmail.com (=?UTF-8?Q?J=2E_Pablo_Mart=C3=ADn_Cobos?=) Date: Sat, 18 Apr 2020 18:44:30 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga Message-ID: Buenas, He escrito un pequeño manifiesto que me gustaría compartir con la comunidad. Espero que os guste yos entretenga en estos días de confinamiento. Si alguno está interesado en contribuir puede hacer un fork y un pull request. Español: https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html Inglés: https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index.html Abrazo, -- Pablo Martín Cobos Ingeniero informático Desarrollador Python/Django 652 53 37 36 goinnn en gmail.com ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From pych3m4 en gmail.com Tue Apr 21 07:22:06 2020 From: pych3m4 en gmail.com (Chema Cortes) Date: Tue, 21 Apr 2020 13:22:06 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga In-Reply-To: References: Message-ID: El mar., 21 abr. 2020 a las 12:53, J. Pablo Martín Cobos () escribió: > Buenas, > > He escrito un pequeño manifiesto que me gustaría compartir con la > comunidad. > > Espero que os guste yos entretenga en estos días de confinamiento. > > Si alguno está interesado en contribuir puede hacer un fork y un pull > request. > > Español: > https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html > Inglés: > https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index.html > > > Interesante. Lo único que veo que hablas de tareas en primer y segundo plano. No sé si te referies a la prioridad de tareas, con el servidor web como tarea más prioritaria, o vas más por distinguir entre tareas síncronas y asíncronas, ya que también hablas de activar *timeouts*. Lo que no he visto nada sobre *resiliencia*. ¿Qué pasa cuando tienes que *amputar un brazo* para mantener la alta disponibilidad? ¿O qué pasa cuando se empieza a rechazar peticiones por la alta demanda? La *resilencia* es fundamental para un sistema de alta disponibilidad. Por si te sirve de comparación, echa un vistazo al *Manifiesto de Sistemas Reactivos*: https://www.reactivemanifesto.org/es -- > > Pablo Martín Cobos > Ingeniero informático > Desarrollador Python/Django > 652 53 37 36 > goinnn en gmail.com > _______________________________________________ > Python-es mailing list > Python-es en python.org > https://mail.python.org/mailman/listinfo/python-es > -- Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": https://blog.ch3m4.org Buscador Python Hispano: http://busca.ch3m4.org ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From goinnn en gmail.com Tue Apr 21 14:37:01 2020 From: goinnn en gmail.com (=?UTF-8?Q?J=2E_Pablo_Mart=C3=ADn_Cobos?=) Date: Tue, 21 Apr 2020 20:37:01 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga In-Reply-To: References: Message-ID: Buenas Chema, Te respondo entre líneas, El mar., 21 abr. 2020 a las 13:23, Chema Cortes () escribió: > > > El mar., 21 abr. 2020 a las 12:53, J. Pablo Martín Cobos (< > goinnn en gmail.com>) escribió: > >> Buenas, >> >> He escrito un pequeño manifiesto que me gustaría compartir con la >> comunidad. >> >> Espero que os guste yos entretenga en estos días de confinamiento. >> >> Si alguno está interesado en contribuir puede hacer un fork y un pull >> request. >> >> Español: >> https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html >> Inglés: >> https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index.html >> >> >> > Interesante. > Gracias Lo único que veo que hablas de tareas en primer y segundo plano. No sé si > te referies a la prioridad de tareas, con el servidor web como tarea más > prioritaria, o vas más por distinguir entre tareas síncronas y asíncronas, > ya que también hablas de activar *timeouts*. > Primer plano = servidor web Segundo plano = sistema de colas de tareas (tipo celery) Por ejemplo en el registro de un usuario, puede que tengas que mandar uno o varios correos, mandar algún SMS, notificar a algún administrador de alguna otra forma, etc. Podrías hacerlo todo en primer plano y dejar al usuario 3-10 segundos esperando, y lo que es peor hacer que otras peticiones se encolen detrás o mucho mejor decirle al usuario: listo, ok! y después hacer todo lo que tengas que hacer (todas las comunicaciones con sistemas externos) en segundo plano > Lo que no he visto nada sobre *resiliencia*. ¿Qué pasa cuando tienes que *amputar > un brazo* para mantener la alta disponibilidad? ¿O qué pasa cuando se > empieza a rechazar peticiones por la alta demanda? > Respondo aquí también lo de los timeouts. Un backend puede estar conectado a muchos sistemas (el nuestro a unos 40 sistemas externos): 1. Servidor de correos 2. Servicio de SMS 3. Notificaciones pushes 4. Servicio de llamadas automáticas 5. Integraciones con sistemas de clientes 6. Sistemas de facturación 7. Otros servicios 8. Etc La idea es que por muy crítico que sea mandar un correo, un SMS, llamar a un servicio que hace que se guarde un PDF, o *cualquier* otra cosa, no hay nada más crítico que tu sistema. Si por ejemplo se cae el servidor de correos y tu backend manda muchos correos, primero tu backend irá lento y finalmente se caerá. Pues la idea es que es mejor dejar de hacer algo incluso si es crítico (mejor amputar) que que tu sistema se caiga completamente. Y esto se puede conseguir no dejando peticiones indefinidamente: 30, 60, 120, etc segundos; sino estableciendo un tiempo máximo a todas las conexiones que hace tu backend a otro sistema (es decir, un timeout). La *resilencia* es fundamental para un sistema de alta disponibilidad. Por > si te sirve de comparación, echa un vistazo al *Manifiesto de Sistemas > Reactivos*: https://www.reactivemanifesto.org/es > Totalmente, nosotros conseguimos la resilencia siguiendo las reglas que he pasado. Alguno más se ánima al debate? Abrazo, > > > -- > >> >> Pablo Martín Cobos >> Ingeniero informático >> Desarrollador Python/Django >> 652 53 37 36 >> goinnn en gmail.com >> _______________________________________________ >> Python-es mailing list >> Python-es en python.org >> https://mail.python.org/mailman/listinfo/python-es >> > > > -- > Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": > https://blog.ch3m4.org > Buscador Python Hispano: http://busca.ch3m4.org > > _______________________________________________ > Python-es mailing list > Python-es en python.org > https://mail.python.org/mailman/listinfo/python-es > -- Juan Pablo Martín Cobos Ingeniero informático Desarrollador Python/Django 652 53 37 36 goinnn en gmail.com ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From lasizoillo en gmail.com Tue Apr 21 15:44:57 2020 From: lasizoillo en gmail.com (lasizoillo) Date: Tue, 21 Apr 2020 21:44:57 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga In-Reply-To: References:

Message-ID: El mar., 21 abr. 2020 a las 20:37, J. Pablo Martín Cobos () escribió: > > Alguno más se ánima al debate? > > Con las tareas asíncronas o en segundo plano como las llamas se pueden hacer virguerías. Aunque a veces eso de los timeouts se queda corto. Planteo un escenario: Tengo un sistema de colas de trabajo que ataca a una pila de servicios externos, pongamos 40. Normalmente todo va como un tiro y se come muchos trabajos por segundo, pero por si acaso pongo un timeout de 5 segundos a las tareas. Si por debajo todo usa la misma cola, en plan configuración por defecto de celery, voy a llegar a un punto en el que todas las peticiones con timeout están haciendo de tapón y no dejando entrar a las que cuando entren irán rápidas porque no fallan. Al final hay un número de workers limitado y están mayormente ociosos esperando al timeout. Posibles soluciones: - Segregar las colas de tareas en diferentes colas de mensajes. Las afectadas se encolarán por el tema de los timeouts y las otras seguirán yendo rápido como si nada pasase. - El worker implementa el patrón circuit breaker y mientras dura la avería ese tipo de tareas se encolan a lo dead letters, se descartan o se ejecutan con un plan b que no implique el sistema afectado. Solo se producen timeouts hasta abrir el circuito, luego no se producen más timeouts. - ??? (pon aquí la solución que se te ocurra, porque hay muchas formas de mejora) Pero no siempre se puede dejar al usuario sin confirmación o hacer las cosas "en segundo plano". Si hay fallos de usabilidad puedes tener al usuario repitiendo la operación todo loco. Si le dices "tu operación estará en unos segundos" lo tendrás haciendo polling cada segundo. Es posible que si un caso de uso va regulero el usuario haga reintentos (como podría estar haciendo tu sistema de colas de trabajo con las tareas que te dan timeout) y haciendo que el sistema pase de regulero a muy malito. Para este tipo de cosas puede venir bien el concepto de "feature switching": lo que va regulero lo deshabilitas hasta que tengas el sistema sano otra vez. Por resumirlo en un rollo de esos zen: - Lo que ahora va mal y en el instante siguiente va mal probablemente seguirá mal: ponlo en cuarentena y no vuelvas a intentarlo en un rato. - Las cosas pueden fallar, pon barreras para que cuando se estropeen no te estropeen el resto. Por ejemplo usa diferentes colas para diferentes tipos de tareas. - A veces es mejor dejar de hacer algo que hacelo mal, usa "feature switching" para esos momentos en los que las cosas no van finas. Un saludo, Javi ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From goinnn en gmail.com Wed Apr 22 05:38:54 2020 From: goinnn en gmail.com (=?UTF-8?Q?J=2E_Pablo_Mart=C3=ADn_Cobos?=) Date: Wed, 22 Apr 2020 11:38:54 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga In-Reply-To: References:

Message-ID: Buenas Javi, Muchas gracias por tu respuesta. Respondo entre líneas, El mar., 21 abr. 2020 a las 21:46, lasizoillo () escribió: > > > El mar., 21 abr. 2020 a las 20:37, J. Pablo Martín Cobos (< > goinnn en gmail.com>) escribió: > >> >> Alguno más se ánima al debate? >> >> > Con las tareas asíncronas o en segundo plano como las llamas se pueden > hacer virguerías. > No es que lo llame yo... es por ejemplo como se define celery :-P "Tasks can execute asynchronously (in the *background*) or synchronously (wait until ready)." http://www.celeryproject.org/ Aunque a veces eso de los timeouts se queda corto. Planteo un escenario: > Los timeouts solo son un punto de todo lo planteado, si fueran lo único que hay que hacer sería el único punto ;-) https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html > > Tengo un sistema de colas de trabajo que ataca a una pila de servicios > externos, pongamos 40. Normalmente todo va como un tiro y se come muchos > trabajos por segundo, pero por si acaso pongo un timeout de 5 segundos a > las tareas. Si por debajo todo usa la misma cola, en plan configuración por > defecto de celery, voy a llegar a un punto en el que todas las peticiones > con timeout están haciendo de tapón y no dejando entrar a las que cuando > entren irán rápidas porque no fallan. Al final hay un número de workers > limitado y están mayormente ociosos esperando al timeout. Posibles > soluciones: > - Segregar las colas de tareas en diferentes colas de mensajes. Las > afectadas se encolarán por el tema de los timeouts y las otras seguirán > yendo rápido como si nada pasase. > - El worker implementa el patrón circuit breaker y mientras dura la avería > ese tipo de tareas se encolan a lo dead letters, se descartan o se ejecutan > con un plan b que no implique el sistema afectado. Solo se producen > timeouts hasta abrir el circuito, luego no se producen más timeouts. > - ??? (pon aquí la solución que se te ocurra, porque hay muchas formas de > mejora) > Totalmente, lo ideal son varias colas.... y es más varios workers. Dado que aunque tengas varias colas una cola puede llegar a bloquear a otra cola si está en el mismo worker (al menos en celery). El propósito era tener una guía simple... sin profundizar. Ya que cuando más profundizas menos genérico es, y a un número más reducido de sistemas se puede aplicar. > Pero no siempre se puede dejar al usuario sin confirmación o hacer las > cosas "en segundo plano". Si hay fallos de usabilidad puedes tener al > usuario repitiendo la operación todo loco. Si le dices "tu operación estará > en unos segundos" lo tendrás haciendo polling cada segundo. Es posible que > si un caso de uso va regulero el usuario haga reintentos (como podría estar > haciendo tu sistema de colas de trabajo con las tareas que te dan timeout) > y haciendo que el sistema pase de regulero a muy malito. Para este tipo de > cosas puede venir bien el concepto de "feature switching": lo que va > regulero lo deshabilitas hasta que tengas el sistema sano otra vez. > Totalmente de acuerdo, no siempre se puede... pero si la mayoría de los casos... por ejemplo nuestras a peticiones a tercero se hacen entorno al 90% en segundo plano. Y tan solo un 10% en primer plano (servidor web). Aunque si que hay maneras de poder hacerlo siempre, aunque más complejas. Por ejemplo: si te comunicas con el backend a través de un socket... el primer plano podría decirle al segundo plano que hiciera X y cuando esté hecha el segundo plano podría responderle al frontend mediante dicho socket... > > Por resumirlo en un rollo de esos zen: > > - Lo que ahora va mal y en el instante siguiente va mal probablemente > seguirá mal: ponlo en cuarentena y no vuelvas a intentarlo en un rato. > - Las cosas pueden fallar, pon barreras para que cuando se estropeen no te > estropeen el resto. Por ejemplo usa diferentes colas para diferentes tipos > de tareas. > - A veces es mejor dejar de hacer algo que hacelo mal, usa "feature > switching" para esos momentos en los que las cosas no van finas. > No conozco "feature switching" ¿tienes algún enlace al respecto? > > Un saludo, > > Javi > _______________________________________________ > Python-es mailing list > Python-es en python.org > https://mail.python.org/mailman/listinfo/python-es > Muchas gracias Javi! Abrazo, -- Pablo Martín Cobos Ingeniero informático Desarrollador Python/Django 652 53 37 36 goinnn en gmail.com ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From lasizoillo en gmail.com Wed Apr 22 09:26:41 2020 From: lasizoillo en gmail.com (lasizoillo) Date: Wed, 22 Apr 2020 15:26:41 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga In-Reply-To: References:

Message-ID: El mié., 22 abr. 2020 a las 11:39, J. Pablo Martín Cobos () escribió: > > No conozco "feature switching" ¿tienes algún enlace al respecto? > > https://en.wikipedia.org/wiki/Feature_toggle https://djangopackages.org/grids/g/feature-flip/ Basicamente te permite poner y quitar funcionalidades bajo demanda sin tener que hacer un redeploy. Otra ventaja es que te puede servir para hacer una especie de canary deploy de una funcionalidad sin hacerte el lio con la infraestructura. Una herramienta más para la caja de herramienta, que te puede hacer falta o no ;-) Un saludo, Javi ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From goinnn en gmail.com Wed Apr 22 09:50:03 2020 From: goinnn en gmail.com (=?UTF-8?Q?J=2E_Pablo_Mart=C3=ADn_Cobos?=) Date: Wed, 22 Apr 2020 15:50:03 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga In-Reply-To: References:

Message-ID: Muchas gracias, muy interesante, la verdad. Es algo que hacemos muchísimo pero no sabía que tenía nombre :-) Abrazo, El mié., 22 abr. 2020 a las 15:28, lasizoillo () escribió: > > > El mié., 22 abr. 2020 a las 11:39, J. Pablo Martín Cobos (< > goinnn en gmail.com>) escribió: > >> >> No conozco "feature switching" ¿tienes algún enlace al respecto? >> >> > https://en.wikipedia.org/wiki/Feature_toggle > https://djangopackages.org/grids/g/feature-flip/ > > Basicamente te permite poner y quitar funcionalidades bajo demanda sin > tener que hacer un redeploy. Otra ventaja es que te puede servir para hacer > una especie de canary deploy de una funcionalidad sin hacerte el lio con la > infraestructura. > Una herramienta más para la caja de herramienta, que te puede hacer falta > o no ;-) > > Un saludo, > > Javi > _______________________________________________ > Python-es mailing list > Python-es en python.org > https://mail.python.org/mailman/listinfo/python-es > -- Juan Pablo Martín Cobos Ingeniero informático Desarrollador Python/Django 652 53 37 36 goinnn en gmail.com ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From ismael en null.net Wed Apr 22 06:44:07 2020 From: ismael en null.net (Ismael de Esteban) Date: Wed, 22 Apr 2020 12:44:07 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga In-Reply-To: References:

Message-ID: Se ha borrado un adjunto en formato HTML... URL: From goinnn en gmail.com Thu Apr 23 05:40:03 2020 From: goinnn en gmail.com (=?UTF-8?Q?J=2E_Pablo_Mart=C3=ADn_Cobos?=) Date: Thu, 23 Apr 2020 11:40:03 +0200 Subject: [Python-es] Zen para un backend en alta disponibilidad y alta carga In-Reply-To: References:

Message-ID: Buenas Ismael, Respondo entre líneas, El mié., 22 abr. 2020 a las 21:19, Ismael de Esteban () escribió: > Gracias por la guía. Está genial. > Muchas gracias. Era algo que siempre estaba sobre la mesa... pero que faltaba plasmarlo por escrito... y de paso ya pues compartirlo con la comunidad. > Con ese stack, ante un pico de carga, a mí me ha funcionado parar las > colas de tareas en background ya que estas seguían haciendo peticiones a > las bases de datos -que es generalmente el recurso más dificil de escalar > rápidamente-. Por tanto encender y apagar algunas colas debería ser un > comando relativamente a mano. > Sí que hay que tener en cuenta la cantidad de tareas encoladas que puedes > almacenar si haces esto para no perder ninguna. > En nuestro caso en más de 3 años no nos ha pasado nunca que las colas lleguen a atascarse... la mayoría de las tareas tardan *como mucho* décimas de segundos (lo normal es menos incluso)... aunque tenemos algunas de segundos, minutos e incluso horas. Las que pueden tardar minutos u horas son tipo cron... con lo que no atascan la cola solo la ocupan parcialmente. > > Feature Switching a mi entender es una setting donde activas o desactivas > una funcionalidad. A mí me gusta implementarlo con un porcentaje en lugar > de un booleano para poder así hacer *Canary Releases* o *Blue-Green* > deployments. Hay que tener en cuenta que si la feature tiene determinadas > migraciones, no se va a poder hacer rollback. Pero no conozco ninguna > librería que ayude a implementarlas. > > Nosotros esto no lo hacemos para ganar alta disponibilidad. Lo hacemos por clientes, unos clientes ven una cosa y otros otras. Si que es verdad que algunas funcionalidades se pueden habilitar y deshabilitar globalmente por un administrador. Y es verdad que este podría deshabilitarlas por alta carga... pero no está pensado para eso, sino por otros motivos propios de nuestra lógica de negocio. Muchas gracias de nuevo! Abrazo, > Un saludo! > > > *Sent:* Wednesday, April 22, 2020 at 11:38 AM > *From:* "J. Pablo Martín Cobos" > *To:* "La lista de python en castellano" > *Subject:* Re: [Python-es] Zen para un backend en alta disponibilidad y > alta carga > Buenas Javi, > > Muchas gracias por tu respuesta. Respondo entre líneas, > > El mar., 21 abr. 2020 a las 21:46, lasizoillo () > escribió: > >> >> >> El mar., 21 abr. 2020 a las 20:37, J. Pablo Martín Cobos (< >> goinnn en gmail.com>) escribió: >> >>> >>> Alguno más se ánima al debate? >>> >> >> Con las tareas asíncronas o en segundo plano como las llamas se pueden >> hacer virguerías. >> > > No es que lo llame yo... es por ejemplo como se define celery :-P > > "Tasks can execute asynchronously (in the *background*) or synchronously > (wait until ready)." > > http://www.celeryproject.org/ > > > >> Aunque a veces eso de los timeouts se queda corto. Planteo un escenario: >> > > Los timeouts solo son un punto de todo lo planteado, si fueran lo único > que hay que hacer sería el único punto ;-) > > > https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html > > > >> >> Tengo un sistema de colas de trabajo que ataca a una pila de servicios >> externos, pongamos 40. Normalmente todo va como un tiro y se come muchos >> trabajos por segundo, pero por si acaso pongo un timeout de 5 segundos a >> las tareas. Si por debajo todo usa la misma cola, en plan configuración por >> defecto de celery, voy a llegar a un punto en el que todas las peticiones >> con timeout están haciendo de tapón y no dejando entrar a las que cuando >> entren irán rápidas porque no fallan. Al final hay un número de workers >> limitado y están mayormente ociosos esperando al timeout. Posibles >> soluciones: >> - Segregar las colas de tareas en diferentes colas de mensajes. Las >> afectadas se encolarán por el tema de los timeouts y las otras seguirán >> yendo rápido como si nada pasase. >> - El worker implementa el patrón circuit breaker y mientras dura la >> avería ese tipo de tareas se encolan a lo dead letters, se descartan o se >> ejecutan con un plan b que no implique el sistema afectado. Solo se >> producen timeouts hasta abrir el circuito, luego no se producen más >> timeouts. >> - ??? (pon aquí la solución que se te ocurra, porque hay muchas formas de >> mejora) >> > > Totalmente, lo ideal son varias colas.... y es más varios workers. Dado > que aunque tengas varias colas una cola puede llegar a bloquear a otra cola > si está en el mismo worker (al menos en celery). > > El propósito era tener una guía simple... sin profundizar. Ya que cuando > más profundizas menos genérico es, y a un número más reducido de sistemas > se puede aplicar. > > >> >> >> Pero no siempre se puede dejar al usuario sin confirmación o hacer las >> cosas "en segundo plano". Si hay fallos de usabilidad puedes tener al >> usuario repitiendo la operación todo loco. Si le dices "tu operación estará >> en unos segundos" lo tendrás haciendo polling cada segundo. Es posible que >> si un caso de uso va regulero el usuario haga reintentos (como podría estar >> haciendo tu sistema de colas de trabajo con las tareas que te dan timeout) >> y haciendo que el sistema pase de regulero a muy malito. Para este tipo de >> cosas puede venir bien el concepto de "feature switching": lo que va >> regulero lo deshabilitas hasta que tengas el sistema sano otra vez. >> > > Totalmente de acuerdo, no siempre se puede... pero si la mayoría de los > casos... por ejemplo nuestras a peticiones a tercero se hacen entorno al > 90% en segundo plano. Y tan solo un 10% en primer plano (servidor web). > > Aunque si que hay maneras de poder hacerlo siempre, aunque más complejas. > Por ejemplo: si te comunicas con el backend a través de un socket... el > primer plano podría decirle al segundo plano que hiciera X y cuando esté > hecha el segundo plano podría responderle al frontend mediante dicho > socket... > > >> >> Por resumirlo en un rollo de esos zen: >> >> - Lo que ahora va mal y en el instante siguiente va mal probablemente >> seguirá mal: ponlo en cuarentena y no vuelvas a intentarlo en un rato. >> - Las cosas pueden fallar, pon barreras para que cuando se estropeen no >> te estropeen el resto. Por ejemplo usa diferentes colas para diferentes >> tipos de tareas. >> - A veces es mejor dejar de hacer algo que hacelo mal, usa "feature >> switching" para esos momentos en los que las cosas no van finas. >> > > No conozco "feature switching" ¿tienes algún enlace al respecto? > > >> >> Un saludo, >> >> Javi >> _______________________________________________ >> Python-es mailing list >> Python-es en python.org >> https://mail.python.org/mailman/listinfo/python-es > > > > Muchas gracias Javi! > > Abrazo, > > -- > Pablo Martín Cobos > Ingeniero informático > Desarrollador Python/Django > 652 53 37 36 > goinnn en gmail.com > _______________________________________________ Python-es mailing list > Python-es en python.org https://mail.python.org/mailman/listinfo/python-es > _______________________________________________ > Python-es mailing list > Python-es en python.org > https://mail.python.org/mailman/listinfo/python-es > -- Pablo Martín Cobos Ingeniero informático Desarrollador Python/Django 652 53 37 36 goinnn en gmail.com ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From garcia.marc en gmail.com Thu Apr 30 04:45:09 2020 From: garcia.marc en gmail.com (Marc Garcia) Date: Thu, 30 Apr 2020 09:45:09 +0100 Subject: [Python-es] Tutorial online para colaborar en software libre Message-ID: Por si alguien tiene interés en colaborar en proyectos de software libre, y no sabe por donde empezar, esta tarde/noche voy a estar dando un tutorial práctico online sobre el tema. El tutorial va a ser 100% práctico, y está pensado para que los participantes vayan siguiendo los pasos, y hagan las primeras contribuciones mientras se aprenden los conceptos. Va a ser a la 13h en Ciudad de México, 15h en Buenos Aires, 20h en Madrid... Más info: https://twitter.com/datapythonista/status/1254892940452921344?s=19 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: