[go: up one dir, main page]

YouTube permite personalizar su reproductor de video e integrarlo en nuestras páginas y aplicaciones para crear experiencias con videos interactivos.
Es un gran desafío personalizar el reproductor de modo de lograr una experiencia consistente a través de diferentes dispositivos, con distintos tamaños de pantalla, como móviles, TV, laptops y tablets. ¿Como podemos hacerlo?

El componente Web del reproductor de Youtube

Gracias a Polymer y los componentes de YouTube podemos utilizar y personalizar el reproductor. Podemos configurar sus parámetros, gestionar su estado y sus eventos!

Los parámetros más importantes son el videoid, con el que especificamos el video que queremos ver, la altura y ancho (parámetros height y width), y finalmente un parámetro que permite simular el modo Chromeless (el reproductor sin controles y branding..), de modo de crear nuestros propios controles para reproducir el video.

Recreando caso de éxito "Videos interactivos, Knorr Mexico"

Recreemos la experiencia con videos interactivos de Knorr México, utilizando Polymer, Fig.1:
Fig.1
En esta experiencia se logra ocultado los controles estándar del reproductor (utilizando el modo Chromeless), y mostrando en cambio controles personalizados. Además se comienza en forma automática la reproducción de video.

Como lo podemos hacer con el componente web de YouTube? Simple:

Vamos a configurar el componente de YouTube con reproducción automática y sin controles (Chromeless):

<google-youtube

 videoid="3T87lMYzqf4"

 height="100%"
 width="100%"
 rel="0"
 autoplay="1"
 chromeless>
</google-youtube>

Veamos el ejemplo:
http://matiasmolinas.github.io/google-youtube/components/google-youtube/demo.html

 Puedes hacer un fork del proyecto en Github:
https://github.com/matiasmolinas/google-youtube

 En el ejemplo solo falta utilizar paper elements para crear nuevos controles de reproducción, algo que es muy recomendado cuando utilizas el modo Chromeless!

 En el próximo artículo veremos cómo incorporar este tipo de controles (paper elements), junto con el API de Datos de YouTube, al hacer uso del componente:
google-youtube-video-wall
https://github.com/GoogleWebComponents/google-youtube-video-wall

 Hasta la próxima!

 Este post ha sido escrito por +Matias Molinas, Google Developer Expert para YouTube API. Editor by +Nicolas Bortolotti

Cual es uno de los mayores desafíos a los que nos enfrentamos hoy en día los desarrolladores al momento de crear la UI de una aplicación?

Probablemente uno de los mayores desafíos es que las aplicaciones se han convertido en servicios, que se consumen desde distintos dispositivos, como móviles, tabletas, portátiles, TV, dispositivos vestibles y autos!!! Todos con distintos tamaños de pantallas, e incluso con distinto tipo de entrada de datos, como mouse y teclado, pantalla táctil y voz.
Por si esto fuera poco, incluso se utilizan estos nuevos servicios o aplicaciones desde distintos dispositivos en forma simultánea.

Este es un problema al que también se enfrenta Google, ya que provee servicios para todas las plataformas, e inclusive es pionero creando algunas de estas plataformas, como Android Wear y Android Auto.

La buena noticia es que Google no solo esta preparado para estos escenarios, en los que ofrece sus aplicaciones y servicios con una interfaz de usuario (UI) y una experiencia de usuario (UX) consistente, si no que ademas a desarrollado un lenguaje de diseño, Material Design, que resuelve el problema, y lo ha implementado sobre varios frameworks y tecnologías open source, como Polymer, Android L y AngularJS, lo que facilita y permite la rápida adopción de esta solución por parte de los desarrolladores para sus propias aplicaciones.

