La programación extrema o XP es una metodología de desarrollo que se englobaría dentro de las denominadas metodologías ágiles en la que se da máxima prioridad a la obtención de resultados y reduce la burocracia que se produce al utilizar otras ‘metodologías pesadas’.

Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.

Kent Beck.

El autor de la XP es Kent Beck, entre otros, que con su larga experiencia como programador eligió las mejores características de las metodologías y profundizó en las relaciones de éstas y como se reforzaban unas a otras. Por tanto, la XP no se basa en principios nuevos, sino que todas, o casi todas, sus características ya se conocen dentro de la ingeniería del software, las cuales se complementan para minimizar los típicos problemas que pueden surgir en todo desarrollo de proyectos software.

Objetivos de la programación extrema

El objetivo principal de la XP es la satisfacción del cliente. Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto. Como metodología ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.

Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.

Valores de la programación extrema

Para garantizar el éxito de un proyecto, los autores de XP han considerado como fundamentales cuatro valores:

• Comunicación. Muy importante. La XP ayuda mediante sus prácticas a la comunicación entre los integrantes del grupo de trabajo: jefes de proyecto, clientes y desarrolladores.
• Sencillez. Los programas deben ser los más sencillos posibles y tener la funcionalidad necesaria que se indican en los requisitos. No hay que añadir algo que no se necesite hoy. Si se necesita añadir más funcionalidad mañana pues ya se hará entonces.
• Retroalimentación. Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema.
• Valentía. Asumir retos, ser valientes ante los problemas y afrontarlos. El intentar mejorar algo que ya funciona. Aunque gracias a las pruebas unitarias no existe el riesgo de ‘meter la pata’.

Algunas voces, añaden además un quinto valor: la humildad. Con la compartición de código, la refactorización y el trabajo de equipo tan estrecho una buena dosis de humildad siempre es de agradecer.

Prácticas de la programación extrema

12 son las prácticas de la XP:

• El juego de la planificación (the planning game). Es un permanente diálogo entre las partes empresarial (deseable) y técnica (posible).
• Pequeñas entregas (small releases). Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media característica y lanzar la versión.
  Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.
• Metáfora (metaphor). Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas “Programa de gestión de compras, ventas, con gestión de cartera y almacén”. Las metáforas ayudan a cualquier persona a entender el objeto del programa.
• Diseño sencillo (simple design). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.
• Pruebas (testing). No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
• Refactorización (refactoring). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.
• Programación por parejas (pair programming). Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca?
  El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera.
• Propiedad colectiva (collective ownership). Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. Si hacemos el código propietario, y necesitamos de su autor para
  que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.
• Integración continua (continuos integration). El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%.
• 40 horas semanales (40-hour week). Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar
  en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.
• Cliente en casa (on-site costumer). Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.
• Estándares de codificación (coding standards). Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.

Algunas de estas prácticas reciben muchas críticas, sobre todo la programación por parejas. Muchos jefes de proyecto no aceptan que dos desarrolladores tengan un único ordenador, ya que creen que esto minimizará la productividad, sin saber que de este modo puede producirse el mismo código que dos personas trabajando en solitario pero con un código de mayor calidad.

Se dice que si no se realizan estas doce prácticas no se está realizando XP. Yo, a mi modo de verlo, creo que nosotros no tenemos que adaptarnos a ninguna metodología, sino que ellas se tienen que adaptar a nosotros dependiendo del tipo de proyecto que estemos desarrollando.

Bueno, esta ha sido una ‘breve’ introducción a la programación extrema. Seguro que algunas de las prácticas que se han visto anteriormente la has utilizado. Como dije al principio, la XP es más una filosofía de trabajo que recoge lo mejor de las distintas metodologías y las junta para que se refuercen unas a otras.

En ActionScript 2.0 teníamos la clase Number para manejar números, tanto enteros como reales. Ahora en AS 3 seguimos manteniendo la clase Number pero se han añadido 2 nuevos tipos de datos: int y uint.

Si utilizamos números enteros que se encuentren dentro del rango que tienen estos dos tipos de datos es mejor usarlos al tipo Number ya que es más rápido y eficaz.

Una breve descripción de estos tipos de datos:

• int. Entero con signo de 32 bits.
  • Valor predeterminado: 0.
  • Valor mínimo: -2147483648
    Código
    Actionscript:

    1. trace(int.MIN_VALUE);  // output: -2147483648

  • Valor máximo: 2147483647
    Código
    Actionscript:

    1. trace(int.MAX_VALUE);  // output: 2147483647

• uint. Entero sin signo de 32 bits.
  • Valor predeterminado: 0.
  • Valor mínimo: 0
    Código
    Actionscript:

    1. trace(uint.MIN_VALUE);  // output: 0

  • Valor máximo: 4294967295
    Código
    Actionscript:

    1. trace(uint.MIN_VALUE);  // output: 4294967295

Cuando se declara e inicializa una variable de tipo int o uint se puede hacer de dos formas: con un literal o utilizando el operador new. Las dos líneas siguientes son equivalentes:

Después de pasarme un mes sin escribir en el blog ya estoy de vuelta para escribir más a menudo, o eso espero...

En los meses siguientes se avecinan bastantes cambios en mi vida, tanto profesional como personal. Nuevos retos y proyectos que se esperan con ilusión y con muchas ganas de afrontarlos.

Bueno, espero que los que hayan tenido vacaciones hayan descansado bien y se lo hayan pasado mejor y, los que no las tuvieron, PSJ

¡Nos leemos!

Hoy me he encontrado en la documentación de Adobe una página donde se muestran todas las diferencias que existen entre AS 2.0 y AS 3.0. Un documento directo para mis marcadores y un buen punto de partida para ir aprendiendo AS3 si ya conocía algo de la versión anterior.

En ActionScript 3.0 todas las clases deben ser colocadas en paquetes. Un paquete (o package) es una manera de organizar clases en grupos, y en ActionScript 3.0 un paquete es sinónimo a un directorio del sistema de archivos. Los paquetes se ordenan relativamente al classpath, el cual es definido como una ruta relativa al proyecto (el archivo .fla en el caso de Flash). Por lo tanto, el paquete top-level es sinónimo de la raiz del proyecto. La declaración del paquete es siempre la primera sentencia que aparece en un fichero de claso; un ejemplo de su sintaxis en la que sigue:

Cuando la clase es definida como parte del paquete top-level, el nombre del paquete no necesita ser especificado. En estos casos, la declaración del paquete es la siguiente:

Cuando el archivo de clase es guardado dentro de un subdirectorio, el nombre del paquete se corresponde con la ruta relativa del subdirectorio usando puntos (.) entre cada directorio. Por ejemplo, si es archivo es guardado en un subdirectorio (relativo a la raiz del proyecto) llamado example, entonces la declaración del paquete es:

ISi el archivo de clase es guardado en un subdirectorio de example llamado subpackage, la declaración del paquete será:

Los paquetes son una parte importante en el trabajo con clases porque permiten aseguarte que tus clases no entrarán en conflicto con otras clases. Por ejemplo, es posible que dos desarrolladores escribieran dos clases diferentes y las nombraran MessageManager. Las dos clases tendrían el mismo nombre pero se utilizarían para diferentes tares. Una administraría emails mientras que la otra administraría mensajes binarios de sockets. No puedes tener dos clases con el mismo nombre en el mismo ámbito. Si lo tuvieras, el compilador no sabría cual de ellas usar. Una opción es usar siempre nombres de clases únicos.

En este ejemplo, podrías nombrar las clases EmailManager y BinarySocket, pero hay buenas razones por lo que esto no siempre es posible. Como que un proyecto podría usar potencialmente ciendos de clases, esto dificultaría mucho el asegurar nombres únicos a las clases. Además, muchos proyectos utilizan librerías de código ya escritas, y no podrías modificar mucho de estas clases. Ya que muchas clases de la librería tendrían dependencias con otras clases, sería muy difícil modificar el nombre de estas clases. Ahí es donde los paquetes hace las cosas más sencillas. Piensa que no puedes tener dos clases con el mismo nombre en el mismo directorio, pero puedes tener tantas clases con el mismo nombre como quieres, si éstas se encuentran en diferentes directorios. Los paquetes te permiten colocar un MessageManager en el paquete net.messaging.email y el otro en el paquete net.messaging.binarysocket.

