Arquitecto IT http://www.arquitectoit.com Análisis de Tecnologías Tue, 25 Apr 2017 22:47:46 +0000 en-US hourly 1 https://wordpress.org/?v=4.7.5 Qué son los Microservicios http://www.arquitectoit.com/arquitectura/microservicios/que-son-los-microservicios/ http://www.arquitectoit.com/arquitectura/microservicios/que-son-los-microservicios/#respond Tue, 08 Mar 2016 09:00:55 +0000 http://www.arquitectoit.com/?p=613 Una de las tendencias en Arquitectura de Software de las que más se viene hablando las últimas fechas (desde el 2014) son los microservicios. Pero, realmente, ¿qué son los microservicios? ¿Qué tiene que ver los microservicios con el SOA? ¿Qué nuevas capacidades nos ofrecen dentro del ámbito del desarrollo de aplicaciones? Quizás, para poderlo explicar […]

The post Qué son los Microservicios appeared first on Arquitecto IT.

]]>
Una de las tendencias en Arquitectura de Software de las que más se viene hablando las últimas fechas (desde el 2014) son los microservicios. Pero, realmente, ¿qué son los microservicios? ¿Qué tiene que ver los microservicios con el SOA? ¿Qué nuevas capacidades nos ofrecen dentro del ámbito del desarrollo de aplicaciones?

Quizás, para poderlo explicar deberemos de analizar la situación en la que nos encontrábamos del desarrollo del software y cual es el nuevo enfoque.

Aplicaciones monolíticas y problemas que conllevan

Si pensamos en aplicaciones de software uno de los enfoques de diseño es el de construir aplicaciones monolíticas. En este enfoque todo el software que desarrollamos de una aplicación se construye de manera conjunta, apoyándonos sobre diferentes librerías o frameworks y realizando un despliegue masivo de la aplicación.

El diseño de aplicaciones monolíticas trae consigo una serie de problemas o inconvenientes:

  • El tiempo invertido en realizar un pequeño cambio y desplegarlo en PRO
  • Capacidad de absorber nuevas necesidades en el software que se está desarrollando.
  • Ante un cambio, hay que probar toda la aplicación. Hay que tener arrancada toda la aplicación aunque hagas pruebas unitarias.
  • Ante un cambio hay que volver a desplegar toda la aplicación y rearrancarla.
  • Al ser un solo proceso se ejecuta una sola vez y el escalado deberá de ser detrás de un balanceador que escale de forma horizontal por varias instancias.
  • En los circuitos de desarrollo, cambios, despliegue y pruebas queda tan poco tiempo entre release y release que es complejo realizar la gestión de versiones/release llegando a complicar mucho la gestión del software.

Esto no quiere decir que el desarrollo de aplicaciones monolíticas no sea una solución. Hay casos en los que es una buena opción.

Nuevas tendencias en el desarrollo del software

Los microservicios no han llegado al diseño del software de la noche a la mañana, si no, que hay un conjunto de tendencias que han hecho que el escenario sea favorable.

  • Mejora en los procesos de integración continua y despliegue de software
  • Consolidación de los API mediante sistemas RESTful como sistemas de integración.
  • Necesidad de acometer nuevas tecnologías como el BigData
  • El cloud con la disponibilidad de entornos de ejecución autoaprovisionados.
  • Implantación de metodologías ágiles, dónde hay un desarrollo dirigido por el usuario en búsqueda de funcionalidad útiles, dentro de un proceso iterativo.
  • Abandono paulatino de los enfoques de factoría del desarrollo del software hacía un modelo más artesanal. Menos ingeniería y más creatividad.

¿Qué resuelven los Microservicios?

Los microservicios no vienen a resolver un nuevo problema, si no que nos ofrecen una forma diferente de enfocar el desarrollo de aplicaciones. La idea que subyace detrás de las arquitecturas de microservicios es el “divide y vencerás”. El nuevo modelo plantea dividir la aplicación en pequeñas funcionalidades o servicios para implementar la aplicación.

De esta forma podemos hablar de tres planos de la arquitectura de la aplicación:

Arquitectura y Desarrollo de la Aplicación

La aplicación se estructurará en un conjunto de servicios independientes entre sí. Cada uno de los servicios debe de cubrir una funcionalidad clara de negocio. Esta independencia y división permite que su implementación en cuanto a código y persistencia de datos pueda ser políglota.

Gobierno de los Servicios

Los servicios en los que dividamos la aplicación no necesitarán ser gobernados o se aplicará un pequeño gobierno (registro del servicio). Los servicios se comunicarán entre sí mediante protocolos ligeros que no contengan ninguna lógica.

Despliegue y Ejecución

Cada uno de los servicios se puede desplegar de forma independiente, sin afectar al resto. De esta manera se podrán realizar modificaciones del software aisladas en un menor periodo de tiempo. A la hora de ejecutarse los servicios, estos se ejecutarán en procesos diferentes. Buscando el escalado más adecuado para cada uno de los servicios.

Definición de los Microservicios

Con todo esto podríamos recurrir para responder a la pregunta de qué son los servicios a la definición de James Lewis y Martin Fowler, la cual nos dice que:

“Una Arquitectura de Microservicios ofrece un enfoque de desarrollar una aplicación como un conjunto de pequeños servicios, mediante un enfoque políglota de programación y con diferente sistemas de almacenamiento, que se ejecutan en su propio proceso y que se comunican entre sí mediante mecanismos ligeros http/api, sin necesitar tener una gestión centralizada de los mismos. Los servicios representan capacidades de negocio y son desplegados de forma independiente.

The post Qué son los Microservicios appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/arquitectura/microservicios/que-son-los-microservicios/feed/ 0
Oracle Linux en el Docker Hub Registry http://www.arquitectoit.com/cloud/oracle-linux-en-el-docker-hub-registry/ http://www.arquitectoit.com/cloud/oracle-linux-en-el-docker-hub-registry/#respond Wed, 11 Nov 2015 08:00:51 +0000 http://www.arquitectoit.com/?p=583 Parece que las grandes empresas se están dando cuenta de la relevancia de Docker como plataforma para la creación de contenedores y empaquetado de aplicaciones, así de cómo facilita el despliegue de estas. El último caso ha sido Oracle, la cual ha subido las imágenes de Oracle Linux en el Docker Hub Registry. Dichas imágenes […]

