Podcast Z #8: Proyecto X - Batiburrillo Final

Podcast Z

Últimos flecos del proyecto https://podcast.jcea.es/podcastz/8

Notas:

• 01:00: No enseño código porque es código propietario y porque por audio es difícil enseñar código. Estoy dispuesto a atender peticiones por correo electrónico para escribir entradas en la página web.

• 02:00: Usar "sys.excepthook" en vez de rodear todo tu código con un "try...except".

• 03:00: Uso "sys.excepthook" para que si el programa falla de forma catastrófica, envíe un informe al servidor, con todos los detalles posibles.

• 04:30: Ventajas de usar "sys.excepthook" en vez de rodear todo con "try...except".

• 07:50: Usamos multithreading para ofrecer al disco duro varias peticiones simultaneas, de forma que pueda planificar el movimiento del cabezal de forma óptima. Paralelizar la lectura de disco.

• 12:10: Lanzar varias peticiones concurrentes tiene consecuencias para el usuario. La actividad de disco propia del usuario compite con el programa.

• 14:30: El programa incluye un microservidor web. La interfaz de usuario es el propio navegador. Esto nos independiza del GUI propio de cada sistema operativo. Además, permitiría acceso remoto de forma automática, si fuera necesario. Ojo con la seguridad.

• 18:30: Grabación de "checkpoints" del programa.

• 21:30: En Windows no se puede hacer como en Unix: grabar con otro nombre+flush+sync+rename. Hay que buscarse la vida para hacer algo que funcione en todas las plataformas soportadas.

• 25:00: Como ahora tengo dos ficheros de checkpoint, debo comprobar su integridad. La integridad verifica muchas cosas, tanto que el fichero está completo como datos sobre la versión del programa, etc.

• 30:00: El programa se autoregistra y se le proporciona un código de registro único. Eso permite muchas cosas interesantes, además de identificar al usuario. Por ejemplo, poder ejecutar código de forma selectiva en determinados usuarios.

• 37:50: Los logs se mandan a disco ANTES de mandarlos al servidor. Cuando el programa se ejecuta, manda los logs pendientes presentes en disco, si los hay. ¿Por qué?. Escucha el podcast :-)

• 43:30: El programa descarga componentes externos de forma segura y eficiente.

• 48:30: Problema: si cambia un componente externo, hay que emitir una versión nueva del código principal.

• 50:30: Problema: cuando empieza un mes nuevo, distribuyo 32 Megabytes a 5000 usuarios. Eso son muchos Gigabytes. Y todos a la vez.

• 55:00: Red CDN (Content Distribution Network) del pobre: Coral Caché - http://www.coralcdn.org/.

• 55:30: Mi web es http://www.jcea.es/. Para entrar en mi web a través de Coral Caché, usaríamos la URL http://www.jcea.es.nyud.net/.

• 58:30: No hace falta ningún trámite. Tampoco te garantizan nada, claro.

• 59:30: En mi código tengo un "fallback": Primero intenta descargar a través de Coral, y si no funciona bien, va directamente a mi servidor. Esto es factible porque tengo control del cliente y el usuario no tiene que esperar nada.

• 01:02:40: Mejoras posibles en la aplicación. Básicamente, usar cifrado en todas partes... o casi. Como controlamos el cliente, no es necesario que el certificado SSL esté firmado por una entidad de certificación reconocida. Así que no hay excusa.

  Una mejora que no se describe en el podcast es que el código descargado lleva una firma digital, pero un atacante podría inyectarnos una versión más antigua con, por ejemplo, problemas de seguridad conocidos. Sería interesante que el descargador no permitiese ejecutar una versión anterior a la última que haya descargado. Es decir, que no se pudiese volver nunca para atrás.

• 01:08:00: Si metemos TODO cifrado, no podemos usar Coral Caché. La solución: las firmas van por Coral y se verifica esa descarga a través de un hash que hemos recibido por una conexión cifrada en paralelo.

• 01:10:30: Mi intención con esta serie de podcasts es dar ideas a los programadores, para sus propios proyectos.

• 01:12:00: No puedo enseñar código real, pero si hay alguien interesado, puedo dar detalles en mi página web.