Ya está disponible una nueva versión de Xailer 2 Beta en la cual hemos intentado subsanar todos los problemas econtrados (de momento) por el rediseño de los ‘Datacontrols’ y además incluimos un nuevo control TListView que había sido solicitado desde hace mucho tiempo.

Se han incuido varios ejemplos para demostrar la potencia del control TListView. Os dejo unas imagenes de los mismos:

No obstante, aún falta por realizar una mejor integración del control en el IDE y su documentación, que seguro estará para la próxima publicación de Xailer 2.

Podéis encontrar la nueva versión de Xailer 2 Beta en el siguiente enlace:

http://www.xailer.com/files/xailer20beta.exe

También podéis descargar la versión xHarbour, que no ha cambiado desde la anterior publicación, desde la siguiente dirección:

http://www.xailer.com/files/xharboursetup2.exe

Os recordamos que está versión de Xailer sólo está disponible para usuarios con suscripción activa. Leer el artículo Novedades de Xailer 2.0 para más información.

Un cordial saludo,

[El equipo de Xailer]

Un editor de propiedades es una extensión del IDE que permite manipular una propiedad publicada de un componente en tiempo de diseño y ofrece una manera sencilla de establecer y/o recuperar su valor, haciendo más cómoda la utilización y configuración de un componente.

Los editores de propiedades son una poderosa herramienta que puede marcar la diferencia entre un componente aceptable y uno realmente formidable. A través de ellos podremos dotarlos de nuevas características que van más allá de la simple validación del valor de las propiedades, pudiendo mostrar una lista de valores, acotar valores, mostrar formularios que permitan la asignación del valor de una o varias propiedades, etc.

Para introducir el valor de las propiedades en tiempo de diseño se utiliza el inspector de objetos, el cuál muestra una columna con el nombre de la propiedad y otra con el valor de dicha propiedad. Su uso es sencillo, se introduce un nuevo valor y listo. ¿Fácil, eh? Aunque externamente parece algo trivial, internamente, el inspector de objetos se comunica con los componentes usando sus editores de propiedades para obtener o fijar el valor, para informar de cómo se debe almacenar una propiedad, etc.

Editores estándar

Xailer incluye una serie de editores de propiedades por defecto que son suficiente para la mayoría de las propiedades con las que trabajamos habitualmente, pero también permite que creemos nuestros propios editores, derivemos de ellos y que incluso reemplacemos los que una determinada propiedad tiene por defecto.

PE_Color
PE_Icon
PE_Anchors
PE_Font
PE_Cursor
PE_Brush
PE_StringOrNil
PE_ExtendedString
PE_Picture
PE_StringList
PE_NumberList
PE_MultiList
PE_Control
PE_Component
PE_ImageList
PE_Menu
PE_Edit
PE_DataField
PE_BrowseFolder
PE_BrowseFile
PE_BrwRecSel
PE_ButtonBitmap
PE_Tooltip
PE_DbfField
PE_ADOConnect
PE_DataSourceTables
PE_DbfDataSetName
PE_WideString
PE_DbfDataSource
PE_SQLiteDataSource
PE_DataSourceCatalogs
PE_TreeView

El editor básico TPropertyEditor

Estos editores derivan de la clase básica TPropertyEditor que provee el interface para que cualquiera de ellos se comunique con el inspector de objetos y el IDE.

* DATA cProperty
Contiene el nombre de la propiedad inspeccionada

* DATA cType
Es el tipo de dato del valor actual de la propiedad

* DATA cDataType
Es el tipo de dato indicado en la cláusula AS … de la declaración de la propiedad

* DATA Value
El valor actual de la propiedad

* DATA cValue
Es el valor actual de la propiedad en formato cadena para mostrar en el inspector

* DATA Default
Es el valor por defecto para la propiedad (cláusula INIT de la declaración)

* DATA aValues
Es el array de valores para mostrar en un combo en el inspector. Es un array de dos dimensiones (nºelementos x 2 columnas), donde la primera columna es el valor de cadena a mostrar en el combo del inspector, y la segunda columna es el valor real que hay que asignar a la propiedad.

* DATA oObj
Contiene una instancia del objeto al que pertenece la propiedad

* DATA lRun
Indica si se muestra el botón “…” cuando la propiedad tiene el foco.

* DATA lExpand
Muestra el pequeño triángulo naranja en el inspector que sirve para abrir un formulario con un memo con el valor de la propiedad.

* METHOD DblClick( @Value )
Se ejecuta al hacer doble click en el inspector y recibe el valor actual de la propiedad por referencia. Si no se define este método, por defecto, llama a Run().