The post Oracle Linux en el Docker Hub Registry appeared first on Arquitecto IT.

]]>
Parece que las grandes empresas se están dando cuenta de la relevancia de Docker como plataforma para la creación de contenedores y empaquetado de aplicaciones, así de cómo facilita el despliegue de estas.

El último caso ha sido Oracle, la cual ha subido las imágenes de Oracle Linux en el Docker Hub Registry. Dichas imágenes se pueden encontrar en el proyecto Oracle Linux. Ahora mismo se puede encontrar desde la versión 5 hasta la versión 7.1.

La información en detalle de las imágenes de Oracle Linux en el Docker Hub Repository se pueden encontrar dentro de la cuenta oficial de Oracle en Git, en el proyecto Docker Library Official Images.

Dentro de las imágenes de Oracle Linux encontramos un par de funcionalidades que ayudarán en su uso dentro del entorno Docker:

  • Tecnología Ksplice, la cual facilita la instalación de parches y actualizaciones en línea, sin necesidad de reiniciar el Kernel. De esta forma se reducen sustancialmente los periodos de inactividad del servicio.
  • Unbrekable Enterprise Kernel (UEK), el cual permite indicar qué versión del kernel queremos arrancar (Linux 6 o Linux 7) de igual manera que permite mantener compatibilidad entre estas versiones de las aplicaciones desarrolladas.

El despliegue de las  imagenes de Oracle Linux en el Docker Hub Registry se suma a las imágenes, ya existentes, de MySQL. Estas, aunque oficiales, no son mantenidas por Oracle, de momento.

The post Oracle Linux en el Docker Hub Registry appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/cloud/oracle-linux-en-el-docker-hub-registry/feed/ 0
QA y la Transformación Digital http://www.arquitectoit.com/editorial/qa-y-la-transformacion-digital/ http://www.arquitectoit.com/editorial/qa-y-la-transformacion-digital/#respond Sat, 07 Nov 2015 08:00:42 +0000 http://www.arquitectoit.com/?p=636 Más de uno está dando vueltas sobre cuál tiene que ser el papel de los departamentos de QA dentro de la transformación digital. La necesidad de modelos ágiles es confundida, con demasiada frecuencia, con una reducción del tiempo en el desarrollo del software. Esto puede desencadenar en la eliminación de ciertas tareas, las cuales, en […]

The post QA y la Transformación Digital appeared first on Arquitecto IT.

]]>
Más de uno está dando vueltas sobre cuál tiene que ser el papel de los departamentos de QA dentro de la transformación digital. La necesidad de modelos ágiles es confundida, con demasiada frecuencia, con una reducción del tiempo en el desarrollo del software. Esto puede desencadenar en la eliminación de ciertas tareas, las cuales, en un primer momento, pueden parecer sobrantes para el programador. Véase el QA. Más aún, algún directivo puede estar pensando en la eliminación de los departamentos de QA en el modelo de transformación digital. Craso error.

Cierto es que el modelo de QA debe sufrir un cambio para adaptarse a los nuevos modelos, ya que su actual funcionamiento no encaja en el ámbito de la transformación digital. Si bien existen una serie de puntos en los cuales pueden ser líderes y facilitadores hacían el cambio y adopción del nuevo modelo.

Patrocinadores del modelo DevOps

Hablar de transformación digital es hablar de una adopción de los modelos de despliegue continuo. El tiempo que transcurre entre el desarrollo del software y la implantación debe de reducirse. La gestión de las actualizaciones debe de ser automática.

En este campo el área de QA debe de ser prescriptor e implantador del modelo. La automatización de las tareas no implica el cese de actividad, si no la búsqueda de una mayor excelencia apoyada en el proceso de automatización:incrementando los casos de prueba, apoyando la evaluación en la base de conocimiento de los resultados del modelo continuo, valorando nuevos áreas como el testing exploratorio,…

Valedores de nuevas tecnologías

Otra de las cosas que está sucediendo en esta transformación digital es laadopción, de una forma más consciente, de nuevas tecnologías, véase Big Data, API Management,…

Un uso más constante de estas tecnologías va a traer consigo un conjunto deineficiencias derivadas de la falta de experiencia en estos modelos.

El área de QA debe de especializarse en estas nuevas tecnologías analizando pautas y comportamientos óptimos para completar las actividades de los equipos de desarrollo y reducir los riesgos derivados de la insipiencia tecnológica.

Palanca entre el negocio y la tecnología

La transformación digital se articula sobre el acercamiento de las áreas de negocio a la tecnología. Construir cosas que realmente el negocio necesite.

El conocimiento del negocio adquirido, durante años, en la optimización de los procesos de la empresa deberá de ser utilizado para poder mejorar los nuevos procesos digitales. De igual manera que ayudarán a no perder de vista los elementos básicos y estructurales del negocio, necesarios en todo desarrollo y que pueden ser olvidados en el modelo digital.

Conclusión

Por lo tanto podemos afirmar que el proceso a la transformación digital de una empresa debe de llevar consigo una modernización y transformación del departamento de QA y de esta manera poder utilizar al área de QA como palanca en la adopción del nuevo modelo digital.

Publicado en LinkedIn como QA y la Transformación Digital.

The post QA y la Transformación Digital appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/editorial/qa-y-la-transformacion-digital/feed/ 0
El reto de monitorizar microservicios http://www.arquitectoit.com/arquitectura/el-reto-de-monitorizar-microservicios/ http://www.arquitectoit.com/arquitectura/el-reto-de-monitorizar-microservicios/#respond Thu, 05 Nov 2015 08:00:55 +0000 http://www.arquitectoit.com/?p=591 Interesante charla de Adrian Cockcroft sobre El reto de Monitorizar Microservicios  (Monitoring Microservices: A challenge!). Adrian Cockcroft incide en que la propia definición de un microservicio “Loosely coupled service oriented architecture with bounded context” nos da dos de los puntos a tener en cuenta a la hora de monitorizar microservicios. Y es que al ser ligeramente acoplados […]

