Método de innovación

Nos  cambiamos a otra dirección

¿Utopía tecnológica?

Technology is only as good as the people creating it.~Clint Borgen.

Durante los últimos dos años pude visitar dos lugares que podrían considerarse opuestos. Por un lado visité una de las ciudades de la "meca del movimiento maker", San Francisco, donde todos quieren tener la ultima idea innovadora, el ultimo gadget, todos hablan de startups, existen espacios y recursos para crear cualquier idea, donde encuentras ingenieros de todos lados del mundo queriendo ser parte del movimiento y la gente se apasiona con dicha profesión y por los temas que aborda. Por otro lado visité un país congelado en el tiempo, Cuba, donde no se encuentran o no es tan fácil encontrar muchos recursos, es difícil y caro tener el ultimo gadget, donde la ingeniería ha tenido un papel de reciclador y proveedor, más que de creador y donde las personas se apasionan más con profesiones que giran en un entorno artístico.

En mi estancia en San Francisco descubrí muchas ventajas de vivir ahí siendo ingeniero en ramas relacionadas con el movimiento maker.

• Los espacios makers, los cuales son lugares donde puedes rentar maquinaria como tornos, fresadoras, impresoras 3D y todo lo necesario para poder crear prototipos.
• El internet funciona, no solo por su buena velocidad si no que los servicios de paqueteria son económicos y rápidos, lo cual agiliza muchísimo el desarrollo de hardware.
• Existe una gran cantidad de gente en este movimiento, la cual impulsa más estos servicios y la creación de nuevos startups y productos. 

En nuestra forma innovadora de pensar podría pensarse que San Francisco es el modelo a seguir, nuestra inspiración, con startups nuevos cada día y con lo último en tecnología siendo parte de la vida diaria. Pero al mismo tiempo no me sentí totalmente cómodo, San Francisco es de las ciudades más caras para vivir en Estados Unidos, esto unido a los pocos servicios gubernamentales para personas con enfermedades mentales genera una gran cantidad de pordioseros, en general la calle es un lugar hostil, donde las pandillas y las peleas son fáciles de encontrar,  la clase media utiliza dicha tecnología para aislarse de esa realidad y  la población joven esta obsesionada con la tendencia actual de "ser tu mejor versión", es decir, hacer ejercicio, comer saludablemente, ser ecológicamente responsable, tener una vida social y cultural muy activa, tener todos los dispositivos tecnológicos nuevos y presumir todo lo anterior con tu apariencia y redes sociales, pero dicha tendencia es individualista y ajena a todos los problemas sociales externos. Tienen la tecnología más innovadora, pero están lejos de una sociedad justa y sana.

En nuestra cultura se pinta a Cuba  como un país pobre a causa de un modelo económico fallido. Dependiendo tu ideología se tiene un culpable distinto para su situación actual, pero en general las personas concuerdan que es un país con muchas necesidades.

Al visitarlo pude comprobar que es cierto esto, Cuba tiene muchas necesidades y la mayoría de la gente vive humildemente. Sin embargo existe poca pobreza extrema, durante todo mi recorrido por el país, desde La Habana hasta Sancti Spiritus encontré menos pordioseros que en San Francisco. Es verdad que vi zonas realmente pobres, pero en general su calidad de vida era mejor. Existe poca hostilidad en la calle, la mayoría de la gente te ayuda cuando buscas direcciones(tal vez demasiado), en todos los lugares conoces gente nueva(ya que se acercan y te integran fácilmente), son muy cálidos(aunque a veces falsos, como buenos latinos) y existe poca delincuencia.

Cuba esta muy lejos de ser perfecta, tiene mucha escacez de servicios y recursos, la gente tiene una relación odio amor con el turista. Por un lado su economía vive gracias a el, en el ven una puerta al extranjero y muchos tienden a aprovecharse de el, por otro lado se sienten en un "zoológico" y un burdel, la gente viaja a ver como viven, a "visitar el pasado", sus coches antiguos, su arquitectura vieja, desconectarse de internet, de su realidad, visitar su realismo mágico,  muchos simplemente viajan por turismo sexual, pero no se dan cuenta que para los cubanos esa es su realidad y añoran tener eso que les hace falta. El cubano tiende a exagerar las cosas, tanto negativas como positivas y esto es parte del por que la gente polariza a Cuba,  frases políticas como"el bloqueo es el genocidio más largo de la historia" pierde impacto cuando toda la mañana escuchaste frases como "este es el mejor mojito del mundo" o "la cucaracha más grande que he visto en mi vida" y al estar presente sabes que no es así. Mucha de su juventud vive añorando lo que no tiene, fantaseando con lujos y dinero e idolatrando a Estados Unidos, al final de cuentas de igual forma se aíslan de su realidad.

En Cuba los ingenieros no son los héroes, son solo una profesión más y no tienen una visión transformadora para el país, su tarea se basa en reciclar y reparar tecnología vieja y los ingenieros jóvenes se dedican a tareas poco trascendentales como desbloquear celulares. Lo que mantiene vivo el espíritu de Cuba(como en San Francisco es la tecnología) es el arte. La gente en general tiene mayor cultura (aunque existen muchos fanfarrones y gusto por expresiones musicales no tan elevadas) y se refleja en la vida cotidiana. Un ejemplo burdo de esto es que si en México dices "estudio ingeniería" te responderán "que padre! mi hijo quiere estudiar eso" y si le dices "estudio arte" te responderán "y de que vas a vivir?" en Cuba al hacer las mismas declaraciones les dará igual que estudies ingeniería y el hijo o sobrino de todos quiere estudiar arte... o medicina. El arte está presente en todos lados, les sirve para expresar su identidad única,  al vivir del turismo tienen una fuente de ingresos constante en materia de artesanías y muchos artistas se dan a conocer gracias a eso y es una buena puerta al extranjero, tanto de entrada(estudiantes) como de salida, convirtiendo al arte  no sólo en una actividad muy atractiva para las personas si no en la mayor actividad innovadora del país.

Como ven ciudades como San Francisco no son mejores que La Habana, pero tampoco al revés, cada sociedad tiene sus puntos fuertes y sus errores. Es ingenuo creer que un modelo económico o político contiene todas las respuestas. De igual forma es ingenuo creer que la tecnología nos llevará a un mundo mejor. Así como somos agnósticos a la hora de seleccionar una herramienta tecnológica, debemos ser agnósticos en el misma integración de la tecnología. Cada caso es singular y se deben inspeccionar las ventajas y desventajas de una implementación tecnológica. Innovar es dar valor y en muchas ocaciones el valor existe en algo ya instaurado y solo se debe perfeccionar

Como innovadores debemos mirar en todas direcciones, aprender de lugares tan distintos como San Francisco y Cuba, ser multidiciplinarios, aprender tanto del arte como de la tecnología, de lo viejo y de lo nuevo y nunca quedarnos con nuestros paradigmas.

Para terminar la entrada hablaré de un caso práctico. En el ultimo día de la conferencia de San Francisco, hablaron del arte en la ingeniería, de como artistas estaban utilizando herramientas tecnológicas como programación y maquinas de prototipos rápidos, enriqueciendo nuestro campo por su forma de pensar. Tambien  hablaron sobre la industria de fabricación de órganos, donde el anexo de la tecnología generó más mal que bien. El error de una empresa había sido poner servomotores en las válvulas del órgano, lo cuál disminuyo los costos considerablemente, pero el organista perdida la capacidad de sentir como la válvula se abría al tocar y perdía gran dominio del instrumento. Por más que económicamente parecía que hicieron lo correcto, decidieron regresar a tecnologías viejas, porque en ellas el organista encontraba un mejor desempeño, esta decisión salvo a la empresa y a la larga les dio más clientes,  ahora su innovación se centra en perfeccionar métodos antiguos de construcción de órganos, los cuales son una obra maestra de la mecánica. Al dar la presentación se le hacia extraño al expositor que lo hubieran invitado en una conferencia donde todo reflejaba el estado del arte en hardware. Pero así como la selección natural la innovación no favorece a lo nuevo, solo lo que mejor se adapta.

Algunos aspectos que ayudaría a mejorar la productividad.

A continuación se presentarán algunos puntos que a muy grandes rasgos podrían ser útiles para mejorar la productividad, hacer eficiente la planeación y ahorrar tiempo.

• Las juntas máximo deben de ser de 30 minutos. Recordemos que tiempo es dinero, si dura más tiempo, probablemente no se optimizó lo suficiente o se debería de dividir en un par de juntas pero, de nuevo, máximas de 30 minutos.

• Algo que también quizá sería importante adoptar, es que deberán ser citados sólo las personas necesarias, sino será tiempo perdido para aquellos que no es necesaria su participación. O sea, si se necesita la presencia de todos como para un tema ‘contexto’, es válido. Pero una vez concluido el tema, los que no participarán más, que se puedan retirar para seguir sus labores.

• Recordemos también que quizá los horarios hábiles no son los mismos para todos los integrantes del equipo, con lo que considero que puede ser buena idea, corroborar los horarios hábiles de todos los citados para checar la intersección y en esa intersección establecer la junta. Porque sino, probablemente los participantes estén dispersos.
  
  Por ser junta, debería de existir una planeación de los puntos a tratar, con el fin de optimizar al máximo el tiempo de todos y ser lo menos redundantes posible.

• Algo importante respecto al trabajo y la productividad es la colaboración del equipo y la comunicación al cliente. Se debe de planear, delegar tareas y establecer tiempos para que se realice el proyecto en tiempo y en forma. Respecto al cliente, para establecer, (e.g.) que, en caso de alguna modificación, se deberá extender el tiempo de entrega o costo, dependiendo el cambio solicitado.
  
• Por ser proyecto, muchas áreas están unidas para completar dicho proyecto, por tal motivo, comunicación interna es crucial para el cumplimiento de lo planeado. En caso de que un cambio sea requerido, se necesita avisar a todo el equipo para ponderar y ver si es o no viable. Suponiendo que el cambio es obligado, se deberá notificar el avance a los integrantes del equipo para evitar dependencias en tiempo o espacios muertos. No se debe de dar por entendido.

• Asimismo, la lista de requerimientos debería de ser cumplida con el fin que los integrantes del equipo del proyecto no trabajen el doble o menos que otros. El chiste es que el trabajo de cada uno se sumen para lograr una sinergia. No esfuerzos aleatorios o incompletos.

¿Ciencia de Datos en los deportes?

La información que se genera a partir de datos, tiene un valor en diversos campos e industrias, por ejemplo, los datos se han empezado a utilizar en la fabricación, operaciones y procesos de los fabricantes de automóviles, electrónicos e industriales, pero ¿qué pasa en otras áreas como los deportes?, miles de personas asisten continuamente a eventos deportivos llevando consigo sus teléfonos inteligentes y por ende sus datos, de los cuales, podemos identificar ideas valiosas, que pueden ser de utilidad tanto para las franquicias deportivas como para los propios aficionados.

El evento del Super Bowl 50, contó con alrededor de 112 millones de espectadores a nivel mundial, sin contar los que estaban viendo el partido a través de un servicio de streaming. También hay que considerar que asistieron más de 70.000 personas al estadio, que pudieron haber juntado alrededor de 50.000 teléfonos inteligentes en el estadio simplemente.

Si consideramos que existen diferentes formas de cómo todos estos datos pueden ser extraídos y utilizados para la acción. En el 2012, la Universidad del Sur de California Annenberg Innovation Lab (AIL) llevó a cabo un análisis en tiempo real de los mariscales de campo de ese Super Bowl, Tom Brady y Eli Manning. 

Se obtuvieron y analizaron miles de tweets públicos en diferentes tonos, sarcasmo, sinceridad, positivismo, etc., logrando descubrir algunas cosas. La opinión pública es muy voluble, la comprensión del consumidor cambia rápidamente.

También se descubrió un tipo de predicción de rendimiento basado en estadísticas de los jugadores, al conectar los datos a una herramienta de análisis predictivo, se puede obtener una buena idea de qué jugador va a funcionar mejor o qué equipo va a ganar. 

Esta tecnología puede parecer un poco demasiado como de ciencia ficción para imaginar un mundo en el que es posible, ahora pensemos ¿Qué haría si tuviera estas herramientas a su disposición? En la actualidad, no podemos limitamos a recopilar, analizar e interpretar los datos, podemos utilizarlos para tomar acciones reales.

Este mercado es valioso; de acuerdo con PricewaterhouseCoopers (PwC), se proyecta que los ingresos del mercado mundial del deporte crecieron anualmente un 3.7% de $ 121.4 mil millones en 2010 a $ 145.3 mil millones en 2015. Ahora tenemos las herramientas para ayudar a las franquicias deportivas a activar sus esfuerzos de obtención de puntos de vista que pueden ayudar a identificar las actitudes, tendencias de comportamiento para alinearse con las preferencias personales, ideas de los aficionados del equipo deportivo.

Las preocupaciones de los directores deportivos en cuanto a cómo aumentar la lealtad a la marca, identificar qué es lo que los aficionados quieren y cuando lo quieren, encontrar la manera de aumentar el retorno de la inversión aumentando las ventas de entradas a los estadios o como evitar que los aficionados dejen de asistir a los estadios. También es importante pensar en cómo involucrar a los aficionados del futuro de la generación del Milenio. 

Hoy en día existen tecnologías, soluciones en la nube para almacenamiento de datos y la ciencia de datos para su recopilación, enriquecimiento y análisis de los datos que generan las interacciones con los aficionados, que nos permiten responder o generar una solución, estrategia o campaña basada en la analítica de los datos  

La semana Innbit 14 a 19 de febrero 2016

Esta semana del 15 de febrero fue especial en Innbit.

Desde que se presentó nuestra estrategia 2016 al cuerpo directivo, empezamos a usar nuestras nuevas oficinas.

Todo nuestro equipo de trabajo estuvo en talleres de integración para mejorar nuestra coordinación y poder responder a la dinámica de trabajo de nuestros cliente. Tuvimos que encontrar el balance entre hacer las cosas de manera perfecta y entregar a tiempo para cubrir las oportunidades de negocio.

Utilizamos Lego Serious Play para conformarnos como un equipo listo para apoyar a la innovación y poder alcanzar los retos de la estrategia 2016

Jueves fue para probar dicha integración, creando un puente con bloques de Lego y que puso al equipo en situaciones donde el cliente pide cambios por que así lo requiere.

Se hizo un trabajo muy interesante, donde no sólo el enfoque de ingeniería fue la guía, sino también el diseño basado en experiencia del usuario, el buscar el valor y rentabilidad.

Viernes fue para crear un producto innovador, usando todas las técnicas revisadas en la semana y donde grupos de múltiples disciplinas pasaron desde la fase de idea, obtener el apoyo de un inversionista, la creación y hasta hicimos nuestra exposición para experimentar la emoción de conseguir recuperar el capital invertido y obtener ganancias.

Al final de del día, se vieron que los retos de un equipo de trabajo, es siempre conservar el valor del producto, que sea útil a un cliente y mejorar la idea original a través de lo que las personas te vayan dando como necesidad. Usamos las técnicas de Lean Startup

El equipo acabó cansado y satisfecho, con nuestro nuevo espacio de trabajo, que fue propicio para realizar todas las actividades.

Tiempo atrás tuve esta idea.

Hoy 19 de febrero 2016, ya no es idea sino hechos y confirmo que trabajar bajo un enfoque de innovación es preferible al esquema tradicional de trabajar con total certidumbre y de acuerdo a un complejo cronograma.

Un poco de caos es a veces preferible a matar las ideas de las personas. 

El comportamiento colectivo es mejor a dejar que solo los gerentes tomen decisiones.

Una vez más, satisfecho por las mieles de probar un supuesto y ver que hay verdad dentro de él; y más por que permite enaltecer el espíritu y nobleza de los seres humanos y lograr un trabajo en equipo.

Recurriendo a los recursos para construir soluciones

Cuenta la leyenda que una vez la humanidad intentó colaborar para construir una torre que llegara al cielo. De igual modo los sistemas y aplicaciones se comunican y colaboran desde algún tiempo a través de distintos mecanismos para construir soluciones cada vez más elaboradas y poderosas.

Numerosas tecnologías han desfilado como soluciones a este planteamiento, desde llamadas a procedimiento remoto (RCP), CORBA, Java con RMI y más tarde con los Session Beans hasta protocolos como SOAP y servicios web que transportan información via HTTP.

La tendencia parece ser simplificar cada vez más los formatos de intercambio y exponer la información por medio de protocolos ligeros y estándar para facilitar la transmisión de datos a través de una red, así como el procesamiento de los datos una vez que llegan al dispositivo solicitante.

Hoy en día se escucha mucho de REST y la construcción de interfaces que permiten exponer datos y disparar acciones a manera de servicios desde aplicaciones de terceros.

Algunos casos de uso de un REST API son:

• Integración de sistemas.
• Automatización de tareas.
• Backend para aplicaciones móviles
• Generación de aplicaciones reactivas (Que amerita su propia entrada de blog inspirada por Freya)

En el siguiente vínculo hay una descripción ámplia, precisa y hasta matemática de los conceptos que tienen que ver con REST.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

De igual modo se intentará sintetizar el conocimiento surgido de quebrarse la cabeza (otros objetos alrederor y por poco algunos cráneos) al implementar soluciones y así resaltar algunos puntos relevantes de la forma más pragmática posible.

Entre recursos y otras artes oscuras

Recurso es el concepto clave en REST, el cual es una abstracción de información identificada por un nombre. Ej: Un documento o imágen, una colección de otros recursos, una persona, un servicio, etc.

Los recursos REST son accesibles a través del protocolo HTTP a través de URL's, usando un método específico, como GET , POST , PATCH , PUT y DELETE . Cada método es una solicitud para realizar una operación en el recurso.

• GET. Recupera un recurso 
• POST. Genera un nuevo recurso a partir de los parámetros de la petición
• PATCH. Realiza una actualización parcial en el recurso
• PUT. Realiza una actualización total en el recurso
• DELETE. Elimina el recurso

Algunos ejemplos de rutas estilo REST son:

Verbo HTTP	Ruta	Descripción
GET	/orders	Muestra una lista de órdenes
GET	/orders/:id	Muestra una órden específica
POST	/orders	Crea una nueva órden
PUT/PATCH	/orders/:id	Actualiza una órden específica
DELETE	/orders/:id	Elimina una órden específica
GET	/orders/cancelled	Recupera una lista de órdenes canceladas
GET	/orders/:id/items	Recupera los artículos de una órden específica
PATCH	/orders/:id/send/	Actualiza el estado de una órden específica e inicia el envío

Cabe señanar que el pensar "a la REST", permite organizar la estructura de una aplicación, ya sea un REST API o una aplicación web tradicional,  basándose en una convención dictada por la industria. Esto ayuda a evitar que los desarrolladores o arquitectos "creativos" definan estructuras que pueden llegar a ser muy complejas y difíciles de manterner.

Las 3D's del génesis

Los recursos que son accedidos o modificados son básicamente un conjunto de conceptos relativos a un problema de negocio específico. Cada concepto puede visualizarse como una entidad la cual está descrita por una serie de propiedades y relaciones con otras entidades lo cual para "la bandota" se conoce como modelo del dominio.

Este modelo del dominio nos remite a una práctica dentro de la ingeniería de software llamada diseño dirigido por dominio (domain driven design o DDD), la cual sostiene que el desarrollo de una solución debe estar basada en un modelo generado a partir de conceptos del negocio particular que se quiere abordar así como encapsular la lógica y reglas que dicte el mismo negocio.

Una vez que se tiene un modelo de dominio robusto y probado (donde entra en juego el desarrollo dirgido por pruebas o TDD), solo resta exponer ese dominio como recursos con la acción que aplique para cada caso.

Este modelo del dominio también funciona como un formato homologado de información entre aplicaciones y plataformas, pues independientemente de la tecnología propia de cada solución, las estructuras de datos dictadas por el modelo de dominio pueden ser implementadas puntualmente por cada tecnología, ejemplo.

• Modelos active record para un backend Ruby on Rails
• Clases Java para una aplicación Android
• Clases Swift u Objective C para una aplicación IOs
• Objetos JSON para intercambio de inforrmación sobre HTTP.
• Objetos JSON para una aplicación basada en Angular o JQuery
• Tablas y llaves foráneas para una base de datos relacional
• Documentos JSON para una base de datos MongoDB o DynamoDB

Anarquía de una tierra sin estado

El protocolo HTTP es por definición sin estado, esto es que una petición guarda un registro de otras peticiones. Esto se extrapola a los servicios ofrecidos por un API REST donde una petición específica no tiene acceso a los datos de peticiones anteriores. 

Una gran ventaja de tener servicios sin estado es la facilidad de crecimiento horizontal que se tiene. Dado la naturaleza sin estado de los servicios es posible generar replicas del servicio y solo utilizar un balanceo de carga para incrementar la capacidad de atención de peticiones.

En un ambiente de nube se puede utilizar el concepto de elasticidad para incrementar o decrementar las réplicas del servicio sin necesidad de mecanismos como la replicación de sesiones.  En el caso de Amazon servicios como Elastic Load Balancer, EC2 y Autoscaling permiten hacer esta magia de forma relativamente sencilla con la opción de agregar otras "monerías" como monitoreo, certificados digitales, replicación en otras regiones, etc.

El Can Cerbero Tokenizado

La seguridad es un tema obligado en cualquier solución tecnológica con el fin de garantizar tanto como sea posible la integridad, confidencialidad y disponibilidad de la información.

El uso de tokens es el mecanismo recurrido para implementar ciertas medidas de seguridad. Para esto pueden distinguirse dos tipos de tokens.

• API Token. El proveedor de servicios genera un token único por aplicación que pretende utilizar los servicios expuestos a manera de REST API. Dicho token es solicitado y utilizado para verificar la aplicación cliente. Los API's de Facebook, AWS o Google son ejemplos que utilizan este mecanismo. Una forma de implementar esto es a través de un API Gateway el cual puede ser utilizado para agregar medidas adicionales como prevención de ataques de DoS.
• Access Token o Auth Token. Utilizado para identificar y autenticar una cuenta de usuario de la aplicación. Dado que este mecanismo permite asociar las llamadas a un cliente en particular se vuelve una manera de implementar una sesión de usuario donde el estado conversacional se mantiene en el cliente. 

Dentro de las ventajas del uso de tokens pueden mencionarse:

• Los tokens pueden ser forzados a expirar como modo de revocar el acceso a un usuario o aplicación.
• Los tokens son cadenas alfanuméricas únicas generadas por el REST API, lo que robustece la aplicación ante ataques de diccionario, fuerza bruta o ingeniería social.

Cabe mencionar que los REST API suelen ser expuestos mediante HTTP SSL/TSL y los tokens suelen enviarse como cabeceras de cada petición para evitar el secuestro de sesiones o la alteración de la información que viaja hasta el proveedor de servicios.

Cache-ando ando

Mucha información consultada tiene muy pocos cambios a lo largo del tiempo, por lo que almacenarla en un cache local incrementa el rendimiento de las aplicaciones cliente al reducir la cantidad de llamadas remotas al proveedor de servicios.

Se pueden identificar dos niveles de cache

• Memoria. Mantiene una copia en memoria de los datos recuperados desde la fuente. Se recomienda para cantidades moderadas de datos que son consultados frecuentemente. Ej, catálogos estáticos, información de la cuenta de usuario.
• Archivos. Genera archivos locales a partir de la información recuperada desde la fuente. Empleado para archivos binarios como imágenes y documentos o grandes cantidades de texto.

Cuando se tiene identificada información que cambia periodicamente puede configurarse el cache para que información específica expire obligando a que sea actualizada desde el origen.

De igual modo es posible manejar diversos caches en diferentes puntos de toda una solución. Si bien se hablaba de un cache local en un cliente (dispositivos móviles o un navegador web), también es posible habilitar bases de datos en memoria (Redis, Memcache, Coherence) donde los REST API puedan almacenar información obtenida de otros repositorios (bases de datos, documentos, etc) y así mejorar los tiempos de respuesta.

La asincronización hace la fuerza

Dado que un REST API expone una serie de servicios remotos, es preferible (y en algunos casos mandatorio) acceder al API de manera asíncrona. De este modo la aplicación cliente puede continuar con su labor o incluso consumir diferentes servicios de manera cuasi simultánea. Por ejemplo mientras se está descargando una foto del portal de Suicide Girls, la aplicación puede estar generando una gráfica, recibiendo una notificación y enviando información de uso.

Aunque tanta magia simultánea requiere un cambio de paradigma en como se desarrollan las aplicaciones cliente, pues ahora el modelo de programación es basado en eventos y notificaciones de cuando una tarea asíncrona es concluida.  

El acceso asíncrono, junto con los esquemas para mejorar la disponibilidad y el poder de cómputo distribuido potencial de las aplicaciones cliente (móviles, web browser, etc) pareciera que nos ván remitiendo a terrenos del manifiesto reactivo. Esto me sugiere que un REST API puede ser un componente de solución para implementar una ansiada arquitectura reactiva (alguna vez Gus me dijo que quería construir una aplicación de este tipo). Pero eso será tema de otra entrada de blog y otro sueño de una noche de insomnio y valkirias.

JavaOne 2015 - A sus 20 años -

En mi asistencia a Oracle Open World decidí incluir también al JavaOne.
Primero, era interesante volver a las acostumbradas platicas y segundo por que a los 20 años de cumpleaños de Java era atractivo ver como estaba la comunidad.

Arrancando el lunes y a diferencia del evento hermano, solo asignaron 2 hoteles. Un evento que llegó en el año 2000 a llenar los dos Moscone y con una comunidad internacional, ahora estaba reducido a una exposición con una sala menor a cualquiera del Oracle Open World y no mas de 20 salones de pláticas.

Mi primera pregunta, donde está la comunidad Java!!

Note que parte de esa comunidad estaba ya en el otro evento, y quizá ya no tanto como desarrolladores sino contro rol. De igual manera, aunque gran parte de la plataforma que se tenía en Oracle Open World al final se ejecuta sobre JVM pero ya es otro el giro.

Donde quedo la emoción de cuando se anunciaban mas APIs. Recuerdo en 1999 cuando llenamos la sala y oimos sobre EJB 1.1 o JMS 1.0 o JINI y probabamos de manera inmediata la tecnología.

Viejos tiempos dije y de ahi me di cuenta de otro hecho, la comunidad ya no es joven, ya no eramos esos programadores entre 20 y 30 años. Poca sangre joven note.  Y donde están esos programadores Java, se supone que hay bastante comunidad.

La respuesta está en una comunidad que por rollos legales y comerciales, para ORACLE es más innombrable que Voldermot

Si, Android, y muchos lectores me van a matar, pero si Java se sigue aprendiendo es por que la anti tesis de ORACLE le ha renovado vida.  
En el evento de JavaOne 2015 cero mención a Android. ORACLE aún sigue hablando de Java Micro Edition pero pues creo que nadie me discute que el tiempo ya dio su respuesta sobre lo que resulto con la idea de dispositivos moviles habilitados con Java. No fue ORACLE el ganador...

Que hay de Java 8? Bueno, ya saben, el intento de incorporar algunos elementos de progamación funcional al lenguaje, las tan citadas Lambda. Este ejemplo era muy tipico de ver ...

Si fuera el único mundo de programación Java quizá muchos dirian, que bien, pero esto ya tienen bastante tiempo con lenguajes como Ruby y como siempre he criticado en Java, siempre se ha temido dar ciudadania a expresiones que requiere el lenguaje. Expresiones regulares resulta demasiado complejo frente a lenguajes que si le dieron esa capacidad de ser ciudadanos de primer mundo en la sintáxis tales como Perl, Python, Ruby. Ahora pasa lo mismo con las lambdas. 

Después de 20 años, por fin se admite que el manejo de las rutas de clases o CLASSPATH necesita ser organizado. Era una crítica que hacian los detractores de la platforma. JDK 1.8 nos ofrece una herramienta llamada jdeps para amaestrar el mundo de los cientos de JAR y no vivir la pesadilla de ClassNotFoundException o peores. 

JavaFX, prefiero mejor no hacer comentarios en un mundo donde HTML5 ya resolvió muchos problemas de Interfaz de usuario.

JavaScript es soportado con el motor de ORACLE llamado Nashorn , no es impresionante si ya se conocia Mozilla Rhino. Pero espero que esto permita ver hacia un posible enfoque políglota del ambiente.

¿Que hay de JEE 7? Bueno,  está llegando un poco tarde a una película que ya lleva un tiempo avanzando. Mientras otras plataformas de programación están en busca de ambientes ligeros (ejemplo Sinatra con Ruby o Flask con Python) nuestro viejo conocido framework aun se niega a seguir dieta.  

Si, ya se tiene inyección de la dependencia, JPA ya converge con Hibernate. Aún siguen las discusiones para que usar Spring si ya JEE 7 cubre todo.  Ya se habla de generar microservicios (aunque aun falta mucho por entender de este estilo ). Pero aquí es donde empezaron mis dudas sobre Java hace años, la sobre especificación y la verdad atado a modelos de hace ya una decada que han demostrado no ser tan efectivos. No quiero un Node.js o Ruby ligero, pero creo que la comunidad de desarrollo ya sabe lo que implica programar aplicaciones en el backend y Java EE 7 aún necesita hacer algo para simplificar el tema.

JSF aún sigue seriamente considerado en la ruta de tecnología de JEE y veo de la comunidad ortodoxa aún el alejamiento hacia Javascript.  No quiero ser pesimista pero JSF temo que sufrirá el destino que Java FX a menos que se replantee. O qué sensación tienen al ver este diagrama de JSF 2.0 para entenderlo a fondo.

Nube, nube por doquier pero ... Les comparto esta presentación  y ésta del evento y ustedes juzgen sobre el tema. 

Su servidor no encontró respuestas sobre cual es la manera de diseñar aplicaciones Java para la nube y tenemos que agregar un poco la manera como ORACLE está enfocado el tema de nube y muchas veces no queda clara su estrategia en términos de PaaS  

Hubo temas donde se toco Scala como lenguaje funcional.

Una plática muy interesante desde la perspectiva de ingeniería donde se hizo una consola de juegos de los años 90 usando Raspberry Pi, impresion 3D y mucha electrónica y superando muchos obstaculos.  Estuvo Stephen Chin, quien es ORACLE Java Community Manager.

Internet of Things estuvo presente, pero aún me pregunto por que no han desenterrado el último regalo de ingeniería que nos dejo Biil Joy, JXTA.

El cierre del Vava one fue entretenido. Salvo que al inicio y mas con la cultura de EUA, nos cerrraron las puertas a los que llegamos un par de minutos tarde por falta de espacio.  Ya que pudimos pasar y con una cervez en mano por su error, pude ver un show preparado por la comunidad Java, la guio Stephen Chin, recorriendo en el tiempo estos 20 años con un Tardis tipo Dr. Who y con la aparición de James Gosgling y recuperando la tradición de aventar las playeras. Algunas bromas donde veo como la comunidad aun cree en ciertos principios como verdad única (JSF, JEE, un solo lenguaje, sintáxis cada vez complicada) 

Les comparto el video del Keynote del cierre. Aun me pregunto por que Brasil se nos adelanto como comunidad Java ... Creo que no nos enfocamos a unir la comunidad mexicana, que vaya que si sabemos del lenguaje pero cada uno en nuestro mundo. Se habló de Java para 2035 (y me quede pensando si yo estaría ahí a mis 63 años o si realmenta existiría un Java One 2035)  y ya saben, los niños, el futuro. Pense, quiero que las nuevas generaciones aprendan Java? 

En resumen, JavaOne 2015 fue una experiencia muy interesante, y más que fui en otra óptica, ya no quiero programar todo en Java y se que ese no es el camino. Extrañe a la comunidad joven (ahora en el mundo del desarrollo móvil o aplicaciones Web con Jscript) y también tuve nostalgia por aquellos tiempos donde el mercado Java daba para cientos de empresas que te mostraban tecnología.

Así que no es lo mismo los tres mosqueteros que 20 años después.  

Deseo que el lenguaje continue pero necesita evolucionar ya, necesita morir y renacer, como el ave fénix. A esto escribire otro articulo que se me ocurrió en el mismo evento.