* METHOD Run( @Value )
Se encarga de mostrar el interface de usuario si la propiedad lo requiere y se ejecuta al pulsar el botón “…”. También recibe el valor actual de la propiedad por referencia. Debe devolver .T. para actualizar la propiedad y .F. para dejar su valor anterior.

* METHOD Get( oObj, nProperty )
Obtiene el valor asignado a la propiedad | del objeto y asigna el resto de las datas del editor de propiedades (cProperty, cType, Value, etc.). Siempre conviene llamar a Super:Get(…)

* METHOD Set( Value, nIndex )
Asigna el valor a la propiedad correspondiente del objeto inspeccionado. sólo tiene valor cuando en el inspector aparece un combo para cambiar el valor de la propiedad. Siempre conviene llamar a Super:Set(…)

* METHOD Load( cValue )
Asigna el valor de la propiedad a partir de la cadena leida desde el fichero .xfm

* METHOD Save( cPrefix, cSufix )
Devuelve la cadena que hay que guardar en el fichero .xfm a partir del valor de la propiedad

Escribir un editor de propiedades

Vamos a desarrollar nuestro primer editor de propiedades, que será editable sobre el propio inspector de objetos y también mostrará un formulario para cambiar el valod de la propiedad.

Los pasos necesarios para escribir un editor de propiedades son los siguientes:

* Crear una nueva clase que descienda de TPropertyEditor o de algún editor estándar.
* Desarrollar los métodos necesarios para dotar al editor de propiedades de la funcionalidad deseada.

Como norma general, se suele anteponer el prefijo PE_ a las clases que definen un editor de propiedades, por ejemplo: PE_MyColorEditor, aunque no es obligatorio.

Creando nuestro primer editor

Imaginemos que tenemos un componente con una propiedad que guarda una dirección de correo electrónico:

La opción más sencilla cuando definimos el componente sería dejarlo como está en el ejemplo pero deberíamos pensar en hacer la vida más fácil a quien vaya a usarlo, así que vamos a establecer un editor que haga una validación básica de la propiedad.

En la definición del editor establecemos lRun a .T. para indicar que la propiedad debe mostrar el botón de acción (los puntos “…”) y hacemos que se lance la misma acción al hacer doble click que al pulsar el botón de acción.

Este sencillo editor muestra un formulario con un TEdit para introducir la dirección de email y tres botones para validar la dirección y para Aceptar o Cancelar el formulario.

Tras cerrar el formulario, volvemos a comprobar si la dirección es correcta llamando a ::MailValidate() y sólo actualizamos la propiedad y devolvemos .T. en caso de que la validación sea correcta.

Sólo nos queda enlazar a nuestra propiedad con su nuevo editor, así que la declaramos:

En el ZIP adjunto se encuentran todos los fuente del componente de ejemplo y una DLL ya compilada para probarla en el IDE (ver post)

En este capítulo aprenderemos lo más básico para crear un nuevo componente, generar la DLL para el IDE y la librería estática (.LIB) para enlazar con las aplicaciones en las que queramos usarlo.

Lo primero que vamos a hacer es crear un nuevo proyecto, al que llamaremos MyFirstComponentDll, en la carpeta samples\MyFirstComponent.

Cuando el IDE muestre el formulario “Propiedades del proyecto”, seleccionaremos la opción DLL en “Tipo de proyecto” y haremos un pequeño cambio. En la opción carpetas, en la entrada Obj el IDE nos ofrecerá c:\xailer2\samples\MyFirstComponentDll\Obj como directorio por defecto, pero le añadiremos “Dll” a esta ruta, quedando c:\xailer2\samples\MyFirstComponentDll\ObjDll. Una vez hecho esto, aceptaremos el resto de opciones por defecto para continuar.

En estos dos pasos anteriores hemos generado el archivo de proyecto para construir la librería dinámica para el IDE. Lo siguiente será repetir estos pasos pero cambiando un par de cosas:

Creamos otro proyecto en el mismo directorio (esto es importante), donde hemos guardado el anterior, pero con otro nombre, esta vez le llamaremos “MyFirstComponent”.

Otra vez el IDE nos muestra el formulario “Propiedades del proyecto”, seleccionaremos la opción LIB en “Tipo de proyecto” y aceptamos.

Si los dos pasos anteriores se han completado correctamente, debemos tener dos archivos de proyecto “MyFirstComponentDll” y “MyFirstComponent” en la carpeta samples\MyFirstComponent.