The post El reto de monitorizar microservicios appeared first on Arquitecto IT.

]]>
Interesante charla de Adrian Cockcroft sobre El reto de Monitorizar Microservicios  (Monitoring Microservices: A challenge!).

Adrian Cockcroft incide en que la propia definición de un microservicio “Loosely coupled service oriented architecture with bounded context” nos da dos de los puntos a tener en cuenta a la hora de monitorizar microservicios. Y es que al ser ligeramente acoplados y al tener su contexto acotado tendremos muchos microservicios que tendrán alguna relación entre sí.

En la monitorización de servicios serán importantes:

1. Velocidad – venimos desde datacenters que son auténticos silos, dónde se despliega en meses aplicaciones para toda la vida, pasando por entornos virtualizados, gestión de contenedores para hacer pruebas de test que duran minutos llegando al extremos de entornos que viven milisegundos para ejecutar un paso de un proceso como sucede en los entornos AWS Lambda Events.

2. Escalado, como crecer en máquinas para estos entornos tan altamente demandantes. ¿Cómo podemos saber qué uso de CPU tienen nuestros microservicios y cuanta demanda existe?

3. Flujo de los microservicios, se deberá de conocer el flujo de los microservicios. Pero dada la cantidad de microservicios que existen se generarán gráficos como el siguiente:

MonitorizacionMicroServicios

4. Fallos, como definir una tolerancia a fallos y controlar las caidas de regiones de microservicios en nuestro sistema.

5. Testing, cómo realizar testing sobre los sistemas, sin que estas pruebas de test y simulación sean muy caras.

6. Simulación, cómo se pueden simular los diferentes tipos de arquitecturas de microservicios a tener y ver cual sería su comportamiento.

Para este diseño de los flujos, pruebas de test, detección de fallos en arquitecturas de microservicios, Adrian Cockcroft ha creado la herramienta Spigo, la cual nos ayudará en la definición de este tipo de arquitecturas.

No os perdáis el vídeo sobre El reto de Monitorizar Microservicios (Monitoring Microservices: A challenge!)

Además os dejo la presentación que iba realizando:

 

The post El reto de monitorizar microservicios appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/arquitectura/el-reto-de-monitorizar-microservicios/feed/ 0
Metamorfosis en la Arquitectura de Software http://www.arquitectoit.com/editorial/metamorfosis-en-la-arquitectura-de-software/ http://www.arquitectoit.com/editorial/metamorfosis-en-la-arquitectura-de-software/#comments Tue, 03 Nov 2015 11:00:20 +0000 http://www.arquitectoit.com/?p=643 Hace no mucho participaba en una conversación sobre los nuevos modelos de desarrollo de software. Equipos ágiles y autosuficientes, con capacidad de decisión a la hora de crear y desplegar su software. Y una de las conclusiones a las que se llegó no dejó de despertar en mí cierto asombro, a la vez que perplejidad… “No hay […]

The post Metamorfosis en la Arquitectura de Software appeared first on Arquitecto IT.

]]>
Hace no mucho participaba en una conversación sobre los nuevos modelos de desarrollo de software. Equipos ágiles y autosuficientes, con capacidad de decisión a la hora de crear y desplegar su software. Y una de las conclusiones a las que se llegó no dejó de despertar en mí cierto asombro, a la vez que perplejidad… “No hay arquitectura, cada uno desarrolla como cree que es correcto”.

¿Por qué hemos llegado a ese punto en el cual no se ve útil un modelo de arquitectura de software para una empresa? ¿Por qué hemos pasado de tener asentados modelos arquitecturales, en ciertas ocasiones megalómanos,  a negar la mayor?

Quizás echando la vista atrás y viendo la metamorfosis en los modelos de arquitectura de software podamos entender mejor este planteamiento. Este análisis nos debería permitir establecer las bases para lo que deben de ser los nuevos modelos arquitecturales.

Arquitectura: Una necesidad imperiosa

La acumulación de software que se empezaba a producir en los años 90 dentro de las grandes empresas derivó en la adopción de Arquitecturas de Software como modelos de organización y optimización de dichos desarrollos.

Eran años en los que nacieron frameworks, como TOGAF, que nos enseñaron a realizar una buena organización de la arquitectura, identificando de forma clara a los arquitectos de negocio, los arquitectos de datos (o información), arquitectos de aplicaciones y arquitectos de tecnología.

Dentro de los éxitos conseguidos por estos modelos arquitecturales iniciales podemos encontrar:

  • Una correcta organización y catalogación de los sistemas del software. Identificando la división entre las aplicaciones así como las relaciones entre ellas.
  • Aplicación de técnicas de modelado de aplicaciones y procesos de negocio. Resaltando la importancia del qué y no del cómo. Aunque ahora suene añejo, metodologías RUP, casos de uso,…
  • Definición de patrones de desarrollo de software y buenas prácticas de codificación. Aplicación de reglas en la búsqueda de una mejora en la calidad del software y la reducción de las deudas técnicas de los aplicativos.
  • Desarrollo de artefactos o frameworks estructurales de apoyo al negocio los cuales reducían las complejidades técnicas a los programadores.

Sobre-arquitecturización: La decadencia

Todo abuso genera un rechazo. El intentar prolongar modelos de software obsoletos basados en una sobre-arquitecturización de artefactos y procesos llevaron a un rechazo frontal por parte de los equipos de desarrollo y, en ciertos casos, de los mandos directivos.

La arquitectura paso de ser un facilitador a ofrecer un modelo de control, plagado de complicaciones e ineficiencias, que no hacía más que lastrar a los desarrollos del software, sobre coste incluido.

Dentro de las malas prácticas de esta época destacamos:

  • Creación de artefactos de desarrollo que recubrían piezas ya existentes (sobre-arquitecturización) y totalmente válidas para uso tal cual estaban.
  • Exceso de modelado de las aplicaciones. Intento de modelar cualquier paso del proceso de desarrollo, por muy insignificante que este fuese. Acompañado del error de aplicar técnicas de modelado UML a cualquier elemento y sobre cualquier tipo de proyecto.
  • No adaptación de los procesos de desarrollo, control y eficiencia a los nuevos tiempos y tecnologías. Anclaje radical en las tecnologías del pasado. Creencia del “esto ya lo hacía el host”.

