lunes, 27 de diciembre de 2010

Editorial de fin del año del 2010 - De vuelta a las bases

Henos aquí al final del año 2010. Primer fin de año de este blog que esperamos que sea el primero de muchos.

La verdad, en estos casi 9 meses de vida (chiste obvio al margen) nos hemos dado algunos gustos. Como dicen por ahi, justamente los gustos hay que darselos en vida y así lo hicimos.

Recuerdo cuando era chico miraba series de televisión (y aquí voy a delatar nuestra edad, ey, tengan en cuenta que la mitad de nosotros somos treintañeros todavia!! mas respeto!) como los angeles de charlie, los dukes de hazzard, BJ (la del camionero con el mono), el Sheriff Lobo (imperdible), el hombre de la Atlantida (ju juuu por DioS!), buck roger o el auto fantástico. Cuando terminaba la temporada de estas series era habitual que el ultimo capitulo fuera en realidad una selección de las mejores partes de los capítulos que se habían emitido este año. Va aquí nuestro homenaje a esta práctica, como modo de resumen del año 2010.

Hemos repasado algunos principios básicos de objetos en la-ley-de-demetrio-y-otras-yerbas-oo y en poo-ejemplos-de-la-ley-de-demeter. No quiero olvidarme tampoco de la seria sobre patrones de tests de unidad: patterns-de-tests-de-unidad-1-como-deberian-ser-los-tests-de-unidad, patrones-de-test-de-unidad-2-humble-objects o como-lograr-tests-de-unidad-rapidos.

Estos principios y patrones parecen bastante obvios y trillados(bah, así nos parecían) pero charlando con mi amigo y co-autor de Blog nos hemos dado cuenta que en estos tiempos muchas veces debido a la falta de recursos para programación o porque hay otros temas mas "fashions", lo cierto es que muchos programadores nuevos no conocen ni a estos ni a los principios más básicos de la Programación Orientada a Objetos.

Hemos recién empezado a charlar sobre un tema muy interesante, importante como buena practica pero bastante extenso como son los Code Smells en code-smells, desgranando algunos en detalle como: desconfien-de-los-parametros-booleanos, o obsesion-primitiva y comentarios

Emprendimos una batalla, desigual desde ya, tratando de aclarar cuestiones muchas veces malentendidas o mal interpretadas de las metódologías ágiles, como en con-scrum-no-alcanza o estas-realmente-haciendo-desarrollo-Agil y dos en particular que me gustaron mucho, por la repercusión que tuvieron y porque fueron generadas con discusión dentro de la comunidad ágil iberoamericana: metaforas-del-desarrollo-de-software-i y metaforas-del-desarrollo-de-software-ii. Para terminar con el articulo fundamental de como encarar el aprendizaje de cualquier nuevo conocimiento y en particular de una metodología ágil : el-camino-del-conocimiento-de-aprendiz-a-maestro.

Como niños buenos e hijos de la generación "La inmaginacion al poder", hemos discutido como debe ser un buen líder y otras cuestiones de liderazgo en liderazgo-i y liderazgo-ii. Pero por otra parte, cuestionando nuestra conciencia, nos hemos encargado de recordar las obligaciones que tenemos como verdaderos profesionales de formarnos constantemente: cuantos-libros-tecnicos-leiste-este-año, y trabajar sobre lo que tienen importancia como en mantenibilidad-vs-reusabilidad, por-que-funciona-pair-programming y nos hemos auto-retado cuando perdemos el tiempo como en larga-el-twitte o productividad-la-espartana.

Para finalizar queremos resaltar dos articulos en particular, ambos han tenido mucha difusión, y creemos saber, al menos parte de, la causa: El primero es flexibilidad-ante-el-cambio que habla sobre porque hay que estar preparados para el cambio en todo proyecto de desarrollo, sobre como descubren lo que quieren los usuarios y como el cambio es esencialmente imparable porque es sencillamente parte de la realidad. Y el otro es pasos-de-bebe-el-fin-del-debugging, una de las herramientas menos utilizadas, difundidas y comprendidas de la programación pero que nosotros le asignamos una importancia capital para enfrentar el caos de la complejidad que impone El Cambio sobre el desarrollo de software, junto, claro está con las prácticas de TDD y pair programming.

Para cerrar el balance , además de los artículos, este año organizamos dos Code Retreats, que nos permitieron compartir tiempo con otros locos (perdón, quiero decir: con otros entusiastas de estos temas) capaces de juntarse un sábado a las ocho de la mañana a programar de a pares, resolver problemas y razonar sobre como mejorar nuestro arte.

