home‎ > ‎

Week 4 - It's all about science

posted Apr 13, 2015, 4:35 PM by Manuel Valle

Esta semana se enfocó en la ciencia y el testing, dos áreas que comparten mucho. Aquí el resumen del material ingerido durante esta semana:

Seth Lloyd on Programming the Universe https://www.youtube.com/watch?v=I47TcQmYyo4

Seth Lloyd: Quantum Machine Learning  https://www.youtube.com/watch?v=wkBPp9UovVU

El primer video habla sobre los progresos en la historia de la transmisión de la información y de cómo el mundo realiza cálculo. No me gustó mucho, en la parte histórica no me pareció que aportara mucho, y en la del universo como computadora me limitare a decir que no me parecieron consistentes sus argumentos.

En el segundo aterriza un poco más las cosas y argumenta en por qué creen que el impacto en el tiempo de cómputo es exponencial. La parte de machine learning per se no fue tan importante en el desarrollo, me parece que fue más que nada por que se escucha matón. Quantum Linear Algebra sería más descriptivo. Me pareció más interesante y mejor fundamentada que la primera, a pesar de no entender todo el contenido de la lecture.


Stephen Wolfram: Computing a theory of everything https://www.youtube.com/watch?v=60P7717-XOQ

No puedo tomar muy enserio a Stephen Wolfram. Su libro, el tan famoso/infame ANKOS (A new kind of science) ha sido el único libro que, literalmente, me ha hecho sentir nauseas. Y no por que fuera muy técnico (al contrario, carece inmensamente de rigor), sino por el tono insoportable con el que está escrito.

Lo que pude leer del libro fue repetitivo y díficil de leer debido a la enorme cantidad de paja que tiene; se puede palpar la finalidad implícita del autor de perpetuarse en la mente colectiva como un genio.. prácticamente es una larga alabanza a si mismo y al "nuevo" tipo de ciencia que inventó "el sólo", ignorando olímpicamente a la gran mayoría de personas que aportaron al desarrollo de los autómatas celulares durante los 40 años anteriores al libro.

["I have mostly ended up having to start from scratch—with new ideas and new methods that ultimately depend very little on what has gone before." - Stephen Wolfram]


En fin. En el video menciona sus términos de "irreducibilidad computacional" y "principio de equivalencia computacional", a pesar de que no haber definido (en el libro) ninguno de los dos en términos formales, lo cuál es sorprendente sobre todo en caso del segundo, pues es lo que más aclama como su mayor descubrimiento. Más que un principio es una conjetura, y una muy vaga.