Transformación Digital: La nueva arquitectura 

La nueva época de transformación digital en la que nos encontramos y el conjunto de cambios tecnológicos que conlleva pide a gritos un nuevo modelo de arquitectura que ayude a las organizaciones en dicho proceso.

Este tiene que ser un punto de inflexión para los modelos de Arquitectura del Software en los cuales se vuelva a demostrar la importancia y los beneficios que conlleva su adopción.

Las responsabilidades de esta nueva arquitectura deben de focalizarse en:

  • Entender y facilitar los nuevos paradigmas y tecnologías. Facilitando la adopción de los mismos por parte de los equipos de desarrollo. Analizar la necesidad de definir nuevos artefactos o frameworks de desarrollo.
  • Ser sponsor y valedor de los desarrollos de software basados en metodologías agile. Adoptar dicha metodología como base de la propia Arquitectura.
  • Redefinir los conceptos de modelado de aplicaciones con un enfoque basado en el Dato.
  • Ayudar a transformar el perfil del desarrollador, adecuándolo a las acuciantes necesidades tecnológicas actuales.

Conclusiones

No nos dejemos llevar por los errores del pasado, aprendamos de ellos y analicemos como debe de ser el nuevo modelo de arquitectura de software.

Adaptemos sus roles y mecanismos para poder utilizar a la arquitectura como punta de lanza en el nuevo modelo de transformación digital de las empresas.

Publicado en LinkedIn como Metamorfosis en la Arquitectura de Software.

The post Metamorfosis en la Arquitectura de Software appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/editorial/metamorfosis-en-la-arquitectura-de-software/feed/ 1
Ejemplo de Layout Adaptable con Media Queries http://www.arquitectoit.com/front-end/ejemplo-de-layout-adaptable-con-media-queries/ http://www.arquitectoit.com/front-end/ejemplo-de-layout-adaptable-con-media-queries/#respond Mon, 10 Sep 2012 07:00:07 +0000 http://www.arquitectoit.com/?p=262 Ejemplo de Diseño Sensible Para el desarrollo de este ejemplo, tomamos el caso descrito en mi anterior articulo a modo de diseño. De este modo, tenemos una página que va a adaptar su presentación de acuerdo al ancho del dispositivo que accede a ella. Este es el Diagrama de Componentes de nuestro ejemplo: Los estilos […]

The post Ejemplo de Layout Adaptable con Media Queries appeared first on Arquitecto IT.

]]>
Ejemplo de Diseño Sensible

Para el desarrollo de este ejemplo, tomamos el caso descrito en mi anterior articulo a modo de diseño. De este modo, tenemos una página que va a adaptar su presentación de acuerdo al ancho del dispositivo que accede a ella.

Este es el Diagrama de Componentes de nuestro ejemplo:

Diagrama de clases del ejemplo

Los estilos que son comunes, los vamos a definir en una hoja de estilos CSS (base.css), para ser empleada independientemente de la resolución que tenga el dispositivo con el que accede el usuario.

Como se puede observar en el diagrama, hemos decidido que nuestra aplicación va a realizar la adaptación de su contenido a dos tipos de resoluciones:

  1. Dispositivos con un ancho de resolución menor de 400 pixeles (px), que visualizarán nuestra aplicación con un layout vertical, representando las distintas zonas cada una en una fila

Layout menor de 400 px

  1. Dispositivos con un ancho de resolución mayor a 400 pixeles (px), que visualizarán nuestra aplicación con un layout que ubique el menú ppal a la izquierda del contenido principal

Ejemplo para Layout mayor de 400 px

Este modo nos va a permitir, el soporte incluso para el mismo usuario en el caso que disponga de un dispositivo con el que pueda variar su orientación

Con el fin de comprobar el cambio en dicha página, la cabecera de dicha página cambiará de color como consecuencia del ancho del dispositivo que accede.

Puedes ver el funcionamiento del ejemplo que vamos a realizar.

Áreas de la Pagina y su comportamiento

Nuestro ejemplo, presenta las siguientes secciones:

  • Una sección que es la cabecera del sitio
  • Una barra de menu, con enlaces a otras secciones.
  • Una sección, donde los articulos son presentados
  • Un pie de página, con un enlace para contactar con el creador de la página

Los cámbios que se van producir son los siguiente:

  1. Dispositivos con un máximo de 400 px. En este caso, las distintas secciones se presentan de modo lineal, una tras la otra. La hoja de estilos, con el nombre Adaptlt400.css, dispone de los siguientes estilos:
#banner {
  color: black;
  font-size: 1em;
  text-align: center;
  background-color:white;
}

En este caso, como no queremos alterar las disposiciones de los elementos, cambiamos el color de fondo de la cabecera, a

  1. Dispositivos con un mínimo de 400px. Los dispositivos que cumplan con esta característica, reciben distinta presentación:
  • La barra de menú se presenta a la izquierda, alineando los distintos enlaces
  • La sección con el contenido, se presenta a la derecha del menú

Para conseguir ese efecto, creamos la hoja Adaptgt400.css, con los siguientes cambios:

Cambiamos los elementos del menú de navegación, para se presenten como una lista

ul
{
  text-align: left;
  list-style-type: none;
  padding: 0;
  margin: 0;
}
li {display: block}
#banner {
  color: white;
  font-size: 1em;
  text-align: center;
  background-color:blue;
}

Indicamos que queremos que la barra de navegación se ubique a la izquierda de la zona de contenidos.

#navMenu {
  padding: 0;
  display: block;
  float:left;
  width: 20%;
  height: 100%;
}

Indicamos que la sección con los artículos, también flote sobre el menú de navegación.

#workArea {
  float:left;
  width: 80%;
}

Aplicar Media Queries a la página

Para que se aplique la hoja de estilo correspondiente, debemos incluir en nuestra página el enlace a las hojas de estilos.