Bueno, eso es todo. Lo que hemos tratado humildemente de hacer este primer año desde este espacio es describir y promover conceptos, libros, técnicas y herramientas que consideramos poco habituales dentro del ámbito de la programación.

Creemos que la terrible presión de la ola de información junto con la inundación de nuevos lenguajes, herramientas y frameworks impone tal ritmo al programador profesional que arrasa con cuestiones de base y produce que todo se confunda en un lodazal de conocimientos superficiales y la Ultima-bala-de-plata-que-viene-a-solucionar-todos-tus-problemas.

Lo que se necesita en realidad es adquirir buenos hábitos, aplicar Buenas Practicas de desarrollo y volver a las bases.

Por eso brindamos. Salud!.





La foto del brindis es propiedad de larrazun. Algunos derechos reservados.

jueves, 16 de diciembre de 2010

Productividad a la espartana

En mi primer trabajo tuve muchísimo tiempo libre. Al principio por estar en la típica situación del junior al que nadie le da bola y después porque dejaron de pagar los sueldos y se decretó una especie de "huelga virtual" : íbamos a la oficina pero no hacíamos nada.

Así que me pasaba 8 horas al día delante de mi terminal Unix (era una espectacular SUN workstation, con monitor de 25 pulgadas, nada mal eh), sin nada para hacer. De puro aburrido, me puse a mirar scripts, a probar comandos, distintos shells, a leer páginas del man y, para cuando se terminó de ir la empresa al tacho, había aprendido bastantes cosas nuevas.

¿Qué pasaría si estuviera en la misma situación ahora? Creo que aún con lo que me gusta mi trabajo no le dedicaría la misma cantidad de tiempo a aprender que en esa época y el principal motivo de esto es que actualmente hay muchas más distracciones disponibles que en mis viejas terminales VT100.

De hecho, hace un tiempo que me venía molestando el tiempo que le estaba dedicando a algunos sitios web, tiempo que sin ser para nada excesivo me parecía que podia dedicar a otras actividades (no necesariamente trabajo: leer un libro, escribir artículos para este blog, etc.). Por lo tanto, decidí implementar una idea que había encontrado varias veces: bloquear esos sitios.

La solución técnica es sencilla: hay que tomar el archivo hosts (qué en Linux se encuentra en /etc y en Windows en \WINDOWS\system32\drivers\etc ) y agregarle líneas del estilo:

0.0.0.0 ole.com www.ole.com www.ole.com.ar

De esta manera, el sitio quedará bloqueado y no podremos acceder más. Por supuesto que así como bloqueamos el sitio podemos desbloquearlo, pero lo importante es que esto exige una acción de nuestra parte y por lo tanto una decisión consciente: ¿quiero ir a leer que dice Carusso Lombardi o prefiero hacer otra cosa?

Adicionalmente, podemos redireccionar los sitios a una lista de cosas para hace, como para que las alternativas a Carusso sean mas claras.

Una cosa más: creo que esto es una excelente idea cuando podemos tomar por nosotros mismos la decisión de hacerlo o no. En cambio, si como jefes bloqueamos el acceso de nuestra gente a cargo estamos dando un mensaje de desconfianza total y además incentivando la búsqueda de maneras de burlar nuestros controles (recuerdo haber escrito un script Perl que cambiaba 12 veces mi password, para burlar una directiva de seguridad que me prohibía reutilizar las últimas 12 passwords, otra vez instalamos servidores proxies para salir a internet sin ser detectados y muchas otras mas que no podemos comentar porque todavía no prescribieron).

Por ultimo, quizás podemos parecer pesados de tanto insistir en administrar de una manera mas productiva nuestros tiempos, o dicho de otra manera de cuanto insistimos en dejar de pavear y perder el tiempo. Bueno, si, es verdad, lo somos.

El problema es que muchas veces nos encontramos diciendo "No tengo tiempo", "No me alcanza el tiempo", "Estoy hasta las manos y no me queda tiempo", cuando en realidad siempre tenemos la misma cantidad: Cada día tenemos 24 horas. El modo en que decidamos como utilizarlo, ahí esta la diferencia.

miércoles, 8 de diciembre de 2010

Saros, Programación de a Pares Distribuida?

Whole Team

