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.