Archivo por meses: marzo 2008

Ajax vs. Flex

O Flex vs. Ajax. O Silverlight. O JavaFX. Menudo debate. A muchos no les gustará y sé que generará mucha controversia. Yo hablaré de Flex pues es el que conozco, pero podríais hacer la misma comparación con los otros dos.

Para el que a estas alturas no lo sepa, FLEX es la tecnología Flash orientada a programadores. Tradicionalmente Flash ha sido una herramienta de animación y diseño, la que conoces de toda la vida. Después de un primer intento más o menos fallido con Flex1 y 1.5, Adobe, tras adquirir Macromedia, decidió reorientar el rumbo, construyendo algo auténticamente revolucionario con Flex2. Las secuelas, además de Flex3, han sido AIR (para aplicaciones de escritorio) y próximamente Thermo (diseño de R.I.A.). Con Flex2 han conseguido crear una herramienta para la construcción de interfaces de usuario en Flash.

No cabe duda que las R.I.A. están de moda. Da igual la tecnología utilizada, cada día aumentan las aplicaciones online. Desde sistemas operativos online hasta aplicaciones de edición de fotografías o vídeos pasando por aplicaciones corporativas de gestión de cualquier tipo.

Pero ¿qué es mejor para construirlas? La respuesta es sencilla: depende de para qué. No me sirven argumentos sobre plugins (¿Javascript funciona en Lynx?) o software libre vs. privativo (¿acaso al usuario habitual le importa o sabe lo que es?) o SEO (¿Javascript es search engine friendly?). Hablemos mejor de utilidad y de conveniencia para el desarrollador y el usuario.

Lo primero que deberíamos preguntarnos es

¿Qué voy a hacer?

No es lo mismo hacer una web o una aplicación que va a utilizar mucha gente que hacer una aplicación de gestión para una empresa de seguros o un banco. ¿Alguien se imagina a una aseguradora haciendo su software de gestión en Javascript? Pero sí en Flex como de hecho están haciendo ya. Por otro lado a nadie se le ocurriría hacer una web en Flex, no tiene sentido, no es su cometido. Pero sí que harías una aplicación como la de Flickr para editar fotografías online o la de Youtube para hacer montajes de vídeo. O pequeños módulos concretos que no podrías hacer de otro modo o que te costaría demasiado, o widgets varios como está haciendo mucha gente utilizando feeds, mapas, etc. Este creo que sería el punto clave diferenciador. Con Ajax hacemos complementos para aplicaciones web o pequeñas aplicaciones, con Flex hacemos aplicaciones completas. Lógicamente estoy generalizando y cada uno puede pensar y hacer lo que quiera, hay aplicaciones completas realizadas 100% en Javascript, no hay ningun inconveniente, para ejemplo EyeOS. ¿Por qué opino esto entonces? Sencillo, por una simple cuestión de ingeniería del software y productividad. Flex es un lenguaje orientado a objetos 100% y con todas las ventajas que aporta. Crear interfaces de usuario con Flex es impresionantemente sencillo. ¿Alguien puede decir lo mismo de Javascript? Que se puede hacer es indudable, pero a costa de convertir la aplicación en una auténtica telaraña de Javascript‘s. ¿Qué ocurrirá cuando otro programador deba tomar esa aplicación y modificarla? Cualquiera que haya hecho lo más mínimo en Ajax sabe que es una locura. No hay un patrón MVC y la interacción con la interfaz de usuario (html) es harto difícil, innerHTML está muy bien y es muy rápido, pero siendo puristas deberíamos utilizar DOM, a medio plazo lo agradeceremos, y sino intenta modificar atributos de código insertado con innerHTML :P.

Mejor aún, encontremos un responsable de proyectos, director técnico o el cargo que se os ocurra que se comprometa a realizar un proyecto medianamente importante en Ajax. Si conoce Flex verá las similitudes con Java, de hecho se hizo con Java en mente. Si no lo conoce pensará directamente en Java, difícilmente se le ocurriría pensar en Ajax, su cuello es el que está en juego en definitiva.

¿Para qué hemos utilizado nosotros Flex?

Hemos hecho widgets de distintos tipos, paneles de control y gestión, aplicaciones de audio/vídeo multiusuario (chat, audio-chat y vídeo-chat). Ahora mismo trabajamos en un cliente IRC en colaboración con una de las principales redes de IRC.