Material Design
Material Design es un lenguaje de diseño que utiliza los principios clásicos de diseño, e incorpora la ciencia y la tecnología para dar un aspecto material a los componentes de UI, como sombras y aceleración, de modo de lograr una metáfora de los componentes con objetos reales que le transmita al usuario información en forma intuitiva y que permita aplicar cientos de años de diseño aplicado a objetos materiales a una nueva rama de diseño, que es el diseño de UI, que solo lleva pocos años de vida.
Material Design es ademas el resultado de la evolución de Android a través de sus diferentes versiones.

Como se trata de una evolución de Android lo podemos encontrar en todas las versiones de Android L o superior, y en sus distintas plataformas, Android, Android Wear, Android TV y Android Auto.
Y para el desktop? y para la Web? Contamos con una implementación sobre las más modernas opciones tecnológicas para la Web, esto es Polymer para Web Components y otra para Angular JS.

Polymer
Polymer es una librería que nos permite crear páginas y aplicaciones Web mediante componentes (web components). 
La potencia de este enfoque radica en que nos permite utilizar componentes propios y de terceros y componerlos para construir nuestra aplicaciones de forma simple, reduciendo tiempos y esfuerzo.

Polymer provee un set de controles estándar, Polymer paper elements, que permiten implementar la UI con Material Design. Ademas Google provee una colección de componentes Polymer que integran la funcionalidad de las distintas APIs de Google:

Si vemos la  lista de componentes vemos que, entre otros, contamos con controles de YouTube.  https://github.com/GoogleWebComponents/google-youtube


Youtube
Cuales son los controles basados en Polymer nos provee YouTube? 

El control del reproductor: google-youtube

Este componente encapsula el reproductor, y expone como propiedades los parámetros que personalizan su apariencia y comportamiento. 

El muro de videos: google-youtube-video-wall

Este control nos provee un muro de videos personalizable, basado en Material Design, y Polymer paper elements.
Este control utiliza el API de datos de Youtube para recuperar  y filtrar los vídeos que se presentan en el muro. Y nos permite especificar los parámetros con los que invoca el API de búsqueda y de datos.



Resumen
Vemos que Google a resuelto uno de los mayores desafíos que se presentan al crear la UI en una aplicación moderna, y ofrece un lenguaje de diseño y diferentes frameworks y plataformas que lo implementan, todo integrado a sus APIs y servicios para utilizarlos en una forma rápida y simple!

El siguiente paso es simplemente utilizarlo en nuestra aplicación!!

Te invito a leer la próxima entrega donde visitaremos casos de éxito de experiencias de usuario y aplicaciones Web con videos de YouTube, con el objetivo de analizar cómo las podemos re-implementar utilizando Polymer y Material Design, de modo de comparar y analizar la potencia de estas nuevas tecnologías y conceptos.

Hasta la próxima!

Este post ha sido escrito por +Matias Molinas, Google Developer Expert para YouTube API. Editor by +Nicolas Bortolotti

Hacia finales del año pasado tuve el privilegio de ser invitado por Google Developers para producir una serie de videos contando cómo fue nuestra experiencia utilizando las tecnologías de Google Cloud Platform para potenciar los exigentes requerimientos de nuestros juegos masivos en ZupCat.
Estos videos pueden ser vistos en 4 capítulos en el canal oficial de YouTube de Google Developers en los siguientes links:
Cada video contiene referencias de código, configuraciones o APIs que me gustaría compartir para poder completar estas entregas y de paso hacer un breve repaso.
En operando un hit hace referencia a un archivo de configuración de aplicaciones llamado app-engine.xml que permite expresar algunas características importantes de las aplicaciones que hosteamos en la plataforma.
En el segundo capítulo, donde cuento acerca de de las  tecnologías disponibles para persistencia y distribución de contenido, hago referencia a Cloud Storage. Es posible acceder a este servicio para subir y modificar contenido utilizando librerías disponibles en diferentes lenguajes, que pueden ser encontradas en este link.

En referencia a Cloud DataStore, las APIs de acceso sobre Java pueden ser encontradas en este otro link y la manera de acceder a Cloud SQL desde AppEngine se describe aquí.
En el tercer capítulo, donde hago referencia a Simple DataStore, se puede encontrar el código del proyecto aquí y los ejemplos de código en este y este link.