Todos sabemos que la forma de comunicación más efectiva que existe es la cara a cara, en un mismo lugar físico, adonde cada uno de los participantes de la comunicación pueda ver las expresiones del otro, sus gestos, y hasta la postura del cuerpo, ademas de escuchar su voz y percibir los cambios de tono.

Por eso una de las practicas centrales que proponía para un equipo de desarrollo eXtreme Programming era Whole Team, todo el equipo, incluyendo usuarios, debían trabajar juntos en un mismo lugar, para que la información fluyera , sin barreras.

En mil y una oportunidades los autores de este blog hemos comprobado cuan cierto es esto.

Outsourcing

Sin embargo, somos realistas, y lo que ha sucedido desde hace varios años es que el modelo económico mundial Globalizado basado en la premisa de buscar fuerza de programación, de análisis, testing o Diseño allí donde sea más barato hace que cada vez sean mas comunes encontrar proyectos distribuidos. Viviendo en paises como Argentina, Chile, Bolivia, Uruguay, Perú, Colombia, Ecuador, Venezuela, Mexico o el mismo Brasil (la unica duda que tengo es España y perdón si me olvido de algún otro País), adonde se recibe cada vez mas proyectos "tercerizados", todos sabemos de lo que hablamos.
De cualquier manera, bienvenido sea el trabajo, ademas porque brinda una gran oportunidad para mostrar la clase de profesionales de primera que tenemos en toda hispanoamerica!.
Las mismas metodologías ágiles lo han terminado aceptando (en algunos casos) y asi existen rios de e-tinta sobre Scrum Distribuido para nombrar una.

Nuevos remedios

Hay una frase de Francis Bacon que es una de mis frases favoritas : "Aquel que no aplica nuevos remedios debe esperar viejos males".

Uno de los problemas más importante ha resolver tiene que ver cuando el equipo de programación esta distribuido. Para ello, para desarrollar sistemas con programadores trabajando en distintos lugares se necesitan nuevas herramientas.

Los que escribimos este blog alguna vez hemos intentado trabajar con herramientas de escritorios compartidos como VNC, TeamViewer, LogMeIn, etc. pero la tasa de refresco de pantalla, la modalidad misma de ver toda la maquina del compañero, no poder hablar al mismo tiempo, todo esto hace difícil el trabajo compartido prolongado y en tiempo real.

Saros

A este respecto hace muy poco nos encontramos con este articulo de Kent Beck que atrajo nuestra atención:
"A Few tips for using Saros for Remote Pairing"

Saros es un plugin de eclipse que permite hacer Pair Programming, programación de a pares distribuida! Prometedor verdad?

Aqui tienen el sitio del proyecto Saros.

Tambien puede ver un video de como se trabaja con Saros.

Tips de Instalacion

Les dejo por ultimo unos tips de instalación, porque hay ciertas cosas que solo funcionan por ahora siguiendo por el caminito de piedras...

1 - El proyecto que compartan lo deben tener ambos desarrolladores ya bajados del repositorio de fuentes o tener muy pocos cambios de diferencia. Lo mejor es empezar con un proyecto nuevo, limpio.

2 - Todos los que vayan a formar parte del pair programming tienen que tener cuentas en el mismo servidor Jabber.

3- La única manera que logre hacerlo funcionar detrás de un entorno VPN con firewall (que impedia acceder a un server Jabber externo) fue primero instalando un servidor de Jabber local en una maquina de la misma LAN, por ejemplo el servidor OpenFire 3.6.4.

4- En las pruebas que hice no funcionó creando las cuentas Jabber por afuera de eclipse. Solo anduvo cuando las creamos desde el menú que instala el plugin en eclipse "Saros\create account", ahí recién el plugin reconocio las cuentas, permitio conectarse y pudimos compartir proyectos.

El plugin esta en un estado de desarrollo beta, pero avanzando a grandes pasos. Al respecto Dice Kent Beck: "...en 15 o 20 años la mayoría de los programas serán escritos a través de colaboración en tiempo real distribuida, así que vale la pena un poquito de dolor ahora para experimentar el futuro."

miércoles, 1 de diciembre de 2010

Sherlock Holmes

"Una vez descartado lo imposible, lo que queda, por improbable que parezca, debe ser la verdad"

Esta frase fue escrita por Arthur Conan Doyle para su personaje Sherlock Holmes y resume el mecanismo de las investigaciones en la mayoría de las novelas policiales: ir descartando posibles explicaciones hasta llegar a la única posible.
Lo difícil, tanto en los casos de Sherlock como en la vida real, es poder descartar N-1 explicaciones, porque N es grande y porque descartar cada explicación no es fácil (creo que no lo podría haber dicho de una manera más nerd o geek, como se dice ahora).

