Pronóstico Tecnológico- Snoop Consulting

PaaSIaaSVMS

IntelIgencIa OPeracIOnalBIg DataInterfaz De USUarIO

HtMl5OPen SOUrceVcS

USaBIlIDaDBD SIn eScalaOPen DataaPPIS MóVIleS natIVaS

KanBanInternet De laS cOSaSclOUD

cOllaBOratIVe analytIcSData ScIence

MOngODBOPen StacKHerOKUQlIKVIewSPlUnK

lOgStaSHKIBanaKnOcKOUteMBerangUjarjS

OSB

PaaSIaaSVMSIntelIgencIa OPeracIOnalBIg DataInterfaz De USUarIO HtMl5OPen SOUrceVcSUSaBIlIDaDBD SIn eScalaOPen DataaPPIS MóVIleS natIVaSKanBanInternet De laS cOSaSclOUDcOllaBOratIVe analytIcSData ScIenceMOngODBOPen StacKHerOKUQlIKVIewSPlUnKlOgStaSHKIBanaKnOcKOUteMBerangUjarjSOSB

Pro

N S

TICo

PRONOSTICOTeCNOlOgICO 2014

SegUNDO SemeSTRe

2PRONOSTICOTeCNOlOgICOSNooP CoNSULTING2014

1PRONOSTICO

TECNOLOGICOSNOOP CONSULTING

2014

sobre nosotros

Somos una empresa de desarrollo, operación y consultoría de software y servicios informáticos que se enfoca en simplificar a sus clientes el acceso a tecnologías emergentes.

Brindamos servicios tecnológicos orien-

tados a incrementar la productividad de

nuestros clientes y garantizarles la inver-

sión en tecnología. Nos especializamos

en diseño de arquitectura de aplicaciones

de misión crítica; interfases de usuarios,

soluciones para decisiones en Tiempo

Real, gestión del conocimiento, desarrollos

Web 2.0, análisis predictivo e inteligencia

de negocios.

Contamos con oficinas en Buenos Aires,

La Plata, Patagonia y Santiago de Chile.

Poseemos las principales certificaciones

de calidad (ISO 9001, CMMI) y desde

hace varios años somos reconocidos por

los CIOs como una de las principales

compañías IT de capitales argentinos,

destacándonos en innovación, calidad, e

imagen.

Sea ViSionario Sea INNOVaDOR

2PronostICoteCnoLoGICoSNOOP CONSULTING2014

¿QUÉ es eL PronóstICo?

Un equipo de especialistas en Arquitectura, I+D, Nego-

cios, Desarrollo y Consultoría de Snoop se propuso la

tarea de definir cuáles son y serán las tecnologías, los

sistemas, los procesos y las herramientas que con-

forman el mapa tecnológico del primer semestre del

2014. El resultado es este Pronóstico Tecnológico de

Snoop Consulting.

Para distribuir toda la información y organizar la lectura

en función de criterios específicos, hemos definido tres

categorías: “Infraestructura y Operaciones”, “Procesos y

Herramientas”, “Desarrollo y Sistemas”.

A lo largo de esas categorías encontrará una serie de

puntos (muchos de ellos con información ampliada)

y, sobretodo, nuestras recomendaciones sobre qué

hacer: si ESPERAR, EVALUAR, ADOPTAR, APURAR,

o SALIR

Utilizamos como referencia, además, el famoso gráfico

de Geoffrey Moore sobre el ciclo de vida de la adop-

ción de tecnología considerando que en los extremos

se encuentra lo experimental, por un lado, y lo obsoleto,

por el otro.

Y dado que la manera en que nos movamos entre un

extremo y otro definirá nuestra posición en el mercado,

el desafío será, evidentemente, saber cómo hacerlo y

hacía donde ir en un contexto dinámico, lleno de nove-

dades y posibilidades.

El “Pronóstico Tecnológico” es nuestra forma de ayu-

darlo a responder esas preguntas y a posicionarlo en el

mercado.

[email protected]

3PRONOSTICO


2014

A QUIÉnes estÁ DIrIGIDo

A todos aquellas personas con altas responsabilidades en gestionar proyectos,

tomar decisiones y definir e implementar planes. Es decir: directores, gerentes y

líderes de IT, desarrollo, producto, funcionales, infraestructura, operaciones, siste-

mas, proyectos.

CóMo se Lee

Se trata de tecnología o procesos que están en

experimentación, que no están del todo testea-

dos y no se puede asegurar su correcto funcionamiento. Lo que le

recomendamos aquí es que tenga cuidado. Será valiente si decide

implementarlo.

Se trata de tecnología o metodología apta para

implementar, tecnología que puede estar en su

primera versión o en una versión incompleta. Nuestra recomendación

es que evalúe su implementación. Si apuesta a ella y, a pesar de la

incertidumbre, decide implementarla, entonces puede considerarse

un verdadero visionario.

Existen pruebas concretas y casos de éxitos

notables en la implementación de estas tecno-

logías y procesos. Le decimos: “es por aquí”, “sea ágil, adelántese a

todos”. “Impleméntelo antes de que pase”.

Si no está implementando ninguna de estas

tecnologías o procesos, entonces está quedán-

dose fuera. Comience a actuar antes de que quede muy atrás de su

competencia.

Estas tecnologías y procesos están volviéndose

obsoletas. Le recomendamos que comience

a salir de allí o que, sí no ha implementado nada de esto,

que se quede así.

VISIONarIO

INNOVadOr

CONSerVadOr

ÁGIL

PreCaVIdO

4PRONOSTICOTECNOLOGICOSNOOP CONSULTING2014

CICLO DE VIDADE LA ADOPCIÓN

DE TECNOLOGÍAEXPERIMENTAL OBSOLETO

TIEMPO

EL GRAN SALTOSea ViSionario Sea INNOVaDOR

VISIONARIO INNOVADOR AGIL PRECAVIDO CONSERVADOR

LE RECOMIENDA ESPERAR SALIREVALUAR APURARADOPTAR

REFERENCIAS

AVANZÓ EN EL CICLO DE VIDA

ESTÁ POR AVANZAR EN EL CICLO DE VIDA

NO CAMBIÓ

BALANCEO DENTRO DE DATACENTERS

STANDARES VERDES DE DISTINTO TIPO

TESTS FUNCIONALES AUTOMÁTICOS

PREPROCESADORES DE CSS PARA APLICACIONES WEB COMPLEJAS

TESTEO DE UNIDAD EN EL CODIGO JS DE LA INTERFACE

OPEN DATA

PLAY FRAMEWORK

IMPLEMENTACIONES DE PARALELISMO MÁS ALLÁ DE THREADS

USAR MOTOR DE REGLAS

MÁS INFORMACIÓN en páginas siguientes

INFRAESTRUCTURAY OPERACIONES

I&O

PROCESOS Y HERRAMIENTAS

P&H

DESARROLLO Y SISTEMAS

D&S

CONTAINERS Y VMS DESCARTABLES

PACKAGE MANAGER EN WINDOWS

SCM (Git, SVN, Mercurial) COMO HERRAMIENTA PARA DEPLOY

DEVOPS: ITERACION RAPIDA, AUTOMATIZACION DE TAREAS DE RELEASE MANAGEMENT

CEP (Complex Event Processing)

FILESYSTEMS HÍBRIDOS, DISTRIBUIDOS Y TRANSPARENTES

PASAR DE INTEGRACION CONTINUA A CONTINUOUS DELIVERY

APPLICATION LIFECYCLE MANAGEMENT

USABILIDAD COMO PARTE DEL PRODUCTO

UTILIZAR METODOLOGÍA DE PROYECTOS FUERA DE SISTEMAS

FRAMEWORKS PARA SERVIDORES CON CONCURRENCIA MASIVA Y TAREAS DE CORTA DURACION

INTERFAZ DE USUARIO USANDO HTML5 + JAVASCRIPT. APLICACIONES COMO APIS, FRONT END CONSUMIDORES A SERVICIOS.

VCS DISTRIBUIDOS, COMMIT COMO UNIDAD DE TRABAJO Y NO DE DISTRIBUCION

FRAMEWORKS MVC DE JAVASCRIPT

OPEN SOURCE DE FUENTES NO TRADICIONALES

LENGUAJES SOBRE JAVASCRIPT

AUTOMATIZACIÓN DE TAREASDE SOPORTE DE DESARROLLO

REALIDAD AUMENTADA

MÓVILES COMO AGREGADORES DE INFORMACIÓN

BIG DATA


DE TECNOLOGÍA

EL GRAN SALTOEL ÁREA BAJO LA CURVA

REPRESENTA LACANTIDAD DE USUARIOS

EXPERIMENTAL

TIEMPO

OBSOLETO

MOBILE ENTERPRISE

REVISIONES DE CÓDIGO COMO PRÁCTICA PARA MEJORAR LA CALIDAD

USABILIDAD DE API. APLICACIONES COMO APIS, FRONT END COMO UN CONSUMIDOR MAS DE SERVICIOS

PROYECTOS EN CASCADA

DESARROLLO DE PORTALESEN FLASH

JSF (Java Server Faces)

PASAR DE ANALISTAS FUNCIONALES A PRODUCT OWNERS

INFRASTRUCTURE AS A SERVICE

INTELIGENCIA OPERACIONAL

APLICACIONES MÓVILES NATIVAS

FRAMEWORKS QUE GENERAN CÓDIGO

MIDDLEWARE DE INTEGRACION

PLATFORM AS A SERVICE

VISION DEL DESARROLLO COMO PRODUCTO, NO SOLO PROYECTO

BASES DE DATOS SIN ESQUEMA

KEY/VALUE STORES

ESCRIBIR LAS APLICACIONES MÓVILES EN HTML5 Y JAVASCRIPT

INTEGRACIÓN CONTÍNUA PARA SACAR METRICAS DE QA EN PROYECTOS

VMS Y CONTAINERS A LA CARTA Y DESCARTABLES

KANBAN PARA MANTENIMIENTO Y SOPORTE

FRAMEWORKS SIMPLIFICADOS PARA SERVIDORES CON CONCURRENCIA MASIVA Y TAREAS DE CORTA DURACIÓN

BOTS PARA AUTOMATIZACIÓN DE TAREAS DE SOPORTE DE DESARROLLO

CONSUMERIZACIÓN DEL REPORTE, BI PARA LAS MASAS

BRING YOUR OWN DEVICE

5PRONOSTICO


2014



TIEMPO

EL GRAN SALTOSea ÁGIL Sea PReCaVIDO Sea CONSeRVaDOR

VISIONARIO INNOVADOR AGIL PRECAVIDO CONSERVADOR

LE RECOMIENDA ESPERAR SALIREVALUAR APURARADOPTAR

REFERENCIAS

AVANZÓ EN EL CICLO DE VIDA

ESTÁ POR AVANZAR EN EL CICLO DE VIDA

NO CAMBIÓ

BALANCEO DENTRO DE DATACENTERS

STANDARES VERDES DE DISTINTO TIPO

TESTS FUNCIONALES AUTOMÁTICOS

PREPROCESADORES DE CSS PARA APLICACIONES WEB COMPLEJAS

TESTEO DE UNIDAD EN EL CODIGO JS DE LA INTERFACE

OPEN DATA

PLAY FRAMEWORK

IMPLEMENTACIONES DE PARALELISMO MÁS ALLÁ DE THREADS

USAR MOTOR DE REGLAS

MÁS INFORMACIÓN en páginas siguientes

INFRAESTRUCTURAY OPERACIONES

I&O

PROCESOS Y HERRAMIENTAS

P&H


D&S

CONTAINERS Y VMS DESCARTABLES

PACKAGE MANAGER EN WINDOWS

SCM (Git, SVN, Mercurial) COMO HERRAMIENTA PARA DEPLOY

DEVOPS: ITERACION RAPIDA, AUTOMATIZACION DE TAREAS DE RELEASE MANAGEMENT

CEP (Complex Event Processing)

FILESYSTEMS HÍBRIDOS, DISTRIBUIDOS Y TRANSPARENTES

PASAR DE INTEGRACION CONTINUA A CONTINUOUS DELIVERY

APPLICATION LIFECYCLE MANAGEMENT

USABILIDAD COMO PARTE DEL PRODUCTO

UTILIZAR METODOLOGÍA DE PROYECTOS FUERA DE SISTEMAS

FRAMEWORKS PARA SERVIDORES CON CONCURRENCIA MASIVA Y TAREAS DE CORTA DURACION

INTERFAZ DE USUARIO USANDO HTML5 + JAVASCRIPT. APLICACIONES COMO APIS, FRONT END CONSUMIDORES A SERVICIOS.

VCS DISTRIBUIDOS, COMMIT COMO UNIDAD DE TRABAJO Y NO DE DISTRIBUCION

FRAMEWORKS MVC DE JAVASCRIPT

OPEN SOURCE DE FUENTES NO TRADICIONALES

LENGUAJES SOBRE JAVASCRIPT

AUTOMATIZACIÓN DE TAREASDE SOPORTE DE DESARROLLO

REALIDAD AUMENTADA

MÓVILES COMO AGREGADORES DE INFORMACIÓN

BIG DATA


DE TECNOLOGÍA

EL GRAN SALTOEL ÁREA BAJO LA CURVA

REPRESENTA LACANTIDAD DE USUARIOS

EXPERIMENTAL

TIEMPO

OBSOLETO

MOBILE ENTERPRISE

REVISIONES DE CÓDIGO COMO PRÁCTICA PARA MEJORAR LA CALIDAD

USABILIDAD DE API. APLICACIONES COMO APIS, FRONT END COMO UN CONSUMIDOR MAS DE SERVICIOS

PROYECTOS EN CASCADA

DESARROLLO DE PORTALESEN FLASH

JSF (Java Server Faces)

PASAR DE ANALISTAS FUNCIONALES A PRODUCT OWNERS

INFRASTRUCTURE AS A SERVICE

INTELIGENCIA OPERACIONAL

APLICACIONES MÓVILES NATIVAS

FRAMEWORKS QUE GENERAN CÓDIGO

MIDDLEWARE DE INTEGRACION

PLATFORM AS A SERVICE

VISION DEL DESARROLLO COMO PRODUCTO, NO SOLO PROYECTO

BASES DE DATOS SIN ESQUEMA

KEY/VALUE STORES

ESCRIBIR LAS APLICACIONES MÓVILES EN HTML5 Y JAVASCRIPT

INTEGRACIÓN CONTÍNUA PARA SACAR METRICAS DE QA EN PROYECTOS

VMS Y CONTAINERS A LA CARTA Y DESCARTABLES

KANBAN PARA MANTENIMIENTO Y SOPORTE

FRAMEWORKS SIMPLIFICADOS PARA SERVIDORES CON CONCURRENCIA MASIVA Y TAREAS DE CORTA DURACIÓN

BOTS PARA AUTOMATIZACIÓN DE TAREAS DE SOPORTE DE DESARROLLO

CONSUMERIZACIÓN DEL REPORTE, BI PARA LAS MASAS

BRING YOUR OWN DEVICE

Filesystems híbridos, distribuidos y transparentesLa disponibilidad de solid state drives (SDDs) redefine la

jerarquía de almacenamiento permanente en 3 capas:

un cache en RAM de muy alta velocidad y relativamen-

te poco tamaño, un cache nivel 2 en SSD de tamaño

medio, y el disco como almacenamiento final. Como

coordinar estos caches para que sean transparentes a la

aplicación es responsabilidad del filesystem. ZFS fue el

primer filesystem que implementó esta política con éxito.

En un ambiente virtualizado, el siguiente paso es eliminar

NAS como punto único de falla, y pasar a una red de al-

macenamiento distribuido virtualizado y transparente entre

pares, donde la combinación de RAM, SSD y disco de

todas las maquinas forman un filesystem virtual, unificado

y escalable. Nutanix y HC3 proveen “software-defined

storage” listas para instalar, con GFS2 de RedHat como

contendiente open source.

Como siempre, las políticas de caching son más eficientes

cuanto más cerca está el criterio de caching de la aplica-

ción que define el patrón de uso de los datos. Delegar el

cache al filesystem es la mejor opción sólo si la aplicación

no puede establecer un criterio más inteligente, o si el

uso del filesystem no sigue un patrón particular de una

aplicación.

VMs y Containers a la carta y descartablesEl problema eterno de tener un ambiente de desarrollo o

producción fácilmente repetible se soluciona mas y mas

mediante VMs. Sin embargo esto mueve el problema de lu-

gar: una vez creada la imagen para la VM ¿Quien configura

a la VM en sí?

Vagrant es un proyecto que permite de manera muy simple

el scripting de configuración de VMs: Cosas como la canti-

dad de memoria asignada a la VM, la manera de interactuar

con la red, de conectarse con el server host, son ahora

configurables y repetibles de manera muy simple.

Vagrant puede funcionar con una variedad de servers de

VMs como VMWare o Virtualbox o Docker. Este último crea

VMs livianas sobre linux sin necesidad de virtualizar la CPU

ni el kernel, lo que redunda en mejor utilización de recursos

y menor tiempo entre la necesidad de una nueva VM y la

disponibilidad de esta.

Infrastructure as a ServiceUn viejo conocido, pero no por ello menos tendencia.

Argentina sigue con baja adopción de la nube para los

“fierros”. IaaS consiste en “alquilar” los servidores, por

hora a medida que los uso: esto no solo permite contro-

lar costos, sino crecer rápidamente (y decrecer cuando

pasa el pico). ¿Necesito sacar un reporte más rápido?

Pido 10 servidores por 1 hora cada uno, en lugar de 1

servidor por 10 horas. ¿El sistema se da de baja? Un

servidor menos.

Aumentan los jugadores, se vuelve competitivo el precio,

aparecen servidores cercanos a casa.

Inteligencia OperacionalLas organizaciones construyen data warehouses con

información comercial, pero normalmente consideran nor-

mal tener a un montón de archivos de logs en un montón

de maquinas, sin herramientas para unificarlos y anali-

zarlos. El costo es visible al momento de que ocurre una

falla en alguna parte de software o hardware vital para

el negocio. Inteligencia operacional consiste en herra-

mientas de captura, unificación, visualización y análisis en

tiempo real de todas las operaciones del negocio: desde

el seguimiento la performance de los accesos a bases de

datos, la velocidad y fiabilidad del intercambio de informa-

ción entre sistemas, a métricas de uso y confiabilidad del

front-end de e-commerce.

Hoy existen tanto herramientas pagas (Splunk) como

open source (Logstash + StastD + Graphite + Kibana)

para hacer posible este tipo de captura, integración y

análisis unificado de los sistemas de IT de la empresa.

exPLICACIón De ALGUnos IteMs en eL PronóstICo teCnoLóGICo

Sea ViSionario

Sea agil

I&o InFrAestrUCtUrA Y oPerACIones

6PronostICoteCnoLoGICoSNOOP CONSULTING2014

Sea ViSionario Sea INNOVaDORCICLO DE VIDA

DE LA ADOPCIÓNDE TECNOLOGÍA

EXPERIMENTAL OBSOLETO

TIEMPO

EL GRAN SALTO

7PRONOSTICO


2014

Sea ÁGIL Sea PReCaVIDO Sea CONSeRVaDOR

Platform as a serviceEn Platform as a service es el usuario paga por un ser-

vicio orientado al desarrollo y rápido despliegue de una

aplicacion, en contraste con pagar sólo por el servicio de

hardware + sistema operativo. La gran ventaja es la de

acelerar el desarrollo sin caer en realizar también tareas

tediosas como la instalación del servidor, y simplifica la

configuración de uno o múltiples ambientes.

Estos servicios existen hace un tiempo pero es reciente la

masificación fuera de lenguajes boutique como python y

ruby. Conviene ver si algunas de estas plataformas es com-

patible con la estructura existente, si lo es, aprovecharlo.

La gran ventaja de PaaS es que no es simplemente

una máquina en otra parte: es una serie de servicios

asociados como monitoreo, logging, autoscaling, deploy

automático entre otros, que simplifica tareas repetitivas

normalmente a cargo del grupo de operaciones.

Hay muchos jugadores: en lenguajes de scripting el más

conocido es Heroku. En el ámbito empresarial, hay oferta

de Red Hat que permite Java en su servidor JBoss, pero

la oferta es variada con Digital Ocean, Cloudbees, y otros.

Mobile enterpriseNo hay empresa grande que no cuente con un área de

arquitectura en sistemas. No hay empresa mediana que

no comprenda la importancia de organizar sus sistemas

para no perder el control. Entonces ¿por qué compran

aplicaciones móviles a diferentes empresas, que las

realizan con frameworks y técnicas diferentes? Debería

empezar a adoptarse, en empresas suficientemente

grandes, lineamientos de arquitecturas para aplicaciones

móviles. Tanto internas, como externas. Todo tiende a ser

Frameworks simplificados para servidores con concurrencia masiva y tareas de corta duraciónNode.js ofreció la loca promesa de que un server de un

solo thread corriendo codigo javascript era ser suficien-

te para implementar una aplicacion con concurrencia

masiva. Y resulta que es cierto, en tanto cada request

dure muy poco tiempo (p.ej. responder a un chat), o estés

dispuesto a vivir dentro de una ensalada de callbacks

para no bloquear al servidor p.ej. con un query que tome

algún tiempo en terminar.

vertx.io es la respuesta (un poco mas sana) del mundo

java a node.js, con la ventaja del diario de lunes. Ambos

dependen de frameworks como ExpressJS o Meteor

(node.js) o Yoke (vertx.io) para hacer la vida un poco más

facil de vivir. ¿Suena familiar?

Bots para automatización de tareas de soporte de desarrolloEl dia a dia de cualquier proyecto de desarrollo hace

que sea necesario interactuar con varios sistemas, entre

ellos: la base de datos, el registro de errores, los pasos

para hacer el despliegue de la aplicacion, el sistema de

monitoreo. Muchas de estas tareas consisten en pasos

repetitivos que se pueden automatizar, com por ejemplo

avisar a todo el equipos de un nuevo commit, o disparar

un nuevo despliegue a partir de un branch del SCM, o

verificar si una bd esta caída y cual fue la última línea de

error en su log.

Una manera simple y práctica de automatizar estas

tareas sin agregar aún otra herramienta es utilizar el chat

que utiliza el equipo de trabajo como interfaz de usuario

integradora. Esto es lo que hace Hubot de GitHub: se

presenta como un usuario mas en el chat, y es capaz de

entender ciertos mensajes, ejecutar scripts que respon-

den a esos mensajes, y mostrar el resultado en el mismo

chat del usuario. El efecto es el tener un robot / linea de

comando extensible, en el que se pueden delegar tareas

de manera simple.

Sea ViSionario

D&s DesArroLLo Y sIsteMAs

Continúa en la siguiente página



TIEMPO

EL GRAN SALTO




TIEMPO


Frameworks MVC de JavaScriptLas aplicaciones web son cada vez más sofisticadas, incluso

son desarrolladas como aplicaciones independientes que

consumen un backend REST (ver “Front end como un con-

sumidor más de servicios”). El problema es que al aumentar

la complejidad de la aplicación el código se convierte en

una enorme lista de funciones y callbacks sin estructura,

difícil de analizar, y donde el código con comportamiento se

mezcla todo el tiempo con el código que modifica la interfaz

de usuario.

Los frameworks MV* de Javascript, como Backbone,

Batman, Ember y AngujarJS proveen una estructura sobre

la que separar model y views, y mecanismos para comu-

nicarlas y mantenerlas sincronizadas (data-view binding),

de manera de reducir la cantidad de código que necesario

como “pegamento” entre partes, y a su vez ofreciendo guías

claras de diseño para aplicaciones complejas. Estos fra-

meworks se encargan de casi la totalidad de las conexiones

entre las partes del código; el desarrollador genera plantillas

en HTML, y código que rellena y modifica los datos en esas

plantillas.

Backbone ha caído en popularidad últimamente por algunas

deficiencias en su diseño, y está siendo eclipsado por Knoc-

kout, Ember y AngujarJS. AngujarJS es un framework con

una opinión mucho más fuerte sobre cómo se estructura

una aplicación web moderna y una curva de aprendizaje

mayor, a cambio de un modelo de arquitectura más puro y

menor cantidad de código “pegamento” necesario. Si bien

AngujarJS es el framework que mas crece en uso, tiene los

problemas de cualquier framework que propone una capa

de abstracción sobre la tecnología subyacente: la magia

hace más difícil hacer debugging, es más difícil ingresar

miembro nuevo al equipo hasta que entienda la manera

“única y verdadera” de usar el framework.

Interfaz de usuario usando HTML5 + Javas-cript. Aplicaciones como APIs, Front end consumidores a servicios.Actualmente todos los navegadores van casi juntos en

cuanto al estándar de HTML5. Además, la preponderan-

cia de IE (el que tradicionalmente menos cumple con los

estándares) baja constantemente. Bajo este paradigma,

conviene aprovechar HTML5 y los servicios que ofrece que

benefician al frontend. Al postular HTML5 y un frontend

rico, pasa a ser tener importancia las APIs que expone la

capa de servidor. Más aún, las APIs de la capa de servidor,

pasan a ser reusables en otros dispositivos.

No todas las aplicaciones sirven para usar HTML5, pero

aquellas web son ideales para esto.

Lenguajes sobre JavascriptJavascript, el lenguaje que hace funcionar la web, no debe

su popularidad a su elegancia: conversiones silenciosas en-

tre tipos, declaración automática de variables, tipado dinámi-

co de variables complican la escritura de código sin errores.

Los lenguajes que compilan a Javascript, como Coffeescript

o Typescript ofrecen mayor expresividad, mejor detección

de errores en compilación, y extensiones como agrupación

de código en modulos. El problema con estos lenguajes ha

sido: el debugging, que se debía hacer no sobre el código

original sino sobre el código objeto en javascript, pero esto

está cambiando con el soporte de source maps en Chrome;

y el soporte en los ambientes de desarrollo, pero tanto Inte-

lliJ como Visual Studio, y en menor medida Eclipse, incluyen

soporte para Typescript.

Open Source de fuentes no tradicionalesTradicionalmente open source estaba asociado a ciertas

organizaciones como GNU o Apache o Codehaus, donde

desarrolladores se reúnen alrededor de intereses comunes

para desarrollar proyectos de código abierto.

La idea ha cruzado la frontera de estas organizaciones

para ser adoptada a nivel de empresas. Hoy no es raro que

grandes compañías como Netflix o Linkedin, Twitter, Zynga

o Palantir, o startups como Square o Wordnik tengan repo-

sitorios de código abierto, que permite acceder a bibliotecas

y proyectos de altísimo nivel. Encontrar, conocer y recorrer

estos repositorios de código abierto empresarial es tan

importante como conocer a los tradicionales.

VCS distribuidos, commit como unidad de trabajo y no de distribucionLos sistemas tradicionales de versionado, tales como SVN,

funden la idea de unidad de trabajo y unidad de distribucion


INNOVADOR

9PRONOSTICO


2014



TIEMPO


en 1 sola: el commit. Por lo tanto cada commit de un desa-

rrollador debe tener funcionalidad completa y correcta para

que sus cambios no impidan el avance de otros desarrolla-

dores. Las desventajas son:

- El desarrollador no tiene manera de hacer checkpoints

según avanza en una idea, para probar alternativas, descar-

tarlas rápidamente y tomar otro camino.

- La cantidad de código en cada commit (unidades de dis-

tribucion) es más grande, por lo que realizar una fusión de

versiones cuando hay conflictos en el código se convierte

en una tarea funesta: no es raro escuchar de proyectos que

toman 1 día cada semana o dos para llevar a cabo estas

fusiones semi manualmente.

Los sistemas de control de versiones distribuidos (en ingles,

DVCS) (p.ej. Git o Mercurial) separan el concepto de unidad

de trabajo (commit) del de distribución (push). Cada progra-

mador puede crear branches todos los commits locales que

quiera, que son invisibles para los otros desarrolladores pero

no para el DVCS. Cuando el desarrollador quiere distribuir

su trabajo, el historial de commits (junto con los de los otros

desarrolladores) hace que realizar una fusión exitosa sea

mucho más simple para el DVCS.

Como contratapartida del modelo de desarrollo es bastante

más complicado: En en particular Git existe el stash, work-

space, el indice, repositorio local, y el repositorio remoto.

Mientras que en Subversion el workflow de desarrollo es

simple, en Git y Mercurial la libertad para crear branches,

versiones y fusiones un acuerdo sobre el workflow de trabajo

del grupo para evitar problemas: Vea la cantidad de páginas

en la web con títulos como “Una estrategia de branching para

Git” o “Un modelo exitoso de branching en Git”.

Usabilidad de API. Aplicaciones como APIs, Front end como un consumidor mas de serviciosEl modelo de desarrollo tradicional de aplicaciones ve a

la aplicación desde dos puntos de vista:

- La aplicacion desde adentro, donde la interfaz de usuario

y el backend son un todo desarrollado en conjunto y a la

vez; la implementación de la interfaz de usuario interactúa

directamente con el codigo del backend (p.e.j. GWT, AWS),

tal vez con alguna capa de abstracción de grano fino entre

medio. Definitivamente no existe la idea de servicio.

- La aplicacion hacia afuera: La aplicación ofrece servi-

cios a otras aplicaciones, que son pensados y desarro-

llados de manera independiente de los servicios “hacia

adentro”. Estos servicios tienen una mejor abstracción

con respecto a la implementación de la aplicación, pero al

costo de mantener 2 fachadas de la aplicación: una hacia

adentro y otra hacia afuera.

Un enfoque alternativo cada vez más popular es pensar en

la aplicación como un backend que ofrece servicios expues-

tos mediante una API. La interfaz de usuario no es más que

un consumidor más de esos servicios, como podrían serlos

otras aplicaciones. Este enfoque requiere un diseño de los

servicios más pensado, teniendo en cuenta la usabilidad

de esos servicios tanto para la mismas aplicación como

para otras aplicaciones. La ventaja es un desacople entre

implementación y exposición de esos servicios, y un diseño

arquitectural desde los servicios (típicamente siguiendo las

convenciones REST) a la implementación.

Bases de datos sin esquemaLa simpleza de diseño lógico de las bases de datos

relacionales, con su formato rígido en tablas, ofrece varias

ventajas, pero la flexibilidad del modelo de datos no está

entre ellas, tanto en la facilidad para incorporar rápida-

mente fuentes heterogéneas con un corazón común bajo

una misma tabla, como la necesidad de descomponer

un conjunto de datos en varias tablas cuando un campo

es multivaluado, lo que tarde o temprano lleva a pagar el

costo de los joins cuando los datos crecen más allá de lo

que la base de datos soporta confortablemente.

Las bases de datos sin esquema proponen el siguiente

cambio: no soportan joins a cambio de soportar campos

multivaluados y que cada registro pueda tener los cam-

pos que hagan falta sin definir un esquema previo. Estas

bases de datos son frecuentemente (aunque no siempre)

columnares, y la aceptación natural de campos multiva-

luados permite en gran parte suplir la falta de joins. Al

no tener que implementar joins, es posible particionar

datos vertical u horizontalmente sin perder performance.

Continúa en la siguiente página

Sea agil




TIEMPO



No son la solución a todos los problemas de datos del

mundo, pero muchos problemas se vuelven más simples

vistos desde el lado de una base de datos sin esquema.

Consumerización del reporte, BI para las masasCuando se originó BI era una preocupación para los más

analíticos, para que el financiero de la empresa cruce

información, para que marketing analice variables. Hoy en

día hay sobrepoblación de información, todos los sistemas

generan datos, y los datos sale barato guardarlos. Y

todos en la empresa tienen sistemas. Frente a esto,

¿hace falta que IT monopolice los reportes? Generar

reportes es una tarea tediosa, y los reportes no aportan

valor por sí solos, salvo cuando son analizados. Con la

tecnología actual, es factible tener sistemas “amigables”

que permiten que el usuario “arrastre cajitas” y arme el

reporte, sin problemas con los datos, sin afectar a otros.

El jugador estrella es Qlikview en plataformas, pero existen

componentes open source que facilitan la visualización:

D3, crossfilter, etc, aunque comenzando desde bastante

más abajo.

Aplicaciones móviles nativasLos celulares inteligentes están en todos lados, desde el

blackberry hasta el iphone. Esto da un poder en el bolsillo

mayor a computadoras enteras de la década del 90 (y

más aún). Además, los celulares tienen una interacción

distinta con el usuario.

La única manera de explotar todos los beneficios de la pla-

taforma, sin perder performance, es por ahora el uso de los

frameworks nativos. Esperamos que para más adelante,

HTML5 sea el reemplazo, pero aún no lo es.

Big data: guarde todo, pregunte cuando sepa qué preguntarEl modelo tradicional de interpretación de información

en una organización está basada en la idea de que

es imposible guardar y procesar toda la información

generada. El resultado es el data warehouse, un almacén

que en teoría contiene datos filtrados, curados, y ciertos

para contestar preguntas definidas de antemano. Nuevas

preguntas puede no poder ser respondidas con los datos

del warehouse y necesitar rediseño significativos.

Las plataformas de big data, cuyo representante más

famoso es Hadoop, ofrecen un modelo de escalabilidad

de almacenamiento de información y procesamiento capaz

de crecer con la cantidad de servidores. Herramientas

desarrolladas sobre Hadoop como Hive o Impala permiten

que nuevas preguntas sean respondidas en corto tiempo

usando toda la información disponible, no solo la oficializa-

da en el warehouse.

Frameworks que generan códigoExisten muchos frameworks, para varios lenguajes, que

“arman” la aplicación por uno. Desde interfaz gráfica,

hasta ABMs de entidades, pasando por muchos otros

servicios. A primera vista, resulta tentador, menos tra-

bajo para el equipo, sin embargo, genera un overhead

importante el entender el código generado cuando hay

que modificarlo. Además, los generadores de código se

adecuan a una generalidad de los casos, que juega en

contra para productos especializados.

En resumen, hay que mirarlos con cuidado, si se adecuan

al problema, utilizarlos, si no se adecuan al problema, no

hacerlo a la fuerza.

Los jugadores clave son los lenguajes de scripting y(en

paréntesis) su framework que simplifica la vida: ruby (on

rails), python (django), php (symfony), etc.

Middleware de integracionCuando se trata de unir varios sistemas, pasando infor-

mación entre ellos, no es necesario ni reinventar la rueda,

ni embarcarse en desarrollos a medida. Existe software

de integración que hace estas tareas rápido y eficaz-

mente y existe hace mucho tiempo. Mientras no sea de

uso general, y los departamentos de IT sigan inventando

scripts, seguirá siendo necesario.

Hay para todos los gustos y bolsillos: Oracle ofrece ODI

y OSB, Open Source está Pentaho.

Sea PReCaVIDO

11PRONOSTICO


2014



TIEMPO


P&H ProCesos Y HerrAMIentAs

Revisiones de código como práctica para mejorar la calidadDe todas las prácticas de Ingeniería de Software para

mejorar la calidad, la única que cuenta con papers

con pruebas cuantitativas, es la revisión de código. Es

independiente, para la revisión de código, si se hace con

herramientas o en persona, pero utilizar herramientas sirve

para el trabajo remoto. Normalmente, más de 1 revisión,

de 1 hora como máximo, resulta improductivo.

Si bien no es tendencia actual, la implementación sigue

siendo poca, o en empresas muy puntuales. Está probado

que mejora la calidad del código, y debería implementarse

en más lugares.

Usabilidad como parte del productoLos productos de software nacen para ser usados, para

resolver un problema. Siempre estuvo claro que el produc-

to debe resultar útil, pero cada vez es más importante que

el cometido del producto sea “facil de lograr”. Esto significa

que el usuario debe encontrar el aplicativo intuitivo, fácil

de aprender, fácil de usar, coherente, etc. Sin embargo,

pocas veces quien define la funcionalidad de un software,

define la interacción con el usuario… porque el mismo

es el usuario, o porque el usuario está en otra área, lejos

del problema. En las startups, aún se llega más lejos… a

veces no se sabe bien quién será el usuario final, ni sus

preferencias.

Cuando se trata de “amigar” al producto, esto debe

pensarse desde el inicio. Involucra no sólo cómo se ve la

aplicación, sino como se siente, si es tediosa, si es simple,

si produce satisfacción usarla, o si no. Esto impacta la

funcionalidad misma del software, y muchas veces dicta

que la funcionalidad debe ser otra. Si no se hace desde el

principio, no sale, es caro, o es imposible.

Esto es un sí o sí. Contratar un consultor de usabilidad

al final, es tirar el dinero que le paga al consultor, y al

desarrollador inicial. Mejor hacer ambas cosas a la vez, el

producto siempre será mucho mejor.

Utilizar metodología de proyectos fuera de sistemasEn las áreas de sistemas, es muy común el uso de

JSF¿Cómo es posible que una copia mal hecha de ASP de Mi-

crosoft haya durado tanto tiempo? Lo que comenzó siendo

la respuesta en Java a la componentización y facilidad

de desarrollo de ASP, se convirtió en un estandard (JSF

1) tan pobre que cualquier implementación necesitaba

expandirlo, y por lo tanto ser incompatible con las otras im-

plementaciones del mismo estandard. Se suponía que los

componentes se iban a editar gráficamente; nunca ocurrió:

lo que se suponía iba a ser armar interfaces de usuario

con drag & drop se convirtió en una maraña de XML. La

cantidad de código que hay que escribir con JSF es pura

verborragia aún para los estándares verborrágicos de Java.

El estado de la interface se mantiene en el servidor, como

si los browsers fueran tan bobos como en 1999.

De veras queremos escribir algo bueno sobre JSF pero no

se nos ocurre.

Para cuando llegó JSF 2 prometiendo curar todos los

males de JSF 1, la gente ya se habia quemado con leche,

y alternativas como GWT le pasaron por arriba.

Sea CONSeRVaDOR

Sea agil




TIEMPO

EL GRAN SALTO

términos de proyectos, y seguir metodologías como PMI,

por ejemplo. Un software que tiene una fase de inicio,

una reunión de avance, y requerimientos de cambio, no

es nada nuevo. Sin embargo, la generación del balance

mensual también puede tener fases, reuniones de avance

y cambios. Lo mismo ocurre con la remodelación de la

oficina, el feedback de desempeño, etc. Es curioso que las

áreas encargadas de estas tareas, no suelen contar con

personal especializado en proyectos: esto ocasiona que

los objetivos sean difusos, los tiempos escasos y otros

problemas.

El manejo de proyectos fuera de IT como proyectos, con

PM y todo, debería ser un hecho. Esto además no sólo se

refiere a metodologías duras, sino también se puede hacer

de manera ágil.

Visión del desarrollo como producto, no solo proyectoLas empresas en general, cuando miran desarrollo de

software, suelen mirar y ver “proyectos”: implementación 1,

implementación 2… Con esta visión, el proyecto termina

exitoso cuando concluye con la implementación exitosa.

Sin embargo, no hay que perder la vista del producto im-

plementado, un producto que se completa en presupuesto,

y en fecha, pero que no usa nadie porque le falta una

feature clave ¿es exitoso?. Entonces, conviene ver los 2

ángulos, el producto con su objetivo (que sea usable, que

tenga feature a, b y c), y el proyecto con su otro objetivo

(que la implementación cumpla x, y, z, y que a su vez esté

dentro de caja.

El usuario final, no espera el proyecto, sino el producto.

Conoce los requisitos del producto, y le interesa más lo

que podrá hacer, que si se hace en tiempo y forma. En-

tonces, cada vez es más recomendable que alguien del

equipo actúe como dueño del producto, para no perder

el foco.

Pasar de analistas funcionales a product ownersContinuando con el desarrollo como producto, el analista

funcional como escriba o mero traductor de requerimien-

tos en información técnica, aporta un valor acotado. Parte

del trabajo lo puede realizar un programador, y en equipos

altamente especializados en una vertical, así sucede.

El analista funcional, realmente brilla como “dueño” del

producto. Su verdadero objetivo debería ser entender los

problemas y ayudar a armar los requerimientos. Estos

requerimientos entonces, dejan de ser lo que el usuario

cree que quiere, sino lo que más le sirve al usuario. Sólo

el analista funcional puede hacerlo, porque conoce las

capacidades de la tecnología, y conoce el negocio.

En empresas que cuentan con su propio departamento

de product management, puede resultar redundante. Se

debería hacer la prueba en el resto.

Kanban para Mantenimiento y SoporteNo solo de Scrum o del Proceso Unificado vive el hombre.

Si bien las metodologías de desarrollo más en boga son

las agiles (Scrum por ej) o simplemente iterativas (UP),

esto no siempre es lo mejor. En equipos que realizan

tareas de mantenimiento, sin iteraciones definibles, una

metodología iterativa o una ágil sólo causan confusión: las

tareas aparecen solas y no acompaña al negocio el dejar-

las para la próxima iteración. En estos casos, Kanban es

extremadamente útil. Utiliza el simple tablero con post-its,

mismo que utilizan algunas metodologías ágiles, pero al no

tener iteraciones fijas, simplifican el flujo.

Una empresa que realice un proceso de mantenimiento

del día a día debería seguir Kanban, a priori. Siempre hay

casos borde, pero son los menos.

P&H ProCesos Y HerrAMIentAs

INNOVADOR

Sea PReCaVIDO

CONTACTO


Damián Rolón [email protected]

PROCESOS YHERRAMIENTASLionel Barrabino

[email protected]

INFRAESTRUCTURA Y OPERACIONES

Federico [email protected]

PRONOSTICOTeCNOlOgICO 2014

SegUNDO SemeSTRe

Pro

NoST

ICo PaaS

IaaSVMSIntelIgencIa OPeracIOnalBIg Data

Interfaz De USUarIO HtMl5

OPen SOUrceVcSUSaBIlIDaDBD SIn eScalaOPen Data

aPPIS MóVIleS natIVaSKanBan

Internet De laS cOSaSclOUDcOllaBOratIVe analytIcS

Data ScIenceMOngODBOPen StacKHerOKUQlIKVIewSPlUnK

lOgStaSHKIBanaKnOcKOUteMBerangUjarjS

OSBSarmiento 1230 . Piso 8

Ciudad Autónoma de Buenos Aires

Buenos Aires (C1041AAZ)

Argentina

(+54 11) 4383 3554

[email protected]

snoopconsulting.com

Date post:	10-Mar-2016
Category:	Documents
Upload:	snoopconsulting
View:	220 times
Download:	1 times

Pronóstico Tecnológico- Snoop Consulting

Documents