Para ello, empleamos la etiqueta “link”, añadiendo las dos hojas de estilos:


	
	

Como se observa, a primera vista, tenemos un nuevo atributo “media” que es el que vamos a emplear para indicar cuando se debe aplicar cada una de las hojas de estilos.

Herramientas empleadas

Debido a mi “afición” al software libre, me siento obligado a enumerar las herramientas que he empleado para la realización de este artículo:

  • Diagramas. Para los diagramas, he empleado la herramienta DIA. Se puede descargar e instalar desde los repositorios por defecto, en Ubuntu.
  • Imágenes. Todas las imágenes han sido redimensionadas con Gimp.
  • Desarrollo HTML 5. Para el desarrollo de la página, he empleado BlueGriffon.

The post Ejemplo de Layout Adaptable con Media Queries appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/front-end/ejemplo-de-layout-adaptable-con-media-queries/feed/ 0
SPDY. Visión general. http://www.arquitectoit.com/front-end/spdy-vision-general/ http://www.arquitectoit.com/front-end/spdy-vision-general/#respond Tue, 14 Aug 2012 08:00:13 +0000 http://www.arquitectoit.com/?p=276 ¿Qué es SPDY? En noviembre de 2009, Google, dentro de su proyecto Let’s make the web faster, anuncia la creación de un nuevo protocolo cuyo principal objetivo es reducir el tiempo de carga de las páginas web. El nombre elegido para el nuevo protocolo es SPDY (pronunciado Speedy). Conjuntamente con el anuncio, se presenta la […]

The post SPDY. Visión general. appeared first on Arquitecto IT.

]]>
¿Qué es SPDY?

En noviembre de 2009, Google, dentro de su proyecto Let’s make the web faster, anuncia la creación de un nuevo protocolo cuyo principal objetivo es reducir el tiempo de carga de las páginas web. El nombre elegido para el nuevo protocolo es SPDY (pronunciado Speedy).

Conjuntamente con el anuncio, se presenta la documentación, la implementación y los resultados de las primeras pruebas realizadas en los laboratorios: ¡la carga de páginas web se ve mejorada en un 55%! Atendiendo a estos resultados y teniendo en cuenta que son pruebas de laboratorio se puede decir que  el tiempo necesario para visualizar una web se ve reducido, aproximadamente, a la mitad.

Características

SPDY está diseñado específicamente para minimizar la latencia de red y disminuir el tiempo utilizado en el transporte de información en las comunicaciones web.

SPDY se sitúa a medio camino entre la capa de sesión y la capa de aplicación. Este protocolo no sustituye al protocolo HTTP sino que lo complementa y mejora determinados aspectos que HTTP no contempla.

SPDY protocol

Las características principales en las que se basa SPDY:

  • Conexiones multiplexadas: es la idea base del protocolo. Se permite un número ilimitado de peticiones sobre una misma conexión. Esta característica también mejora la eficiencia del protocolo TCP: se necesita realizar menos conexiones y enviar menos paquetes de información en cada conexión (aunque son más densos).
  • Compresión de cabeceras HTTP: SPDY comprime las cabeceras HTTP, tanto de peticiones como de respuestas. Esto hace que se envíen menos paquetes y menos bytes en cada paquete disminuyendo el tiempo necesario para procesar la petición.
  • Priorización de peticiones: SPDY implementa un sistema de prioridades para el procesamiento de peticiones. El cliente puede asignar a cada petición que realiza una prioridad y el servidor resolverá antes las peticiones de prioridad más alta. Esto previene que se produzca una congestión de red con peticiones a recursos que no son críticos.
  • Push desde el servidor: este protocolo experimenta con la idea de enviar datos desde el servidor al cliente antes de que este haga una petición expresa a un recurso, es decir, el servidor envía información al cliente que este va a necesitar pero que aún no ha pedido. Para ello utiliza la cabecera X-Associated-Content. Esta característica puede suponer una mejora significativa en el tiempo inicial de carga de páginas web.

Uso de SDPY

Actualmente, está liberada la versión 3 de SPDY. Para poder sacar partido a las características del protocolo y aprovechar las mejoras en el rendimiento de las comunicaciones web es necesaria una adaptación de las dos partes más importantes implicadas en la comunicación web: el navegador y el servidor.

Del grupo de navegadores más conocidos y utilizados, Internet Explorer, Chrome, Firefox, Opera y Safari, los que soportan SPDY son Chrome y Firefox desde las versiones 6 y 11, respectivamente. También en sus versiones para Android. Esto supone más de la mitad de los navegadores que se utilizan actualmente en la navegación por internet por lo que ya existe un uso muy alto de navegadores web que pueden aprovechar las mejoras proporcionadas por SPDY. Amazon con Silk, el navegador para Kindle, también soporta SPDY.

Opera, por su parte, ha lanzado un cliente a través de Opera Labs con una versión de prueba que soporta SPDY pero aún no está disponible en la versión estable de su navegador, aunque probablemente lo estará en una de las siguientes versiones estables.

Por otro lado, dos compañías muy importantes en el mercado de navegadores como Microsoft y Apple, con sus navegadores Internet Explorer y Safari respectivamente, no parecen tener planes para dar soporte a SPDY.

Si quieres puedes consultar el soporte de los navegadores para SPDY.

El otro agente principal involucrado en las comunicaciones web son los servidores web. Google es quien más esfuerzo está realizando para que el proyecto salga adelante dando soporte a este protocolo en todos sus servicios que funcionan bajo HTTPS: Google Search, Gmail, Google Ad’s…

Recientemente, Twitter y Facebook también han anunciando que dan soporte a SPDY en sus servidores, es decir, van a servir sus páginas web a través de este protocolo si el usuario accede con un navegador que lo soporte. Varios servidores web muy utilizados van implementando, poco a poco, el soporte a SPDY: el módulo mod_spdy da soporte a este protocolo para el servidor Apache y también Jetty y nginx implementan las características para soportar SPDY.

