Hoy te traemos el tercer curso completo de Google Developers Hackademy presentado por nuestro GDE +César Antón quien nos adentra a Google Drive en 5 lecciones. Ya sea que no lo hayas seguido, como recordatorio o repaso, César Antón nos lleva de la mano por esta introducción al desarrollo web en HTML5 con Google Drive.
¡Escuchemos al experto!

Sesión 1
En esta lección +César Antón explica temas como, la estructura de documentos HTML5, estructura de archivos en aplicaciones HTML5, web hosting gratuito usando Google Drive Public Folders, sincronización automática con Google Drive y la creación de un sitio web HTML5.



Sesión 2
Introducción a Google Charts, creación de una primer gráfica con Google Charts y Google Pie Charts, son los temas que recorrerán en esta sesión para finalizar con la creación de una aplicación HTML5 con Google Charts.

Sesión 3
Aprenderán qué es Google Spreadsheets, conectar tu aplicación con Google Spreadsheets para poner todo en práctica para conectar tu aplicación HTML5 con la nube de Google.

Sesión 4
Para seguir con este curso, nuestro GDE +César Antón, les explica cómo crear un proyecto con Google Cloud Console, cómo activar la API de G+, registrar una app, activar el botón de “Login” de G+ y agregarlo a nuestra app.

Sesión 5
¡A repasar todos los fundamentos y conceptos adquiridos a lo largo del curso!











En enero cerramos la temporada 2013 del Developer Bus, que nos dejó grandes experiencias que demuestran la cultura e innovación presentes en Latinoamérica. Hubo un total de 5,000 inscritos de toda la región y 160 seleccionados que representaron a Argentina, México, Colombia y Brasil ante una audiencia virtual de más de 500,000 personasCada parte del recorrido del Developer Bus dejó una invaluable muestra del potencial tecnológico de la región.


El recorrido inició en Buenos Aires (Argentina) donde los equipos llegaron con mucha energía y donde comenzó el famoso lema que nos acompañó a lo largo de todo el recorrido “cuanta adrenalina”. Así se formaron los equipos y explotó la innovación regional de la mano de proyectos como Viaje Ecológico con un carismático desarrollador que proponía las principales ventajas de un modelo de carpooling pero adaptado a nuestra región, Band Hunter que llegó con todo el empuje del concepto que propone la búsqueda de talentos en este competitivo segmento musical, Task Control directamente relacionado a las Pymes y las mejoras de proceso y de esta forma el resto del talento Argentino en cada uno los proyectos y por supuesto el representante elegido para la última estación de la temporada en Silicon Valley, Commercial Viewer.

globo2.JPG
Después de Argentina, hicimos una pausa para ajustar nuestra estrategia y cargarnos de energía para vivir las siguientes tres paradas del Developer Bus, en semanas consecutivas, en la Ciudad de México, Bogotá y Sao Paulo.
Tuvimos grandes paralelos entre las ediciones de la Ciudad de México y Bogotá. Por un lado, dos universidades que volcaron talento, apoyo e instalaciones de primera para albergar durante tres días a nuestros talentosos equipos. El Tecnológico de Monterrey Campus Santa Fé en México y la Universidad Sergio Arboleda en Bogotá, respectivamente.
Formación equipos5.jpg
Por otro lado, el nivel de emoción, entrega y compromiso de los equipos; nos dejó sin aliento. Cualquiera de ellos hubiera sido un digno representante pero los vencedores fueron Hot Street en México, y Match Point, en Colombia. Tuvieron competencia formidable de equipos como Disgraph, con un uso avanzado de Prediction API para ayuda de la gente con dislexia; Klou, una plataforma para ejecutar Ruby en Google Compute Engine; y Best Place, una app para poner en contacto a productores y consumidores; entre otras. Aquí puedes encontrar todos los proyectos realizados en la Ciudad de México y en Bogotá.
_MG_2857 (1).jpg


La edición del Developer Bus en portugués en Sao Paulo, Brasil; estuvo a la altura del gigante tecnológico de América Latina; tuvimos una verdadera fiesta de innovación y talento; los proyectos cuentan parte de la historia, pero la camaradería y garra con que disputaron el primer lugar es digna de alabar. Al grito de ¡cuánta adrenalina! avanzaron día a día, presentaron ante un jurado con amigos de primer nivel y festejaron a Power Up, una app para usuarios y administradores de gimnasios, como el equipo ganador. Sin embargo, hubo varios equipos con soluciones atractivas y bien terminadas, como Expense Me y Taskkilla, entre otros.