Para no complicar demasiado este artículo, el componente que vamos a crear, TMyLabel, será un control derivado de TLabel y cuya única diferencia con la clase padre es que va a tener como color de fondo por defecto el blanco y no va a ser transparente.

Construir la librería

Una vez que ya tenemos el espacio de trabajo listo, podemos empezar con la definición del componente. Añadimos un nuevo módulo PRG (CTRL+N) y lo salvamos (CTRL+S) con el nombre MyLabel.prg

En este nuevo módulo desarrollamos la clase TMyLabel:

Compilamos (F9) y si todo ha ido bien, el IDE habrá construído MyFirstComponent.Lib en la carpeta del proyecto.

Construir la DLL

Para terminar de construir el componente, abrimos el proyecto MyFirstComponentDll que creamos al principio y con Proyecto->Añadir archivo al proyecto, añadimos el archivo MyLabel.prg con la definición de la clase.

Creamos un nuevo módulo PRG (CTRL+N) y lo salvamos (CTRL+S) con el nombre MyLabelDll.prg y le añadimos el código que se encargará de registrar el componente en el IDE:

En el caso de un proyecto que tenga más de un componente, la única diferencia es que será necesario llamar a RegisterComponent() tantas veces como necesitemos, por ejemplo: supongamos que tenemos un proyecto que contiene tres controles tal que TMyLabel, TMyEdit y TMyButton, registrarlos es tan sencillo como:

Por supuesto, recordando siempre que deberemos añadir al archivo de recursos una imagen por cada componente para identificarlos correctamente en la paleta del IDE.

Para completar la construcción del componente, necesitaremos una imagen que lo identifique en la paleta del IDE. Para ello abrimos el Gestor de recursos del menú Vista, pulsamos en el botón “Nuevo recurso” y aceptamos el nombre por defecto que nos ofrece el IDE.

Una vez creado el archivo de recursos, añadimos el bitmap que identificará al nuevo componente y cerramos el gestor de recursos.

Consideraciones

La función RegisterComponent() le indica al IDE el nombre de la paleta en la que colocar el componente, el nombre del bitmap, la tooltip que se mostrará al poner el puntero del ratón encima del componente y la función de clase que crea el componente y hay que llamarla siempre que queramos registrar un componente externo.

Como norma general, el nombre del procedimiento que registra el componente puede ser cualquiera, la única condición es que sea un INIT PROCEDURE.

Hay que recordar que el bitmap debe tener unas dimensiones de 24×24 para que se muestre correctamente en la paleta y en caso de que el componente no tenga ningún bitmap asociado, el IDE le asignará uno por defecto.

Es posible incluir información en el propio componente usando la opción Proyecto->Propiedades del proyecto->Versión. La información de número de versión, copyright, etc. que se introduzca será accesible luego desde el botón “Información…” del Gestor de componentes.

Una vez completados los pasos anteriores, compilamos (F9) el proyecto y se creará la DLL con el nuevo componente listo para ser usado desde el IDE.

Instalar el componente

Para utilizar el componente desde el IDE, seleccionamos la opción Componentes->Gestor de componentes del menú principal, pulsamos el botón “Añadir” y desde el cuadro de diálogo que se muestra, apuntamos a samples\MyFirstComponent para seleccionar la DLL que acabamos de construir.

Una vez que pulsemos en el botón Aceptar y comprobamos que la pestaña “Samples” ya tiene correctamente registrado el nuevo componente.

Utilizar el componente

En aquellos proyectos donde queramos utilizar el componente, deberemos informar al IDE para que enlace la librería con nuestra aplicación, así que abrimos el formulario “Propiedades del proyecto” y en la opción “Librerías” añadimos la librería que construimos al principio y que estará en samples\MyFirstComponent\MyFirstComponent.lib

Para probar el nuevo componente, creamos un nuevo formulario en un proyecto nuevo (o en uno de nuestros proyectos), seleccionamos la pestaña “Samples” de la paleta de componentes, pinchamos en el componente y lo soltamos en el formulario.

¡Funciona! Ahora habrá que probarlo también en tiempo de ejecución, así que F9 y …

Notas finales

Si se quiere hacer algún cambio en el código del componente y la DLL está cargada en el IDE, es importante no olvidar que antes de recompilar, hay que eliminarla con el Gestor de componentes, si no el enlazador nos dará un mensaje de error avisando que la DLL está siendo usada.

El ZIPadjunto incluye el proyecto completo para generar la librería y la DLL.

