Friday, December 21, 2012

Felicidades a Todos.... Happy NewYear++


Para los ateos: Felices días de Vacaciones.
Para los cristianos: Felices Navidades.
Para los satánicos: Lo siento tios.... a soportar otras Navidades
Para el resto: Felicidades sin especificar.

Wednesday, November 14, 2012

Introspección en Python mediante inspect

Mediante el módulo inspect podemos de una forma sencilla obtener todos los símbolos (funciones, variables, classes, etc) de un módulo. Para ello debemos usar la función inspect.getmembers que nos devuelve todos los símbolos del módulo.
Una vez de que disponemos del símbolo podemos usar las funciones ismodule, isfunction, ismethod y similares para clasificar el símbolo.

El siguiente ejemplo podemos ver cómo se obtienen todas las clases y todas las funciones de un módulo:

Ejemplo introspección con inspect

Esta técnica se usa por ejemplo en el boscli-oss-core para una vez cargado un módulo de forma dinámica identificar todas las funciones cuyo nombre cumple un formato concreto (https://github.com/eferro/boscli-oss-core/blob/master/src/boscli/boscli.py#L515).


Tuesday, November 06, 2012

Ejemplo uso importlib carga dinámica de módulos por nombre

En muchas ocasiones es bastante útil poder cargar módulos o acceder a símbolos usando como entrada una cadena. Esto permite cargar de forma dinámica código, por ejemplo si estamos desarrollando un sistema de plugins.

En versiones de python anteriores a la 2.7 se solía usar  la función __import__, pero a partir de la 2.7, tenemos disponible el módulo importlib que recubre la función  __import__ dándonos un api algo más elegante.

Podemos ver un ejemplo de uso en el siguiente snippet de código: https://gist.github.com/3928018

Importer Class (importlib wrapper)

Tests for importer module

Espero que este pequeño ejemplo de código le puesa ser útil a alguien...

Monday, October 29, 2012

Resumen Clean Coders capitulo 6: TDD Parte 2 (III) Conclusiones



Continuamos con el resumen del Capitulo 6 Parte 2. En este caso finalizamos con las conclusiones.
Si no lo has hecho, puedes leer los anteriores posts sobre el capitulo (parte 1  parte 2).

Conclusiones

  • El código se pudre porque tenemos miedo a cambiarlo
  • Para mantenerlo limpio tenemos que eliminar el miedo a cambiarlo
  • Sólo con una batería de tests en la que confiamos se elimina el miedo a cambiar el código
  • Reglas del TDD
    • No se puede escribir código de producción excepto para pasar un test que está fallando
    • Escribe solo lo suficiente de un test para demostrar el fallo (no compilar es un fallo)
    • Escribe solo lo suficiente del código en producción como para pasar el test fallando
  • Siguiendo estas reglas de TDD se consigue:
    • Menos defectos
    • Tiempos de depuración más bajos
    • Documentación de bajo nivel confiable y detallada
    • Código altamente desacoplado
    • Y una batería de tests en la que puedes confiar
  • TDD te hace ir más rápido
  • Los desarrolladores profesionales debemos esperar que el departamento de QA no encuentre ningún defecto (ese es el objetivo)
Con este post concluimos el resumen de este interesante capitulo de clean coders 

Sunday, October 28, 2012

Review Agile product management with scrum

Agile product management with scrum creating products that customers love

Este es uno de los pocos libros dedicados al rol de Product Owner que he visto... Es un rol, que aun siendo fundamental, es muy difícil hacerlo bien y no cuenta con tanta literatura como el rol de Scrum Master o como las prácticas de desarrollo de software que debe usar cualquier equipo de desarrollo ágil.

El libro se centra en entender el rol de product owner, crear la visión general del producto, trabajar con el backlog, planificar las versiones (releases), y cómo introducir el rol de product owner en empresas que no estén acostumbradas a ese tipo de rol.

La parte que más me ha gustado es la que se centra en crear la visión general del producto y el trabajo con el backlog. En estas partes, da bastantes herramientas y trucos para ayudarnos en el proceso creativo y en la toma de decisiones.

Enlace a goodreading

Thursday, October 25, 2012

Resumen Clean Coders capitulo 6: TDD Parte 2 (II)



Continuamos con el resumen del Capitulo 6 Parte 2. Tal y como comentamos el capitulo es muy completo y contiene gran cantidad de información por lo que hemos dividido el resumen en tres posts. Este es el segundo.

Si no lo has leido, puedes comenzar por el anterior post sobre este capitulo.

Para trabajar con código legacy en el que no tenemos tests:

  • Encuentra un modulo pequeño que puedas probarlo sin realizar demasiados cambios
  • Realiza los tests para realizar esos cambios con más seguridad
  • Para funcionalidades nuevas, se hacen pequeños cambios para poderlas testear
  • Si en una modificación, existe la posibilidad de modificar y hacer los tests a posteriori o hacer un nuevo módulo, deberemos hacer un nuevo módulo, usando TDD Siempre que sea código nuevo, se hace con TDD

Como testear GUI/View

  • Para la parte de vista pura, no merece la pena, puesto que es una parte que se presta a muchos cambios (estilo, presentación, …) y que además no tiene un resultado prefijado sino que se suele ajustar continuamente
  • Pero se puede probar todo el código relacionado en las capas anteriores...
  • Es decir podemos probar el contenido de los elementos de pantalla, pero no merece la pena testar cómo están posicionados, qué forma tienen, colores, etc...
  • Para ello se separa el GUI en dos componentes Presenter / View
    • Presenter interroga objetos de negocio y prepara estructuras de datos
    • Las estructuras de datos generadas por el Presenter, son renderizadas por el objeto View
    • Se testea el Presenter
  • Algunos hacen tests para las vistas (a nivel de interface), pero en ese caso lo hacen después de realizar las vistas, con el objetivo de que una vez que han conseguido un resultado, detectar si cambia. El, en general no lo recomienda.

Como testear la BD

  • Se testea que tu esquema y tus consultas funcionan como se supone
  • Necesitas tener la aplicación y la capa de BD separada
  • Esto permite probar la aplicación sin la BD real
  • Luego se puede probar la capa de BD separada. Por ejemplo se puede testear:
    • Se puede testear que se genera el SQL correcto
    • Incluso se puede probar que el SQL se comporta bien cargando una pequeña cantidad de datos

Disciplina y profesionalismo

  • El software es una disciplina que tiene que atender a muchísimos detalles, cualquier pequeño cambio y/o error hace que la aplicación deje de funcionar. Es muy propenso al fallo humano y las consecuencias (a nivel de la aplicación) suelen ser importantes.
  • Esto no pasa en otras disciplinas, y quizás en la que si pasa es en contabilidad y por eso establecieron como “buena práctica” el “sistema de partida doble” (Double-entry bookkeeping system) por el que cada entrada se realiza de dos formas independientes con cálculos independientes de forma que si existe una discrepancia se detectase de forma más o menos inmediata.
  • El TDD sería el equivalente en desarrollo de software a esta buena práctica del “sistema de partida doble” puesto que todo se desarrolla con un doble flujo (el de test y el de producción) que se validan el uno al otro.
  • Como desarrolladores profesionales debemos esperar conseguir que el departamento de QA no encuentre errores en nuestras entregas y en caso de que los encuentre debemos esforzarnos en que no pueda volver a pasar ese tipo de error.
  • Debemos liberar código que sabemos que funciona (lo contrario es irresponsable y no profesional).
  • La mejor forma conocida para asegurarnos de que el código que liberamos funciona es seguir la disciplina del TDD en su creación.
  • Debemos buscar tener una cobertura de código del 100%, ese es el objetivo, aunque puede que en algún caso no sea totalmente posible, pero el 100% debe ser lo que se persiga.

En el próximo post terminaremos con las conclusiones de este capitulo...

Monday, October 22, 2012

Resumen Clean Coders capitulo 6: TDD Parte 2 (I)



Continuamos con las acciones de mejora / compartiendo videos cleancoders. En esta ocasión toca el resumen del Capitulo 6 Parte 2


Este capitulo está lleno de detalles interesantes, por lo que voy a hacer varios posts para resumirlos...
Comencemos....

@unclebob, comienza con una sesión (ligera) de diseño de la solución al problema, el la que:
  • Obtenemos el vocabulario del sistema
  • Identificamos los componentes básicos
En la práctica no se sigue el diseño que hemos hecho, se usa como guía o referencia, pero el diseño final será el que emerja mientras resolvemos el problema usando TDD.

@unclebob Comienza con una estructura de test y un test vacío  de forma que se verifica que todo está en su sitio antes de comenzar la sesión de TDD propiamente dicha.

Al principio, cuando todavía no hemos entrado en el problema, podemos identificar los primeros pasos haciéndonos la siguiente pregunta: ¿Qué test tengo que escribir para forzarme a escribir el código que se que quiero escribir?

Es común escribir un test, simplemente para poder escribir cierto código inicial de producción y que luego, según evoluciona la solución, ya no tenga sentido (o no pruebe nada) y se elimine (canCreateGame, canRoll, …)

Nunca escribimos tests que sabemos que van a pasar.

El código de los tests es tan importante como el de producción y tenemos que tener el mismo cuidado con el. Es decir tiene que ser clean code y se debe refactorizar de forma continua.

En muchas ocasiones, desarrollando con TDD, el resultado no se corresponde con el diseño original. Normalmente es más sencillo, puesto que sólo tiene el código necesario para la funcionalidad actual.

Respuestas a las objeciones típicas a usar TDD:

  • Objeción: Se debe de tardar más con TDD, puesto que se escribe mucho código de test... Se tarda mucho menos, puesto que se avanza más rápido trabajando siempre sobre clean code, además se gasta mucho menos tiempo en depuración. No nos pasamos todo el tiempo peleando con código sucio y dificil de entender.
  • Objeción: Los managers no dejarán practicar TDD a los desarrolladores... Es una práctica interna, que no tiene porqué entrar en discusión con los managers.
  • Objeción: Refactorizar es volver a realizar trabajo, seria mejor hacerlo bien a la primera... Asi es la vida... efectivamente es volver a realizar el trabajo, pero lo normal (y adecuado) para trabajos creativos es hacerlo de forma iterativa con pequeños cambios, puesto que es practicamente imposible hacerlo perfecto a la primera.
  • Objeción: Quién/Qué prueba los test... Con TDD disponemos de dos flujos alternativos para una funcionalidad, los tests y el código de producción, por lo que cada flujo testea el otro, los tests, testean el código de producción y al reves.
  • Objeción: Quizás el mantenimiento de los tests es demasiado caro... No tiene que serlo, puesto que los tests, también deben estar correctamente diseñados y deben de ser clean code, por lo que su coste de mantenimiento debe ser bajo.
  • Objeción: Un test puede probar que un bug ya no se produce, pero no puede probar que no existen bugs. Es decir no puede probar que el software es completamente correcto. El objetivo no es estar 100% sino disponer de una red de seguridad que nos elimine el miedo a cambiar el codigo puesto que tenemos una confianza/certeza sobre que el código funciona correctamente muy alta.
  • Objeción: TDD es un disciplina, seguir reglas en vez de pensar y usar la cabeza... Las disciplinas nos ayudan a no tener que realizar las mismas decisiones una y otra vez... Necesitamos que sea una disciplina para poder ser eficientes (tener mecanizado e interiorizada la práctica) lo que no quita para que de vez en cuando nos planteemos como mejorar la disciplina.
  • Objeción: No importa si se hacen los tests antes o después del código de producción... Si se hacen los tests a posteriori, nos parecerán opcionales y se tenderá a no hacerlos o a que no sean completos, por tanto no confiaríamos en ellos. Además, haciéndolos después perdemos la ventaja de que los tests primero nos obligan a hacer nuestro diseño testable (es decir con bajo acoplamiento).

Seguiremos en el próximo post...

Monday, October 15, 2012

Review NoSQL Distilled

NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence

He tardado algo de tiempo en sacar un rato... pero mejor tarde que nunca...

Hace como un mes que termine de leer el libro NoSQL Distilled, de Martin Fowler y Pramod J. Sadalage y la verdad es que me ha parecido muy interesante.

Este libro se centra en dar una rápida visión de los tipos de bases de datos que se suelen llamar NoSQLs.
El libro trata bases de datos clave-valor, de columnas, de documentos y de gráfos. Para cada uno de los tipos, habla de los pros y contras, los casos de uso típicos y el uso más general que se le puede dar.

En general el libro me ha gustado bastante, sobre todo porque explica muy bien los conceptos y da una visión general sobre en qué casos se puede usar cada una de las tecnologías.... Eso si, en caso de que necesitemos un libro de referencia, este no es el libro, pero como no pretende serlo, no hay problema.

El libro se lee muy fácil y esta muy bien escrito... además como es tan cortito en unos pocos días se puede leer.

Recomendable para los que quieran introducirse en el tema  y no tengan demasiado tiempo o no quieran entrar en demasiada profundidad a cada uno de los tipos de bases de datos.

Enlace a Goodreads



Sunday, September 16, 2012

Olas Septiembre 2012 / Sopelana

Hacía años que no dedicaba algo de tiempo al bodyboard, por suerte, he tenido unos días libres y me ha cuadrado algún bañito... Divertido!!!

Tuesday, September 04, 2012

Resumen Clean Coders capitulo 6: TDD Parte 1


Continuamos con las acciones de mejora / compartiendo videos cleancoders. En esta ocasión toca el resumen del Capitulo 6 Parte 1

Clean Code, Episode 6 - TDD - Part 1

  • Reglas TDD
    • No escribir código de produccion excepto para hacer pasar un test que esta fallando
    • Escribir solo lo suficiente de un test como para demostrar el fallo
    • Escribir solo lo suficiente del código de produccion como para pasar el test
  • Pasos TDD
    • Red
    • Green
    • Refactor
  • Miedo y Descomposición del código (Code Rot)
    • El código y el diseño de un sistema suele irse deteriorando si no lo limpiamos de forma continua.
    • Esto hace que el sistema sea rigido, fragil y dificil de cambiar y que las estimaciones cada vez sea más imprecisas y dificiles de hacer.
    • No lo limpiamos, pq tenemos miedo (de romperlo)
  • Un esfuerzo de limpieza que no sea constante no tiene sentido (normalmente cuesta mucho más y si no tenemos como validar que todo sigue funcionando, suele terminar en desastre).
  • Eliminando el miedo a cambiar el código
    • Gran cobertura de tests
    • Que se ejecutan en muy poco tiempo
    • Que se ejecutan con solo pulsar un boton o escribir un comando
    • Con una buena cobertura de tests, se puede llegar a un estado en el que no se tiene miedo a que si pasan los tests, simplemente se libera la versión.
    • Ventajas de disponer de una buena cobertura de tests
      • No hay miedo para cambiar el código
      • No hay miedo a limpiar el código
      • No hay miedo a liberar una versión
      • Número de bugs muy bajo
  • Usando TDD en su experiencia
    • El proyecto se desarrolla más rápido
    • Nos ahorran tiempo
    • Se desarrolla con mucha mas fiabilidad
    • Muchos menos errores
    • y se dedica menos tiempo a depurar
    • Y la estrcutura resultante es mejor
  • Las tres reglas del desarrollo TDD
    • Es una disciplina y tiene una serie de reglas
    • Las tres reglas
      • No se puede escribir código de producción excepto para pasar un test que está fallando
      • Escribe solo lo suficiente de un test para demostrar el fallo (no compilar es un fallo)
      • Escribe solo lo suficiente del código en producción como para pasar el test fallando
    • El ciclo debe ser de unos pocos segundos... algo de test, algo de código, algo de test, algo de código, …
  • Con TDD, siguiendo estas reglas se obtiene:
    • Tiempo de depuración reducido por un factor de 10
    • Documentación (actualizada y funcional) con ejemplos
    • El código está mucho más desacoplado dado que tiene que ser testeable, es decir un sistema mucho más flexible
    • No tenemos miedo a cambiar el código
    • No tenemos miedo a limpiar el código
    • Es decir, el TDD, evita que el código se vaya corrompiendo

Monday, August 20, 2012

Resumen Clean Coders capitulo 5: Estructura (Form)


Una vez más, siguiendo con la acciones de mejora / compartiendo videos cleancoders, continuamos con los resumenes de los capítulos de Clean Coders
Hoy toca el Capitulo 5

Cap 5 - Estructura / Form

Este capitulo se centra en todo lo que tiene que ver con la estructuración que realizamos del código de nuestras aplicaciones, comenzando con el formateo del propio código fuente y terminando por algunos consejos sobre cómo definir los límites de los diversos componentes y capas de la aplicación, comenzando de esta forma con algunos temas de arquitectura.

Comentarios en código

  • Se deben tener pocos comentarios en código
  • Cada vez que escribimos un comentario es que hemos fallado en en expresar con nuestro código, luego tenemos que trabajar muy fuerte para que eso sólo sea necesario en raras ocasiones (ejemplo una expresión regular complicada, …)
  • Se deben escribir lo más cerca posible del código al que hacen referencia. 
  • Nunca comentarios superfluos que no añadan nada a lo que ya dice el código. 
  • Los comentarios nunca deben ser obligatorios 
  • Nunca comentarios sin código, ni comentarios tipo banner, ni TODOs, ni FIXMEs (somos profesionales y si no está terminado, seguimos trabajando)
  • El código comentado se elimina (sin mirarlo).
  • Comentarios legales: 
    • Copyright
    • Documentación de API publico (con herramientas automaticas) aunque es preferible los APIs que no requieren ni siquiera esa documentación. 

Formateo de código

  • Guía de estilo: 
    • No existe como documento 
    • Todo equipo tiene una 
    • El código del equipo es el ejemplo de la guia de estilo
    • El equipo debe ser consistente y compartir ese estilo (si usa un IDE, debe compartir la configuración para que el estilo sea coherente). 
  • Importante tener una convención para el uso de lineas de separación, el recomienda una linea para separar cada método, cada grupo de variables, etc. Hay que ser consistentes en su uso. Las lineas en blanco son un elemento más de formateo.
  • Logitud de linea. Nunca scrolls horizontales, entre 40 y 80 caracteres... en algún caso se podría ir a 120 caracteres, pero nunca más. 
  • El tamaño de fichero medio, puede ser por debajo de 100 lineas, y nunca superar a las 500 lineas. 
  • Para formateo de Java el usa/recomienda: 
    • Estilo K&R 
    • Indentación por espacios 2 espacios de indentación 

Clases vs Estructuras de Datos 

Las clases nos protegen de nuevos tipos
Las Estructuras de Datos nos protegen de nuevas funciones

Clases

  • Tell don’t ask (con métodos con alta cohesión con respecto a las variables de la clase)
  • Evitando usar getter y setters, si en algún caso es necesario usar un getter es importante ocultar los datos, dando el interfaz más abstracto posible (getPercentFuelRemaining no getGallonsOfGas...)
  • Protegen de nuevos tipos

Estructuras de Datos

  • Sacos de datos con métodos con baja cohesión
  • No se ponen reglas de negocio en este tipo de estructuras
  • Se pueden manipular con switchs si es necesario
  • Protegen de nuevas funciones, pero no de nuevos tipos

Límites (Boundaries) 

Los limites dentro de la aplicación separan las diversas partes, y siempre tienen las siguientes caracteristicas:

  • Una parte tiene una definición abstracta
  • Otra parte es concreta e implementa la definición abstracta de la otra parte
  • Las dependencias de fuentes van parte concreta ---> parte abstracta
  • No existen dependencias de fuentes en el sentido inverso

Los Objetos de dominio y las tablas de BD no son lo mismo, en realidad, ni están fuertemente relacionadas.
Los Objetos de dominio deben estar separados de las tablas de BD mediante una capa de abstracción que debe depender de las abstraciones de la aplicación (la parte con los objetos de dominio) y de las tablas de BD. Los objetos de dominio (y el resto de la aplicación) nunca deben depender de esta capa (y por supuesto, menos de las tablas que están por debajo).

Monday, August 06, 2012

Instalación de stack python independiente...

Tal como comente en el post sobre uso de paquetes deb de python no oficiales en la mayor parte de los casos, para el desarrollo de aplicaciones de servidor, lo normal es disponer de una stack python independiente del de sistema, por ello, lo normal es descargar y compilar python y utilidades básicas para gestionar paquetes y entornos virtuales.

En este ejemplo, vamos a instalar la última versión de Python 2.7 en el directorio /opt/py2.7

Python 2.7.3 for old gnu/linux systems (test debian/ubuntu)

Una vez que hemos realizado la instalación y verificado que el interprete python funciona correctamente, podemos pasar a instalar las setuptools, pip y el virtualenv.

setuptools, pip and virtualenv installation

En este punto ya disponemos del interprete de python y de las herramientas mínimas para poder crear entornos python, instalar paquetes, etc...
Este proceso permite usar un stack python moderno en servidores que dispongan de una versión obsoleta de sistema operativo.
Aun en el caso de que nuestro servidor disponga de una versión moderna de python, es bastante conveniente disponer de nuestra propia versión controlada del interprete y de las herramientas separada de la que viene con el sistema operativo...

Wednesday, August 01, 2012

Paquetes Python no oficiales para Ubuntu

En cada versión de ubuntu suele existir un par de versiones de Python soportadas de forma oficial, normalmente una de la rama 2.x y otra de la rama 3.x. En algunas ocasiones puede ser conveniente disponer de paquetes para otras versiones de Python para poder hacer pruebas de aplicaciones, depurar paquetes deb o para poder generar paquetes que puedan ser usados en varias distribuciones de forma simultanea. Para estos casos nos puede venir muy bien el respositorio de launchopad https://launchpad.net/~fkrull/+archive/deadsnakes Este repositorio contiene gran cantidad de paquetes de Python con distintas versiones capaces de convivir con los paquetes de Python oficialmente soportados en esa versión de ubuntu.... Para poder acceder a esos paquetes, lo primero es añadir ese repositorio a nuestros sources, por ejemplo ejecutando:

sudo add-apt-repository ppa:fkrull/deadsnakes
Una vez hecho esto, podemos por ejemplo instalarnos un Python 2.5 en una Ubuntu lucid 10.04, con los siguientes comandos:

sudo apt-get update
sudo apt-get install python2.5
Este repositorio contiene paquetes Python desde la versión 2.4 hasta la 3.2 para distribuciones ubuntu desde Lucid 10.04 hasta precise 12.04 Recomiendo el uso de este repositorio para el caso de que tengamos que trabajar con los paquetes Python oficiales por algún motivo, o si estamos trabajando con paquetes deb de programas hechos con Python y necesitemos probarlos en varias distribuciones o hacer las primeras pruebas de cómo funcionarían con otras distribuciones o cuando queremos hacer un backport de un paquete que nos de problemas por la versión de python. Por supuesto, si tenemos una aplicación de servidor, lo más normal es usar nuestro propio stack para el deploy usando virtualenv y no usar ninguna de las versiones de python y de paquetes de python del sistema.

Monday, July 30, 2012

Resumen Clean Coders capitulo 4: Estructura Funciones (Conclusiones)



Siguiendo con la acciones de mejora / compartiendo videos cleancoders, continuamos con los resumenes de los capítulos de Clean Coders.
En este caso, nos toca el Capitulo 4. Como este capitulo es bastante denso es posible que termine haciendo varios posts relacionados, pero de momento, en este post me voy a centrar en las conclusiones más importantes del capitulo.

Cap 4 - Estructura Funciones (Conclusiones)

  • Los prototipos de funciones deben ser pequeños, pocos argumentos (<=3), no pasar booleans, ni usar argumentos que puedan ser null, no argumentos de salida
  • Las funciones se organizan siguiendo la regla de step down, lo publico primero, lo privado después y siempre intentando que las funciones a las que llama cada función estén debajo de la definición de esta primera función y descendiendo cada vez en abstracción.
  • Switch va en contra del paradigma OO e interfiere en el despliegue independiente de componentes (y por tanto en el desarrollo independiente) .
  • Debemos remplazar los switchs por polimorfismo o por lo menos mover los switchs a sitios donde no generen ese problema de dependencias (por ejemplo a una factoria o al main).
  • El Temporal coupling en muchos casos se puede limitar o eliminar usando el patrón de pasar un bloque.
  • Conviene separar las funciones de query (consulta) de las de comando (modificación) (CQS)
  • Tell don’t not ask
  • No hacer cadenas de queries, evitar que una sola linea tenga gran conocimiento de la estructura de la aplicación o de gran cantidad de objetos. Recordando la Ley de Demeter... No se habla con extraños.
  • Limitar el uso o eliminar de salidas de bucle desde dentro (break). Hacen menos entendible el código.
  • Pensar en el control de errores antes que en el código normal
  • Usar excepciones para el control de errores. (no devolver error codes)
  • Las excepciones deben ser de la clase o modulo que las lanzas
  • No check exceptions.
  • funciones o gestionan errores o hacen cosas, no las dos cosas.

Friday, June 22, 2012

Nos vemos en el Agile Open Spain 2012 en Zaragoza

Este fin de semana, nos espera el emocionante Agile Open Spain 2012 ... Con muchas ganas de reencontrarme con gente y de compartir los valores ágiles...

Para los que no conozcan el  Agile Open Spain 2012 os comento que es una reunión/encuentro de gente que comparte los valores ágiles en formato Open Space. El formato de Open Space es uno de los formatos de conferencia más impresionantes que he visto, resulta completamente impresionante ver cómo tanta gente se autoorganiza sin ningún tipo de plan previo y con unas sencillas reglas.

Este año además, voy ha realizar el experimento social de ir junto con mi pareja y nuestra pequeña, que ni que decir tienen que no han tenido contacto previo con la agilidad (excepto que me ven jugar con tablones y pizarras por todos lados...)
Estoy convencido que el formato Open Space, les va a impresionar tanto como me han impresionado a mi todos los Open Spaces en los que he participado (por que en un Open Space no se asiste, se participa...)...

Tal como se decía en el Open Space de desarrollo Dev Open Madrid 2012, las reglas son sencillas...
  • Involúcrate y pásatelo bien
  • Los que vienen, son los que tienen que venir.
  • Lo que ocurre, es lo que tiene que ocurrir.
  • Empieza cuando tiene que empezar.
  • Termina cuando tiene que terminar.
Si no estás aprendiendo o contribuyendo, es tu responsabilidad usar tus dos pies para encontrar otro lugar donde aprendas o contribuyas.

Nos vemos en el Agile Open Spain 2012, este fin de semana en Zaragoza!!!



Actualización:
En http://www.proyectosagiles.org/que-es-open-space/ disponeis de una descripción muy acertada de cómo es un Open Space.


Friday, June 01, 2012

Resumen Clean Coders capitulo 3: Funciones

Siguiendo con la acciones de mejora / compartiendo videos cleancoders, continuamos con los resumenes de los capítulos de Clean Coders.
En este caso, nos toca el Capitulo 3


Funciones

  • Las funciones deben ser muy cortas (hasta 4) y hacer una sola cosa.
  • Separar por agrupaciones de operaciones.
  • Separar cosas de distinto nivel de abstracción.
  • En las funciones largas es dónde se esconden las clases.
  • Una función sólo hace una cosa cuando ya no podemos extrar más funciones ni clases de su implementación.
  • Los bloques dentro de una estructura de control, son una oportunidad para encontrar nuevas funciones.

En este caso, en mi opinión,  sin llegar a ser tan extremista como Uncle Bob en cuanto al número de lineas, el código es más mantenible y legible con funciones cortas (de hasta 10 lineas).

Depende de a lo que estemos acostumbrados, nos puede parecer que el tener un gran número de funciones pequeñas y de clases pequeñas, hace que el código sea menos legible, pero creo que es más una tendencia proveniente de una forma de trabajo y que realmente una vez de que tienes interiorizado el realizar un buen nombrado de las funciones / clases y que organizas correctamente tus estructuras, es mucho más sencillo de mantener, con clases y funciones muy pequeñas y que tengan una única responsabilidad.


El resumen de este episodio ha quedado un poco pequeño puesto que gran parte se centra en ejemplos básicos y refactorizaciones... Por otro lado, me parece tan evidente lo que comenta, que poco puede aportar el resumen que yo haga....

Continuamos en el siguiente capitulo.

Tuesday, May 29, 2012

Resumen Clean Coders capitulo 2: Nombrado

Tal y como comente en el acciones de mejora / compartiendo videos cleancoders continuamos con los resumenes de capitulos del Clean Coders.
Esta vez nos toca el Capitulo 2


Capitulo 2 Nombrado

En este capitulo, uncle Bob se centra en enseñarnos cómo debemos usar los nombres (clases, métodos, variables, etc...) que seleccionamos al desarrollar, como una herramienta de comunicación...
  1. Los Nombres son una herramienta poderosa de comunicación... Hay que elegirlos y tratarlos con cuidado
  2. Elige nombres para comunicar tus intenciones. Si tienes que poner un comentario para explicar el nombre, es que no está bien elegido. Si tienes que leer el código para entenderlo, también está mal escogido.
  3. Siempre evitar la desinformación (generada por mal naming o por cambios que hacen que se queden los nombres obsoletos). (Said what it means, means what it says)
  4. Los Nombres deben ser pronunciables.
  5. No usar encoding (no notaciones hungaras, no I para interfaces, …)
  6. Clean Code como prosa. Para Clases nombres, Para Variables nombres, Boolean predicados, métodos verbos, si devuelven boolean predicados.
  7. Scope rules...
    1. Variables con nombres cortos o incluso muy cortos si tienen scope pequeño.
    2. Variables con nombres más largos si tienen scope más largos.
    3. Funciones, métodos, clases
      1. Nombres cortos y convenientes si el scope es grande y su uso muy común.
      2. Nombres más largos y descriptivos si el scope es más corto (métodos y clases privadas, por ejemplo).

Lo más importante:
Any fool can write code that a computer can understand.  Good programmers write code that humans can understand. Martin Fowler

--
Actualización:
31/5/2012 Resueltos algunos problemas de formateo...

Tuesday, May 22, 2012

Resumen Clean Coders capitulo 1



Tal y como comente en el acciones de mejora / compartiendo videos cleancoders aquí va el primer resumen de los capítulos de Clean Coders. Concretamente del Capitulo 1


Capitulo 1 Clean Code


  1. ¿Qué es Clean Code?
    1. Código escrito por alguien que parece importarle y con atención a los detalles.
    2. Código que se lee como si fuese buena prosa.
    3. Código en que cuando lees un método/función es más o menos lo que esperabas (por el nombre).
  2. ¿Importa?
    1. Tanto, como que es la única forma de ir deprisa en el desarrollo de Software.
    2. Tanto que el no tenerlo en muchos casos es el principal problema de los departamentos de desarrollo de software.
  3. ¿Quién es el culpable de crear código sucio (no clean code)?
    1. Somos los desarrolladores, nadie más.
    2. Todo lo demás son disculpas.
  4. ¿Por qué creamos código sucio los desarrolladores?
    1. Por desconocimiento / falta de profesionalidad.
    2. Porque nos autoengañamos:
      1. Pensando que obtenemos ventajas a corto plazo
      2. Pensando que lo limpiaremos en el futuro
  5. ¿Cómo nos limita el trabajar/crear código sucio.
    1. El código es dificil de entender, y por tanto dificil de modificar y de mantener. Por lo que el coste de mantenimiento (e incluso el de desarrollo) es muy alto.
    2. Se crean sistemas rígidos, en que cada cambien requiere de muchos otros cambios en otros módulos. Haciendo que el coste de mantenimiento sea alto e impredecible.
    3. Se crean sistemas frágiles en el que cambios afectan a partes de la aplicación que en principio no deberían verse afectados. Esto provoca sensación de fragilidad y de baja calidad. Hace que los managers y los clientes no confíen en el producto. El coste de meter cualquier modificación es bastante impredecible.
    4. Se crean sistemas inseparables en los que nunca sabes si vas a poder reusar un modulo. Normalmente, no puedes reusar los módulos fuera del contexto en el que fueron creados. Esto conlleva duplicadidad de código y un coste alto de mantemiento. Además los costes son impredecibles, puesto que nunca sabes lo que puedes reusar.



The only valid measurement of code quality: WTFs/Minute



Hasta el siguiente capitulo....

Saturday, May 19, 2012

Acciones de mejora... Compartiendo videos cleancoders

Actualmente en Alea Soluciones, nos encontramos en pleno proceso de construcción de un equipo de desarrollo basado en los principios ágiles y en prácticas de Extreme Programming

Dentro de este proceso en una de las retrospectivas internas acordamos realizar una especie de grupo de estudio sobre los videos creados por @unclebobmartin (uncle Bob) en http://www.cleancoders.com/


Cada semana, cada miembro se ve/escucha un capitulo previamente acordado, tantas veces crea necesario, y posteriormente, a final de la semana, ponemos en común nuestras impresiones, dudas, mejoras internas que podemos realizar siguiendo los consejos de los videos....

De momento llevamos seis capitulos y tengo que decir que, si bien ver los videos es bastante enriquecedor, verlos a la vez que el resto de los miembros, y comentar posteriormente las impresiones, es mucho más enriquecedor y aporta un aprendizaje mucho más sólido.

Así que espero que durante el Largo proceso, podamos seguir realizando este tipo de acciones, tanto con estos videos como con otros materiales de formación sobre desarrollo de software...

Siguiendo los patrones del Apprenticeship Patterns,  record_what_you_learn y share_what_you_learn, tengo la intención de compartir por aquí las conclusiones que saquemos de cada uno de los capitulos.

Curso Agile Inception ofrecido por path11

El pasado jueves y viernes asisti al curso sobre cómo realizar una Agile Inception ofrecido por path11. El curso me resulto de lo más inspirador y se notaba que las profesoras, @rlaina
y @amaliahern, no sólo sabían muy bien de lo que hablaban y habían meditado y preparado muy bien cómo transmitirlo, también se notaba que tenían mucha experiencia real con esta herramienta ágil y daban todo tipo de ejemplos, situaciones reales, posibles escenarios y esos trucos que sólo la experiencia da.


De momento path11 es una de las pocas empresas que usan las Agile Inception de forma sistemática en el arranque de un proyecto, por lo que es un verdadero lujo que comparta su experiencia con el resto de agilistas.

Resumiendo, un curso altamente recomendable para cualquier equipo ágil que quiera alinearse rápidamente con el cliente y comenzar a trabajar juntos compartiendo una visión y un objetivo común.

Tuesday, April 10, 2012

Review "Apprenticeship Patterns"

Apprenticeship Patterns 

(Guidance for the Aspiring Software Craftsman)

Este es uno de los libros más inspiradores que me he leído últimamente...
Por un lado me ha recordado todo lo que me gusta de mi profesión y por otro lado me ha aportado sugerencias y prácticas concretas para avanzar como en el "largo camino" como desarrollador.

Contiene patrones sobre cómo mejorar nuestras habilidades como desarrollador y nuestra profesionalidad. Estos patrones son bastante concretos y están bien explicados, por lo que el libro resulta realmente práctico. Además es fácil de leer.

Este libro a pasado a mi lista de libros profesionales favoritos.

Quien necesite que se lo preste, que me lo indique, estoy deseando que lo lea cuanta más gente posible :-)

