Esta es la narración de una historia de amor. Breve, intensa y que terminó de forma brusca, contra un muro.

Todo empezó con un encuentro tan casual como inevitable.

Por un lado un estudio digital buscando una herramienta que hiciese el desarrollo de aplicaciones web más eficaz, fiable y escalabale, y que abriese la puerta a exportar ese conocimiento para generar aplicaciones móviles.

Por otro, con uno de tantos frameworks de JavaScript ofreciéndose cual sandía abierta en la red de redes (saludos a los señores periodistas digitales de los mass media).

 

Qué inocente parece, tan sencillo, pulcro y fácil de instalar.

Dentro de las opciones disponibles, estaban los nombres habituales: Angular, React, Ember, Backbone

Pero uno llevaba desde hacía un tiempo llamando poderosamente la atención de todo aquel que se adentraba en este mundo: Vue.

Sus virtudes eran obvias: ligereza, rapidez, versatilidad y sobre todo una curva de aprendizaje de lo más agradable, en la que con un conocimiento previo de HTML/CSS/JavaScript podías obtener resultados muy vistosos de forma casi inmediata.

Para un estudio modesto, en el que la inversión en I+D no puede competir con la de grandes corporaciones al estilo Weyland-Yutani, era una verdadera tentación, imposible de resistir.

El tiempo es dinero, y si un 89% de los desarrolladores decían en 2016 estar tan satisfechos con él como para volver a usarlo, no había más que pensar.

Así, la relación nació llena de ilusión, con un primer acercamiento a la reescritura del Rand-o-matic muy rápida y vistosa.

Versión 0.1 del Rand-o-matic Vueizado. Jusqu’ici tout va bien.

El Tocstrap, como buen amigo, echó una mano en ello, y todo parecía ir sobre ruedas, pero ya sabemos que al principio la pasión lo tapa todo.

El problema vino, como tantas otras veces, con una tercera persona.

Llegó la hora del cambio, de dar el siguiente paso y comprometerse a ser capaces de hacer aplicaciones móviles.

Deberíamos haber empezado a sospechar cuando la elección del framework que debía ayudarnos a conseguirlo no se mostraba con claridad ¿Weex? ¿Cordova? ¿Phonegap? ¿Quasar? ¿Framework7? ¿Ionic? Cada uno tenías sus ventajas e inconvenientes, algunos ya los conocíamos y no nos convencían, otros estaban en un estado de desarrollo demasiado temprano, otros no estaban pensados para funcionar con Vue sino con Angular, otros eran de Adobe…

Con las dudas propias de quien da un like en Tinder a alguien que solo tiene una foto, optamos por Weex. Parecía la opción menos mala dentro de las posibles.

Weex.

Recordad ese nombre. Anotadlo junto al de Summer.

Los problemas empezaron a manifestarse desde el principio, una vez metido entre medias de la relación.

El hecho de tratar de hacerlo funcionar en un entorno Windows no hizo sino agravarlos ¿Pero qué clase de futuro podía esperarnos si no era capaz de resistir una prueba tan dura? Variables de entorno, actualización de Node, instalación de Android Studio, JDK y drivers del dispositivo, añadido de la plataforma de Android… todo lo que en el ecosistema Web App había sido fluidez y avance, aquí se volvía barricadas, retrocesos y desesperación.

Cuando creíamos haber logrado por fin deshacer el nudo, se volvía a enmarañar y había que volver a empezar.

Y para colmo, al ser un proyecto de Alibaba y estar poco extendido aún, gran parte de las dudas había que resolverlas en chino ¿Os imagináis Stack Overflow en chino en vuestro día a día? Intentadlo.

Gracias chicos, pruebo lo que decís y os cuento

El golpe definitivo vino cuando tuvimos que añadir estilos: instalación de paquetes de node (style-loader, css-loader), intentos de importación de ficheros externos, como si de un componente se tratase, intentos de carga asociados a <style>, intentos de carga de todo nuestro Tocstrap incrustado inline. Nada, que no había forma de que aquello cogiese los estilos. Estábamos intentando forzar algo que había nacido fracasado.

Y la culpa fue nuestra, por fiarnos. Por no leer la documentación y ver esto:

The CSS standard may support a lot of selectors, but now weex only support single-class selector.

The CSS standard can support many types of length units, but now weex only support pixel, and the px unit could be ignored, you can write number directly.

The styles of Weex cannot be inherited to children elements, this is different to the CSS standard, such as color and font-size.

The CSS standard contains a lot of styles, but weex only sopport few styles which include layouts such as box model, flexbox, positions.

¿En serio?

¿Y nos dices ahora que estás casado y tienes hijos?

¿De verdad no crees que es algo que deberías poner en tu página home para que, si empiezo algo contigo, sepa a que atenerme?

No sé, algo así como en letras mayúsculas, a tamaño 70 y en #f00. Está bien, no podíamos echarle la culpar, la información estaba ahí, algo escondida, pero estaba. Y nuestra obligación era habernos informado antes de tirarnos a la piscina del I+D.

No era momento de buscar culpables, sino soluciones.

Bien, bien… lo que se dice bien… ahora mismo no me caes mucho

Así que hicimos lo que hemos aprendido en tantas películas: cortar.

Asumir que aquello no iba a ningún lado, que no estábamos hechos el uno para el otro. Ta vez en dos años hubiese tenido más sentido, pero no ahora, nos habíamos equivocado con el momento.

Hicimos limpieza, nos quedamos con la parte de Vue que aún podía salvarse para hacer Web Apps de forma rápida y ligera, y nos pusimos a buscar otra pareja con la que seguir recorriendo al camino.

¿Cuál fue nuestra elección? Solo adelantaremos que, como decía Hitchcock, «en caso de duda lo mejor es refugiarse en lo conocido«.

 

 

 

 

 

Invitamos a Juan Vázquez, desarrollador Ruby y cofundador de Sociack, a que nos cuente sus sensaciones en su visita desksurfing a nuestras nuevas oficinas.

No fue mi primera vez, ni tampoco será la última que haga desksurfing. Si aún no sabes de qué va el tema, te sugiero que des una vuelta por Google y mires qué cosas más chulas ocurren en torno a este movimiento.

Como te decía, hace unas semanas los chicos de Elemento115 me invitaron a que pasara los días que me iba a quedar en Madrid, trabajando desde sus oficinas en Pirámides.

La idea era redonda: tenía sitio para trabajar como si se tratase de mi oficina, rodeado de “compañeros del metal” como diría Bonilla, internet, risas y lo más importante, aprender cómo funciona otro equipo aunque solo fuera por 2 días y medio. Fue un win-­win.

Yo estoy ahora mismo en Dublin, trabajando en un equipo similar en características pero con un entorno y una historia muy distinta.

Ellos son un estudio que da servicios de desarrollo mientras que yo estoy en el lado de la empresa de producto único.

El poder contrastar qué y cómo llevan a cabo el día a día te da un punto de vista de qué hay en común y qué se puede mejorar/cambiar en tu propio equipo.

Lo mismo en el sentido contrario.

El desksurfing es un win-win

Si tienes un equipo con oficina física (nada de remoto, este es otro tema), deberías unirte a ofrecer un puesto a visitantes como yo.

Piensa lo barato que sale el hecho de tener a un profesional que puede ver el funcionamiento de tu equipo y darte una idea que te permita mejorar tus procesos ahorrando costes, que ahora puedes invertir en algo que te haga falta y todo por el uso de una silla, un escritorio y acceso a tu wifi.

Como dije un win-­win.

Foto de la visita desksurfing de Juan Vázquez con el equipo de Elemento115

Un selfie de Juan con el equipo de Elemento115

Tanto si eres nuevo en esto del desksurfing como si eres veterano, si estás o pasas por Madrid tienes que hacerles una visita a los compañeros de Elemento115 para vivir el buen rollo que tienen siempre (mira que son majos los joios) y por descubrir que hay formas de vivir tranquilos y sin presiones, si se tiene todo planeado cómo debe ser.

¡Nos vemos en la siguiente visita a Madrid!

__

Juan Vázquez, desarrollador Ruby y cofundador de Sociack
@jnillo9

La semana pasada llegaba, de la mano de Firefox 52, la primera versión definitiva en producción de Grid Layout. Dos días más tarde le seguía Chrome 57, y es de esperar que Safari lo haga en breve, incluso han publicado ya un artículo en su blog con una introducción a Grid. A Edge de momento no se le espera, salvo soportando la anterior especificación.

La importancia, posibilidades e impacto que tendrá en la forma de trabajar, la poco habitual simultaneidad en el soporte de los principales navegadores, así como el largo y tortuoso camino seguido hasta llegar aquí, hacen de este lanzamiento uno de los eventos más importantes en la historia reciente de CSS.

Pese a que no han faltado los primeros bugs en Chrome, con extraño diagnóstico incluído, parece el momento adecuado para leer el estupendo tutorial de Rachel Andrew, esta guía tan completa o tal vez prefiramos empezar con el sencillo inicio que propone CSS-Tricks, en donde nos encotramos una cita de Jen Simmons que convendría no perder de vista:

We need to explore CSS Grid until we understand what it wants to do, what it can be forced into doing, and what it refuses to do. Many designers may not ever learn to code CSS, but you need to understand CSS well enough to understand our artistic medium.

No sería la primera vez que la llegada de una nueva tecnología, o incluso una forma totalmente nueva de abordar el trabajo, nos lleva a forzar los límites y caer en un uso incorrecto de la misma. Leamos, aprendamos, pongamos en práctica y disfrutemos. Se nos acaba de abrir un nuevo horizonte 🙂

Elemento115-La-hipotesis-de-la-Reina-Roja

Lo que es aquí, como ves, hace falta correr todo cuanto una pueda para permanecer en el mismo sitio.

-Dijo la Reina Roja.

 

Es una frase que hace años me obsesiona, y que describe muy bien la exigencia que me impongo, y el cómo siento y vivo el crecimiento personal y profesional.

Para mí significa el esfuerzo constante, por evolucionar y aprender, para poder estar a la altura de los retos que se nos presentan.

Desde que fundamos Elemento115, es una idea que también aplico en la empresa.

Nos dedicamos fundamentalmente al desarrollo de aplicaciones web B2B y eso, creedme, requiere una actualización, tensión competitiva y evolución constante.

En nuestro sector, la investigación y uno de sus frutos, la innovación, son inherentes al trabajo, y partes imprescindibles del mismo.

Básicamente, nos permiten, como empresa, conocer mejor al problema que nos enfrentamos, dotarnos de herramientas para resolverlo y mejorar el proceso para hacerlo más competitivo.

Resolver problemas que no se conocen en profundidad, con las mismas herramientas y método, volviendo a la Reina Roja, no solo nos limita como empresa, nos dejaría atrás en pocos meses.

 

Problemas y obstáculos

Sin embargo, dedicar el tiempo adecuado a la investigación es complicado, nos enfrentamos a dos obstáculos muy importantes: la inercia por permanecer en la zona de confort, y la necesidad de atender a tareas urgentes.

En las últimas retrospectivas, hemos ido tratando el problema, buscando un sistema para superar esos obstáculos, y eso nos ha conducido hasta aquí.

No os puedo decir que el camino hasta este post haya sido agradable o fácil, pero sí que ha merecido la pena, por que hemos aprendido y hemos llegado.

I+D Tortilla – Buffer I+D+i

En la última retro, acordamos abordar el problema de una forma más sistemática, obligándonos a incorporarlo en nuestras rutinas, y compartiendo el proceso y los resultados.

Primero, somos gordos. Qué mejor que relacionarlo con la comida. Los viernes, haremos una pequeña parada para comer Tortilla de Patata, será el momento I+D Tortilla.

Durante una media hora o cuarenta y cinco minutos, tendremos una charla en la que abordaremos los siguientes temas:

  • Recopilación de tecnologías, herramientas, procesos, etc… que puedan merecer una investigación en profundidad.
  • Priorización de esa lista, para incorporar lo que nos parezca más interesante y relevante para el estudio, lo que se incorporará al «buffer» o planificación de investigaciones.
  • Repaso del estatus de las investigaciones en curso.
  • Presentación de las conclusiones, cuando toque, de una investigación concreta.

Para incorporar un tema al buffer de I+D+i, son necesarios definir, a día de hoy, los siguientes aspectos:

  • Objeto de la investigación, ya sea una técnica o tecnología, una herramienta, un proceso, etc.
  • Líder o responsable de llevarla a cabo.
  • Objetivos de la misma, qué hipótesis o preguntas debe responder.
  • Método, herramientas y personas que participarán.
  • Entregables que requiere y dónde queda documentado el proceso.
  • Fechas marco o fechas límite.

¿Y si no funciona?

Ya os contaré, muy pronto empezaremos a ver los resultados, o en todo caso, detectaremos que no funciona el método y tendremos que buscar otro.

La cuestión es seguir corriendo todo lo que podamos. =)

Recursos y referencias

Wikipedia: La hipótesis de la Reina Roja

Wikimedia: Alicia en el país de las maravillas

Youtube: La metáfora de la Reina Roja en la teoría evolutiva

 

Manuel Barroso Parejo.
Comandante de la misión Elemento115.
mbarroso@elemento115.es
@manubarpar