Para lograr estos ambientes ricos en innovación, emoción y trabajo serio se sumaron muchos factores: la presión de haber seguido en vivo por YouTube Live y, de cierta manera, vivido en tiempo real las experiencias de los equipos en las ediciones anteriores, así como el trabajo incansable de los mentores locales y remotos.

Todos los amigos del Developer Bus: gobierno, universidades, industria, incubadoras y aceleradoras, así como ilustres influenciadores independientes; estuvieron en todo momento dando mentoría y ayuda a los equipos, para llevarlos al siguiente nivel, para convertir sus ideas en potenciales soluciones a grandes problemas regionales.
Agradecemos el esfuerzo y compromiso de todos los participantes, universidades, amigos y equipos de producción y ejecución locales.  Todos ellos hicieron posible esta interesantísima experiencia.   



IMG_1750.JPG

En Internet no existen provincias; todo está en la capital. Y buena muestra de ello pudimos comprobarlo por nosotros mismos durante la visita que realicé la semana pasada a La Rioja ...
En Internet no existen provincias; todo está en la capital. Y buena muestra de ello pudimos comprobarlo por nosotros mismos durante la visita que realicé la semana pasada a La Rioja.

Con motivo de la presentación del GDG La Rioja en la universidad, tuve la oportunidad de conectar con la comunidad universitaria, desarrolladores locales y un puñado de excelentes startups que juegan en primera división.

La Rioja, una preciosa región del norte de España, además de por sus vinos, productos naturales y su calzado, empieza a ser conocida por algunas de sus empresas tecnológicas que sin renunciar a mercados globales, disfrutan de una de las mayores calidades de vida.

La visita arrancó con una reunión en la sede de la FER, Federación de Empresarios de la Rioja. Allí pude conocer las interesantes experiencias de 89Bits, CreativiTIC,  FunApps, JIG o Quantitas. Si bien no están todos los que son, son todos ellos excelentes representaciones de un tejido tecnológico en pleno desarrollo.

Tras esto llegó la presentación del Programa de Desarrollares de Google para España, los Grupos de Desarrolladores de Google Españoles, con especial mención al GDG La Rioja y un ejemplo práctico de difusión de tecnologías Go y AppEngine. El objeto de la charla fue destacar el papel que juegan los grupos de desarrolladores en la capacitación y formación continua de todos los desarrolladores, haciendo especial hincapié en como complementan a la formación universitaria.

A la luz de una sala abarrotada, parece que el tema fue de interés para todos los asistentes, que incluso compartieron su particular visión del logo de AppEngine. Tras la charla, conocimos a los representantes del colegio de Informática de la Rioja.

Finalmente, el día finalizó con un meetup con algunos desarrolladores en la zona conocida popularmente como el Laurel. Allí pude conocer a Juan Jose Bilbao, y su interesante proyecto de accesibilidad colaborativa EsAccesibleApp, que permite valorar la accesibilidad física de locales de ocio, imprescindible para la integración de personas con dificultades motrices o en silla de ruedas.

Durante el segundo día de mi visita, tuve la oportunidad de visitar el vivero de empresas del centro de tecnológico de la Rioja, también conocido como La Fombera, charlando con algunas de las empresas alojadas en el vivero que actualmente desarrollan tecnologías de gaming, realidad aumentada o motores de inferencia de aplicaciones diversas.

Finalmente, como colofón de este par de días, visité una interesante experiencia de formación profesional de tercer ciclo llevada a cabo por el Centro Educativo Los Boscos que en colaboración con la Federación de Empresarios de la Rioja forma profesionales TIC en una experiencia piloto en la región. En definitiva, dos días conociendo experiencias de innovación de enorme interés.



Felicidades a todos por su excelente trabajo y espero visitarles pronto de nuevo. Esto no hubiese sido posible, sin la ayuda de Eloy Mata, de La Universidad de la Rioja y el único, el inimitable, el fabuloso Mario Esquerro, que continua haciendo una labor exceptional en la región.

Gracias!