Los servicios web se han convertido en el principal modo de intercambio de  información entre aplicaciones independientemente de plataformas, sistemas operativos y lenguajes de programación. SOAP es uno de los protocolos sobre los que se realiza el intercambio de los datos y está basado en XML, de manera que la parte cliente interroga al servidor con un código XML en el formato adecuado y recibe la respuesta en otro XML. Para entender de qué estamos hablando veamos la estructura de una petición SOAP y su respuesta.

Llamada (request):

Respuesta (response):

Como se puede ver en los listados anteriores, tanto el request como el response constan de dos nodos XML, header y body. El que se utiliza habitualmente es el body (que yo he dejado en blanco pues no nos interesa en este momento) y es el que contendría tanto los parámetros que se envían al webservice en el request como los que devuelve en el response.

Enviando headers soap

En el caso que nos ocupa debía enviar determinados parámetros en el header y leer de allí los potenciales códigos de error si los hubiese habido. El envío, pese a ser una estructura en vez de un parámetro simple, fue sencillo, se define una clase con los parámetros adecuados y se le envía directamente. El motor de SOAP de PHP se encarga de la traducción. Veamos un caso práctico.

Como veis es bastante sencillo de entender. Al añadir una cabecera hay que indicarle el namespace al que pertenece para que el motor SOAP sepa como tratarla, se le da un nombre y el objeto que la contiene.

Con esto hemos solucionado la parte del envío de nuestras cabeceras SOAP y tendremos un request como indicábamos en el primer XML.

Recibiendo headers SOAP

Ahora resulta que el método de nuestro webservice nos responde con otras cabeceras que debemos saber interpretar según el XML de response del segundo listado. Pues tenemos un problema y muy gordo. No hay forma de obtener estas cabeceras, el motor SOAP de PHP sólo devuelve el body, nunca los headers.

Según el manual de PHP el método __soapCall del cliente SOAP permite definir un array en el que se devolverán estas cabeceras, pero no fui capaz de hacer funcionar la invocación de un método del webservice con esta sintaxis mientras que invocándolos directamente en el cliente (cómo la documentación indica que se puede hacer) sí que me funcionaba perfectamente. Es decir, la teoría dice que con el primer método puedo recibir las cabeceras pero no me funcionó mientras que el segundo me funcionaba pero no me devuelve las cabeceras ni hay ningún método para recuperarlas.

Tras pelearme mucho con las funciones SOAP e investigar todavía más no llegué a ninguna conclusión, es como si no le hubiese pasado a nadie, no encontré absolutamente nada útil. Sólo me quedaba una solución, hacer mi propia clase SOAP a partir de la original y procesar el XML del response a mano para obtener los datos que necesitaba. Dicho y hecho. Veamos la solución.

Primero creo mi propia clase de SOAP y compruebo si voy a poder hacer lo que quiero.

Parece que voy a tener suerte, si pruebo este nuevo cliente SOAP funciona perfectamente, pero además si compruebo el contenido de $response veo que contiene íntegramente el XML de la respuesta del webservice. Cómo veis lo único que cambia al instanciarlo es que le paso el nombre de la nueva clase. Buen comienzo, si juego bien mis cartas podré sacar las cabeceras en el método __doRequest .

Tratemos pues ese XML para obtener lo que buscamos. Gracias a las funciones DOM y XPATH de PHP será muy sencillo. Este es el resultado final de mi cliente SOAP con recuperación de cabeceras:

Problema solucionado y de manera bastante elegante. Si alguien sabe cómo conseguir las cabeceras sin montar todo este lio que me lo cuente por favor.

Linux + DVD Julio 2009

En el DVD adjunto:

# Ubuntu 9.04 Jaunty Jackalope
La última versión de la distribución Linux más popular
Versión 32 bit, bootable

# BackTrack
Distribución basada en Slax con más de 300 herramientas de seguridad
Versiones 3.0 (estable) y 4 beta

También podréis leer los siguientes artículos:

BackTrack
Herramienta perfecta para ethical hacking

Xprobe2
Técnicas de fingerprinting

Criptografía de curva elíptica
Aplicaciones básicas de la criptografía ECC a nivel de usuario

Programación en Gambas
Acceso a base de datos SQLite

Historia del Hacking
¿Quiénes fueron los primeros hackers?

Formularios Web
Creación, validación y filtros con MUUU

Seguridad en Linux
¿Cómo protegernos?

¡¡¡ CONCURSO !!!

Toma parte en nuestro concurso y gana el libro Hacking Ethico por Carlos Tori y otros…

http://www.lpmagazine.org/prt/view/pag-prin/issue/1050.html

Sólo he leído el índice así que no es que pueda decir si está bien o no, pero viniendo de quien viene, merece la pena echarle un vistazo.

Como curiosidad: Aparte del PDF, lo proporcionan en formatos de “libro electrónico” como epub y mobi. Los tiempos están cambiando.

Inversion of Control o IoC, es un principio de la ingeniería del software. Este patrón que se ha puesto de moda actualmente gracias a frameworks como Swiz. En este artículo veremos indagaremos un poco en todos estos conceptos usando Swiz como base para el estudio...

(more...)

Leyendo hoy la entrada sobre una entrevista al fundador de HOTorNOT en Pensamientos ágiles he recordado un libro de entrevistas a fundadores de empresa de tecnología que ley hace algún tiempo: Founders at Work

Es un libro que me gustó mucho y que recomiendo a cualquiera interesado en estos temas. En él se entrevista a muchísimos emprendedores, los fundadores de empresas como flickr, delicious, paypal, 37signals y así 33 entrevistas a cual más interesante.

Una cosa que me gustó mucho fue las distintas perspectivas que te ofrece toda esta gente: Ideas, escalabilidad, momentos bajos y altos, …

Se puede leer una buena parte del mismo en Google Books.

Eso sí, es un libro infeccioso. Leerlo y querer montarnos nuestra propia empresa, es todo uno :-)

He de decir que este libro no me ha sorprendido mucho, ya que en cuanto llevas algo de tiempo programando sobre Win32 y visitando la MSDN a menudo, te acabas conociendo las partes más utilizadas. Además, este libro es bastante antiguo (del 2004).

En general, no me convence la forma de explicar los temas por parte del autor, casi todos los capítulos se limita a copiar las diferentes funciones que se utilizan para hacer lo que sea, y a explicar cada uno de sus parámetros. Por lo que el libro se transforma en una especie de resumen de la MSDN.

De todo el contenido del libro me quedaría con los capítulos sobre los servicios de Windows y las estructuras de seguridad (SIDs, ACLs, ACEs) de Windows.

Aún así, puede servir como punto de partida para empezar a programar sobre Windows utilizando Win32, si no fuera por las pegas que he comentado.

Recomendación: Baja.
Nivel: Medio.
Idioma: Inglés.

Recordemos también que comienza la cuenta atrás para la llegada de Zend Framework 2.0

Muchos probablemente ya lo hayan visto, tiene su tiempo. Pero vale la pena verlo de nuevo, seguro con algo se sentirán identificados si trabajan en la industria del software. Abajo la traducción de los comentarios…

Los desarrolladores en todos lados están sufriendo un dolor terrible.

Siento dolor

Vamos 4 meses de un cronograma de 5 meses y acabo de recibir los requerimientos finales ayer (¡y cambiaron de nuevo!)

Paso la mitad de mis días en reuniones sobre cómo terminar mas trabajo (en vez de estar trabajando)

Mi jefe leyó en una revista que los desarrolladores que usan el lenguaje de programación “______” son dos veces más productivos. Así que nos compró una coopia y recortó nuestras fechas a la mitad.

Todos los días mi jefe cambia de parecer sobre lo que estamos construyendo.

La gente me sigue pidiendo que les arregle el e-mail, así que no tengo tiempo de escribir código.

Mi papá no tiene más tiempo para mí.

Un consultor le dijo a mi jefe que podían construir nuestra próxima versión en la mitad del tiempo, por la mitad del dinero. Él le creyó pero ahora se gastaron todo su presupuesto, usaron todo su tiempo y…
Apenas terminaron la mitad. Ahora se han ido y su código es un desastre. Tenemos que arreglarlo y terminar lo que comenzaron.

Abraza a un desarrollador hoy.

Y el último, gigante para los programadores de Visual Basic un

Acabo de terminar un curso intensivo de 6 semanas de Visual Basic.

El video fue creado por Devshop una aplicación hosteada de gestión de proyectos diseñada para planear proyectos de software específicamente.

A continuación la presentación sobre Flex + SEO que Gonzalo Pezzi y yo dimos es la última reunión de MIF en Barcelona con motivo del Adobe Global Tour 2009.

La presentación trata sobre como tener los mismos beneficios que ya disfrutábamos con webs HTML tradicionales aplicados a una web Flex. Es decir, que el contenido sea indexable por buscadores, enlaces de profundidad ha contenidos, que tengamos habilitados los botones del navegador para ir adelante o atrás por las páginas de la web Flex y otros temas adicionales como es el multidioma, por poner un ejemplo.

