El desarrollo ágil

Durante la formación para ser profesionales del mundo de la informática se enseñan metodologías de ingeniería del software para lo cual, normalmente se, enseñan con cierta profundidad procesos pesados (en contraposición a los ágiles) como métrica o UP. Las metodologías ágiles se suelen nombrar, pero no se profundiza mucho en ellas.

Nunca me han gustado las metodologías pesadas ya que considero que en la mayoría de los casos es más costoso seguir la metodología y escribir la documentación que desarrollar el proyecto.

En contraposición con todo esto existen las metodologías ágiles, que permiten utilizar un esquema de desarrollo mucho más natural.

Utilizando una metodología pesada el ciclo de desarrollo puede ser algo como:

• Entrevista con el cliente para obtener requisitos
• Convertir los datos obtenidos del cliente en una especificación de requisitos (doc1)
• Hacer diagramas de casos de uso que contemplen todas las funcionalidades (doc2)
• Hacer un montón de documentos más (Plan de pruebas,…)
• Presentarle los documentos anteriores al cliente (que en muchas ocasiones no es técnico y no los entiende bien)
• Desarrollar el proyecto
• Desplegar el proyecto

En las metodologías ágiles se busca aligerar la carga que conlleva la documentación, pero también se consigue hablar de manera natural el lenguaje del cliente. El ciclo anterior podría ser:

• Entrevista con el cliente para obtener requisitos en forma de ejemplos (se utiliza un lenguaje cercano al la lógica de negocio del cliente)
• Convertir los ejemplos en tests (esto es código)
• Desarrollar el proyecto verificando que pase los tests
• Desplegar el proyecto

En el primer caso era necesario convertir en explícito los datos entregados por el cliente mediante multitud de documentos. Esto hace que, si los requisitos del proyecto cambian, sea necesario modificar todos los documentos generados con nuevas versiones que reflejen los cambios, con lo cual el coste del cambio va aumentando con el transcurso de los distintos ciclos. En este tipo de metodologías el contrato son los documentos.

En el segundo caso se evita generar documentos para explicitar los acuerdos, requisitos, etc, presentados por el cliente. Acuerdos, requisitos, etc. se reflejan en los ejemplos, que, una vez convertido en tests, son el contrato. Además el contrato es en sí mismo el plan de pruebas (o al menos una parte muy importante de este).

 

Sobre la compra de SUN y el futuro del Software Libre

En estos días se ha producido la compra de Sun por parte del gigante Oracle, lo cual ha hecho que el mundo del Software Libre se haya estremecido ya que Sun era la abanderada del software libre (con el permiso de IBM) entre las empresas grandes. Este movimiento es bastante curioso ya que no se ha dejado claro qué espera Oracle de Sun o en otras palabras cuáles son los motivos que les han empujado a gastarse miles de millones de dolares en  su compra.

 

Linux como SO de escritorio en las empresas

Escribo esta entrada a colación de una muy interesante entrada en Barrapunto. Me ha parecido extremadamente interesante, especialmente los comentarios. Parece que el avance del Software Libre en los escritorios es cada vez más patente. Hace unos pocos años nadie tenía “Linux” en el escritorio, y pocos en los servidores. A día de hoy, los sistemas operativos basados en GNU/Linux ya dominan el mercado de los servidores (en la organización en la que trabajo son aproximadamente el 80% de los servidores) y parece que poco a poco se están abriendo paso en los escritorios.

¿Qué ha hecho posible esto?¿Qué camino habría que seguir para que dentro de 5 ó 10 años el 80% de los escritorios use este sistema?

 

Debian en CH3WNAS

Este aparato es un NAS de la marca Conceptronic para discos IDE 3.5″ PATA con interfaz wireless, que compré hace unos meses. El dispositivo ya tiene un Linux dentro. Aquí siguen las instrucciones necesarias y los pasos que he aprendido para acceder a el, y para poder instalarle una debian etch.

 

Crisis, Responsabilidad Política, Inversión Pública y Software Libre

A nadie se le escapa que en este momento tenemos una crisis bastante profunda en España. En realidad no tenemos una crisis sino dos crisis unidas. La primera crisis es la crisis financiera internacional, mientras que la segunda es la explosión de la infladísima burbuja inmobiliaria. España es un país en el cual aproximadamente el 30% del PIB (no recuerdo la fuente) proviene directa o indirectamente del sector construcción. Otros paises como Alemania rondan el 11%.

Los dirigentes políticos (ni nadie) no saben qué medidas serán efectivas a la hora de superar la crisis. Una de las que se propone en España es la inversión pública.  Esta medida me parece acertada, solo que creo que se están equivocando sobre en qué invertir. Existe la necesidad de reducir el porcentaje de la economía que depende del sector construcción, pero es precisamente en este sector donde se va a intertir la aplastante mayoría de la inversión pública que se hará para superar la crisis.

 

Cambio de tendencia