Finalmente el capítulo final del ciclo, que habla de BigQuery, contiene varias referencias de acceso a la base de datos desde un cliente Java regular y de otro dentro de AppEngine. Los links son:
Este post ha sido escrito por +Hernán Liendo, Google Developer Expert Cloud Platform, profesor universitario y co-fundador/CTO de ZupCat donde coordina los esfuerzos de ingeniería para desarrollar juegos mid-core free-to-play. Editor by +Nicolas Bortolotti

O’Clock es una plataforma de cuentas regresivas sociales que nos ayuda a recordar los momentos importantes de la vida. Solo basta acceder al sitio www.oclck.com o descargar la App, programar una cuenta regresiva social (o seguir una existente) y comenzar a interactuar con nuestros amigos (y/o desconocidos) para compartir esa ansiada espera. 

Los relojes están organizados en la plataforma por ubicación (mediante geolocalización) o tendencias y se pueden acelerar y/o compartir por redes sociales o incrustarlos en otros sitios web. Hasta el momento hemos recibido el reconocimiento de múltiples organizaciones, entre los que destacan Angelhack, AppCampus, AppMyCity, IncubaUC, AppCircus y desde hace pocos días, formamos parte del programa Startup Launch. 



La plataforma web ha sido construida en Python (algunos procesos con Django y otros sin framework para agilizar los tiempos de respuesta), el motor DB para datos persistentes es MySQL, la App fue desarrollada de forma nativa con Android SDK, y utilizamos algunos servicios externos mediantes APIs como Mandrill y PubNub entre otros, para concentrar nuestro foco en el producto. 

Sin embargo, el servicio más importante que utilizamos y que nos ha permitido escalar tranquilos es Google App Engine. Los peaks de uso de O’Clock ocurren en la proximidad de fechas emotivas (San Valentín, Navidad, año nuevo, etc...), y utilizar esta plataforma como servicio nos permite descansar en problemas de escalamiento, sin estar despiertos a las 2 de la mañana por un peak de usuarios. 

El apoyo de los Google Developer Experts ha sido vital 

Cuando O’Clock comenzó a aparecer en prensa, nos dimos cuenta que:

  1.  El rendimiento no era óptimo. 
  2.  La experiencia de un usuario en Europa era distinta a la de un usuario en Latinoamérica. 


Y si bien intentamos prescindir de Django (framework) para agilizar algunos procesos, nos dimos cuenta que no era suficiente, y fue entonces cuando tocamos la puerta (o más bien el Hangout) de los Google Developer Experts Hernan Liendo (Argentina) y David Cifuentes (Colombia), quienes no solo nos ayudaron a resolver algunas dudas específicas, sino que también nos dieron los siguientes consejos que tuvieron gran impacto en el rendimiento y experiencia: 


  1. Cambiar de Blobstore a Cloud Storage para el almacenamiento de imágenes: Mejoramos el rendimiento, obteniendo el máximo potencial de la infraestructura y distribuyendo las imágenes para que los usuarios que descarguen el contenido lo hagan desde un punto cercano (y por lo tanto, más rápido).
  2. Pasar de SQL a GAE Datastore: Con esta medida hemos podido mejorar la velocidad/rendimiento de la plataforma, considerando algunas cualidades como el manejo de entidades que nos permiten seguir escalando tranquilos. 


A continuación les dejamos un pequeño código de como realizamos el upload de las imágenes:


                  def create_file(filename,fil): 
                    write_retry_params=gcs.RetryParams(backoff_factor=1.1)                                                                     content_type=mimetypes.guess_type(filename)[0] 
                    with gcs.open(filename,'w',content_type=content_type,options={b'x-goog-acl':b'public-                        read'}) as f:
                   while True:
                       chunk=fil.read(8192)
                       if not chunk: break f.write(chunk)
                   return 'https://storage.googleapis.com%s'%(filename)