[Sin embargo, los autómatas celulares son (a mi parecer) sumamente interesantes. El ejemplo clásico en dos dimensioneses el juego de la vida de Conway, un conjunto especifico de reglas en el que las celulas 'mueren' (por isolación/sobrepoblación) o 'viven' (por supervivencia/nacimiento) dependiendo de la cantidad de vecinos 'vivos'. Dicho autómata es turing completo (o en otras palabras, puede simular cualquier cálculo que realiza una computadora) y en el se pueden implementar desde una navecilla sencilla (https://www.youtube.com/watch?v=OSHgl1GPFpo), que resulta ser el emblema hacker (http://es.wikipedia.org/wiki/Emblema_hacker hasta ideas salvajes como representar de manera gráfica de una máquina de turing (http://rendell-attic.org/gol/tm.htm) ó algo que haría temblar a dos que tres fans de inception (https://www.youtube.com/watch?v=xP5-iIeKXE8)]


Mathematica y Wolfram Alpha por otra parte son algo más concreto. Del primero no tengo mucho que decir pues nunca lo he usado, pero se escucha mucho. El segundo, Wolfram Alpha si lo he usado varias veces, sobre todo en el pasado. No se si atribuirle eso a que últimamente me ha dado resultados muy malos o a que gran parte del uso que le daba era para revisar mis respuestas a ejercicios de cálculo diferencial, cálculo integral y ecuaciones diferenciales (venía con los pasos para encontrar la solución, lo cuál era bastante útil). Fuera de eso (y buscar cosas curiosas) tengo entendido que dicho sistema alimenta de conocimiento a siri.


Ambas son herramientas interesantes, pero de eso a predicar que está haciendo una revolución científica (sin dar un sólo resultado **concreto** de ello) hay una diferencia absurda.



Richard Feynman, The Great Explainer: Great Minds  https://www.youtube.com/watch?v=JIJw3OLB9sI

TEDxCaltech - Tony Hey - Feynman and Computation https://www.youtube.com/watch?v=9miKIWIYi4w

TEDxCaltech - Danny Hillis - Reminiscing about Richard Feynman https://www.youtube.com/watch?v=8CKW4A6jnJA

Feynamn on Scientific methods https://www.youtube.com/watch?v=EYPapE-3FRw

Las primeras tres cortas charlas (ya me estoy acostumbrando a videos largos) fueron un mini homenaje a Richard Feynman; el famoso físico-cuántico, gana-nobels, abre-bóvedas, estudia-bombas, toca-bongos. Fue un científico cool con rostro sonriente y espíritu aventurero.

La cuarta fue un extracto de Feynman ejerciendo su naturaleza: enseñando sobre el método científico. Las ideas las maneja con una asombrosa claridad y carisma de sobra.


Me acuerdo de una vez que vi un libro en una feria del libro que se llamaba "Lectures On Computation" y pensé en comprarlo pero no lo hice. Después un amigo me plático sobre las coloridas anécdotas de "Surely You're Joking, Mr. Feynman!" y fue donde conocí sobre el físico. Al tiempo supe que el libro que había visto era suyo, y me arrepentí un poco por no habermelo llevado. En uno de los videos mencionan unas lectures que dió en Caltech, y descubrí que son las mismas del libro. Y me arrepentí más :P


De Feynman siempre me resuena una anécdota de cuando él era niño, cuyo mensaje me parece que es oro: https://www.youtube.com/watch?v=05WS0WN7zMQ


Tools for Continuous Integration at Google Scale https://www.youtube.com/watch?v=KH2_sB1A6lA  

El primer video de testing habla sobre como es el sistema de integración sistema en Google.

Toca algunos problemas con los que se encontraron y cómo los resolvieron. También menciona algunas estadísticas de uso, y cómo, de acuerdo a la proporción de falsas alarmas, reconocen los tests más y menos confiables.


Testing Engineering@Google & The Release Process for Google's Chrome for iOS  https://www.youtube.com/watch?v=p9bEc6oC6vw

En el segundo abordan el proceso de desarrollo de la versión de Chrome para iOS desde un punto de vista de las pruebas que hicieron. Mencionan que el proceso de testing es colaborativo y no sólo responsabilidad de los QAs, y que el hecho de que gran parte de ese proceso sea automatizado es una de las ventajas que les permiten llevar un buen ritmo de innovación.

Menciona que es díficil competir con Safari en iOS debido a que éste tiene acceso a APIs nativas que chrome no.


GTAC 2014: The Testing User Experience https://www.youtube.com/watch?v=J7c0Bw840X8

El tercer video sobre testing aborda el asunto de que, si bien las pruebas automatizadas ofrecen muchas ventajas, la cantidad de esfuerzo necesaria para mantener dichos tests se está volviendo un problema para ellos. Menciona que en Google usan aprox. 60 años de tiempo de CPU al dia, ejecutando cerca de 100 millones de pruebas.

La propuesta es un sistema que analice los resultados de distintos sistemas usados en la cadena de desarrollo y ofrezca información útil. El link que dan del proyecto es https://github.com/google/rich-test-results


GTAC 2014: Test coverage at Google  https://www.youtube.com/watch?v=4bublRBCLVQ

El cuarto video habla del proceso de admisión de código. Todo el código es analizado automáticamente y, unicamente si pasa las pruebas, es revisado por otros desarrolladores (peer review).

Se me hizo muy interesante que una de las métrica que usan es el alcance de los tests en términos de porcentaje de lineas cubiertas. Si no está suficientemente 'cubierto' se pide que se realicen más tests. Apuntan a un 99% de cobertura en código nuevo y un 85% en código viejo.


GTAC 2014: I Don't Test Often ... But When I Do, I Test in Production https://www.youtube.com/watch?v=xkP70Zhhix4

Este último video fue el que me pareció más interesante de todos los de testing. Es un bato de Netflix hablando de algunas estrategias que usan para hacer pruebas de su sistema en producción.


La idea general detras de todas las técnicas que aborda es algo a lo que le llama 'Chaos testing', que es simular situaciones de caos en el sistema y si el sistema reacciona/se recupera de manera esperada.


Una de estas estrategias es la de el Ejercito de Simios. Un grupo de 'code monkeys' que se encargan de realizar tareas en el sistema de producción, la mayoría de ellas destructiva.

Los primero tres simios (Chaos Monkey, Chaos Gorilla y Chaos Kong) se encargan de simular la baja de servicios a diferentes niveles (simulan errores a nivel cluster, zona y región, respectivamente) y ver que el servicio de Netflix sea capaz de continuar operando a pesar de que una parte falle.

Otros monkeys son Latency Monkey, Conformity Monkey, Janitor Monkey, Security Monkey y Howler Monkey. Éstos son servicios que se encargan de revisar diferentes aspectos en producción (e.g. que el sistema no esté lento, que esté programado de acuerdo a sus estándares, que se haga un buen manejo de recursos, etc). Varios de estos changos los tienen disponibles en el github de netflix.


Otra es la cobertura de lineas de código. Algo parecido a lo que mencionaban  en el video de Test Coverage de Google, pero en lugar de enfocarse a la cobertura de los tests esta enfocado a la cobertura del código en producción, por usuarios reales. Menciona que para ello usan un sistema llamado Cobertura, que el impacto en su performance no es mucho y ésto les permite encontrar las rutas criticas del código, en las que deben de tener mayor cuidado, así como código muerto, que pueden borrar sin problemas.


La última técnica mencionada son los Canary Deployments, que consiste en que los cambios nuevos al sistema se mandan a una fracción de los clientes, dónde se verifica que no haya ningún problema con el código en un ambiente real.

La herramienta que usan se llama Asgard.

Es una extensión al clásico Move Fast & Fail Fast: Fail Small.



Comments