Enlace a goodreads

Saturday, April 07, 2012

Comunidades locales y pasión por la profesión

El pasado 24 de marzo se celebro en Madrid el primer Codemotion en España (http://www.codemotion.es/), un evento que aglutino gran cantidad de desarrolladores y futuros desarrolladores interesados por mejorar dentro de su profesión... (conociendo nuevas técnicas y tecnologías... pero sobre todo, socializando con otros desarrolladores con los que comparten este interes).

No voy a hablar de cómo se desarrollo la jornada, puesto que tenéis gran cantidad de resúmenes aquí http://codemotion.es/follow-up

Lo que voy a comentar, es lo impresionado que me quede de que un evento así reuniese tanta gente interesada y lo motivador que es ver que la profesión va dando sus pasos...

Este evento me hizo ver con perspectiva la evolución que han ido teniendo las comunidades técnicas relacionadas con la informática en este país...
Desde los primeros grupos relacionados con la informática en los que intervine (R34 linux en Fidonet, BBSs, Grupo de LinuxUsuarios de Bizkaia,...) hasta ahora he podido ver que el número de grupos han crecido en cantidad, madurez e interés...
Es impresionante ver el número de grupos locales relacionados con tecnologías en los que se puede participar y la cantidad de gente apasionada por estos temas con la que se puede quedar e intercambiar experiencias...

Actualmente suelo ir de vez en cuando a saraos organizados en los grupos python-madrid, madrid-agil, Madrid-Devopsmadrid.rb

He podido ver una gran evolución en temas relacionados con software libre, desarrollo, agilidad, lenguajes dinámicos... y puedo asegurar que cuando se ven las cosas a lo largo de unos cuantos años, se ve un avance evidente en la madurez de la profesión y de los que la practicamos (y en todos los frentes)...

Vamos, que cuando oigo a la gente quejarse porque todo el trabajo relacionado con informática es pura basura, dominada por consultoras ("Charcuteras") (Ver diccionario-comercial-recursos-humanos) o que no se desarrolla con agilidad (Ver diccionario-agil-metodo-proceso), no puedo más que acordarme de todos esos grupos locales y toda esa gente apasionada que en vez de quejarse (o además de...) se dedican a cambiar todo eso, trabajando por mejorar la profesión que les apasiona...

Que envidia (sana) dan las nuevas generaciones de informáticos que disponen de todos estos grupos, todas estas conferencias, todas estas reuniones... Así que todos a una a reforzar lo que nos gusta de la profesión y a cambiar lo que no nos gusta...


Actualización:
En el blog de Adolfo Sanz podeis encontrar una fántastica recopilación  de lo acontecido en el codemotion.

Wednesday, April 04, 2012

Review "Extreme Programming Pocket Guide"

Extreme Programming Pocket Guide

Seguramente este libro no va ha cambiar tu forma de pensar sobre el desarrollo del software, pero puede introducirte en la metodologia XP. Es muy conciso, fácil de leer y muy práctico como referencia rápida en las prácticas y valores de XP.

Es muy útil para recordar/reforzar los principios, artefactos, rolos y practicas usadas por XP.

(adicionalmente es tan pequeño que se puede leer bien mientras se empuja un carro de bebe :-) )

