Introducción

Tapestry es un framework open source para la construcción de aplicaciones web en Java dinámicas, robustas y altamente escalables. Tapestry complementa y se basa en la API estandar de Java Servlet, y por tanto funciona en cualquier contenedor de servlets o servidor de aplicaciones.

Tapestry divide una aplicación web en un conjunto de páginas, construidas a su vez de componentes [3]. Esta parte proporciona una estructura consistente, permitiendo al framework Tapestry asumir la responsabilidad de actividades clave como la construcción y servicio de URL, almacenamiento persistente en el cliente o en el servidor, validación de datos, localización/internacionalización e informes de errores. Desarrollar aplicaciones con Tapestry engloba crear plantillas HTML usando simplemente HTML plano, y combinando esas plantillas con pequeñas cantidades de código Java (opcional) usando ficheros descriptores XML (NT: desaparecen en Tapestry 5 y se sustituyen por anotaciones). En Tapestry, creas tu aplicación en términos de objetos, además los métodos y propiedades de esos objetos – y específicamente no en términos de URL y parámetros. Tapestry proporcionan un desarrollo orientado a objetos verdadero a las aplicaciones web Java.

Tapestry está específicamente diseñado para crear nuevos componentes muy fácilmente, ya que esta es una rutina habitual en el desarrollo de aplicaciones. La distribución base incluye 50+ componentes, desde simples componentes que sólo generan salida hasta complejas tablas de datos y árboles de navegación.

La arquitectura de Tapestry permite escalar desde pequeñas aplicaciones hasta aplicaciones masivas formadas por cientos de páginas individuales, desarrolladas por un amplio y diverso equipo. Tapestry se integra fácilmente con cualquier tipo de back-end, incluyendo J2EE, HiveMind y Spring [4].

Principios

Tapestry está organizado alrededor de cuatro principios:

1. Simplicidad: las aplicaciones web no debería ser una ciencia de construcción de cohetes!.
2. Consistencia: lo que funciona en páginas debería funcionar en componentes. Lo que funciona en pequeñas aplicaciones debería funcionar en aplicaciones grandes. Diferentes desarrolladores deberían encontrar soluciones similares a problemas similares.
3. Eficiencia: las aplicaciones deben tener un alto rendimiento y escalabilidad.
4. Feedback: cuando las cosas van mal, el framework no debería abandonarnos; en realidad, debería proporcionar diagnósticos útiles. (NT: gran diferencia con Java Server Faces).

Los anteriores cuatro principios guían al meta-principio: La solución más simple debería ser la solución correcta.

Hemos encontrado (NT: los desarrolladores de Tapestry) que la aproximación al desarrollo de aplicaciones web mediante componentes es la mejor forma de materializar estos principios. Estructurar el framework y una hipotetica aplicación alrededor de componentes hace posible mover todo el código de la aburrida fontanería de dicha aplicación al framework. Como resultado escribes menos código, en ocasiones código más simple, algunas veces ni siquiera escribes código.

Es algo más de lo que puedes hacer con Tapestry… es también como lo haces! Tapestry es un entorno enormemente productivo. Los desarrolladores Java lo aman porque hacen cambios en el código Java y lo ven inmediatamente… sin redespliegues, sin reinicios!, en tiempo real (NT: esta característica está en Tapestry 5 [5]) Y es increiblemente rápido en arrancar (incluso cuando los ficheros cambian). Los diseñadores lo veneran porque las plantillas son muy parecidas a HTML ordinario, sin toda la confusión que se ve en los Java Server Pages. Los jefes de proyecto también lo tienen idealizado, porque hace fácil que equipos grandes de desarrolladores trabajen juntos y conozcan que las características importantes (incluyendo la localización) las proporciona el framework. Una vez que trabajas con Tapestry existe retorno

Referencia:

1. http://java-source.net/open-source/web-frameworks
2. http://tapestry.apache.org/
3. http://tapestry.apache.org/tapestry5/tapestry-core/ref/
4. http://www.springsource.org/
5. http://tapestry.apache.org/tapestry5/
6. http://www.infoq.com/articles/tapestry5-intro

* NT: Nota traductor

A continuación se muestran un poco más en detalle, algunas características que hacen de Tapestry una opción muy a tener en cuenta en la elección del framework de desarrollo para la capa de presentación de una aplicación web Java.

Explicar todas las características y en profundidad que ofrece Tapestry sería demasiado extenso, por lo que teniendo en cuenta que además de las indicadas en este artículo seguro que hay otras que pueden resultar interesantes y que se pueden consultar en mayor profundidad en los enlaces de referencia y en la documentacion del propio proyecto.

Plantillas de páginas y componentes

Una de las diferencias de Tapestry respecto a otros frameworks es que utiliza su propio sistema de plantillas en vez de Java Server Pages como es el caso de Struts. Las plantillas de Tapestry están diseñadas para ser ficheros (X)HTML válidos en las que las referencias a los componentes se ocultan en atributos especiales de forma poco intrusiva.

Referencia:

http://tapestry.apache.org/tapestry5.1/guide/templates.html

http://tapestry.apache.org/tapestry4.1/usersguide/template.html

Cambios en caliente

En Tapestry 5 los cambios en los componentes (incluso en las clases Java) se cogen en “caliente” sin necesidad de hacer redespliegues ni reinicios. Como resultado se obtiene una mayor productividad en el desarrollo (estas características solo están disponibles para los componentes de Tapestry).

Referencia:

http://tapestry.apache.org/tapestry5.1/guide/reload.html

Crear componentes

En Tapestry 5 los componentes son aún más sencillos que en Tapestry 4. No tienen que extender de ninguna clase base, no son abstractos y no hay un fichero XML que los describa, esto último se sustituye por medio de anotaciones.

El código de un componente de Tapestry que simplemente genere un texto puede ser tan sencillo como:

package com.entelibai.tapestry5.component;

import org.apache.tapestry5.MarkupWriter;
import org.apache.tapestry5.annotations.BeginRender;

public class HelloWorld {
@BeginRender
void renderMessage(MarkupWriter writer) {
writer.write(“Hola mundo !!!”);
}
}

Y su uso:

<span t:type=”HelloWorld”/></span>

Referencia:

http://tapestry.apache.org/tapestry5.1/guide/component-classes.html

http://tapestry.apache.org/tapestry5.1/guide/event.html

Librerias de componentes

Cada aplicación en Tapestry incluye al menos una serie de componentes personalizados específicos de esa aplicación. La parte que resulta tan interesante de Tapestry es lo sencillo y util que es empaquetar esos componentes para ser reutilizados en varias aplicaciones… y el que las aplicaciones que usen una librería de componentes no necesita ninguna configuración especial. Una librería consiste en un conjunto de componentes pero además una librería puede definir nuevos servicios que utilicen los componentes o configurar otros servicios presentes en Tapestry. Finalmente, los componentes son empaquetados en un archivo jar junto con las imagenes, hojas de estilo y librerias de javascript que necesiten proporcionar al navegador web.

Referencia:

http://tapestry.apache.org/tapestry5/cookbook/lib.html

Lenguaje de expresiones

Tapestry tiene un potente lenguage de expresiones que permite asignar valores a los parámetros de los componentes. La expresiones están precedidas por un prefijo que indica como se ha de interpretar la expresión a continuación del prefijo. Mediante estas expresiones los componentes pueden acceder de forma sencilla en la plantilla (X)HTML del componente a assets (css, imagenes, …), referencias a otros componentes, mensajes localizados, propiedades del componente, …. Una de la diferencias respecto a otros lenguages de expresiones es que en Tapestry no están limitadas a las propiedades que sigen la espeficación de los JavaBeans, esto es interesante ya que no todas las clases Java siguen esta norma, como por ejemplo la propiedad size() de la clases que implementan la interfaz java.util.List.

Referencia:

http://tapestry.apache.org/tapestry5/guide/parameters.html

Navegación

En esencia, una aplicación Tapestry es un conjunto de páginas relacionadas trabajando juntas. Una petición tendrá como destino una única página. Las peticiones pueden venir en dos formas:

• Eventos de componentes que tienen como objetivo un componente específico de una página específica, lanzando un evento en ese componente.
• Peticiones para mostrar una página especifica, generar el etiquetado HTML de esa página y enviarlo al cliente.Esta dicotomía entre eventos de componentes y peticiones para mostrar páginas es nueva en Tapestry 5. Está basada en las ideas de la especificación de los Portlets y permite aliviar una serie de problemas presentes en aplicaciones web tradicionales como el botón atrás o el botón refrescar de los navegadores.

Referencia:

http://tapestry.apache.org/tapestry5/guide/pagenav.html

Internacionalización/Localización

La localización de las plantillas en Tapestry no sólo hace referencia a los mensajes de texto sino que se pueden tener dos plantillas totalmente diferentes e imágenes dependiendo del idioma del usuario.

En Tapestry los catálogos de mensajes de localización pueden ser a nivel de aplicación y/o a nivel de componente proporcinando una gran flexibilidad.

Los cambios en caliente también se aplican a los catálogos de mensajes.

Referencia:

http://tapestry.apache.org/tapestry5.1/guide/localization.html

Informe de errores

Una de las mejores características es el informe de error que se genera en caso de que algo vaya mal. El nivel de detalle proporcionado es amplio y muy útil, lo que permite identificar de una forma más sencilla la causa del error. En el informe se incluye la linea de la plantilla donde se ha producido el error asi como la traza de la excepción. Por supuesto, este informe de error puede ser redefinido para que en un entorno de producción se muestre de otra forma más util para el usuario final.

Referencia:

http://tapestry.apache.org/tapestry5.1/cookbook/exceptions.html

AJAX/JSON

Tapestry proporcina un sofisticado soporte de Ajax y Javascript basado en las librerías Prototype y Scriptaculous, estas librerías están incluidas dentro del mismo framework.

Referencia:

http://tapestry.apache.org/tapestry5.1/guide/ajax.html

Valicación de formularios

Una de las cosas que comparten todas las aplicaciones web es la necesidad de validar la información introducida por el usuario. Tapestry proporciona un excelente soporte para realizar la validación de forma declarativa, lo que significa que simplemente se le indica que validaciones aplicar a que campos. Tapestry no sólo es capaz de presentar los errores al usuario sino también de decorar los campos y etiquetas que contienen errores.

Otra de las necesidades de todas las aplicaciones web es la de convertir los valores del servidor a cadenas de texto en la parte cliente y viceversa, de esto se encargan las clases que implementan la interface Translator.

Referencia:

http://tapestry.apache.org/tapestry5.1/guide/validation.html

http://tapestry.apache.org/tapestry5.1/apidocs/org/apache/tapestry5/Validator.html

http://tapestry.apache.org/tapestry5.1/apidocs/org/apache/tapestry5/Translator.html

Mantenimiento de estado en el servidor

En ciertos momentos de practicamente todas las aplicaciones web hay que conservar cierta información sobre una tarea que esta realizando el usuario, para ello Tapestry dispone de varias estrategias de persistencia: en sesión hasta que se de por finalizada la sesión del usuario, flash donde la información se conserva hasta la siguiente petición del usuario, en cliente en forma de un nuevo parámetro en URL o un campo oculto en un formulario. Este tipo de persistencia puede aplicarse a cada una de las propiedades de los componentes. En caso de que necesitemos que cierta información este disponible en varias páginas Tapestry usa el concepto de Application State Objet (ASO) que permiten mantener el estado pero sin tener que estar asociada esta información a una propiedad de una página o componente en concreto, de nuevo a estos ASO se les puede aplicar diferentes estrategias de persistencia.

Referencia:

http://tapestry.apache.org/tapestry5/guide/persist.html

http://tapestry.apache.org/tapestry5/guide/appstate.html

URLs amistosas

El concepto de URLs amistosas hace referencia al formato de las URL que genera Tapestry. Que el entorno genere las URLs de esta forma permite aplicar a las mismas la seguridad declarativa de J2EE o Spring.

Referencia:

http://tapestry.apache.org/tapestry4.1/usersguide/friendly-urls.html

IoC (Inversion of Control)

Un concepto clave en Tapestry es el uso de la inyección. Tapestry, mediante las anotaciones, permite una inyección de una instancia de un servicio directamente sobre las propiedades de un componente, página o servicio.

Referencia:

http://tapestry.apache.org/tapestry5.1/guide/inject.html

http://tapestry.apache.org/tapestry5.1/tapestry-ioc/

Integración con Spring

Tapestry proporciona integración con Spring permitiendo a los beans definidos en Spring ser inyectados en los servicios o componentes.

Referencia:

http://tapestry.apache.org/tapestry5.1/tapestry-spring/

http://tapestry.apache.org/tapestry5.1/tapestry-ioc/injection.html

Rendimiento

Con el objetivo de aumentar el rendimiento de las aplicaciones, Tapestry realiza de forma automática una serie de actividades:

• Eliminación de espacios: Tapestry elimina todos los espacios no necesarios reduciendolos a sólo el único necesario. Los bloques que sean únicamente espacios son eliminados completamente. Esto tiene ventajas tanto en el servidor como en el ciente, por un lado hay menos salida que generar y en el cliente menos que procesar.
• Versionado: Tapestry permite versionar los assets que se envían al cliente marcándolos además con una fecha de expiración muy lejana en el futuro. Esto significa que el navegador del cliente puede almacenar en la cache los ficheros que recibe y sirve para que en el momento que cambien el cliente pueda acceder a los nuevos.
• Compresión: Desde Tapestry 5.1 se comprime mediante GZIP el contenido generado para el cliente. Esta peculiaridad reduce significativamente la cantidad de tráfico de red a costa de tiempo de procesado en el servidor. Lo anteriormente mencionado afecta al contenido HTML como a los assets (imagenes, css, javascript, …) enviados al cliente. Proporcina mayor rendimiento que un filtro que haga la compresión ya que este no sabría que contenido es dinámico y cual estático haciendo repitiendo el proceso de compresión para el mismo contenido.

Finalmente, como se explica en la propia página de Tapestry, la versión 4 tiene un rendimiento comparable a su aplicación equivalente Servlet/JSP, la versión 5 con estas y otras características es mucho más rápido.

Referencia:

http://tapestry.apache.org/tapestry5.1/guide/compress.html

http://tapestryjava.blogspot.com/2009/02/speeding-up-tapestry-51.html

Happy Hacking!

Autor, D

Lo primero que necesitamos especificar es que entendemos por proyecto, y para tener un orden de magnitud conjunto, nos referiremos a todo aquel proyecto que supere los 65.000 € y los 4 meses de duración; de esta forma identificaremos y especificaremos un conjunto de mínimos.

En segundo lugar necesitamos aclarar que es lo que se entiende por Plan del Proyecto y, no es más, que el conjunto de elementos que permiten, como mínimo, dar respuesta a:

• ¿Qué producto necesita el cliente?
• ¿Qué trabajo hay que realizar?
• ¿Cuándo hay que realizar el trabajo?
• ¿En qué fechas hay que realizar el trabajo?
• ¿Cuánto tiempo le vamos a dedicar?
• ¿Quiénes vamos a participar en el proyecto?
• ¿Cuánto costará la realización del proyecto?
• ¿Cuánto dinero esperamos ganar en la realización de éste proyecto?
• ¿Cuál es el precio de venta?
• ¿Qué problemas podremos encontrar en la realización del proyecto?

Esto me lleva a diseñar un flujo de trabajo que facilite el tránsito de información entre los diferentes productos que conforman el Plan del Proyecto.

• Documento de Requisitos: Especificación formal, estructurada y ordenada de las necesidades y problemática de los clientes. Aunque no pertenece al Plan del Proyecto, su existencia es fundamental.
• Alcance del Producto: Descripción de la solución tecnológica adoptada para cubrir, de forma total o parcial, las necesidades especificadas.
• Alcance del Proyecto: Conjunto de actividades que permiten desarrollar, gestionar y controlar el desarrollo del producto propuesto.
• Cronograma: Distribución temporal de las actividades, según la estrategia de ejecución planteada, que especifica el compromiso de plazos y el trabajo colaborativo.
• Hoja de Esfuerzo: Describe el tiempo de dedicación estimado para completar cada una de las actividades a realizar. Sólo aparecerán aquellas personas cuya producción ha de ser controlada por el Jefe de Proyecto.
• Hoja Financiera: Describe los flujos de caja esperados, incluyendo gastos, facturas a realizar (cliente) y recibir (proveedores).
• Hoja de Riesgos: Descripción de los diferentes riesgos, su impacto, probabilidad, fecha estimada en que se produzca y plan de resolución.

Un aspecto asociado a la Hoja de Riesgos, que puede haberte llamado la atención de la imagen anterior, es que hay ciertas flechas que relacionan dicho entregable con otros del Plan del Proyecto, saltándose el proceso normal. Esto se debe a que la solución adaptada de un riesgo (un nuevo escenario) se debe a la modificación de diferentes elementos (producto, actividades, ordenación cronológica, perfil de los recursos, tiempo de dedicación, costes del proyecto, margen del proyecto, precio del proyecto, etc…), el cual desencadena un conjunto de efectos a tener en cuenta según el flujo especificado.

También podría hablarse en este artículo de qué información, métricas e indicadores deberían aparecer en cada uno de los entregables citados, y cómo los flujos de información nutren el resto de elementos relacionados, pero esto, en todo caso, puede ser objeto de otro artículo.

Es en estos casos, es donde tienen una mayor aceptación los nuevos modelos ágiles, tanto aplicables en todo el ámbito del proyecto, como los especializados en la dirección de los mismos.

Estos modelos se basan en los cuatro pilares del manifiesto ágil, donde se valoran:

1. A los individuos y su interacción por encima de los procesos y las herramientas
2. El software que funciona, por encima de la documentación exhaustiva.
3. La colaboración con el cliente, por encima de la negociación contractual.
4. La respuesta al cambio, por encima del seguimiento de un plan.

Como podemos observar, existen ciertas divergencias en comparación con los modelos clásicos o dirigidos, pero debemos tener en cuenta, al igual que con el resto de metodologías y modelos, que para resolver un mismo problema tenemos que tener en cuenta los siguientes factores:

1. Capacitación y capacidad del equipo, ya que son las personas las que idean y crean cada elemento, creando un entorno de gestión del conocimiento compartido, coherente, directo y no sobrecargado.
2. Disponer de forma temprana de parte del producto final. Esto permitirá recibir feed-back por parte del cliente, y recabar nuevas necesidades, además de disponer de un entorno de pruebas mucho más potente e integral.
3. El proveedor de soluciones IT debe ser más un aliado tecnológico que hace las veces de consultor, que un mero suministrador de tecnología.
4. Si el entorno en el que se mueve el cliente cambia, su necesidad o problemática mutará, por lo tanto debemos disponer de los medios que nos permitan adaptarnos a dichos cambios lo antes posible.

En este punto podréis pensar que soy un gran soñador, y que no he tenido en cuenta grandes problemas organizativos, pero antes de plantearnos siquiera el trabajar con metodologías ágiles, debemos de cumplir ciertos prerrequisitos y tener claras ciertas cuestiones:

• El equipo debe de estar formado por un conjunto de personas que muestren una actitud colaborativa y dispongan de aptitudes y conocimientos destacables en diferentes áreas de conocimiento, ya que si no es así, ¿que innovación y contribución diferencial existirá?
• El no disponer de documentación exhaustiva no quiere decir que no haya documentación. Debemos saber qué es crítico en el ciclo de vida del producto y dónde se encuentra su complejidad.
• La comunicación interpersonal es la base de la gestión del cambio continuo. Esto puede parecer que choca con las políticas de calidad de las organizaciones, pero no es así, ya que como hemos indicado en el punto anterior, debemos tener muy claro, qué debe quedar por escrito.
• Para conocer el nivel de cumplimiento de un contrato, necesitamos conocer  alcance, plazo y coste, ¿pero qué pasaría si no conocemos el primero de los factores? ¿No podríamos crear un contrato marco y para cada uno de los entregables realizar un anexo?

Una persona encargada de la venta o de gestionar un presupuesto, puede resaltar de la dificultad de gestionar la ocupación y rentabilidad de un departamento, y la complejidad añadida de tener que negociar de forma continuada. Este enfoque nos obliga a trabajar estrechamente y colaborar con el cliente, centrarnos en sus necesidades y hacer un trabajo de alto valor añadido en cada entrega.

Al igual que existen muchas metodologías tradicionales, atendiendo a la importancia y relevancia sobre la que se quiere hacer énfasis, existen muchas otras denominadas ágiles, como son:

• Agile Database Techniques
• Agile Modeling
• Agile Unified Process
• Crystal
• Feature Driven Development
• Dynamic Systems Development Method
• Lean Software Development
• Scrum
• Test-Driven Design
• XBreed
• eXtreme Programming

Muchas de ellas tratan tanto el ciclo de vida de desarrollo de software como el de gestión, mientras que algunas de ellas se centran única y exclusivamente en el modelo de gestión. Dada la extensión del análisis de las mismas, podrá ser objeto de otra futura aportación a este blog.

Aun así, me gustaría comentar algunas de las características de una de ellas, SCRUM. Es un término acuñado del rubgy, y haciendo una semejanza, describe cómo:

• El equipo debe organizarse haciendo una piña, y donde cada persona aporta tanto individualmente como colectivamente.
• El objetivo de cada iteración es la aportación de valor, es decir, conseguir un ensayo.
• El objetivo es ganar el partido y que el cliente (interno y externo) esté satisfecho del resultado final.

Personalmente, esto me lleva a un dilema, si el objetivo de todo proyecto de desarrollo de software, es crear el producto necesario con el nivel de calidad requerido, y debe estar disponible con la premura que requiere el negocio al que dará soporte, el fin justifica los medios ¿no?

Alberto Salgado

Consultor IT, Consultoría y Formación

Como ya sabéis Microsoft dio a conocer su tecnología .NET a finales del 2000 para hacer frente al avance o “éxito” de Java de Sun. En ese momento fue cuando Miguel de Icaza (Co-fundador de la empresa Ximian, fundador y presidente de la GNOME Foundation y actualmente Vicepresidente de Desarrollo en Novell) teniendo acceso a la información de la tecnología .NET vio una forma de solucionar la problemática existente en GNOME.

Como él mismo dijo… “su pasión es el desktop, y Linux ya no puede ser más un sistema escrito por programadores para programadores, sino que tiene que ser apto para cualquier usuario”.  Gracias a la tecnología .NET el proyecto GNOME consigue lo que siempre había buscado, independencia del lenguaje para programar en dicho desktop. Por este motivo surgió el proyecto Mono y así conseguir que GNOME, en un futuro, sea un desktop mejor y más atractivo tanto para los usuarios como para los programadores.

Actualmente, Mono es la solución madura para desarrollar con la tecnología .Net en todos los sistemas operativos, aunque para Windows le queda mucho por recorrer. Para que os hagáis una idea, se están rematando los últimos detalles de la versión de Mono 2.0 que implementa el Framework 2.0 mientras que Microsoft ya ha lanzado la versión 3.5 del Framework. Lo que imposibilita que las aplicaciones desarrolladas con las versiones superiores no pueden migrarse completamente a Mono.

Y es que una de las virtudes de Mono, es la posibilidad de ejecutar aplicaciones desarrolladas con Visual Studio sin tener que modificar ni una línea de código y viceversa, claro está con alguna limitación. Al parecer todas las aplicaciones migrables de Windows a Linux son aquellas que sólo utilizan el API definido dentro del namespace System y que no usan P/Invoke. Aunque no lo he mencionado, estas aplicaciones también funcionarían en HP-UX, Solaris, MacOS X, entre otros; ya que la aplicación utiliza un Entorno de Ejecución para poder funcionar, que está disponible en la pagina Web de Mono.

Como no siempre lo que leemos es totalmente cierto, realicé la prueba con varias aplicaciones que tenía de cuando empecé con .NET. Me llevé una grata impresión al ver que compilaban correctamente casi todas ellas sin tener que modificar ni una línea de código. Pero no creáis que fue todo tan bonito, también me surgieron algunos ‘problemillas’:

• El proceso de instalación del producto me causó más de un quebradero de cabeza, no sé si fue debido a tener instalado el Visual Studio o que todavía no funciona correctamente con Windows. Pero tratándose de este Sistema Operativo puede ser por cualquier motivo.
• Hay que tener en cuenta la versión del .NET Framework que tenemos instalado al no ser totalmente compatible con el Framework 3.5. Aunque no he encontrado ninguna mención a este problema en la página del proyecto Mono.
• Otra de las cosas que no soporta es el uso de código “no manejado”, pero por un buen motivo… El código se basa en el uso de los recursos del propio sistema operativo haciendo nuestra aplicación más rápida pero más insegura, pero es dependiente directamente del sistema operativo.

Experiencias como estas podréis encontrarlas en muchos foros especializados, tal y como se comenta, hay que entender que es un proyecto que está empezando aunque en poco tiempo ha realizado avances significativos.

Una de las grandes sorpresas, ha sido la aplicación de Mono en el mundo de los videojuegos, para que os hagáis una idea podéis descargar la versión de prueba del entorno Unity para desarrollo de videojuegos. Tanto ha sido su éxito que Jim Purbrick (Babbage) de Linden Labs ha anunciado la migración de todos los scripts de Second Life a Mono, por las siguientes razones:

• Uso de la mitad de recursos de memoria.
• Los scripts funcionan hasta 220 veces más rápido.

y es que estamos hablando de una granja de aproximadamente 6000 servidores!.

Para concluir, creo que las empresas deberán tener en cuenta este entorno de desarrollo como una solución de software libre alternativa a la de Microsoft. Sólo nos falta saber los siguientes pasos que dará “El gigante de Redmond”.

Oscar Delgado
Consultor IT, Consultoría y Formación

Uno de los factores clave en el éxito a la hora de diseñar cursos e-learning, es saber elegir un buen modelo pedagógico que permita a los alumnos realizar el proceso enseñanza / aprendizaje con total garantía.

Estos son los puntos fuertes a tener en cuenta:

• Se debe adaptar a las necesidades y posibilidades del estudiante a quien va dirigido.

• Debe acompañarlo para que sienta apoyado, marcándole el camino para que sepa cómo avanza y hacia dónde se dirige.

• Que sienta que lo que aprende es útil, tanto los conceptos teóricos como sus aplicaciones prácticas.

• Un entorno y unos docentes que ayuden a crear un sentimiento de pertenencia a una comunidad, por los beneficios conjuntos que pueden alcanzarse a través de la interacción entre sus miembros, que comparten conocimientos y aprenden.

• Una formación basada en una planificación y un contexto más que en materiales dispersos.

Pero también: 

• Un modelo que sea capaz de gestionar e incrementar la flexibilidad, la personalización, la interacción y la cooperación: aportar soluciones formativas a medida de las necesidades de los usuarios, teniendo en cuenta los condicionantes vinculados al tiempo, a la distancia, y a una estructuración de los contenidos.

• Ofrecer a las empresas un sistema formativo que tenga en cuenta las competencias de sus trabajadores y cuál es el diferencial que deben adquirir para cubrir sus necesidades formativas.

• Potenciar la interactividad, no sólo entre los estudiantes y el contenido, sino también entre los estudiantes y los formadores o facilitadores.

Todas estas características hacen que los participantes deben asumir un rol mucho más activo, pues van a ser los que van a tomar las decisiones sobre su propio proceso de aprendizaje.

¿Cuáles son los posibles riesgos?

Cuando se busca un modelo un modelo pedagógico, existen una serie de riesgos que se deben tener en cuenta:

• Riesgos de convertir la formación en una mera mercancía, que se transporta a través de Internet. Eso puede suceder si se reduce la formación a lo que se denomina “e-Reading “o una mera “descarga” de información.

• No es prudente contribuir a la confusión conceptual entre conocimiento e información. Incluso cuando se quiere, únicamente, capacitar a alguien en unas competencias determinadas. Existe el riesgo de suponer que el conocimiento es algo estático, cuando no es cierto. Se puede tener información, pero ¿se dispone de conocimiento?.

• Por otro lado, si bien es cierto que la formación es un proceso, y que como tal puede gestionarse, también lo es que determinados posicionamientos se están centrando excesivamente en la propia gestión, olvidándose de quiénes son los sujetos de la formación, y qué elementos metodológicos están jugando un papel determinado y cómo lo están haciendo. En este sentido, las interpretaciones que consideran los conceptos LMS (Learning Management Systems) y LCMS (Learning Content Management Systems) en sí mismos como sistemas y, a veces, incluso como modelos de formación, son claramente reduccionistas.

• Finalmente, otro riesgo bastante común es el de imaginar que el e-learning es un modelo de autoformación. Algunas propuestas de e-learning entienden que un verdadero sistema de este tipo, no necesita la existencia de formador. La autoformación, o el autoaprendizaje, no son conceptos propios del e-learning, sino que forman parte de los sistemas más tradicionales de educación a distancia. El papel del formador puede convertirse en crucial para desarrollar un sistema de e-learning competitivo y de alto valor añadido.

En conclusión, teniendo en cuenta tanto los puntos fuertes como los factores de riesgo mencionados en este artículo, un buen modelo pedagógico para el e-learning es aquel que se deriva del concepto emergente de “comunidad virtual de aprendizaje”, donde cada persona es un autor y usuario al mismo tiempo del proceso enseñanza – aprendizaje.

Adelardo Sánchez
Responsable de la Línea de Servicio e-learning 

1. Un SDK (cómo no) del estilo “aplicaciones web desarrolladas a toda velocidad”.
2. Un panel de control web para monitorizar la aplicación (picos de CPU, errores, versionado, etc).
3. La infraestructura distribuida de Google para almacenamiento, cálculo, escalabilidad, APIs, etc.

Hay una serie de vídeos muy ilustrativos en la página oficial de este proyecto de Google.

Preguntas que yo me hice y respuestas que obtuve:

1. ¿A quién va dirigido?: A cualquier desarrollador web con cualquier nivel de experiencia. Lógicamente, a mayor experiencia, mejores resultados en menos tiempo.
2. ¿Qué lenguaje de programación soporta?: Muchos en el futuro, actualmente python.
3. ¿Usa algún framework preexistente por debajo del que podamos hacer uso?: Sí, Django ¡!
4. ¿Cuánto cuesta el “hosting” de Google para tus aplicaciones?: No queda claro pero tiene pinta de que será gratis en una versión “normal” y si tienes una megaweb de millones usuarios tendrás que comprar espacio en disco, más CPU, etc.
5. ¿Cómo se hace un deploy de tu aplicación web?: la idea es que usas el SDK en tu máquina local y en cualquier momento ejecutas una orden en consola que se conecta a Google y almacena la nueva versión de aplicación. Interesante saber que desde el panel de control web puedes reactivar una versión antigua de tu aplicación instantáneamente (por ejemplo, una que no contuviera un error malvado).
6. ¿Limitaciones en la API?: tres: nada de abrir sockets alegremente, los encapsulan con una API de Google. nada de guardar archivos en el disco duro (no hay), usas su base de datos a través de la API. Nada de threads, la arquitectura hardware y el Django que hay por debajo ya se encargan de todo eso por ti. Así que son limitaciones pero Google te ofrece una alternativa adecuada.
7. ¿Qué sistemas operativos pueden usar el SDK localmente?: GNU/Linux, Mac y Windows. En realidad, cualquier entorno que soporte Python nativamente.
8. ¿Esto es una beta o qué?: Sí pero es bastante funcional y merece la pena probarlo.
9. ¿Dónde puedo ver aplicaciones realizadas con GAE?: aquí.
10. ¿Es otro paso para la dominación del mundo por Google?: es posible. Imagino que quieren crear una red de aplicaciones web fácilmente integrables con sus otros servicios (google maps y gmail son jugosos ejemplos) y quizá promuevan el uso de su programa AdSense de anuncios pero al final, viendo los vídeos de presentación y la gente involucrada (el propio Guido, creador de Python), es un conjunto de herramientas que facilitan la creación y mantenimiento de aplicaciones web complejas.

Personalmente, me encanta que hayan elegido Python como lenguaje inicial y Django como framework MVC en particular. Google es muy pro-python pero hasta ahora se circunscribía fundamentalmente a desarrollos internos. Con este paso promueven este lenguaje, muy maduro y flexible, para desarrollos de terceros.

1. Un aspecto de la tecnología.
2. Que sea curioso o destacable.
3. y, a ser posible, relacionado con vuestra actividad (para poner algún ejemplo cercano).

Así que, ánimo, dedica media hora a sacar unos párrafos en un tono técnico y desenfadado al mismo tiempo y te lo colgamos aquí mismo.

Como éste es un blog tecnológico de una empresa tecnológica, había pensado en publicar una entrada animando a proponer regalos curiosos que, por probabilidad, deberían agradarnos a nosotros, los techies, geeks, gadgetomaníacos, etc.

Para no lanzar la piedra y esconder la mano, aquí va mi propuesta: Lego Mindstorms. Os comento qué es esto…

Antes de que nadie piense que he tenido un ataque de nostalgia, os diré que Lego Mindstorms es un producto relativamente reciente de diseño, construcción y programación de robots con un sinfín de posibilidades. Hace un año sacaron al mercado la segunda generación de este producto, llamado NXT, que es el que se vende en la tienda online de Lego (ojo, no es barato pero son múltiples robots en uno y, en ese sentido, es una ganga).

La clave es la combinación de piezas Lego Technic (u otras, siempre que encajen) con una unidad de procesamiento independiente a la que se pueden conectar servos, sensores de luz, de sonido, de distancia, de color, de dirección, de presión, etc. Todo este hardware funciona perfectamente y hay muchas piezas para comprar por separado y montar robots verdaderamente complejos.

El último elemento es la programación. ¿Cómo programo un robot? En el caso de Lego Mindstorms tuvieron una idea brillante: desarrollaron un interfaz de programación visual en el que se usan bloques que representan los sensores (un motor A), las acciones (gira en sentido de las agujas a 75% de potencia) y las condiciones (si el sensor de presión detecta obstáculo). Para los que tengáis hijos o sobrinos de entre 10 y 16 años es una forma práctica pero completa de iniciarse en la programación (imperativa). Pero esto no acaba ahí, al abrir el firmware de su CPU, otros desarrolladores crearon compiladores específicos que comprenden sintaxis que se parece a C, Java, Fortran, Pascal, etc. A mí me gusta especialmente NXC (Not eXactly C) porque no tienes que modificar el firmware original y aunque no tiene capacidad de números flotantes, permite estructuras muy complejas. Probablemente os decantéis por esta línea o directamente en ensamblador si os emociona jugar directamente con registros.

Para terminar con mi recomendación os diré que la CPU (llamado también el brick) es un ARM con 64KB de RAM (y ahí caben muchas instrucciones) y 256KB de memoria Flash (en donde se almacenan los programas o ficheros temporales generados por ellos).

Enlaces útiles:

• Tienda online de Lego Mindstorms
• Vídeo curioso en Youtube

Ahora os toca a vosotros dar ideas o, por qué no, pedir a ver si cuela…

Por parte de Entel asistirá Pablo Ruiz Múzquiz, Director FOSS, y le acompañarán tanto representantes del mundo académico como del sector informático y tecnológico. El punto de vista de una empresa que cuenta con un área específica de software libre servirá de base para comentar el perfil de las nuevas generaciones de licenciados y los cambios de percepción en las empresas.

Sin embargo, a la hora de desplegar una aplicación en un Tomcat nos hemos encontrado con diversos problemas. Despues de nuestra labor de investigación y pruebas, hemos conseguido la “receta” para poder desplegar las aplicaciones.

1- El primer paso es obviamente conseguir que funcione correctamente en el entorno de GWT. Mientras no funcione ahí, no es planteable desplegarlo en el Tomcat.

2- Compilarla, bien mediante el comando aplicacion-compile, bien mediante el botón de compilación del propio entorno GWT

3- En el directorio de webapps del Tomcat, crear la siguiente estructura de directorios (en Ubuntu está en /var/lib/tomcat5.5/webapps):

webapps/Aplicacion
webapps/Aplicacion/WEB-INF
webapps/Aplicacion/WEB-INF/classes
webapps/Aplicacion/WEB-INF/lib

4- Cuando se compila la aplicación (en el segundo paso), se genera en el directorio de la aplicación un subdirectorio llamado www. Y dentro de él otro subdirectorio llamado <nombre del paquete>.<nombre de la aplicación>. Pues bien, ahora hay que copiar todos el contenido de ese directorio a webapps/Aplicacion

Ej:

cp -R /home/user/java/workspace/App/www/es.prueba.App/* /var/lib/tomcat5.5/webapps/Aplicacion

5- Copiar el contenido del directorio de la aplicación/bin a webapps/Aplicacion/WEB-INF/classes

Ej:

cp -R /home/user/java/workspace/App/bin/com /var/lib/tomcat5.5/webapps/Aplicacion/WEB-INF/classes/com

6- Crear el fichero webapps/Aplicacion/WEB-INF/web.xml con el siguiente contenido:

<web-app>
   <servlet>
      <servlet-name>Servicio</servlet-name>
      <servlet-class>es.prueba.Servicio</servlet-class>
   </servlet>
   <servlet-mapping>
      <servlet-name>Servicio</servlet-name>
      <url-pattern>/Servicio</url-pattern>
   </servlet-mapping>
</web-app>

Los valores son los mismos que los definidos en el fichero gwt.xml de la aplicación

7- Este paso es muy importante, y nos dio un montón de problemas hasta que lo conseguimos. Hace falta copiar las bibliotecas de GWT gwt-servlet.jar y gwt-user.jar al directorio webapps/Aplicacion/WEB-INF/lib. Pero gwt-user.jar incluye las librerías javax, que por temas de licencias están prohibidas en tomcat. Por lo tanto, hay que editar el contenido de ese jar y eliminar el directorio javax. Por ejemplo, con el ark es fácil.

Con estos siete pasos, ya tenemos un par de aplicaciones funcionando sin problemas en nuestros servidores.