Este método recibe el nombre de la imagen y el contenido de esta como parámetro, dentro del método obtiene el MIME Type ('image/jpeg','image/bmp') del archivo, luego usando la librería cloudstorage, creamos un nuevo archivo usando el modo 'w', pasando además el nombre de la imagen, el tipo de contenido, y la opción para dejar un enlace público a la imagen ('x-goog-acl':'public-read'), luego se lee el contenido de la imagen y se escribe en el nuevo objeto de gcs, y finalmente se retorna la url para acceder a la imagen en GCS. 

También pueden utilizar al siguiente función para obtener información del archivo (tamaño, tipo, timestamp y md5 por ejemplo) :
 def stat_file(filename):
   stat=gcs.stat(filename)
   return repr(stat)

Gracias al apoyo de inversionistas ángeles, en 2015 hemos traído nuestra operación a San Francisco (EE.UU), donde esperamos acelerar el desarrollo. Los invitamos a seguir o crear las cuentas regresivas sociales para esas fechas importantes que no quieren dejar pasar. 

 Este post ha sido creado por Guillermo Díaz, fundador y CEO de O’Clock.

One Community nace para promover la colaboración entre las comunidades que conforman el ecosistema emprendedor latinoamericano y para que esta unión de esfuerzos genere sinergias entre todos los miembros del ecosistema, ya sean desarrolladores, gente de negocios, diseñadores, creativos, emprendedores, etc.

Google Developers se ha aliado con UP Global, una organización sin ánimo de lucro dedicada a fomentar el emprendimiento en el mundo. Y ahora, para incrementar la calidad de las startups latinoamericanas; Google Developers y UP Latam buscamos unir a los líderes de las comunidades de emprendimiento y técnicas, y que se involucren en la organización de diversos Startup Weekends. Para este piloto seleccionamos varias ciudades en México, Colombia, Argentina, Perú, República Dominicana, Costa Rica, Chile, Guatemala y Uruguay.



“Ésta es una gran oportunidad para desatar el potencial de nuestra región. Si trabajamos juntos, las startups latinoamericanas serán más competitivas a nivel internacional.” - Gustavo Álvarez, director de Up Global Latam.

“El futuro de la comunidad de emprendimiento debe ser uno que nos una a todos”- Francisco Solsona, Developer Relations en Google.

¿Cuáles son los beneficios de One Community para tu comunidad?

  • Conectar a los líderes de UP Latam y de Google para que continúen trabajando en el desarrollo de sus ecosistemas locales de manera conjunta. 
  • Incrementar el nivel de los proyectos que se generan en Startup Weekend, al contar con más perfiles técnicos entre los participantes. 
  • Generar contenido técnico y de negocio que fortalezca las habilidades de los emprendedores antes y después de Startup Weekend (bootcamps, meetups, workshops, etc.). 
  • Crear contenido de valor para la comunidad de tu ciudad. 
Participar en One Community es muy sencillo. Primero, participa en el siguiente Startup Weekend en tu ciudad e invita a tus compañeros y amigos. Segundo, acércate a los grupos y comunidades que existen en tu ciudad: GDG, GBG, JavaScript, Java, PHP, Python, entre muchos otros.

Te dejamos las fechas de los siguientes Startup Weekend que forman parte de la campaña #OneCommunity. ¡Apúntate y desata tu potencial!

Bogotá, COLOMBIA 24 de octubre
Medellín, COLOMBIA 14 de noviembre
Guatemala, GUATEMALA 14 de noviembre
Lima, PERÚ 14 de noviembre
La Paz, BOLIVIA 14 de noviembre
Arequipa, PERÚ 21 de noviembre
México DF, MÉXICO 21 de noviembre
Monterrey, MÉXICO 21 de noviembre
Santo Domingo, REPÚBLICA DOMINICANA 21 de noviembre
Buenos Aires, ARGENTINA 21 de noviembre
Quito, ECUADOR 21 de noviembre
Cali, COLOMBIA 21 de noviembre:
Juliaca, PERÚ 21 de noviembre:
Montevideo, URUGUAY 21 de noviembre:
San José, COSTA RICA 21 de noviembre:

Puedes encontrar más información sobre cada uno de los eventos aquí.

Startup Grind es una organización mundial que nace en Silicon Valley en 2010 y que tiene como objetivo educar, conectar e inspirar emprendedores a través de distintos mecanismos, principalmente realizando eventos mensuales con actores clave del ecosistema emprendedor. Actualmente, tiene capítulos en más de 125 ciudades y 55 países alrededor del mundo, gracias al apoyo de Google for Entrepreneurs. Con el objetivo de contribuir al ecosistema emprendedor mexicano, hace un año decidí traer la iniciativa a México y actualmente se celebran eventos mensuales en Monterrey y en DF, y en los próximos meses iniciaremos actividades en San Luis Potosí y Morelia.

DSC_0008.JPG

En lo que va de 2014 hemos realizado 16 eventos, en nuestros dos capítulos: DF y Monterrey. Si lo ponemos en números, podríamos decir que hemos impactado personalmente a más de 1,300 personas y, dado que las charlas quedan grabadas y se puede acceder a ellas a través de internet, digitalmente otras 3,670 han podido ser parte de esto.

La idea detrás de nuestra comunidad es crear un espacio de apoyo y de amplio impacto que logre no solo brindar conocimiento a los fundadores de Startups, sino también crear verdaderas comunidades en las que los emprendedores se sientan incluidos y que se conviertan en grupos de colaboración.

En los primeros 12 meses, hemos generado 15 citas entre startups e inversionistas, hemos dado mentoría a 9 startups y hemos hecho más de 35 presentaciones. Hemos disminuido la regionalización de los ecosistemas invitando a Monterrey Speakers de otras ciudades o países.

Paul Ahsltrom comentó que en México existe un gran número de oportunidades para emprender, un porcentaje importante de las empresas en las que invierte están en México, y casi todas tocan al mercado mexicano.

Enrique Jacob Rocha habló de la importancia de integrar al ecosistema emprendedor actores estratégicos, como el Gobierno y las Universidades.

Con Andres Barreto platicamos de el estado del Venture Capital en América Latina, y el proceso que deben de seguir las startups buscando capital.

A través de estos encuentros logramos que fundadores de Startups exitosas, inversionistas, directores de fondos públicos o privados, compartan con nuestra comunidad sus principales éxitos, fracasos y consejos para generar sabiduría colectiva y eventualmente desarrollar y crear ecosistemas que apoyen e impulsen a los nuevos emprendedores.


Este post ha sido escrito por Pablo G. Lascurain, Director de Startup Grind México Para conocer más detalles de nuestros eventos y acceder a los videos, pueden visitar nuestro sitio www.mexico.startupgrind.com .

Hace un mes abrió las puertas en México una escuela diferente a las demás: Dev.F. Sus estudiantes iban desde niños de 14 años hasta señores de 50. Todos ellos con un objetivo común: convertirse en hackers. 



Esta des-escuela, como la llaman sus fundadores, nace para promover una cultura diferente entre los desarrolladores y generar talento developer que ayude a nutrir la demanda que existe hoy en día, como dice Manuel Morato, fundador, “desarrollar personas que construyan cosas nuevas en este mundo, personas que se atrevan a hacer cosas diferentes, personas que transformen nuestras industrias y nuestra sociedad de manera positiva.” Lo que buscan, en palabras de +Enrique Díaz, GDG Androidtitlán y uno de los fundadores de Dev.F, es “aprovechar las distintas virtudes de cada individuo y potenciarlas, en vez de formar a todos con un mismo molde.” 