Review en goodreads


Tuesday, April 03, 2012

Libros técnicos pendientes de leer

Siguiendo los consejos del Apprenticeship Patterns, concretamente el patrón (reading list) dejo aquí mi lista de lectura pendiente

También podeís ver la lista de libros que actualmente estoy leyendo

Si alguien quiere comentar algo sobre cualquiera de estos libros o de los libros técnicos que ya he leido, que me pegue un toque :-)

Monday, April 02, 2012

El largo camino para el desarrollador de software

Siguiendo algunos consejos del libro  "Apprenticeship Patterns" voy a intetar en el blog ir compartiendo los pequeños pasos que de dentro del "largo camino" para convertirme en un desarrollador de software...

La verdad que después de casi tres años estar más centrado en temas de sistemas, en cuanto he comenzado a programar un poco otra vez he vuelto a redescubrir que desarrollar es lo que realmente me gusta... sobre todo cuando se desarrolla en equipo...

La idea es ir registrando en el blog los libros relacionados con el mundo de la programación que vaya leyendo (Apprenticeship Patterns :: read_constantly), los libros que quiero leer (Apprenticeship Patterns :: reading_list) y las conclusiones o ideas que vaya madurando con la lectura de estos libros (Apprenticeship Patterns :: record_what_you_learnApprenticeship Patterns :: share_what_you_learn)