Pero nosotros no necesitamos resolver cosas en la vida real. Sólo necesitamos que nuestros programas anden y existen factores que hacen viable comportarnos como si fuéramos Sherlock Holmes (o el Dr. House, para un ejemplo más moderno).

En primer lugar, las computadoras son determinísticas. Esto significa que si una computadora recibe dos veces exactamente el mismo input el resultado que va a producir va a ser exactamente el mismo. Esta idea no se condice con nuestra experiencia de todos los días (sobre todo si somos usuarios de ciertos sistemas operativos), pero no deja de ser una verdad absoluta, por lo menos para computadoras de nuestra época que no planeen tomar el mundo.

¿Cual es la consecuencia para nuestro método Sherlockiano? Que podemos descartar todas las hipótesis que sean del estilo "no cambié nada y dejo de andar". Si dejó de andar, es por un motivo; quizás nunca podamos descubrirlo; quizás lo haya hecho otra persona, pero existió un motivo (siempre quise poner un punto y coma escribiendo en castellano, es raro porque odio hacerlo cuando programo).

Este es un punto muy importante, porque nos permite liberar nuestro cerebro de mucho trabajo inútil. Si algo deja de funcionar, solo necesitamos ver que cosas cambiaron desde la última vez que anduvo y podemos estar seguros que alguno de esos cambios va a ser el culpable. Teniendo pocos sospechosos, siempre es más fácil descubrir al criminal.

Es aquí donde, además de las características inherentes de nuestro medio, entran en juego hábitos que permiten mantener la lista de sospechosos corta. En el párrafo anterior hay una frase tramposa: solo necesitamos ver que cosas cambiaron desde la última vez que anduvo. Parece sencillo, pero para saber esto se necesita poder determinar primero cual fue la última vez que nuestro programa anduvo y segundo que cosas cambiaron desde entonces.

¿Cómo podemos ser capaces de saber cuándo fue la última vez que nuestro programa funcionó? Si se trata de un problema que aparece en nuestro ambiente de desarrollo, las técnicas que mencionamos aquí son muy eficientes. Si dejamos pasar poco tiempo entre pruebas, es facil saber cuando fue que nos equivocamos. Los tests de unidad en estilo TDD son particularmente eficaces: si corremos los tests cada 10 minutos, un test fallado debe tener un sospechoso bastante obvio.

Si se trata de un problema que apareció en producción o en testing la cosa es más complicada. Hay que recrear los ambientes anteriores para poder verificar en que momento apareció el bug, lo cual a veces es difícil y consume mucho tiempo. Pero nada de esto es nuevo, siempre supimos que dejar llegar bugs a producción es muy caro.

La otra mitad del problema es determinar que cambió para que nuestro programa dejara de andar y aquí entra en acción un hábito muy querido por los autores de este blog: los commits frecuentes. Digamos que logramos determinar que el programa dejó de andar la noche del 24 de julio a las 3AM y que podemos considerar todos los cambios ocurridos cerca de ese momento como sospechosos. Si un programador estuvo modificando código sin commitear durante un mes e hizo commit a las 2AM, todos esos cientos de cambios son igualmente sospechosos. En cambio, si trabajamos de manera de poder commitear todos los días, el conjunto de sospechosos (la cantidad del codigo commiteado) es mucho más corto.

La misma solución se puede aplicar para los problemas en Producción, si no para evitarlos por lo menos para minimizarlos, aplicando las práctica de Integración Contínua y Entregas Frecuentes. La idea es la misma: No esperar a tener mil cambios en la aplicación para pasarla a productivo porque eso implica que cualquier error tiene miles de "sospechosos". Mientras que si uno hace mini-implementaciones y entrega frecuentemente, cada bug tendrá unos pocos "posibles" sospechosos.

Por supuesto, hay variaciones de estos problemas en equipos de trabajos grandes, con gente que modifica a la vez las mismas partes del programa, pero la regla general se mantiene: si algo dejo de andar fue por algún cambio y cuando más fácilmente puedas determinar ese cambio tu vida va a ser más fácil.

Elemental Watson!, Diria Sherlock Holmes (Claro que esa frase no la dice en ninguno de los cuentos o novelas que escribió Arthur Conan Doyle, "Urban Legend" que le dicen).