A BUG’S LIFE (Not the Movie)

Bueno bueno, en esta ocasión escribiré sobre un paper que vimos en la clase llamado SECRET LIFE OF BUGS.

En resumen, había un grupo de personas que les interesaba indagar sobre los bugs, como se generaban, como se almacenaban, como se enterraban y morían o si se les daba seguimiento. También, cual era el procedimiento que llevaban los ingenieros para buscar referencias que los ayudaran a solucionar problemas que posiblemente alguien más ya se habia enfrentado.

Para esto fueron a las oficinas de MICROSOFT y pidieron acceso a un bonche de registros de BUGS con la idea de rastrearlos en su proceso de vida así como a las personas involucradas para saber a donde llegaba el análisis con respecto a las mejores practicas a las  hora de buscar recursos de referencia a la hora de corregirlos y evitarlos. Muchas ramas de esta busqueda terminaron en rutas sin sentido y se generó una gran nube de puntos dispersos que se llegaron a involucrar el los diversos bugs de cierto proyecto. FIN.

Bueno, sinceramente no se me hizo de mucho intereses ese paper. En particular algo rebuscado y con mucho relleno para mi gusto. Sin embargo lo que puedo sacar de él es: no tiene caso tratar de generar todo un pipeline o investigación robusta para solucionar problemas. Si bien la documentación de estos problemas, así como la asistencia de foros (donde generalmente se tratan los topics de ciertas tecnologías o herramientas) son aliados muy fuertes junto con la misma experiencia de la persona como con las personas que colaboran. Lo que me ha servido a mi en mi área laboral fuertemente es la investigación.

En lo que mi experiencia trabajando me ha dictado, ademas de mis ya 3 años como estudiante técnico en programación, y 4 años en la carrera de Ingeniería en Sistemas es, el auto aprendizaje e investigación inteligente te va entrenando sobre donde y como buscar. Siempre habrán expertos en la industria y grupos (como hacker garage por ejemplo) que organizan reuniones semanales para discutir ciertas tecnologías y es una oportunidad muy grande de escuchar y aprender de personas que llevan posiblemente décadas de experiencia ante ti. Ahí es donde uno aprovecha a pedir consejos o en casos más específicos, asesorías.

Internet es una herramienta muy poderosa, en el muy rara vez no he podido encontrar apoyo en alguna etapa que he estado atorado o a solucionar bugs. Al menos una buena alternativa encontraras. Pero lo más importante, paciencia y perseverancia. Tienes estas dos, tarde que temprano seras más y más capas, más sabio. Tendrás maneras más inteligentes de hacer las cosas y cada día que te sientes en la computadora, si, habran bugs, pero tambien habrá sabiduria.

Si les interesa hechar un ojo al paper del que hablo les dejo la liga siguiente. Si necesitan algun consejo relacionado al tema no duden contactarme en redes sociales.

Haz clic para acceder a aranda-secretLifeofBugs.pdf

 

Aprovecho este blog para promocionar nuestra primer experiencia VR-OnLocation al publico por parte de XR Tales, una compañía de tecnologías de alto impacto aplicadas a la industria del entretenimiento.

Estaremos presentando en el Festival Internacional del Cine y se pueden registrar para vivir esta experiencia ÚNICA en la siguiente liga.

https://m.facebook.com/story.php?story_fbid=961505554051678&id=865486070320294

Adler Alonso Zamora Ruiz

¿Las risas no faltaron? TC|R

En esta ocasión me di la oportunidad de escuchar el podcast 2 veces. La primer ocasión por mi cuenta de manera corrida, y la segunda ocasión acompañado haciendo pausas y (puesto que la persona con la que lo escuche es ajena a la carrera) compartiendo perspectivas y aplicaciones de algunos de los comentarios que se realizaron en la entrevista.

Al día siguiente, horas tarde en la oficina mientras avanzaba con algunos pendientes que tenia, aproveche y vi en Youtube  un vídeo sobre el creador de Dead Space que nos platicaba sobre los retos a los que se enfrento él y su equipo a la hora de realizar el juego y me di cuenta que muchos de estos problemas se resolvían por puntos híbridos tocados en el podcast.

Desde la manera de planear el problema, tenia una idea completa de cierta escena del juego y al querer resolverlo todo de un mismo jalón, las cosas simplemente no embonaban, eran como piezas de ajedrez de diferentes sets y tomó la decisión de empezar de cero (esta metodología) y desglosar las cosas por capas. Entonces (aunque me consta no igual) iban atacando punto por punto. Hacían que cierto task funcionara, seguían a partir de ahí. No seria algo, vamos para atrás pero en el pequeño ultimo punto que funcionó y así sucesivamente hasta que lograron terminar la gran escena de una lombriz zombie alienigena gigante que agarra a nuestro personaje.

Retroalimentando un poco mi idea de como muchas practicas y metodologías aplicadas al software tienen su pariente de aplicación en otras áreas de la industria platique el viernes con nuestro profesor Ken Bauer y me comenta como a el le pasaba que a pesar de ser un tema que hablaba y sugería desde hace 20 años, constantemente se encontraba con personas que recomendaban un libro donde hablaba de esta metodología. Un poco cuando en la primaria decías un chiste y nadie te escuchaba, y el compañero de al lado que si te contestó lo repite y todos se ríen. Duele pero al menos, las risas no faltaron ¿no?

Ahora volviendo al tema, TC | R. ¿Funciona? en resumen, puedo decir que he adoptado esta metodología involuntariamente acostumbrando a trabajar modular-mente por features individuales. Sin embargo por el tipo de trabajo que realizo, no me es posible hacer commits | reverts. Lo más cercano que puedo hacer es tener mi control de versiones diaria con documentación de todos los cambios que se han ido involucrando, desgraciadamente si llegase a ocurrir algo que corrompa mi proyecto, a menos que haya hecho un zipup del proyecto recientemente por (misma precaución) algún cambio mayor, tendria que regresar a hacer los cambios hechos el mismo día. Y créanme, me ha pasado más de alguna vez, lo cual me ha obligado a constantemente mejorar mi metodología y saber cuando hacer copias extra. Mi mismo dolor y experiencia les aconseja !HÁGANLO!, más vale prevenir. Y es cierto, así se comentaba en el podcast, hay ciertas situaciones donde esta metodología no funciona tan bien como en un proyecto individual compatible con git. Hay proyectos donde se involucran equipos de personas muy grandes donde para cada cambio hay un protocolo de revisión y aprobación y si se espera a que cada uno de estos commits pase por eso, puede prolongar el tiempo de desarrollo mucho mayor. Será cuestión simplemente de ver que tan compatible es con el proyecto de cada uno pero sin duda es una metodología que vale la pena revisar. Por la parte de testing que tienes también te ayuda a saber que parte del nuevo pequeño cambio fue lo que arruino que cosas.

Por lo pronto es todo, y a las personas que no tengan acceso a ese podcast les adjunto el link.

itunes podcast

Y recuerden, si mis test pasaron, !COMMIT!

por Adler Alonso Zamora Ruiz alias Tepic Guy