Aunque hablamos de que es necesaria una adaptación tanto de los navegadores como de los servidores para utilizar SPDY, estas adaptaciones son transparentes a los usuarios de la web. Es posible que las mejoras introducidas por este protocolo vayan a influir en el diseño de los nuevos sitios web y en las técnicas de optimización de la parte de front-end de los servicios que proporcione una empresa si se incrementa o estandariza el uso de este protocolo.

Conclusiones

El objetivo inicial de SPDY era proporcionar un acceso más rápido a la web sin necesidad de cambiar el contenido y de forma transparente a los usuarios. Ha demostrado que es posible y viable. Presenta importantes mejoras a nivel de rendimiento en cualquier tipo de conexión,  tanto en conexiones normales como en conexiones para móviles.

SPDY se basa en una serie de buenas ideas (compresión de cabeceras, una única conexión para múltiples peticiones, etc.) que dan una base sólida para la posible definición de un nuevo estándar. ¿HTTP 2.0?

SPDY es una de las propuestas, enviada por Google al IETF, para la definición del estándar HTTP 2.0. Otra de las propuestas enviada por Microsoft es HTTP Speed+Mobility y, para su definición, toma como base varias características de SPDY y añade mejoras relacionadas con el trabajo que se ha hecho hasta ahora de WebSockets.

En esta época donde existe una gran cantidad de información y la posibilidad de acceder a ella desde cualquier punto y dispositivo es imprescindible que el acceso sea lo más rápido posible. Parece que Google y SPDY han iniciado con fuerza este proceso de mejorar el acceso a la información de la red.

Estaremos atentos a los movimientos que se vayan produciendo. Mientras tanto, ¿cuál es vuestra opinión sobre este protocolo? ¿Creéis que su uso se va a seguir extendiendo? ¿Se convertirá en un estándar de facto?

The post SPDY. Visión general. appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/front-end/spdy-vision-general/feed/ 0
Layout Adaptable en Diseños “Sensibles” http://www.arquitectoit.com/front-end/layout-adaptable-en-disenos-sensibles/ http://www.arquitectoit.com/front-end/layout-adaptable-en-disenos-sensibles/#comments Sun, 12 Aug 2012 17:36:03 +0000 http://www.arquitectoit.com/?p=135 Que tu diseño sea “Sensible” al contexto del usuario Dentro del ámbito de la Accesibilidad, encontramos un punto muy importante, que todo arquitecto y desarrollador Web debería de tener en cuenta a la hora de plantear la Arquitectura de una nueva Aplicación Web. Me estoy refiriendo a la adaptación del contenido al dispositivo que emplea […]

The post Layout Adaptable en Diseños “Sensibles” appeared first on Arquitecto IT.

]]>
Que tu diseño sea “Sensible” al contexto del usuario

Dentro del ámbito de la Accesibilidad, encontramos un punto muy importante, que todo arquitecto y desarrollador Web debería de tener en cuenta a la hora de plantear la Arquitectura de una nueva Aplicación Web. Me estoy refiriendo a la adaptación del contenido al dispositivo que emplea el usuario para acceder a dicha aplicación, tomando de modo adicional el contexto en el que se desenvuelve.

Cuando me refiero al contexto, principalmente, podemos centrarnos en la orientación del dispositivo, la resolución del mismo, etc…

A lo largo de los últimos años, ha surgido un nuevo paradigma denominado Responsive Design, que podemos traducir como Diseño Sensible. El planteamiento del Diseño Responsable se basa,  en tener en cuenta el Dispositivo y el contexto que el usuario emplea para acceder al contenido de modo que:

  • Dicho contenido se adapte al dispositivo, siendo adaptable a las características del Viewport (espacio donde se muestra el contenido) y se evita que el usuario deba realizar scroll por nuestras páginas, impidiendo una experiencia de usuario correcta.
  • De modo adicional, también debe adaptarse al modo de navegación del que dispone el usuario (si la navegación se va a realizar por teclado, por pantalla táctil, etc…)
  • Evitar la duplicidad de páginas para dar cábida a todos los dispositivos, de modo que no entremos en un mantenimiento costoso y pesado
  • Marcar las bases para la evolución de nuestra Aplicación Web a nuevos dispositivos, de un modo ágil

El diseño sensible presenta varios aspectos a tener en cuenta, pero en este articulo vamos a enfocarnos a la gestión de las distintas presentaciones (Layouts) de una Aplicación Web diseñada de este modo, siendo adaptadas al llamado Viewport (espacio en el que la página será presentada en el dispositivo que accede a ella).
Recomiendo la lectura, para aquellos que se encuentren cómodos con el ingles, del post de Ethan Marcotte

Distintos clientes, misma necesidad

Actualmente, nos encontramos con la siguiente necesidad.

Necesidad actual: representar contenido adaptado al dispositivo

A dia de hoy, nos encontramos con multitud de dispositivos, que presentan distintas características a las que nuestra Aplicación Web debe tener en cuenta en su diseño:

  • A nivel hardware, las pantallas presentan distintas resoluciones, en incluso algunos, como las tabletas pueden variarla de modo dinámico.
  • Ciertos dispositivos son elegidos por usuarios que requieren desarrollar tareas “sobre la marcha” y de modo óptimo, para mejorar su acceso a Internet, por lo que estamos obligados a presentarle el contenido más importante de un modo accesible
  • Los dispositivos presentan distintos navegadores, con distinto soporte a lenguajes de marcas y tecnologías complementarias (javascript, soporte a lenguaje de marcas)

Media Queries, la solución a aplicar

Para ayudarnos en esta nueva tarea, disponemos de un mecanismo denominado Media Queries. El objetivo de esta tecnología, cumple con el objetivo que tenemos que cubrir.

Si queremos conocer el soporte actual de los navegadores, podemos encontrar aquí más información.

Por medio del uso de Media Queries, podemos establecer distintas hojas de estilo para lograr que nuestro ntenido se adapte a distintos tipos de medios. Si a este nivel equiparamos los distintos “tipos de medios” a los distintos tipos de dispositivos para los que deseamos que nuestra Aplicación Web, nos encontramos con el siguiente escenario:

Diagrama de clases del ejemplo

