Evolucionamos en tecnologías para innovar en software
El pasado día 16 de noviembre participé en el DevFestAsturias 2019 organizado por GDG Asturias
En la charla hablé sobre los fundamentos de WebAssembly, sus ventajas y los casos de uso tanto dentro del navegador como fuera.
Básicamente que WebAssembly lo cambiará TODO
Como ex-responsable de producto, en mi experiencia, estos son los pasos para conseguir un gran producto:
Lo primero es crear un buen puñado de funcionalidades que según tu opinión harán despegar el producto. En algún caso son acciones de marketing, documentos de producto o funcionalidades interesantes. Las fuentes pueden ser muchas, competencia, libros, mercado, conversaciones, etc.
Creo que todos tenemos grandes ideas para el producto que puede ayudar al usuario actual o al futuro.
No es que tengas pocas o malas ideas, es que tienes demasiadas y ponerlas en orden, priorizadas y analizadas es un trabajo descomunal.
Por otro lado, nunca podrás ver el producto como un usuario ya que al tener una visión interna del producto todas las mariposas impiden ver la realidad.
Que mejor que el usuario/cliente te transmita directamente o por algún medio lo que seguramente hará triunfar a tu producto. Ellos, al igual que tú, tienen cientos de ideas brillantes para tu producto. Al conocer el producto como usuario, siempre podrán transmitirte lo mejor a desarrollar.
Lo que pide el cliente/usuario es distinto a lo que necesita. Al no tener un contexto técnico o estratégico puede pedir cosas que compliquen el producto o el rumbo de futuro.
Solo el cliente/usuario conoce lo que le duele. Es importante diferenciar lo que quiere de lo que necesita el cliente. La diferencia es abismal.
En reuniones presenciales con clientes, se les notaba en la cara algo que les «dolía», una funcionalidad o problema que realmente le afectaba. Gracias a la comunicación no verbal conseguías información que ninguna encuesta o conversación telefónica podía obtener.
Cuando empatizas con la necesidad de la persona, es más fácil ponerla en contexto y priorizarla. No son números, son personas.
Una vez conozcas la necesidad, toca unir puntos, buscar una solución. Tu experiencia es «vital» para resolver esa necesidad de la mejor forma posible.
Un formato binario de bajo nivel creado bajo un estándar y al paraguas de la colaboración de varias compañias tecnológicas. Al ser abierto y basado en la integración con el omnipresente Javascript permite ofrecernos muchas ventajas en muy distintos ámbitos.
Actualmente la ejecución de funciones serverless, se basan generalmente en entornos basados en dockerizar para aislar entornos. Aunque muy eficientes y rápidos, estamos hablando de entornos que tardan milisegundos en iniciarse y consumen megas de recursos. Esas mismas funciones en WebAssembly se inicializan en microsegundos y consumiendo unos KB.
El coste y rapidez hacen presagiar que será un buen camino en los entornos de serverless , Cloudflare ya ha empezado a ofrecer este tipo de funciones serverless.
Los miles de frameworks Javascripts existentes deben lidiar con el rendimiento y las funcionalidades para poder ofrecer la mejor experiencia en el frontend o en el backend (node.js). El uso de WebAssembly integrado en partes críticas de los frameworks puede consolidar y acelerar partes importantes que aporten rendimiento y fiabilidad a todas la librerías. WebAssembly ha nacido para potenciar Javascript, no para sustituirlo y este es uno de los puntos donde lo veremos extenderse en los próximos años.
Existen millones de proyectos desarrollados en múltiples lenguajes que suelen basar sus compiladores o runtimes en C o lenguajes de bajo nivel. Mediante la compilación a WebAssembly mucho del código fiable puede aprovecharse para ejecutarse de forma ubicua en cualquier engine moderno de navegador.
Una industria que está empujando en esta dirección son los videojuegos,
poder portar juegos desarrollados en C++ a Web abre un nuevo mundo de posibilidades a la industria.
La ejecución de aplicaciones multiplataforma ha sido el santo grial del desarrollo de software. Java, Velneo, Python y otros, han nacido con el propósito de simplificar el desarrollo en multiplataforma. Pero lidiar con el reto de la multiplataforma complicaba la mantenibilidad o mermaba el rendimiento.
WebAssembly no es solo web, durante los últimos meses se está definiendo WASI, un interface de WebAssembly con el sistema, lo que una vez estandarizado se podrá «compilar» y ejecutar directamente en sistemas operativos que soporten dicho interfaz. Esto simplificará la compilación multiplataforma de una forma notable, al mismo tiempo que se acerca a rendimientos de ejecución nativa.
Nos esperan años apasionantes, donde el software será más ubicuo, más seguro, más portable y más eficiente.
Cuando creamos un fichero que va a circular por emails, webs, ftps, google drive y el mundo en general, es importante pensar el nombre para evitar problemas y unificar criterios.
Consejos:
Son consejos, no son verdades absolutas, úsalos con moderación 😉
Enlaces de interés:
https://developers.google.com/style/file-names
https://www.csudh.edu/web-services/web-standards/file-folder-naming/
¿Como percibirá el usuario las acciones que realiza en tu aplicación?
De 0 – 0,1 segundos
Es el tiempo máximo para que un usuario sienta que una acción suya esta provocando que ocurra algo en la aplicación de forma instantánea. Viene a ser como el interruptor de la luz.
0,1 – 0,3 segundos
El usuario siente una pequeña demora pero entiende que se está realizando su orden. Un ejemplo podría ser el tiempo que tarda en cambiar de cadena una televisión usando el mando a distancia.
1 segundo
Es el tiempo máximo en que el usuario sigue conectado a la tarea, sabe que manda una orden y el equipo la procesa en un tiempo adecuado sin que pierda la focalización mental. El encendido de un coche de gasolina puede ser un buen ejemplo.
Más información en este gran articulo de Jakob Nielsen Powers of 10: Time Scales in User Experience
Durante los últimos meses estamos implantando internamente nuevas aplicaciones desarrolladas en Velneo. Por otro lado necesitamos conectarlas con otras aplicaciones de terceros que usamos en diferentes departamentos ( Google Apps, WordPress, Twitter, Zendesk, etc ).
Esta situación nos obligaba a marcar una estrategia de futuro en la comunicación entre aplicaciones.
Debíamos buscar una forma de comunicar cualquier aplicación entre sí, da igual si está en web, en escritorio o en móvil. Buscábamos un solo idioma para que se comuniquen nuestras aplicaciones.
Después de evaluar las opciones existentes todas nos llevan hacia las siglas REST / JSON
Al ser un servicio tipo REST tenemos la garantía de que funcionaremos sobre HTTP/HTTPS con todas las ventajas que ello conlleva.
Nos decantamos por JSON respecto a XML por varios motivos :
Lo primero que debíamos hacer era crear un API que permitiera que otras aplicaciones consumieran nuestras aplicaciones, para ello con el vJavascript de Velneo creamos una aplicación capaz de generar de forma dinámica todo el API en base a un proyecto de Velneo. Esta aplicación no solo nos genera los puntos de acceso, sino una web dinámica con toda la documentación del API
Para darle salida a la aplicación usamos el componente vModApache y configuramos el Apache para añadirle cache, compresión y encriptación.
Con este proyecto, cualquiera de nuestras aplicaciones de Velneo V7 tenían un API dinámico en base a las tablas y búsquedas ya creadas.
Necesitábamos obtener información de nuestras aplicaciones, en unos casos que Google Apps pudiera obtener diferente información de nuestro vERP, para ello desarrollamos scripts en Google Apps Script que acceden a nuestro API y le consultan la información que necesita. El resultado devuelto en JSON se procesa de una forma muy sencilla y se realizan las operaciones necesarias.
Por otro lado nuestra web necesitaba mostrar información privada en los sitios que funcionan con WordPress. Desarrollamos un plugin en PHP que se conectaba a nuestro API para obtener información y mostrarla al visitante.
Desde los centros de soporte en Zendesk se consulta nuestro API para mostrar información de nuestro vERP en tiempo real
Desde Google Script se generan emails con los indicadores clave de la empresa calculados en diferentes aplicaciones
Existen cientos de servicios web que ofrecen funcionalidades mediante sus APIs REST JSON
Nuestra idea es comunicar toda esta «nube» de aplicaciones con un mismo idioma, lo que nos permite ser más ágiles en cuanto a la implementación y mantenimiento de nuevos servicios.
Durante los años que llevo en el desarrollo de software todavía no he dado con la forma «perfecta» para ofrecer una documentación clara y eficiente para los usuarios de la aplicación.
Una documentación de usuario efectiva debería permitir :
Sin duda lo más complicado de una documentación de usuario es mantenerla. Un producto software esta vivo y se le van añadiendo funcionalidades, la documentación sea mucha o poca, debe ir actualizándose al mismo ritmo.
Elementos que van encontra del mantenimiento
Ayudas de Google
Google se esmera en no incluir capturas de pantalla, siempre lo explica con texto, lo que facilita su mantenimiento respecto los constantes cambios que van añadiendo.
Jenkins
Esta documentación tiene una buena división general ( Conoce, Usa, Extiende ) que permite ubicarte facilmente en que información necesitas.
Lo que dice Wikipedia de la latencia:
En redes informáticas de datos se denomina latencia a la suma de retardos temporales dentro de una red. Un retardo es producido por la demora en la propagación y transmisión de paquetes dentro de la red.
En la era de las aplicaciones para internet hay que tener muy encuenta como la latencia puede ser nuestro enemigo.
Hasta hace poco tiempo el problema de una aplicación era el ancho de banda, que consiste en la cantidad de datos que podían viajar por segundo ( 1 Mb/s , 10 Mb/s ). Con el tiempo, en general, las conexiones ya permiten transmisiones de gran cantidad de datos por segundo.
Por otro lado la latencia es el tiempo que tarda en ir un paquete de un punto a otro.
¿Por qué es la latencia importante para las aplicaciones?
En las aplicaciones donde existe una parte cliente y servidora, la comunicación entre estos dos elementos es constante, enviandose y recibiendo datos para las distintas acciones del usuario. Si durante el desarrollo de la aplicación no se ha tenido en consideración la posible latencia, el usuario podrá llegar a odiar la aplicación ya que tendrá que sufrir constantes esperas entre una y otra acción.
¿Cuál es la latencia en red local?
Normalmente es menor a 1 ms, 50 veces más rapido que una conexión nacional y 100 veces más rápido que una conexión intercontinental.
¿Cómo podemos reducir la latencia entre el servidor y el cliente?
Esto está en manos de las redes de comunicaciones, y parece un problema complejo, porque nos encontramos con limites físicos ( Velocidad de la luz y esas cosas 😉 )
Siempre te queda la opción de poner el servidor más cerca de los usuarios.
¿Cómo puedo reducir los efectos de la latencia?
Existen muchas técnicas, pero basicamente debemos de buscar que los efectos de la latencia no afecten a las acciones del usuario.
Te recomiendo el post de Jarboleya sobre consejos para programar aplicaciones en la nube
En el desarrollo ágil de software, se habla de sprint al periodo de tiempo de una iteración, es la parte repetible y que debe ir mejorando poco a poco.
Pero cuando hablamos de un desarrollo de software podemos buscarle también una perspectiva mayor y hablar que esos sprints están dentro de una gran maratón.
¿Corres maratones o solo haces sprints?
Una vez quieras vender tu producto tendrás que correr otro maratón
Generalmente son dos parámetros que se contradicen, si hago un producto más rápidamente lo hago con menos calidad y si lo hago con calidad requiere mayor tiempo de desarrollo.
Existe el factor coste, invierto más dinero y lo consigo con más calidad y menos tiempo. Pero en el mundo real con más dinero tendrás más gente, más gente es más tiempo, más gestión y posiblemente menos calidad.
Si le preguntamos al cliente te dira que lo quiere rápido, pero asume que tiene calidad, si no funciona bien, ¿para que le vale?
Una posible solución a este dilema es menos.
Pero aunque la idea parece fácil, es extremadamente complicado saber cuales son las mínimas funcionalidades que conseguirán satisfacer las necesidades de tu cliente.
Menos, es más cálidad y más rapidez!
davidgu 