Andrés a.k.a almo i.e. @davilgrau es responsable en Google de relaciones con desarrolladores en España. Entre sus intereses se encuentran favorecer comunidades de desarrolladores de habla hispana, liderando programas estratégicos, contenidos de alta calidad para profesionales técnicos y favoreciendo un ecosistema alrededor de tecnologías software que incluya educación, empresas de base tecnológica e innovación social. Es además miembro asociaciones internacionales como IEEE, Computer Society y ACM.





Si eres nuevo en App Engine, entonces el modelo de sistema de archivos puede ser un poco diferente de lo que has experimentado usando otras plataformas.


Con una aplicación App Engine, no puedes escribir al sistema de archivos donde tu aplicación es desplegada. Tu aplicación puede leer cualquier archivo desde la estructura del directorio desplegado, pero no puede escribir en ese sistema de archivo. En su lugar, la aplicación puede usar Google Cloud Storage (GCS) tanto para leer como para escribir archivos. Para convertir una aplicación y que pueda usar GCS para archivos escribibles tienes que seguir los siguientes pasos:



Otra de las consecuencias del modelo solo lectura para archivos de sistema es que si tu aplicación tiene un modelo de conexión ( ‘plugin’) como WordPress, no puedes instalar o actualizar plugins desde tu aplicación desplegada. En su lugar, necesitarás instalar o actualizar cualquier plugin localmente, y después volver a desplegar la aplicación.

Puedes encontrar mucha más información (en inglés) acerca de todo lo siguiente en la documentación del ambiente de ejecución de PHP.

El sistema de archivos de la aplicación
Con las aplicaciones de App Engine, el sistema de archivos “local” - el árbol directorio del proyecto, que es cargado junto a la aplicación desplegada- es de sólo lectura. Esta restricción se da por motivos de escalabilidad y seguridad; a veces, este tema es denominado como ‘sandboxing’. (muchos de los puntos débiles o vulnerabilidades comunes del framework están bloqueados por aplicaciones App Engine).
Puedes leer cualquier archivo en la estructura del directorio de despliegue, por ejemplo, tu aplicación puede leer plantillas implementadas o archivos de configuración. (Si en el código de tu aplicación quieres leer archivos que también suministras de forma estática puedes usar la directiva application_readable en el archivo de aplicación app.yaml).
Es importante señalar que  tu aplicación no puede crear o modificar archivos en este sistema local de archivos - por ejemplo, no puede escribir archivos caché ahí.
Debido a este sandboxing, si tu aplicación tiene un modelo de conexión ‘plugin’, como WordPress, no puedes instalar o actualizar plugins desde tu aplicación implementada. En su lugar, necesitarás instalar o actualizarlos localmente, en tu entorno de desarrollo, poniendo en marcha tu aplicación usando el  servidor de desarrollo de App Engine. Puedes hacer un test de la actualización localmente y, si quieres, volver a desplegar la aplicación con las actualizaciones. Si te sientes cómodo, puedes simplemente descargar y descomprimir los archivos del plugin directamente, moverlos al directorio adecuado y entonces volver a desplegar la aplicación; mejor que instalarlos a través de la consola de administración de WordPress  
Nota si estás haciendo algunos cambios en las bases de datos almacenados desde el servidor de desarrollo, como estableciendo opciones de plugin, estos por supuesto no se van a propagar a la aplicación implementada/desplegada, que está usando una base de datos diferente. Una vez que vuelvas a implementar tu aplicación con los nuevos archivos de plugin, puedes configurar el plugin en la aplicación implementada.
Google Cloud Storage
Para un archivo de sistema lectura/escritura, tu aplicación puede usar los recipientes de Google Cloud Storage (GCS). Google Cloud Storage es un servicio RESTful de almacenaje y acceso a objetos de datos en la infraestructura de Google. GCS es rápido, escalable y altamente disponible, con muchas capas de redundancia; y los objetos pueden ser almacenados en terabytes.
Para el tiempo de ejecución App Engine PHP existe un encapsulador de transmisión que soporta la mayoría de las funciones relacionadas con archivos de sistema estándar. Este encapsulador de transmisión te permite usar tus archivos PHP y directorios de funciones como file_put_contents, file_get_contents, fopen, y opendir. La información de archivo y directorio puede ser recuperado para los objetos GCS usando funciones como file_exists, is_writable, filesize, is_dir, etc.
Apuntas a un directorio GCS o archivo usando sintaxis como esta:
gs:///path/to/file
Para que puedas escribir código en tu app como este:
$fp = fopen("gs://my_bucket/some_file.txt", "w");
fwrite($fp, "Hello");
fclose($fp);
o este otro:
$options = [ "gs" => [ "Content-Type" => "text/plain" ]];
$ctx = stream_context_create($options);
file_put_contents("gs://my_bucket/hello.txt", "Hello", 0, $ctx);
En este  link encontrarás más detalles y otros ejemplos (en inglés).
Antes de que un código de este tipo funcione en tu aplicación, necesitarás configurar GCS en un proyecto Google Cloud y autorizar tu aplicación de App Engine para este proyecto tal y como se describe aquí (en inglés).