Ya sea por el medio que sea, análisis de estadísticas de acceso de dispositivos en Internet, por las necesidades de nuestro cliente o de nuestra empresa; hemos decidido que nuestra aplicación va a realizar la adaptación de su contenido a dos tipos de resoluciones:

  1. Dispositivos con un ancho de resolución menor de 400 pixeles (px), que visualizarán nuestra aplicación con un layout vertical, representando las distintas zonas cada una en una fila

Layout menor de 400 px

  1. Dispositivos con un ancho de resolución mayor a 400 pixeles (px), que visualizarán nuestra aplicación con un layout que ubique el menú ppal a la izquierda del contenido principal

Ejemplo para Layout mayor de 400 px

Los estilos que son comunes, los vamos a definir en una hoja de estilos CSS (base.css), para ser empleada independientemente de la resolución que tenga el dispositivo con el que accede el usuario.

Este enfoque, nos obliga a tener en cuenta a la hora de diseñar nuestra aplicación, de la importancia que tiene la definición de los estilos CSS y el mejor modo de agruparlo.

Como hemos comentado anteriormente, media Queries nos va a permitir aplicar una hoja de estilos u otra, dependiendo de las reglas que establezcamos. En nuestro caso, será el ancho mínimo el valor por el cual la CSS correspondiente será empleada.

Siempre queremos dar soporte a cualquier dispositivo, pero debemos tener en cuenta que el uso de media queries puede tener impacto en cuanto al rendimiento de nuestra Aplicación:

  • El navegador evalúa variaciones en el viewport, que provocar hacer el usuario, como cambio del tamaño de la ventana donde visualiza el contenido o variación en la orientación del dispositivo, redimensionar la ventana del navegador. Por esta razón, debemos establecer un límite a la hora de indicar el número de reglas, con el fin de no penalizar el rendimiento en la respuesta del navegador
  • Limitar los estilos de las hojas para el layout, sólo para posicionar contenido de nuestra página y no de presentación
  • Si los estilos los tenemos en ficheros CSS, hay que tener en cuenta las peticiones que debe realizar el navegador para no sobrepasar el número optimo

 Por norma general, las peticiones de recursos desde nuestra página debería de estar entre 6 y 8, contando con las peticiones para otros recursos, como las imágenes)

Resumen

Una vez visto el funcionamiento de Media Queries, podemos reconocer una herramienta a tener en cuenta si queremos adaptar la presentación del contenido de nuestras Aplicaciones Web a los distintos dispositivos que pueden emplear nuestros usuarios, y los que puedan aparecer en un futuro (más que próximo).

A la hora de aplicar Media Queries debemos tener en cuenta:

  • El rendimiento. Hay que tener en cuenta que la modularización que supone su uso, implica añadir peticiones de nuestras páginas. Deberíamos tener siempre como meta, que no se superen las 8 peticiones por página, sobre todo si nuestros usuarios van a acceder con dispositivos móviles.
  • Los estilos a incluir en las hojas de estilos. Debido a que el navegador reevalua cualquier cambio en el espacio donde se presenta nuestra página, el hecho de añadir cambios en la presentación de los elementos de nuestra página supone más tiempo de proceso del navegador para aplicarlos. Deberíamos, por tanto, añadir a las hojas de estilo cambios en la disposición de los elementos, e intentar centralizar en una hoja base la presentación de los mismos (color de fondo, fuentes, bordes, etc.)

Herramientas empleadas

Debido a mi “afición” al software libre, me siento obligado a enumerar las herramientas que he empleado para la realización de este artículo:

  • Diagramas. Para los diagramas, he empleado la herramienta DIA. Se puede descargar e instalar desde los repositorios por defecto, en Ubuntu.
  • Imágenes. Todas las imágenes han sido redimensionadas con Gimp.

The post Layout Adaptable en Diseños “Sensibles” appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/front-end/layout-adaptable-en-disenos-sensibles/feed/ 6
Diseños Web Multimedia con Popcorn http://www.arquitectoit.com/front-end/disenos-web-multimedia-con-popcorn/ http://www.arquitectoit.com/front-end/disenos-web-multimedia-con-popcorn/#respond Wed, 20 Jun 2012 07:00:32 +0000 http://www.arquitectoit.com/?p=83 La aparición de los elementos VIDEO y AUDIO en HTML5 ha simplificado la capacidad de insertar elementos multimedia en nuestros diseños webs. Si bien, el estado primigenio de la especificación HTML5 hace que sea complicado mantener la compatibilidad de código para diferentes navegadores. Popcorn: Unificando el elemento VIDEO Popcorn es un proyecto de Mozilla que […]

The post Diseños Web Multimedia con Popcorn appeared first on Arquitecto IT.

]]>
La aparición de los elementos VIDEO y AUDIO en HTML5 ha simplificado la capacidad de insertar elementos multimedia en nuestros diseños webs. Si bien, el estado primigenio de la especificación HTML5 hace que sea complicado mantener la compatibilidad de código para diferentes navegadores.

Popcorn: Unificando el elemento VIDEO

Popcorn es un proyecto de Mozilla que pretende dar un interface unificado y sencillo para el tratamiento de los elementos multimedia en las páginas web.

De esta manera, lo primero que nos ofrece Popcorn es el framework Popcorn.js, el cual, mediante un sistema de eventos facilita la interacción con los elementos multimedia. Así Popcorn.js nos permite centrarnos en lo que realmente queremos hacer simplificandonos el control y gestión del vídeo.

Popcorn.js estandariza las propiedades del elemento HTMLMediaElement. Ya que a día de hoy no tiene una implementación unificada en todos los navegadores. Cada versión del framework tiene unos 1400 test de regresión para asegurar la compatibilidad con los navegadores web.

Popcorn: Realizando mashups multimedia

Pero Popcorn no se queda en una simplificación de la gestión de vídeos, si no que su idea es el poder proporcionar una experiencia multimedia completa al usuario. De esta forma, el framework Popcorn.js cuenta con multiples funcionalidades para acceder a recursos multimedia: fotos, tweets, wikipedia,… los cuales iremos cargando, mostrando y ocultando en el avance del vídeo.