En backoffices y otros paneles administrativos hemos comprobado que para el usuario la comprensión y utilización de la aplicación es muy superior a interfaces html puesto que son más parecidas a una aplicación de escritorio tradicional y tienen más interactividad, algo que el usuario agradece.

En artículos posteriores os expondré algunos ejemplos de cosas que hemos ido haciendo a lo largo de los dos últimos años, aunque también veremos cosas en Ajax, no son tecnologías excluyentes.

Añadir que Flex ya es de código abierto, el SDK es libre y hay un excelente plugin para Eclipse. Lo único que es de pago es el Flex Builder de Adobe, la aplicación oficial, pero puedes hacer tus aplicaciones con el plugin de Eclipse del mismo modo.

Por cierto, Adobe no me paga nada por este post :P.

¿Por qué nos siguen enseñando gestión de proyectos en cascada?

Cada día que pasa lo entiendo menos. Cualquiera que haya participado en algún proyecto de software, da igual el tamaño del mismo, se habrá dado cuenta que los patrones a seguir que nos enseñan a todos en las asignaturas de ingeniería del software y gestión de proyectos ya no tienen sentido. De hecho hace mucho tiempo que dejaron de tenerlo. Toma de requisitos, análisis, desarrollo, pruebas, implantación… Y cuando los usuarios finales comienzan a utilizarlo te das cuenta de que la usabilidad es nula (no es lo mismo como piensan los técnicos que los usuarios finales), faltan funcionalidades básicas, determinados procedimientos cotidianos se han complicado tanto que el trabajo diario se alarga… ¿Solución? O bien se aumenta el presupuesto para contemplar las modificaciones (suele ocurrir con las administraciones públicas) o bien el cliente no te paga hasta que el software funcione como él y sus empleados necesitan, con lo cual tu estimación de tiempo/recursos se ha quedado corta y empiezas a perder dinero sobre el plan inicial.

¿Por qué ocurre esto? Sencillo, por que es muy difícil contemplar todas las necesidades del cliente en la fase inicial del proyecto. Pensar que con las notas que se toman durante esas semanas va a ser suficiente lleva a ocultar las potenciales carencias. Sí, hablas con el personal de tu cliente, ves como trabajan, te lo apuntas todo. Pero tú no eres el que trabajará con la aplicación, son ellos, pero vas a plantear el proyecto desde tu punto de vista, no desde el del cliente. Cuando les enseñas el producto aparecen los problemas.

¿Y si, en vez de eso, implantas en tu equipo de desarrollo técnicas de desarrollo ágil? Podríamos decir que sería un método de desarrollo orientado a producto, periódicamente se liberan versiones funcionales del software, con más o menos funcionalidades, pero que funcionan y permiten al cliente toquetear y jugar con su compra.

El ejemplo más evidente lo tenemos en el desarrollo de webs. Cualquiera que haya trabajado en ese campo se habrá topado con el momento en que el cliente empieza a ver lo que hay hecho (es una web, puede verla en cualquier momento ¿no?) y comienza a pedir cambios y a decir cosas que no le gustan. Para nosotros, que tenemos nuestra idea clara del desarrollo lineal, que sabemos que teníamos tres meses para hacer el desarrollo y vamos a cumplir ese plazo, comienzan los problemas. Pierdes la línea de tus planes y comienzas a centrarte en lo que el cliente ha dicho al ver cosas, en cambios, en errores, olvidándote de todo lo planificado que te queda por hacer porque mañana volverá a ver la web y querrá ver los cambios solicitados, tu mente en cascada no es capaz de verlo de otro modo.

En vez de eso vamos planteando pequeños desarrollos cada tres o cuatro semanas. Cada periodo se presenta algo nuevo que funciona, es decir, comenzamos por una pequeña porción del sistema, siempre funcional, y la vamos aumentando poco a poco en periodos posteriores teniendo siempre en cuenta los errores detectados y las impresiones del cliente, sin olvidarse de las funcionalidades pendientes. Estaríamos, por tanto, ante un desarrollo adaptativo en función de las necesidades que se van viendo sobre la marcha. Por esta misma razón comenzamos a tirar líneas de código mucho antes que en los procesos tradicionales ya que apenas nos preocupamos por concretar todos los detalles al inicio, lo vamos haciendo sobre la marcha y con una idea inicial bastante general es suficiente. El objetivo es algo siempre complicado, que el cliente se implique en el proyecto y aporte continuamente su feedback.