La presentación se basa en la nueva web de Codeoscopic donde se implementan todos estos conceptos y que todavía estamos terminando de completar pero que ya vuestra a nivel técnico todas estas posibilidades.

También y como se anunció al final de la charla, pretendemos hacer la base de esta plataforma Open Source de forma que Codeoscopic empiece a realizar aportes a la comunidad dentro del ámbito OS.

En esta cuarta versión de Flex se han producido cambios considerables en la arquitectura de componentes así como en el lenguaje MXML. Esto se ha hecho para potenciar varios aspectos como son la productividad, facilitar el workflow designer / developer o la integración con herramientas externas.
En esta entrada se hará una introducción a los espacios de nombres de Flex 4.

(more...)

Lanzamiento de la nueva Web del Juguy – www.juguy.org

Se lanza oficialmente la nueva página Web del Grupo de Usuarios – www.juguy.org

Ya se encuentra disponible y esperamos sus comentarios y críticas sobre la misma.

Mayor interacción
Esta nueva Web tiene como objetivo presentar el sitio mucho más simple y moderno, publicando noticias en forma más constante.

Mas eventos presenciales
Una nueva idea que el grupo promotor está encarando es la de generar mós y mejores eventos presenciales en distintos lugares como Universidades, Empresas, etc.
Pronto se publicará el calendario de eventos ya confirmados que tendremos en el 2009

Sitio del JUGUY renovado

El primero de estos eventos presenciales:

Evento – Web 2.0 en Java EE (frameworks y productividad)

Agenda

18:00 – Charla de presentación del evento
18:30 – Grails in action
Descripción: Grails es uno de los principales frameworks de desarrollo de aplicaciones Web en Java EE. Esta charla pretende presentar este framework ejemplificando y viendo casos prácticos.
Expositores: Ing. Alejandro Mateo, Ing. Pablo Kamil, Ing. Leandro Bertolami

19:30 – JBoss Seam + Richfaces + JGenUI
Descripción: Analizar Jboss Seam como framework de aplicación utiilizando un proyecto open source uruguayo para generar código sobre esta tecnología
Expositores: Ing. Horacio Vico, Lic. Rodolfo Vazquez

20:20 – JBoss Seam experiencia real. Medidas de productividad e integración
Expositores: Ing. Ariel Ludueña, Ing. Martin Cabrera

21:00 – Mesa redonda sobre tecnologías para la capa de presentación (GWT, Seam, Grails, Java FX, JSF)

¿Dónde y Cuándo?

Lugar: Aula Magna de la Universidad Catolica del Uruguay
Fecha: 30 de julio de 2009
Horario: de 18:00 a 21:30 horas.

Contacto

Correo: mailto:info@juguy.org
Sitio web JUGUY: – www.juguy.org

Al final he encontrado el tiempo para colgar las presentaciones y el codigo que utilizé para mis sesiones de MIF Onsite IV.

• Hello Gumbo
• Assert( Gumbo )

Cualquier duda no dudeis en preguntar.

Sin embargo, me inclino por utilizar un servidor de integración continua específico para PHP. Y es que estos aportan soporte específico para herramientas de PHP como phpUnit, phpDocumentor, etc… con lo que simplifica mucho la configuración y, sobre todo, la visualización de los resultados obtenidos (Front End). Como siempre, dentro del software libre, tenemos bastantes soluciones de calidad variable. Para mí destacan principalmente dos: Xinc y phpUnderControl.

phpUnderControl es una adaptación de Cruise Control a PHP. Cruise Control es el servidor de integración continua (originalmente para Java, pero ahora con versión para .NET, Ruby, etc.) con una comunidad de desarrolladores más grande y activa. Como consecuencia, tiene una enorme cantidad de documentación y de extensiones desarrolladas. Para funcionar, utiliza herramientas típicas de Java como Ant, etc. aunque a efectos prácticos, configurar un proyecto para utilizarlo con CruiseControl es escribir un XML.

Xinc significa Xinc is not CruiseControl. Como se puede ver por su propio nombre, nace como alternativa a phpUnderControl. Su idea es crear una herramienta más específica para el desarrollo en PHP, escrita en PHP y que, por ejemplo, utilice Phing (el Ant de PHP) en vez del propio Ant. A efectos prácticos, también supone escribir un XML. Una de sus ventajas es que no necesita Java, así que puede funcionar en un LAMP necesidad de instalar nada más. Su comunidad de desarrolladores es mucho menor que la de CruiseControl, pero también es más específica para PHP.

Finalmente, David y yo nos hemos inclinado por phpUnderControl, por varias razones:

• Más documentación y extensiones desarrolladas. He sufrido muchas veces la falta de documentación. Da igual lo potente que sea un framework, herramienta o servidor: si la documentación no es extensa y rica en detalles.. no sirve.
• Desde el momento en que nuestras pruebas funcionales van en Selenium,  ya necesitamos instalar Java… así que la posibilidad de utilizar un LAMP sin nada más desaparece.
• Aprendiendo Selenium y CruiseControl no solo aprendemos integración continua específica para PHP, sino que también obtenemos conocimientos aplicables a Java u otros lenguajes. Aprender Phing sólo es útil en PHP…

Sobre las charlas, opino como Abel Mendivil, se pueden agrupar en fuera de lugar, falta de profundidad y las que tenían fundamento.

Como suele ser habitual en estos eventos, los patrocinadores tenían charlas y algunas eran paja en un evento para programadores, o lo parecían, ya que el segundo día no fuí a ninguna de las que tenían esa pinta: la mesa redonda sobre open source, la de redes sociales, madridonrails… al menos para mi no son productivas. Otras me resultaron aburridas, un tanto básicas, y sobre todo en las que eran en inglés, desconectaba con facilidad. Por lo que, como ya he dicho, me pegué parte del segundo día trabajando en unas mesas fuera de las salas, que en algunos momentos casi se quedaban hasta pequeñas.

Pero también hubieron charlas interesantes:

• Las de Jorge Sánchez sobre ESB, que por no haber trabajado mucho en integración me resultaron curiosas.
• La -no- charla de Francisco Morero, donde nos pedía a los asistentes que comentásemos aplicaciones exóticas desarrolladas con Java, y se acabó regalando un iPod como premio :).
• La de Javier Ramírez acerca de JRuby on Rails, que aunque para mi no dijo nada nuevo, me gustó el enfoque que le dió a su charla de pasar un poco por Ruby, luego por Rails y finalmente ver como integrar con Java usando JRuby.
• La de Dave Currie acerca de escalabilidad con MySQL, donde tampoco se dijeron cosas especialmente novedosas que no haya escuchado ya en otros eventos, pero siempre es interesante ver las soluciones tomadas en un caso real concreto(también me resultó gracioso que usara el topicazo de que Ruby on Rails no escala XD).
• Desarrollo y test de componentes Ajax de Ignacio Coloma, sobre todo la parte de testing es la que más me gustó, y junto a la charla que dió el año pasado, tengo muy claro que sabe mucho de desarrollo web.

En cuanto a los talleres, el primer día asistí al de Spring 3.0 que impartía Sergi Almar, donde hubieron problemas de espacio en la sala, no habían suficientes tomas de corriente y los usuarios de Mac no pudimos seguir el taller por un problema de última hora, una pena que ante tantos problemas nos quedáramos sin tiempo para ver finalizar el taller completo, tal y como pasó el año anterior :S. El segundo día, fuí al de Grails que impartían conjuntamente Nacho Brito y Álvaro Sánchez-Mariscal, donde de nuevo nos quedamos sin concluir el taller completo, realmente había mucho que decir y el tiempo se terminó consumiendo :S.

Sobre el tema puramente organizativo, hubieron algunos detalles mejorables: Las salas estaban bien pero no habían enchufes, nada más llegar al campus Montepríncipe no había ningún cartel ni indicación, tampoco se nos dieron identificaciones a los asistentes y ponentes, la tarde del segundo días se cambió la sala de las charlas del track 1 y no se pudieron emitir por streaming…
Pero lo que más eché en falta fué más tiempo para charlar/saludar/conocer a otros asistentes y ponentes, que hubiera sido fácilmente solucionable “convocando” a quien quisiera a quedar en algún lugar a tomar unas cervezas(lo que los modernos llaman networking :P), cosa que sí pude hacer con unos pocos y a otros no pude más que saludarlos y poco más :S.

Como podéis ver, un poco de todo en el evento. Veremos si Sun/Oracle siguen celebrando un evento de estas características en España, y si lo hacen, esperemos que intenten organizarlo para que resulte más interesante.

La razón por la que utilizamos Google Docs y no la clásica pizarra de SCRUM es porque el equipo no se encuentra físicamente en el mismo sitio. Quizá en el futuro utilicemos herramientas más específicas para la gestión de las user stories, iteration backlog e increment … pero a día de hoy éste sistema nos está funcionando por lo sencillo y visual que es.