Alrededor del proyecto Popcorn han nacido un ecosistema de proyectos y librerías que complementan a este framework, dando la posibilidad de extender su uso.

Entre los plugins podemos encontrar: Twitter, Flickr, Lastfm, Linkedin, OpenMap, Wikipedia, Google Maps,…

A descargarse Popcorn

Si quieres trabajar con el framework Popcorn.js tienes que saber que la versión actual de Popcorn es Popcorn 1.2. Las librerías que necesitarás son:

Otra opción es personalizarse la librería de producción mediante un builder.

Si te has descargado Popcorn es bueno que ahora le eches un vistazo a la documentación de popcorn, sus apis y demos.

Algo de código con Popcorn

El uso del framework Popcorn.js es muy sencillo. Veamos algunas pequeñas líneas de código sobre lo que podemos hacer:

Cargando Popcorn:

Creando texto en un momento determinado del vídeo:

var popcorn = Popcorn( "#ourvideo" );

popcorn.footnote({
  start: 2,
  end: 5,
  target: "footnote",
  text: "Pop!"
});

Integrando Popcorn con las fotos de Flickr:

var pop = Popcorn( "#video" );

pop.flickr({
  start: 5,
  end: 15,
  userid: "35034346917@N01",
  target: "flickrdiv"
});

Integrando Popcorn con el timeline de Twitter:

pop.twitter({
  start: 5,
  end: 15,
  title: "Steve Song",
  src: "@stevesong",
  target: "twitterdiv",
});

Ejemplos de Webs hechas con Popcorn

Algunas de las demos que puedes visualizar con Popcorn son:

  • Know you exit – un experimento musical con gente componiendo alrededor del mundo. La composición de música y vídeo queda integrada con tweets de Twitter y geolocalizaciones.
  • Zaragoza Public Spaces, vídeo que nos muestra sitios de interés de Zaragoza integrando localizaciones con Google Maps y texto anexo al vídeo.
  • Open Images, Open Data – una iniciativa holandesa que nos muestra como se puede enriquecer un vídeo con contenido multimedia diverso obtenido de Wikipedia, Google Maps, repositorios de los museos de Holanda,…
  • Color Tracker, como poder seguir un color dentro del vídeo y añadirle información.
  • otras demos.

Aunque hemos comentado que Mozilla Popcorn es un proyecto que soporta diferentes navegadores, es muy recomendable visualizarlo con Firefox. 😀

Popcorn Maker (proyecto Butter): editando nuestros vídeos

Adicionalmente al framework Popcorn.js el proyecto Popcorn está construyendo Popcorn Maker. Que es conocido como el proyetco Butter.

Popcorn Maker es un editor de vídeos en formato web. De esta forma el editor Popcorn Maker creará de forma dinámica el código del framework Popcorn.js en base a las acciones que definamos: insertar elementos en el vídeo, realizar overlaping,…

Todo el trabajo con Popcorn Maker se realiza de forma visual, sin tener que tirar ni una sola línea de código.

A día de hoy podemos probar la Preview de Popcorn Maker y habrá que esperar hasta noviembre 2012 para poder disponer de la primera versión de Popcorn Maker.

Adicionalmente podemos bajarnos el código de Popcorn Maker, realizar pruebas, reportar bugs, extenderlo,…

Más información sobre el proyecto en Mozilla Popcorn y @popcornjs

The post Diseños Web Multimedia con Popcorn appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/front-end/disenos-web-multimedia-con-popcorn/feed/ 0
ArquitectoIT.com: Arquitectos hablando de tecnología y arquitectura http://www.arquitectoit.com/general/arquitectoit-com-arquitectos-hablando-de-tecnologia-y-arquitectura/ http://www.arquitectoit.com/general/arquitectoit-com-arquitectos-hablando-de-tecnologia-y-arquitectura/#respond Fri, 08 Jun 2012 08:00:37 +0000 http://www.arquitectoit.com/?p=41   Como Arquitectos IT que somos hemos podido comprobar que un buen uso de la tecnología, un uso razonable y en un camino de equidad conlleva el poder realizar grandes proyectos de tecnología. El Arquitecto IT, denostado a veces, glorificado las que menos, intenta dar una visión de la estandarización, coherencia y buen uso de las tecnologías. […]

The post ArquitectoIT.com: Arquitectos hablando de tecnología y arquitectura appeared first on Arquitecto IT.

]]>
 

Como Arquitectos IT que somos hemos podido comprobar que un buen uso de la tecnología, un uso razonable y en un camino de equidad conlleva el poder realizar grandes proyectos de tecnología. El Arquitecto IT, denostado a veces, glorificado las que menos, intenta dar una visión de la estandarización, coherencia y buen uso de las tecnologías. Para ello, el Arquitecto IT se basa en el uso de estándares, patrones, buenas prácticas, prueba nuevas tecnologías, intenta convencer en el avance tecnológico,…

En ArquitectoIT.com nos hemos juntado un grupo de Arquitectos IT que tienen ganas de hablar sobre nuevas tecnologías, de cómo estas nos pueden ayudar en el desarrollo de proyectos. Arquitectos IT que quieren compartir sus experiencias y conocimientos.

Buscamos la conversación, la crítica, el aprendizaje, el debate,… pero siempre desde el lado positivo, desde el lado de la colaboración, del compañerismo, del aporte de soluciones por parte de la gente. Buscamos que, de forma ordenada, la gente exprese sus visiones, de a conocer sus puntos de vista sobre las cosas que aquí se escriben.

La meta. Aprender de la arquitectura y tecnología. Y, como no, pasar un buen rato entre amigos.

Solo nos queda deciros una cosa, ¡Aprendamos!

Los que abajo suscriben.

Carlos, José Luis, Enrique, Jorge, Juanma, Marcos, José Carlos, Jose Ignacio, Miguel Ángel y Víctor.

The post ArquitectoIT.com: Arquitectos hablando de tecnología y arquitectura appeared first on Arquitecto IT.

]]>
http://www.arquitectoit.com/general/arquitectoit-com-arquitectos-hablando-de-tecnologia-y-arquitectura/feed/ 0