Puedes comenzar con el Manifiesto ágil y buscar documentación y bibliografía sobre desarrollo ágil y SCRUM (una de las técnicas más utilizadas). Ya de paso no estaría de más echar un vistazo a Xtreme Programing (no, no es trabajar 15 horas diarias).

A los desarrolladores, en general, nos cuesta mucho asimilar los conceptos ágiles. Nos enseñaron a ser mecánicos en los procedimientos de desarrollo de software y este tipo de técnicas se basan más en ir sobre la marcha, y cuidado, esto no significa ni mucho menos que sin planificación, al contrario. La primera pregunta del director de proyectos la primera vez que oye hablar de desarrollo ágil será: bueno, pero así ¿cómo hago las estimación del tiempo necesario? Pues igual que lo hacías hasta ahora, estamos proponiendo nuevas técnicas de desarrollo, pero la estimación tienes que seguir haciéndola igual: piensa en las tareas que hay que hacer y estima el tiempo necesario para realizarlas, compáralo con la cantidad de recursos (personas) de tu equipo y obtén las estimación, o mejor aún, ya que hablamos de técnicas ágiles, deja que sea el propio equipo el que estime la duración de las tareas, a fin de cuentas son los que las van a hacer.

Subversion, ese gran desconocido

Equipos de varias personas, proyectos sin fecha de finalización, corrección de bugs, nuevas funcionalidades… ¿cómo gestionáis todos esos cambios?

Me resulta difícil de creer, por no decir incomprensible, que, en la época en que vivimos, la inmensa mayoría de empresas de desarrollo de software no utilicen un mínimo sistema de control de versiones (CVS, Subversion, Sourcesafe…). Y no hablamos sólo de pymes, hablamos también de grandes consultoras con grandes proyectos de las administraciones públicas. Y es que no hay mejor cara que aquella que se te queda cuando haces update y te contesta file merged. O mejor aún, cuando has metido la pata hasta el fondo y recurres al superhéroe de la película, a revert.

Algunos pensarán, cuando hablamos de desarrollo de software, que hablamos de grandes aplicaciones o proyectos, pero están equivocados, hablamos de cualquier cosa que se programe, incluida una web.

Subversion es lo que se conoce como un sistema de control de versiones (del inglés Control Version System). Control de versiones es la gestión de los cambios y modificaciones en el código fuente de un proyecto, es decir, cada cambio que se hace en el código queda registrado de manera que en cualquier momento se puede saber quién hizo qué. Pero eso no es todo. ¿Qué ocurre cuando dos o más programadores trabajan sobre la misma aplicación y sobre los mismos ficheros de código? En un escenario normal no podrían. Uno tendría que esperar a que terminase otro para obtener la última versión, hacer sus modificaciones y pasárselo al siguiente. Obviamente eso no es ni óptimo ni deseable, tendríamos programadores esperando para poder trabajar. Subversion soluciona esto permitiendo que varios programadores trabajen sobre el mismo proyecto simultáneamente. Llegado el momento de unir todas las piezas, él lo hace por ti, es lo que se conoce como merge.

¿Qué ocurre cuando el cliente solicita cambios en tu proyecto y, cuando lo tienes terminado, da marcha atrás y prefiere que todo vuelva a estar como antes? Como no has hecho copia de seguridad del código en el estado anterior tendrías que volver a rehacer tu código para quitar lo nuevo y ajustar lo anterior. Con Subversion es tan sencillo como recuperar la versión anterior.

Lo más sorprendente es buscar gente para tu equipo de desarrollo y encontrarte con que a ninguno les suena ni CVS, ni Subversion ni nada similar. ¿Tan poco profesionalizado está el sector? Dá igual los estudios, nadie sabe lo que es y siempre les cuesta adoptar el cambio de filosofía ftp/Subversion.

Lo mejor de todo es que hoy en día no tienes que saber ningún comando manual, está todo automatizado. Eclipse tiene integración plena con Subversion, de manera que hacer commit, update o cualquier otra cosa son unos simples clicks de ratón. Pero eso no es todo, con TortoiseSVN tendremos integración plena con el explorador de archivos de Windows. De un vistazo podrás ver qué archivos has modificado, cuales están sincronizados, etc…

¿Aún no ves las ventajas?

Calendario Multirango en Flex2

