RegionScout: Exploiting Coarse Grain Sharing in Snoop Coherence
Pronóstico Tecnológico- Snoop Consulting
-
Upload
snoopconsulting -
Category
Documents
-
view
222 -
download
1
description
Transcript of 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.
3PRONOSTICO
TECNOLOGICOSNOOP CONSULTING
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
CICLO DE VIDADE LA ADOPCIÓN
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
TECNOLOGICOSNOOP CONSULTING
2014
CICLO DE VIDADE LA ADOPCIÓN
DE TECNOLOGÍAEXPERIMENTAL OBSOLETO
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
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
CICLO DE VIDADE LA ADOPCIÓN
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
TECNOLOGICOSNOOP CONSULTING
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
CICLO DE VIDADE LA ADOPCIÓN
DE TECNOLOGÍAEXPERIMENTAL OBSOLETO
TIEMPO
EL GRAN SALTO
8PRONOSTICOTECNOLOGICOSNOOP CONSULTING2014
CICLO DE VIDADE LA ADOPCIÓN
DE TECNOLOGÍAEXPERIMENTAL OBSOLETO
TIEMPO
EL GRAN SALTOSea ViSionario Sea INNOVaDOR
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
D&s DesArroLLo Y sIsteMAs
INNOVADOR
9PRONOSTICO
TECNOLOGICOSNOOP CONSULTING
2014
CICLO DE VIDADE LA ADOPCIÓN
DE TECNOLOGÍAEXPERIMENTAL OBSOLETO
TIEMPO
EL GRAN SALTOSea ÁGIL Sea PReCaVIDO Sea CONSeRVaDOR
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
10PRONOSTICOTECNOLOGICOSNOOP CONSULTING2014
CICLO DE VIDADE LA ADOPCIÓN
DE TECNOLOGÍAEXPERIMENTAL OBSOLETO
TIEMPO
EL GRAN SALTOSea ViSionario Sea INNOVaDOR
D&s DesArroLLo Y sIsteMAs
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
TECNOLOGICOSNOOP CONSULTING
2014
CICLO DE VIDADE LA ADOPCIÓN
DE TECNOLOGÍAEXPERIMENTAL OBSOLETO
TIEMPO
EL GRAN SALTOSea ÁGIL Sea PReCaVIDO Sea CONSeRVaDOR
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
12PRONOSTICOTECNOLOGICOSNOOP CONSULTING2014
CICLO DE VIDADE LA ADOPCIÓN
DE TECNOLOGÍAEXPERIMENTAL OBSOLETO
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
DESARROLLO Y SISTEMAS
Damián Rolón [email protected]
PROCESOS YHERRAMIENTASLionel Barrabino
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
snoopconsulting.com