En la mayoría de los casos, una vez has redefinido tus rutas a gs:// URIs, tus llamadas de sistema de archivos trabajarán como lo hacían antes. Debes revisar las opciones de configuración para tu aplicación antes de implementarla. Por ejemplo, puede que necesites direccionar directorios de cache a GCS.
Sin embargo, GCS no es el típico archivo de sistema ya que soporta el anexo de archivos (objeto). En lugar de anexar a un archivo, debes escribir una nueva versión de este archivo que incluya el contenido actualizado.
Un contexto en el que esto puede surgir es en el de registro (logging), y una buena alternativa es simplemente usar syslog. Todas las llamadas a syslog de tus aplicaciones, y la transmisión del error estándar, serán incluido en los logs de la consola de Admin de tu aplicación, donde puedes buscarlos. También puedes usar  Logs API para acceder a los logs de forma programada. Puedes también descargar los logs usando el comando appcfg.py request_logs.


‘Incluyendo’ archivos de GCS
Puedes incluir o requerir archivos de GCS en tu aplicación.  Esto, por ejemplo, te permite escribir/leer plantillas que están almacenadas en caché o plantillas recopiladas. Por motivos de seguridad,  necesitas habilitar expresamente este componente. Esto se puede hacer especificando qué recipientes contienen archivos inclusivos, usando la directiva google_app_engine.allow_include_gs_buckets en tu archivo php.ini:
google_app_engine.allow_include_gs_buckets = "bucket_1, bucket_2"
Puedes usar este componente para usar modelización de librerías como Twig o Smarty con tu aplicación de PHP App Engine app.
Cargando archivos a GCS desde tu aplicación
Tu aplicación no puede usar el sistema de archivos solo lectura para almacenar archivos subidos. En su lugar, puede usar GCS para almacenar archivos cargados (y GCS es magnífico para manejar archivos de gran tamaño, incluso muchos archivos de ellos). App Engine hace este proceso muy directo.
Para subir archivos desde tu aplicación, generas un  URL especial de carga de archivos, especificando un operario resultante como “callback”, y usas esta URL especial en la forma de carga. Una vez el archivo está cargado, el operario “callback” recibe una petición de POST, desde la que la carga puede ser procesada. Más información aquí ( en inglés).
Si estás poniendo en marcha WordPress on App Engine, hemos construido un plugin que, entre otros componentes, soporta la carga y acceso a media desde GCS, así que todo lo que necesitas es instalar el plugin.
Similar, para otras aplicaciones, probablemente necesites modificar los formularios de carga de manera que usen esta URL de carga generada, que entonces llamarán de vuelta al operativo existente, que puede procesar el archivo temporal de la misma forma que lo hacían antes.
Una vez que tu aplicación está escribiendo archivos de manera exitosa en GCS, hay una serie de formas para que tu aplicación pueda acceder a ellas y ponerla en servicio, esto además de usar GCS como un encapsulador de transmisión.
En resumen
Con aplicaciones App Engine, tu aplicación puede leer desde la estructura de directorio implementada, pero no puede escribir sobre ella. En su lugar, puede usar GCS para hacer eso. Hay tres cosas importantes que probablemente tengas que hacer, para poder convertir una aplicación y que use GCS:
Finalmente, el ‘sandboxing’ del sistema de archivos de la app dicta que no puedes modificar este sistema de archivos desde tu aplicación implementada. Así que, para plugings de WordPress y similares, necesitarás instalar/actualizar plugins localmente usando el servidor de desarrollo y volviendo a implementar la aplicación.










Presentación del equipo Power Up (Brasil)