La primera edición de su curso Cinta Blanca finalizó hace una semana. Entre los participantes de esta primera edición había ingenieros mecatrónicos, desarrolladores de aplicaciones móviles, diseñadores web, un actuario, estudiantes de preparatoria, estudiantes universitarios, estudiantes de secundaria y desarrolladores de videojuegos. Durante su participación recibieron mentoría uno a uno con alrededor de 20 especialistas, emprendedores y líderes de comunidades en México, y aprendieron tecnologías como Android, Ruby on Rails, HTML + CSS, Polymer y Github, entre otras. Además, se ha hablado de otras tecnologías como JavaScript, Python, Google Cloud Platform, Open Data, Agile Development, Scrum y Git. En resumen, todos los asistentes tuvieron la oportunidad de utilizar herramientas que apenas conocían o que desconocían totalmente y estaban fuera de su área de experiencia. 

Los resultados de esta iniciativa ya son cuantificables: al inicio del curso dos personas recibieron ofertas de trabajo y fueron contratados, el 70% de los participantes ha recibido ofertas de empleo y uno de los equipos recibió una oferta de inversión para su proyecto. 

Cómo comenzó 

Dev.F surge de la energía y las ganas de cambio de 5 jóvenes, +Manuel Morato, +Elias Shuchleib, Enrique Díaz (parte del GDG Androidtitlán), +Sandy Macías y +Víctor Borja, quienes quieren promover la cultura hacker y llevar los valores del desarrollo no sólo a quienes ya lo conocen, sino también a quienes aún no tienen conocimientos técnicos, fomentando el trabajo en equipo, la resolución de problemas reales, el pensamiento crítico y la capacidad de aprender de manera eficiente.

Una plataforma avanzada como Google App Engine presenta varias diferencias al momento de poner a punto una aplicación. Hoy Hernán Liendo,  Google Developer Expert de Cloud Platform, co-fundador y CTO de ZupCat, habla de estas diferencias basándose en su experiencia haciendo hosting de juegos masivos. 

google-datacenter-tech-13.jpg
En primer lugar, la motivación es diferente cuando ponemos a punto una app en una infraestructura tradicional ya que el resultado puede hacer que funcione o no.


Google App Engine es una plataforma con auto-escalabilidad por lo que puede tomar recursos virtualmente sin límites. En este caso la principal motivación es reducir los costos de hosting.

El modelo Platform as a Service (PaaS) es superior al modelo Infrastructure as a Service (IaaS) en el sentido de que no debemos lidiar con ajustes de parámetros de bajo nivel, que en general tienen relación con el desempeño de una aplicación.

google-data-center-green.jpg

En experiencias pasadas con IaaS acabé haciendo búsquedas binarias hasta encontrar valores de configuración óptimos sobre diferentes muestras de procesamiento. Este esfuerzo requería lidiar con aspectos como: parámetros del kernel, drivers, buffers, pools, caches, sistema operativo, networking, procesos, firewalls, routers, parámetros del filesystem, application servers, clusters, threads, colas, workers, base de datos, memoria, etc.  

La buena noticia es que, no sólo no necesitamos lidiar con todos ellos sino que, además, la mayor parte de la configuración de desempeño de Google App Engine se reduce a esta pantalla:

Screen Shot 2014-05-03 at 20.43.27.png
Mi recomendación es dejar todos estos parámetros en sus valores por defecto.

En relación al ajuste del software de aplicación, hay que seguir los principios asociados a los atributos de calidad software como en toda pieza de software.

Pero con Google App Engine además es particularmente importante controlar de cerca las invocaciones a las APIs que Google ofrece. Y esto se debe a que la mayoría de las llamadas a estas APIs tienen relación con consumo de recursos en red y al sistema de facturación de la plataforma.

Google tiene una herramienta llamada AppStats, que permite monitorear y poner a punto las llamadas a APIs de Google App Engine. Para ello intercepta cada una de las llamadas a estas APIs y almacena el llamado y tiempo de procesamiento en MemCache con el objetivo de generar estadísticas de uso.