Aunque los nombres de paquetes anteriores serían inicialmente unas buenas opciones, es posible usar un nombre de paquete mejor para asegurar una probabilidad mayor de unicidad. Generalmente es mejor usar nombres de paquetes que se correspondan con el autor y/o un proyecto relevante. Por convención, los nombres de paquete empiezan con nombres de dominio en orden inverso. Por ejemplo, si yo (davidvalverde.com) escribo clases en ActionScript 3.0, guardaría todas las clases en el paquete com.davidvalverde (o un subpaquete de com.davidvalverde). De esta manera, me aseguro de la unicidad de los nombres de las clases (no creo que nadie más que yo use el paquete com.davidvalverde para organizar sus clases XD ).

Cuando las clases forman parte de una libería común usada para muchos proyectos dentro de la compañía/organización entonces pueden ser colocadas en subpaquetes directamente dentro del paquete principal. Por ejemplo, si las clases anteriormente mencionadas MessageManager forman parte de una libería común usada por muchas aplicaciones que yo desarrolle, entonces deberían guardarse en los paquetes com.davidvalverde.net.messaging.email y com.davidvalverde.net.messaging.binarysocket. Cuando una clase forma parte de una aplicación específica, debería guardarse dentro de un subpaquete específico de esa aplicación. Por ejemplo, tengo una aplicación llamada WidgetStore. Si la aplicación WidgetStore usa una clase llamada ApplicationManager, entonces esta debería ser guardada dentro de com.davidvalverde.widgetstore o un subpaquete de este paquete.

Por cierto, por convención los nombres de los paquetes empiezan siempre con letra minúscula.

Los archivos de clase siempre son guardados en la ruta de directorios que se corresponde con el paquete de la clase. Por ejemplo, com.davidvalverde.net.messaging.email.MessageManager debe ser guardado en com/davidvalverde/net/messaging/email/MessageManager.as. El compilador sabe buscar clases dentro de la ruta que indica el paquete. Sin embargo, el compilador tambien debe conocer donde buscar el directorio top-level que contiene los subdirectorios. En el ejemplo, el compilador necesita saber donde se encuentra el directorio com dentro del sistema. El compilador sabe donde buscar por algo llamado classpath. El classpath por defecto para cualquier proyecto Fles o Flash incluye el directorio del proyecto. Por ejemplo, el directorio com es guardado en el mismo directorio que el archivo .fla (Flash), entonces el compilador encontrará las clases. Sin embargo, podrías querer guardar los ficheros en un directorio diferente. Por ejemplo, si tienes una librería común usada por muchos proyectos, seguro que querías guardar esa librería en un lugar mejor que estar copiándola para cada proyecto. Puedes añadir y editar el classpath para que el compilador conozca donde buscar todas tus clases.

En Flash, puedes editar el classpath tanto a nivel de proyecto como globalmente. A nivel de proyecto, selecciona Archivo>Configuración de publicación, y selecciona el botón Configuración... de ActionScript en la pestaña Flash. Para el classpath global, selecciona Edición>Preferencias, y selecciona el botón Configuración... de ActionScript. Ambos abren una ventana de diálogo similar que te permite editar el classpath. Tu puedes seleccionar el botón + para añadir un nuevo directorio al classpath. Por ejemplo, si el directorio com para la librería está guardado en c:\libraries, entonces deberías añadir c:\libraries al classpath.

Una CheatSheet es una especie de 'chuleta' donde vienen recogidas la mayoría de las funciones de un lenguaje. Viene bien para recordar la sintaxis del lenguaje, parámetros de las funciones y palabras clave. Y sirve tanto para gente que está aprendiendo como para gente que ya tiene años de experiencia en el lenguaje (que siempre se olvida algo XD ).

Como estoy aprendiendo ActionScript 3.0, aquí tenemos la AS3 CheatSheet, 3 páginas con las clases y métodos del lenguaje, operadores y palabras clave.