Friday, March 23, 2012

Libro de citas (X)

"[big design up front] is the maxim of those that haven't implemented very many large systems."

#SICP Structure and Interpretation of Computer Programs

Tuesday, March 13, 2012

Trabajo con texto / sed básico

sed permite realizar cualquier tipo edición en ficheros de texto mediante el uso de comandos o pequeños programas "sed".
La verdad es que sed es muy potente, pero aquí sólo voy a comentar dos o tres ejemplos básicos, que en muchas ocasiones me han preguntado...

En general sed acepta que la operación se haga sobre el mismo fichero usando la opción "-i" (inplace). Lo más normal (y lo más seguro) es no usar esta opción y simplemente trabajar usando la entrada/salida estándard y pipes o redirecciones. Pero como estos comandos son para gente que no usa demasiado la linea de comandos, tratan de ser lo más sencillos posible y usarán esta opción.


Sustituir en todo el fichero ejemplo.txt, la palabla 'inicial' por la palabra 'final':
sed s/inicial/final/g -i ejemplo.txt

Sustituir sólo la primera ocurrencia de la palabla 'inicial' por la palabra 'final' en fichero.txt:
sed s/inicial/final/ -i ejemplo.txt

Borrar las lineas que contengan la palabra 'ejemplo' del fichero ejemplo.txt:
sed /ejemplo/d -i ejemplo.txt

Borrar las lineas que empiecen por la palabra 'ejemplo' del fichero ejemplo.txt:
sed /^ejemplo/d -i ejemplo.txt


Borrar las lineas que terminen por la palabra 'ejemplo' del fichero ejemplo.txt:
sed /ejemplo$/d -i ejemplo.txt

Borrar las dos primeras lineas del fichero.txt
sed '1,2 d' -i fichero.txt

Borrar la última linea de fichero.txt
sed  '$ d'  -i fichero.txt

Borrar las líneas vacias de fichero.txt
sed  '/^$/ d'  -i fichero.txt

Mostrar las tres primeras lineas de fichero.txt
sed  -n '1,3 p' fichero.txt

Mostrar las lineas 4,5,6 de fichero.txt
sed  -n '4,6 p' fichero.txt

Más info:
man sed
info sed


Tuesday, March 06, 2012

Trabajo con texto / uniq

uniq permite identificar, contar, y omitir lineas repetidas dentro de un fichero que esté ordenado, así que su uso más típico es junto con cat y sort.

Eliminamos líneas duplicadas:
cat file_a | sort | uniq
Contamos líneas duplicadas:
cat file_a | sort | uniq  -c

Si consideramos que tenemos ficheros de texto (file_a y file_b) con registros por líneas, facilmente podemos realizar las siguientes operaciones:

Union de registros de A y B:
cat file_a file_b | sort | uniq > file_c
Intersección de registros de A y B (registros comunes):
cat file_a file_b | sort | uniq -d > file_c
Diferencia de registros de A y B (A - B):
cat file_a file_b file_b | sort | uniq -u > file_c


Más info:
man sort
man uniq
info coreutils

Monday, March 05, 2012

Más libros... Para prestar...

Continuando con el post de libros que tengo que podría prestar y que viene del DevOpenMadrid 2012, además de los libros del post anterior, dispongo de los siguientes:

  • El lenguaje de programación C++, Stroustrup
  • The mythical man month, Frederick P. Brooks (no original)
  • Pragmatic Unit Testing, In Java with JUnit 
  • Practices of an Agile Developer
  • Agile Retrospectives Derby/Larsen
  • Effective C++, Meyers
  • More Effective C++, Meyers
  • Agile Web development with Rails
  • Programming Ruby, Thomas Hunt
  • Pattern Oriented Software Architecture (Vol1)
  • Design Patterns, GOF
  • The Design Patterns Smalltalk Companion
  • Surviving Object-Oriented Projects, Alistair Cockburn
  • SQL Pocket Guide
Algunos de estos libros son difíciles de conseguir por lo que si alguien está interesado que me diga algo por correo o por twitter o por cualquier medio que se le ocurra.