El objetivo de la gestión es planificar, ejecutar y controlar. Veamos a continuación cómo planificamos, ejecutamos y controlamos el valor funcional de la aplicación.

Algunos apuntes sobre la ejecución:

• El documento recoge tanto el Iteration Backlog como el Increment. Pero es un documento que sólo ve el equipo. El cliente puede ver el Product Backlog (que está en un documento a parte) y se le envía una versión “más redactada” del Increment.
• Cada iteración está en una tabla. Las tablas se guardan todas en el mismo documento, de tal manera que si vamos bajando por el documento podremos ver el backlog de las anteriores iteraciones. Las iteraciones se nombran con el primer día que se ejecutan (Iteración 18-05-2009) . Suelen ser de dos semanas.
• Todos los proyectos son gestionados desde el mismo Iteration Backlog.
• Marcamos la prioridad de una funcionalidad dentro de una iteración con [1],[2] y [3].
• Se puede saber en qué estado está una Iteración porque:
  • Si está a la izquierda y sólo pone la prioridad([1]), es que está sin empezar.
  • Si está a la izquierda pero pone la prioridad  y un dueño ([1][Luis]), es que está empezada y la está haciendo Luis.
  • Si está a la derecha, es que está terminada.
• En el incremento, además de los items terminados en la iteración, se añaden los unplanned items ([U]), defectos ([D]) y cuestiones técnicas abordadas ([T]). Supongo que para los defectos sería mucho mejor utilizar un Issue Tracker, pero normalmente los clientes suelen querer comunicarse solo por teléfono, y bastante cuesta ya hacerles escribir un mail… como para intentar que se peguen con un Issue Tracker…
• Los defectos tienen siempre prioridad sobre el desarrollo de nuevas funcionalidades.
• La trazabilidad del proyecto es enorme, no sólo porque así tenemos un histórico de todas las iteraciones, sino porque el Google Docs guarda versiones de cada cambio que se hace.. así que podríamos retrotraernos a cualquier situación pasada del documento.

Forma de detectar cómo va la iteración (controlar):

• Si se están generando muchos Unplanned Items ([U]) es que algo se diseñó mal.
• Si se están generando muchos Defectos ([D]) es que la aplicación no está suficientemente probada.
• Si se están atacando funcionalidades de prioridad [2] sin haber terminado las de prioridad [1], o se están atacando funcionalidades sin haber corregido los Defectos, probablemente se esté programando en el orden incorrecto.
• Otras cuestiones muy relacionadas con las funcionalidades, las iteraciones, sería el control de costes y plazos: lo voy a dejar fuera del artículo por no extenderme.

Algunos apuntes sobre planificación de las funcionalidades que se incluyen en cada iteración. En cada iteración se meten una serie de funcionalidades de el/los Product Backlog. Esas funcionalides cumplen que:

• Es la mayor cantidad de funcionalidades que se pueden hacer en dos semanas.
• Son las funcionalidades que más valor añaden a la aplicación.
• Camino crítico: desarrollar esas funcionalidades ayudan a descubrir posibles nuevos requisitos de forma lo más temprana posible (aunque no sea la que más valor añade), eliminar incertidumbres y hacer pensar al cliente (feedback) en qué es lo que quiere realmente. Esto también puede incluir desarrollar funcionalidades que ayuden a descubrir el diseño técnico (orientación a objetos, patrones de diseño) de la aplicación.
• La que el cliente exija (a veces no hay más remedio: hay que implementar funcionalidades que el cliente exija aunque se le argumente que no son las que más valor añaden o las que más ayudan a descubrir la forma exacta de la aplicación).
• Se evita programar funcionalides que no puedan probarse o ponerse en producción cuanto antes. Ejemplo: “Informe anual de ventas”, implementar éste informe en la primera iteración del producto, cuando todavía la empresa no ha introducido ni una sola venta, hará que no pueda probarse correctamente y traerá problemas meses después.
• Resolver defectos tiene más prioridad que desarrollar nuevas funcionalidades, aunque dependerá de la gravedad del defecto. Los defectos son difíciles de planificar porque no sabes ni cuando ni cómo saldrán.
• Es importante saber dividir o juntar funcionalidades para poder adaptarlas al tamaño de la iteración. No sirve para nada hacer “Listar facturas”, si no tienes un “añadir facturas”. Deberán ir en la misma iteración. Quizá “buscar facturas” pueda ir en la siguiente iteración, pese a que todo ello fuera planificado originalmente como “gestionar facturas (listar, añadir, modificar, eliminar, buscar)”.