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