Recientemente se ha publicado la pre-release de Flash 10 para 64bits. Y lo ha hecho primero para Linux!!!.

Esto es una gran noticia ya que parece indicar un claro cambio de tendencia en uno de los principales proveedores de software. El hecho es que hace unos años esto simplemente no era posible. Vamos a ver cuantos toman nota y siguen sus pasos.

Por cierto lo he probado y me da la sensación de que va mucho más fluido. Lo he notado al ver una película a pantalla completa. Ya no apreció saltos ni nada por el estilo (antes sí).

 

El consumismo y los ordenadores

Hace ya algún tiempo que algunos usuarios hemos tomado conciencia sobre un fenómeno inquietante. Los ordenadores cada vez son más veloces, disponen de más memoria RAM, de discos duros de mayor tamaño y de tarjetas gráficas capaces de manejar más y más millones de triángulos texturizados. Es natural que la industria se esfuerce en progresar y ofrecer cada vez mejores productos a sus consumidores. Sin embargo hay muchos usuarios que no llegarán nunca a utilizar ni siquiera el 10% de los recursos con que cuenta su máquina y está adquiriendo un hardware que no necesita; y que además consume mucha más energía (por ejemplo las tarjetas gráficas de última generación) que el hardware que sí necesita.

 

Varias apreciaciones sobre XEN

Cuando se utilizan sistemas de virtualización es común utilizar dispositivos loop para montar los discos duros de las máquinas virtuales (dominios en el argot XEN). Los kernels de Linux tienen un límite máximo para este tipo de dispositivos; y aunque, es configurable, el límite por defecto se sitúa en los 16 lo cual no es mucho. Es sencillo aumentar este numero mediante la pertienente configuración del modulo.


options loop max_loop=128


Sin embargo existe un número máximo de 256 para el número de loops en el sistema aunque utilices está opción. Teniendo en cuenta que empíricamente parece que cada dominio (disco, swap, etc.) consume aproximadamente 4 loops esto implica que la cantidad máxima de dominios que pueden estar ejecutándose en el sistema es de 64; lo cual no es poco; pero puede ser un problema si quieres plantear un sistema con determinadas un grano muy fino. También es cierto que, dado que no es posible consumir más memoria de la que tiene el sistema entre todos los dominios, este límite parece razonable, pero en mi opinión es alcanzable.

 

XEN

Estos días he podido hacer algún experimento más con el sistema de virtualización XEN. En alguna entrada anterior ya se habló en este blog sobre distintas herramientas de virtualización libres. Desde hace bastante tiempo vengo utilizando VirtualBox para utilizar Windows o versiones de 32 bits de Linux; sin embargo hace unos pocos días he vuelto a experimentar con Xen. Entre las ventajas que tiene utilizar Xen en lugar de un sistema de virtualización como VirtualBox destacan el rendimiento, lo sencillo que es manejar a mano los dominios, la posibilidad de permitir que una máquina virtualizada tenga acceso a determinados recursos software. Entre las desventajas habría que destacar que es un poco más complicado comenzar a utilizar y que no existen opciones directas para ejecutar sistemas operativos para otras arquitecturas.

 

Escribir bonito en python PEP-0008

Aquí va una lectura muy recomendable para que los programadores de python se la lean una una vez en la vida. Python como a guido le gusta que se vea

Como no me voy a acordar de nada, hago un resumen para las cosas que se me van a olvidar.

• indentación: 4 espacios. No tabs.
• líneas a 80 caracteres, rompiendo después de los operadores
• separar funciones y clases por dos líneas vacías
• separar métodos y/o funciones por una línea vacía
• grupos de funciones por dos o más líneas
• enconding: utf-8 (será preferido para python >=3)
• los imports a tu propio código, que sean absolutos
• un import por linea salvo los from xxx import yyy,zzz
• paréntesis y corchetes siempre pegados a ambos lados de las cosas
• dospuntos, comas y puntoycomas pegados a la izquierda y con espacio a la derecha
• operadores con 1 espacio a ambos lados
• el igual de los parámetros pasados por nombre, pegado a los dos lados
• escribe docstrings para toda cosa que sea pública, tanto el módulo como las clases como los métodos públicos. Incluye también los difíciles (docstrings en pep 257)
• Los comentarios mejor que sean de una línea, comiencen con mayúscula y acaben sin punto, solo cuando sean estrictamente necesarios
• módulos y packages: minusc y cortitos
• clases y excepciones: LasPublicas y _LasPrivadas
• variables globales y funciones: separadas_por_subrayados y los privados con _underscore_delante
• si un nombre colisiona con algo de python y no lo puedes evitar, añade subrayado al final
• crea una clase para cada excepción
• aprovecha el else del try-except para cuando las cosas van bien

Y el siguiente fisco de código es interesante si usas svn/cvs, para ponerlo después de la docstring del modulo:

__version__ = "$Revision: 63990 $"
# $Source$