Hace algo más de un año trabajábamos en un proyecto que consistía en una aplicación de gestión de reservas para una cadena de hoteles. Una de las opciones necesarias era el mantenimiento de las temporadas de cada hotel, es decir, las tarifas. Aunque pueda parecer algo sencillo y sin importancia, en realidad dista bastante del clásico alta/media/baja. De hecho ni siquiera es algo que permanezca inalterado a lo largo del año, sino que, en función de la demanda y disponibilidad de habitaciones, el propio hotel va modificando las temporadas en función de sus necesidades. La gestión de temporadas se realiza manualmente día a día y para cada uno de los hoteles de la cadena y cambia cada año. Necesitábamos, por tanto, desarrollar un sistema que permitiese administrar las temporadas de manera rápida y sencilla.

La solución que se nos ocurrió fue crear un calendario anual completo, doce DateChooser, uno por cada mes del año, y permitir al administrador configurar en un solo paso el año entero de temporadas. Simplemente seleccionando la temporada que se va a configurar y haciendo click en los días de cada DateChooser se van marcando de un color distinto para cada temporada. Como podéis ver en el ejemplo, es muy sencillo cambiar de temporada los días, seleccionamos otra tarifa y hacemos click en el día que queremos modificar. Es casi tan sencillo cambiar un día como un mes completo.

El problema llegó con el DateChooser puesto que, por defecto, sólo permite seleccionar un día o rango de días, pero siempre marcándolos en el mismo color. Nosotros necesitábamos que de un vistazo el administrador supiese la configuración de las temporadas de su hotel, necesitábamos un código de colores para los fondos de los días, en los números sería poco visual. La solución parte de un componente desarrollado para Flex1.5 hace bastante y que su autor no llegó a portar a Flex2, algo que hicimos nosotros con algunas modificaciones.

Extendiendo el DateChooser

El efecto que queríamos conseguir era colorear el fondo cada día del calendario en función de la tarifa adjudicada, de manera que con un rápido vistazo se tenía claro qué es cada uno.

Lo primero que necesitábamos en nuestro caso particular era ocultar las flechas de navegación de meses, puesto que sólo íbamos a utilizar un mes de cada DateChooser dejando la navegación por años. Por defecto no hay forma de hacerlo ya que estos botones se han definido en mx_internal, así que hemos de recurrir a:

this.mx_internal::fwdMonthButton.visible=false;
this.mx_internal::backMonthButton.visible=false;

En nuestro componente está por defecto, vosotros tendríais que eliminar esas líneas o, mejor, crear un método publico que permita quitarlos.

A continuación definimos el método que haremos público para colorear los días. Como véis en el código, los parámetros son un array con los días a marcar y el color de fondo que le vamos a dar. Tuvimos que implementar un callLater ya que nuestra aplicación, al iniciarse, carga del servidor las temporadas del año en curso y configura los distintos DateChooser, pero nos dimos cuenta que esto se producía antes de que el componente estuviese disponible, con lo cual si intentábamos colorear los días saltaban excepciones de componente no disponible.

Finalmente la función highlight busca los días que se le pasan en el array y configura el color de fondo de cada uno. Dentro del DateChooser, los días son instancias de TextField, pero de nuevo no son accesibles, tenemos que acudir de nuevo a mx_internal. El código es muy explicativo.

public function highlightDays(dayArray:Array, highColor:Number=0xff9900):void{
	var o:CalendarioMultipleColor = this;
	callLater(highlight,[dayArray, highColor]);
}
private function highlight(dayArray:Array, highColor:Number):void {
	if (!dayArray is Array) return;
	if (isNaN(highColor)) highColor = 0xff9900;
	// row 0 of the dateGrid is used for the display of day names
	var startRow:Number = 1;
	// calculate the column where the first day of the month is placed
	var startCol:Number = getOffsetOfMonth(this.displayedYear, this.displayedMonth);
	// how many days do we have this month?
	var lastDay:Number = getNumberOfDaysInMonth(this.displayedYear, this.displayedMonth);
	for (var i:Number = 0; i < dayArray.length; i++) {
		var day:Number = dayArray[i];
		 // only numbers allowed
		if (isNaN(day)) continue;
		if (day < 1) continue;
		if (day > lastDay) continue;
		// calculate row and column of the day
		var row:Number = Math.floor((day-1 + startCol) / 7) + 1;
		var col:Number = (day-1 + startCol) % 7;
		//finally we set background color
		this.mx_internal::dateGrid.mx_internal::dayBlocksArray[col][row].background=true;
		this.mx_internal::dateGrid.mx_internal::dayBlocksArray[col][row].backgroundColor=highColor;
	}
}

Aquí os dejo el ejemplo y código fuente, ya sabéis, botón derecho y View Source.