El resultado puede visualizarse en una página web dinámica donde se detallan los últimos 1,000 requests efectuados. Se podrá ver la información ordenada por request de negocio (por ejemplo https://miapp.appspost.com/miServicio) y también ordenada por método específico de un API (por ejemplo: datastore.Put() )

appstats_path_stats.png

appstats_rpc_stats.png

En ambos casos veremos la cantidad de invocaciones que fueron efectuadas y el tiempo que tomaron.También es posible visualizar una línea de tiempo que indica las llamadas efectuadas por un servicio:

appstats_rpc.png

Esto nos permite encontrar resultados no deseados, como más llamadas de las esperadas, así como oportunidades para uso de MemCache, para uso de asincronismo o refactoring de código.

Los pasos necesarios para configurar AppStats se encuentran en el sitio oficial de Google App Engine pero es importante mencionar que es también necesario incluir varios jars como indica este foro.

Este post ha sido elaborado por Hernán Liendo, GDE Cloud Platform, profesor universitario y co-fundador y CTO de ZupCat, donde coordina los esfuerzos de ingeniería para desarrollar juegos masivos free-to-play.



Google App Engine permite escalar aplicaciones y es por ello que en ZupCat desarrollamos nuestros juegos masivos free-to-play sobre esta plataforma. En esta ocasión les contaremos cómo realizamos nuestros procesamiento batch.
Para darles una idea de volumen que nuestros juegos alcanza, tenemos tablas con 270 millones de registros y no es raro tener requerimientos que impliquen recorrer cada uno de ellos para realizar operaciones como reactivación de usuarios o generación de rankings.
Procesar un registro en un proceso batch lleva los siguientes pasos obligatorios:
  1. Leer el registro de entrada
  2. Ejecutar queries adicionales en función del registro de entrada
  3. Correr ciertas líneas de código
  4. Efectuar operaciones de escritura relacionadas al registro de entrada
Imaginen ejecutar estos 4 pasos 270 millones de veces durante varias veces al día. Si procesar un registro lleva 1 segundo, todo el proceso demoraría ¡¡3125 días!!
MapReduce es un modelo de programación destinado a procesar grandes cantidades de datos en paralelo y de manera distribuida sobre un cluster. Se basa en partir el total de registros a procesar en grupos con cantidades similares de registros. Cada grupo va a ser procesado en paralelo de manera distribuida.
Ese procesamiento comienza por una fase llamada Map que se ocupa de filtrar, seleccionar, contar u ordenar un conjunto de registros.
El resultado de la fase Map, que en general es menor al grupo original de registros, es procesado en una fase posterior llamada Reduce. Esta fase también corre en paralelo y en general sumariza los resultados de la fase Map.
En general un programador necesita implementar código en Map y Reduce mientras que el framework se ocupa de correr las tareas en paralelo, administrar la comunicación entre los procesos, transmitir datos y proveer redundancia y tolerancia a fallos.
mapreduce_mapshuffle.png


Es posible utilizar este modelo en Google App Engine integrando el proyecto open source llamado appengine-mapreduce y contar con esta estrategia de procesamiento.


Screen Shot 2014-05-03 at 17.22.06.png


Esta captura de un proceso real muestra como casi 7000 registros fueron procesados a una promedio de 84 por segundo en 50 procesos en paralelo. Las barras amarillas muestran como claramente el proceso fue dividido en 50 trabajadores paralelos.
Es importante notar que 50 trabajadores es un número configurable en relación a velocidad contra el costo de procesamiento que estamos dispuestos a pagar. Es decir, podemos reducir linealmente el tiempo que demora un proceso aumentando la cantidad de trabajadores involucrados en Map Reduce. Esto se logra sin tocar una sola línea de código sino solo configurando los parámetros del proceso.
Este post ha sido escrito por Hernán Liendo, Google Developer Expert en Cloud Computing, profesor universitario y co- fundador y CTO de ZupCat donde coordina los esfuerzos de ingeniería para desarrollar juegos masivos free-to-play.