Sunday, March 04, 2012

Libros Smalltalk y otros temas... Para prestar...

Libros Smalltalk y otros temas... Para prestar...

Hoy en el DevOpenMadrid 2012 hemos estado haciendo book croosing (Bookcrossing) y he comentado con varios algunos libros más o menos dificiles de conseguir sobre informática...

Concretamente varios me han preguntado por varios libros de Smalltalk Pongo aquí la biblioteca física que tengo actualmente, por si alguien quiere leerse alguno...

  • Object Design, Wirfs-Brock, Rebecca|McKean, Alan
  • Exceptional C++
  • Object-oriented Analysis and Design With Applications, Booch, Grady
  • Programando Con Smalltalk, Deck, Diego Gómez
  • Software Libre Para Una Sociedad Libre, Rms
  • Gnu Emacs Manual, RMS
  • Smalltalk, Objects, and Design, Liu Chamond 9781583484906
  • Squeak 
  • Smalltalk Best Practice Patterns, Beck, Kent 9780134769042
  • Squeak. Galán, Ana Pizarro
  • The Art and Science Of Smalltalk
  • En El Principio Fue La Línea de Comandos, Stephenson, Neal 9788493298227
  • Regular Expression Pocket Reference
  • Hackers & Painters, Paul Graham
  • Cathedral and the Bazaar, Raymond, Eric S. 
  • Object Solutions, Booch Grady 9780805305944
  • Just For Fun, The Story of an Accidental Revolutionary, Linus Torvalds; David Diamond
  • Practical Django Projects, James Bennett
 Antes tenia muchos más, pero poco ha poco he intentado limitar el número de libros en formato "físico"... Algunos de estos libros son difíciles de conseguir por lo que si alguien está interesado que me diga algo por correo o por twitter o por cualquier medio que se le ocurra.