Normalmente, cuando se aprende un lenguaje nuevo, lo primero que se hace es implementar un "Hola mundo"; esto es, mostrar un mensaje por pantalla. Con esta sencilla aplicación se puede empezar a conocer la sintaxis del nuevo lenguaje y a familiarizarse con él.

En nuestro intento por aprender ActionScript 3.0 vamos a desarrollar nuestro primer programa con un "Hola mundo".

En primer lugar crearemos una carpeta o directorio donde guardaremos nuestro proyecto y le daremos un nombre, en mi caso "AprendiendoAS3".

Abrimos Flash CS3 y le indicamos que queremos crear un nuevo archivo ActionScript 3.0. Y ponemos el siguiente código:

Y lo guardamos con el nombre "HiWorld" en nuestra carpeta de trabajo. Analicemos el código que hemos puesto:

• En ActionScript 3.0 todas las clases deben encontrarse en paquetes (o packages). Un paquete es una forma de organización de clases y en AS3, al igual que en otros lenguajes, se corresponde con directorios en el sistema de ficheros. La sintaxis de un paquete es:
  Código
  Actionscript:

  1. package name {
  2. }

  Si no vamos a guardar nuestra clase en un subdirectorio podemos omitir el nombre, tal como hemos hecho en el ejemplo de más arriba. Si queremos organizar las clases con una jerarquía de subdirectorios, cada nombre de paquete podemos separarlo con un "." (punto).

  Código
  Actionscript:

  1. package com.davidvalverde.examples {
  2. }

• La segunda línea declara la clase a implementar. Por conveniencia, el nombre de las clases debería empezar por letra mayúscula y debe seguir las mismas reglas de nombrado que las variables y funciones (pueden ponerse letras, números y guiones bajos "_", y no pueden empezar con un número). La palabra "class" es una palabra reservada del lenguaje que indica que se va a declarar una clase. El modificador "public" indica que la clase descrita es pública para todo el mundo (mira la ayuda para ver los distintos modificadores posibles).
• Con la tercera línea declaramos un método de la clase, en este caso un método constructor que será ejecutado siempre que creemos una instancia de la clase.
• La cuarta línea muestra en pantalla (en la ventana de resultados) el mensaje "Hola mundo".

Ya tenemos creada nuestra clase. Ahora hay que crear un archivo .fla desde donde instanciaremos la clase HiWorld. Para ello, vamos a Archivo >> Nuevo y elegimos Archivo de Flash (ActionScript 3.0). Y aquí ponemos en la ventana de Acciones (F9 para que aparezca sino está visible) el siguiente código:

La sentencia import sirve para importar las clases que se van a utilizar en el proyecto. Se debe de poner la ruta de los packages para encontrar la clase. En nuestro ejemplo, como no le dimos nombre al paquete sólo hay que poner el nombre de la clase, pero en otro caso habría que poner la ruta:

Si se quisieran importar todas las clases de un paquete, en vez de tener una sentencia import por cada clase del paquete podríamos utilizar:

Bien, una vez hemos importado nuestra clase, llega el momento de instanciarla. Para ello tenemos el operador new, que nos devuelve una instancia de la clase elegida (en este caso, HiWorld). En la segunda línea del código hemos declarado una variable (con la palabra reservada var) con el nombre hw1 que es del tipo HiWorld y le asignamos la instancia que hemos creado con el operador new.

Ahora sólo queda pulsar Ctrl+Intro y veremos en la ventana de resultados como aparece el mensaje "Hola mundo". Ya hemos creado nuestra primera aplicación en ActionScript 3.0 ^^

El primer paso que hay que hacer es instalar Flash. Puedes descargarte un Trial de Flash para 30 días desde las páginas de Adobe. Elige el producto que quieras y dale a descargar. Tardará un poco porque son unos 400 MBs.

Una vez se haya descargado, ejecuta el instalador para que se descompriman los archivos. Una vez realizada esta operación puedes proceder a realizar la instalación de Flash. Después de un buen rato, tendrás Flash CS3 listo para usar.

La primera vez que entres en Flash CS3 te pedirá que introduzcas un número de serie (si lo tienes) o elijas la opción de probar Flash CS3 Professional de manera gratuita durante 30 días. Elige la segunda opción y aparecerá la interface de Flash CS3: