Por fin leo una exposición que viene de alguien de Adobe y que explota el problema desde el lado puramente empresarial que es el verdadero nicho de las aplicaciones Flex.

Michael da justo en el clavo y nos hace ver lo que yo y otros muchos hemos intentado comunicar a Adobe una y otra vez sin éxito debido sencillamente a los objetivos claramente distintos de Adobe (la venta de herramientas para el tratamiento de contenidos) y de las empresas que adoptan Flex para sus soluciones empresariales (sistemas empresariales cuya construcción está subyugada a entornos de integración continua donde se deben integrar con otras muchas soluciones open source, donde la orientación a objetos es crucial, donde nunca ha sido crucial tener un “Design View”, pero si un plugin de maven-flashbuilder y donde la naturaleza de la propia empresa es muy distinta a la del usuario *de la calle* donde HTML5 está teniendo tanto éxito en móviles y tablets).

Está claro que el caso que yo me esfuerzo en defender, el de las aplicaciones empresariales, afecta a un colectivo muy concreto, al cual no puedes ofrecerle una visión irreal o utópica. El mundo de la empresa se mueve en otros tiempos (quizá tiempo bala, como en Matrix ) y con objetivos claros de fiabilidad, seguridad y alta disponibilidad. Suele tener además implicaciones muy distintas a las pequeñas soluciones que se manejan en internet (cualquier servicio en internet suele ser ordenes de magnitud más pequeño, manejable y mantenible a nivel de desarrollo).

En definitiva, muchos de los casos de uso a los que me refiero yo y donde Flex se utiliza de forma brutalmente extensiva, son aplicaciones privadas, que viven dentro del entorno de la empresa, en redes privadas o intranets, cuyo acceso es privado y ciclo de vida y necesidades son muy distintos a los que podemos encontrar en el mundo al que Google, Apple y ahora Adobe se quieren dirigir de forma exclusiva.

Lo nuestro siempre ha sido un escenario donde Apache, Java, Spring, y otras muchas organizaciones han sido las que han marcado las aplicaciones. Adobe Flex siempre ha sido una tecnología con un aporte claro y necesario pero con una naturaleza extraña por estar dentro del ala de Adobe, y que ahora por fin puede ocupar su lugar natural junto con el resto de soluciones del sector en Apache.

Creo que esta es una lectura obligada y que a todos los que estáis en un entorno empresarial similar a mí os va a gustar y vais a ver que por fin alguien de Adobe “habla vuestro mismo idioma”.

Enhorabuena Michael!

Flash en el móvil

Con respecto a la primera decisión, no me extenderé mucho. Me parece una buena decisión teniendo en cuenta como está evolucionando el mundo y como se consume contenido en los dispositivos móviles, donde el público prefiere aplicaciones nativas y el navegador tiene el uso para el que fue creado (búsquedas, consumo de información textual, blogs…).

Salvo por la mala comunicación de Adobe PR (Public Relations), Hasta aquí todo correcto. De hecho no creo que esta decisión afectase a nadie ya que con la negativa de Apple de incorporar Flash Player en iOS, la única opción real en los navegadores moviles era HTML5. Esto dejaba las webs informativas tradicionales, blogs y demás sucedáneos, en un formato diseñado con el objetivo de servir información textual. Quizá solo podamos tener un cierto sentimiento de “estar siendo manejados” al quitarnos la libertad de elegir si queremos usar una u otra tecnología o la combinación de ambas.

Para la aplicaciones nativas siempre podemos recurrir a Adobe AIR (que incluye el Flash Player) donde podemos, con un solo desarrollo, desplegar en iOS, Android y BlackBerry. En este sentido los desarrollos Flash y Flex cobran todo su sentido.

El futuro de Flex

Por el contrario el cambio de estrategia con Flex y su malísima comunicación por parte del departamento de relaciones públicas de Adobe (que parece un grupo de aficionados por sus repetidas meteduras de pata), unido al cambio radical de la dirección empresarial de Adobe han provocado que la comunidad Adobe se sienta engañada y enfadada. Engañada por que esto significa un cambio de 180º en la visión marcada por Adobe (Visión que ha sido soportado por millones de profesionales del sector y refrendada por los clientes de dichos profesionales que han confiado en las soluciones tecnológicas soportadas por el fabricante) y enfadados por que la imagen y el daño generado suponen un perjuicio, quedando en el campo de los profesionales el dar explicaciones a los clientes y convencer sobre el uso correcto de Flash/Flex.

Tal es el daño generado por Adobe que desde hace varios días se pide la dimisión de su CEO (537 firmas recogidas en el momento de escribir esta entrada), cuya falta de liderazgo ha llevado a Adobe a ser un actor pasivo en esta guerra tecnológica. Desde que Steve Jobs inició su batalla contra Flash, debido a sus rencillas con Adobe y a su interés de mantener el control del canal de venta dentro de sus dispositivos iOS, Adobe no ha sido capaz de responder a las difamaciones sobre su tecnología, ni de hacer notar las maravillas de la misma al público, lo que finalmente ha llevado a esta situación.

Durante estos años tanto las empresas cliente como los profesionales de la industria han invertido mucho en Flex ofreciendo resultados espectaculares. Esta decisión repentina de Adobe tendría sentido en el caso de que tuviésemos un reemplazo actual para Flex a día de hoy y no solo una promesa de futuro. El segmento de las *aplicaciones* empresariales no es el mismo que el de las *webs* donde HTML5 cobra todo el sentido. HTML5 *no* está todavía preparado para solventar los problemas que surgen en el mundo de las aplicaciones empresariales y lo peor es que no sabemos cuando ni como estará.

Realmente HTML no ha cambiado significativamente durante los últimos años. El motivo por el que todos nos pasamos a Flex fue debido a la fragmentación de los navegadores y a la inconsistencia de la experiencia de usuario que existía entre ellos. Esto sigue siendo así y continuará así a no ser que todos los fabricantes se asocien para crear un motor único que permita asegurar esa experiencia única de visualización.

La innovación generada en el Flash Player a través de los años así como su alta penetración (mayor al 98%) en la base de ordenadores en todo el mundo y su consistencia a través de plataformas convierten a Flash en un entorno de ejecución perfecto y clave en el desarrollo de aplicaciones empresariales.

Además, la naturaleza de la tecnología es lo esperado por un desarrollador de aplicaciones : Lenguaje OOP, debugger, compilación sobre interpretación, IoC, Metadatos, AOP, protocolos de comunicación avanzados como AMF y RTMP, Profiling, Acceso a bajo nivel (Bitearray, pixel level handling), etc…

Estas características son el principal motivo por el que HTML5 no podrá sustituir a Flash (y sobre todo a Flex) en el desarrollo de aplicaciones corporativas. HTML siempre ha sido una tecnología orientada al *documento* y flash orientada las *aplicaciones*. Los desarrollos empresariales (ERPs, sistemas de información corporativos, …) son soluciones de miles/millones de lineas de código que no pueden estar basados en una amalgama desordenada de scripts. El desarrollo y posterior mantenimiento de esas aplicaciones sería muy costoso y en muchos casos imposible de llevar a cabo. La orientación a objetos es crucial en este campo.

¿Que podemos esperar en un futuro de HTML5 y de Flex?

Está claro que si Google, Apple, Adobe y otras muchas están apostando por HTML5 en un futuro será la tecnología predominante. Pero ese futuro no será real hasta dentro de al menos 4 o 5 años. En mi opinión muchos de los problemas que existían en Flash debido a malos programadores los veremos nuevamente en HTML5 ya que no es un problema de la tecnología y si de hacer un buen uso de las mismas.

Por el contrario Flex es la opción real hoy en día para aplicaciones empresariales de cierta envergadura. Como Adobe dice en su última entrada: Nada ha cambiado de un día a otro en el estado de HTML5 y la realidad es que entrar hoy en día en HTML5 supone un alto coste, una alta incertidumbre y estar dispuesto a sufrir los problemas de una tecnología que, lejos de estar madura no soporta la mayoría de las necesidades que actualmente ya están resueltas en Flex.

Además, y según noticias de última hora, Adobe donará Flex a la fundación Apache, donde residen la mayoría de proyectos open source más importantes de los últimos tiempos (Apache Tomcat, Apache Maven, Apache Web Server,…). Esta noticia es muy positiva, ya que el nuevo empuje de la tecnología será llevado por personas con un entendimiento de los problemas mucho más acertado, en mi opinión, que la propia Adobe, cuya filosofía era por naturaleza distinta y más centrada en la venta de “cajas” y herramientas para la edición de contenido.

Además Adobe asegura que el Flash Player continuará soportando las aplicaciones Flex y que Flash Builder esté actualizado con los cambios en el SDK bajo el gobierno de la fundación.

Asi mismo un equipo de ingenieros de Adobe estará asignado a tiempo completo a seguir mejorando Flex que continuará con la evolución marcada para la siguiente release.

En resumen

Realmente nada cambia por el momento. Yo diría que incluso hay mejoras gracias a que Apache formará parte fundamental de la evolución de Flex. Todos los que estamos ahora en Flex tendremos la oportunidad de ver como evoluciona la tecnología (tanto Flex como HTML5) y podremos ir girando progresivamente con las mismas según nuestros intereses. Es de esperar que en el futuro todas las empresas que están empujando el carro de HTML5 lo hagan viable, no solo para moviles o para webs, si no que también consigamos herramientas y mejoras del lenguaje (alguna plataforma OOP sobre la que desarrollar), de forma que HTML5 sea viable para aplicaciones empresariales.

Por el momento HTML5 NO es una opción si tú segmento es el de las aplicaciones empresariales. No lo es hoy y no lo será por los próximos 3 o 4 años. Mientras tanto y durante ese tiempo la mejor opción que tienes es Flex.

Ya tendremos tiempo de ver si HTML5 realmente funciona y consigue evolucionar hacia algo realmente interesante…y si por descontado, los coches eléctricos terminan siendo una realidad

Esta nueva versión 4.5 de Flex y de su entorno de desarrollo Flash Builder es sin duda alguna la mejor hasta la fecha con notables novedades a destacar. La mayor de ellas es la nueva orientación hacia dispositivos móviles que adopta Flex, añadiendo las plataformas Android, iOS y BlackBerry, a la gama de “pantallas” sobre las que podemos desplegar nuestras aplicaciones y contenidos SWF.

Sin duda Adobe ha trabajado muy duro en conseguir que Adobe Flash Player rinda a la perfección en dispositivos moviles y tablets con Flash Player 10.2 y continua mejorando la tecnología sabiendo la importancia que tendrán dichos dispositivos en los próximos años. La filosofía “Write Once and Run Everywhere” alcanza con esta versión una importancia relevante a tener muy en cuenta a la hora de enfocar un desarrollo RIA.

Por último aprovechar este post para dar públicamente las gracias a Adobe por incluirme en los creditos de esta versión de Flash Builder 4.5!

No lo dudéis! bajad los nuevos bits y probar las novedades y el entorno pues vereis grandes mejoras de productividad y rendimiento que no os podeis perder.

Go Flex Go!

La aplicación hace uso intensivo de las nuevas capacidades de AIR 2.0 para comunicarse de forma nativa con procesos del sistema operativo (NativeProcess API). Además ha sido diseñada pensando en la sencillez máxima: Simplemente basta con arrastrar los documentos que queremos firmar a la aplicación y hacer “click” en el botón firmar para tener todos los documentos firmados en pocos segundos.

Puedes descargar una versión de evaluación de 30 días del producto para Windows o Mac desde aquí.

A su vez es de esperar que Made In Flex y CEV aprovechen los conocimientos del equipo de MIF en estas tecnologías y las estupendas instalaciones del CEV para ofrecer nuevos eventos para beneficio de toda la comunidad.

Os dejo la nota de prensa:

CEV Y CODEOSCOPIC: ACUERDO DE COLABORACIÓN

GeoStratum es un sistema de información basado en un visor cartográfico sobre el que podemos desarrollar diferentes aplicaciones basadas en visualización georeferenciada.

La usabilidad de una aplicación de estas características alcanza niveles excelentes gracias a la sencillez de navegación, basada principalmente en clicks y movimientos del ratón, en contraposición a los típicos formularios de las aplicaciones de gestión tradicionales y la exposición de la información de forma espacial sobre localizaciones geográficas en vez de las tablas de datos normales en estos casos.

Este es sin duda un buen ejemplo de aplicación RIA, desarrollada sobre Flex y JEE, por uno de los equipos de producción de Codeoscopic. El concepto principal detrás del producto es el poder extender la base GIS para añadir información propia de un negocio concreto. En ese aspecto, GeoStratrum 2.0 es la herramienta apropiada para gestionar infraestructuras de suministro (agua, electricidad, etc), planes urbanísticos, líneas de transporte (metro, autobus,…), servicios de logística, polígonos industriales, parques naturales, etc…

Codeoscopic nace para unir fuerzas y congregar a muchos de los grandes profesionales de nuestro sector bajo una misma marca que aporte un significado claro de calidad y compromiso. La buena trayectoria de empresas como carlosrovira.com y Prexon Consulting durante los últimos dos años, unido al boom de los aplicativos RIA de última generación con Adobe Flex, nos han conducido a esta evolución natural y a la necesidad de crecimiento de estas dos jovenes empresas generando una mayor y más potente capaz de asumir los nuevos retos que nos depara el mercado actual del desarrollo software.

Codeoscopic cuenta con sedes en Madrid y Barcelona (Sabadell) para dar soporte a sus clientes de forma eficaz y cercana. Entre sus clientes, Codeoscopic cuenta con marcas de reconocido prestigio como: Metro de Madrid, Carolina Herrera, Grifols, InfoBolsa, Indra, Rugoma Cartografí­a por nombrar algunas.

En lo que a mi respecta, me ocuparé de las tareas de Dirección Tecnológica de la empresa, centrandome actualmente en las tendencias RIA que siempre hemos aconsejado y que tan buen fruto están dando.

Os invito inicialmente a visitar la web de Codeoscopic de la que hablaremos en otro post para conocer algunas caracterí­sticas técnicas muy interesantes que aporta al desarrollo de webs creadas con Adobe Flex.

Larga vida a Codeoscopic!

Este nuevo evento tiene un montón de charlas muy interesantes donde podremos conocer todo lo nuevo que está preparando Adobe:

Flash Builder 4 (el nuevo Flex Builder), Gumbo (Flex 4), Spark (el nuevo juego de componentes de Flex4), Flex Unit 4, Flash Catalyst.

También tendremos otros temas que son igualmente muy interesantes: Flex + SEO o como hacer webs Flex Indexables y por otra parte, una comparación de frameworks : Cairngorm, Swiz, PureMVC y Mate.

Todo esto amenizado por el buen rollo y ganas de compartir que siempre tenemos en los eventos que organizamos en Made In Flex.

Sin desperdicio ¿no?. Podéis leer más aquí­. Si queréis asistir no olvidéis registraros aquí­ !

Nos vemos el 5 de Junio en Barcelona!

Históricamente, este problema se ha resuelto con una técnica denominada Lazy Loading, de forma que nosotros podemos definir para nuestras entidades que propiedades deben de ser “Lazy” y no deben de ser iniciadas al ejecutar una query. Es decir, se trata de reducir el conjunto de datos que viajaran por la red, accediendo solo a lo necesario.

El problema con BlazeDS y LCDS es la forma de serializar la información para enviar los DTOs hacia el cliente que se lleva a cabo inicializando TODAS las propiedades del objeto, lo que obliga en caso de relaciones complejas a que se empiece a tirar del hilo y terminemos trayendo más datos de los requeridos.

En el caso de GraniteDS, existe una solución basada en externalizers, pero esta es torna demasiado compleja y tediosa de implementar ya que obliga al desarrollador a escribir un par de métodos por entidad definiendo la forma de serializar-deserializar los objetos que viajarán por el cable y especificando que propiedades se añadirán o no. En BlazeDS/LCDS, no existe por el momento una solución oficial para solventar este problema, y en principio no tiene porque haberla ya que esto no es del dominio de este software.

RIAlity, por el contrario, si es una arquitectura que debe solventar este tipo de problemas. Por eso hemos buscado una solución elgante, flexible y transparente al usuario. Esta basada en un Interceptor que se aplica a nivel de DAO. Básicamente lo que se hace es aplicar un aspecto (AOP) a todos los DAOs de forma que se intercepte la llamada a la recogida de resultados. En ese momento se aplica la funcionalidad que elimina el proxy que genera Hibernate de forma que tratemos con las entidades originales y evitemos la lógica interna del proxy que provoca que traigamos esos datos de forma innoportuna.

Esta solución permite que el usuario no se preocupe de las interioridades y decida como quiere tratar con sus entidades. Solo tenemos que indicar en las propiedades habituales si queremos un comportamiento EAGER o LAZY .

Continuando con la serie de videos, vamos a ver una demo de como generar un proyecto de modulo para RIAlity. Este proyecto ya estará configurado para usar las librerias de RIAlity, compilar en la carpeta de despliegue de la aplicación web, compilar usando los reportes del login y el shell para reducir los tamaños del modulo y otras muchas cosas.

De nuevo con unos pocos clicks de raton y en pocos segundos nos ahorraremos la tediosa configuración de todos estos parametros y estaremos listos para desarrollar la funcionalidad que queramos.

En el siguiente video, mostraremos como generar el código de una entidad sobre los próyectos generados en los pasos anteriores.