Archivos

RedBit y el éxito de su juego Splashy Fish







































 
Este post está basado en el caso de éxito publicado por AdMob. Publicación original aquí.

Explorando la monetización desde AdMob en soluciones nativas Android

En esta ocasión queremos compartir con ustedes la posibilidad de monetizar utilizando un enfoque de integración y desarrollo en una aplicación nativa Android.

Para este ejemplo vamos a utilizar un modelo de integración simple, en donde trabajamos un banner desde el entorno programático y como opción utilizando XML en el Layout.

Veamos la estructura de la aplicación propuesta desde la Fig. 1



Fig. 1 Estructura básica de la aplicación
Como podemos observar en la Fig. 1 tenemos dos activities que representan cada ejemplo de integración como comentamos en nuestra introducción.

En la Fig. 2 podemos observar el ejemplo más simple en donde utilizamos la visualización de un banner con un integración mediante XML en el Layout.


Fig.2 Código de integración para la opción de integración XML
Al utilizar el modelo de integración mediante XML en el layout debemos analizar en concreto donde ocurre, como decimos coloquialmente, la magia de programación. En este ejemplo utilizamos un objeto AdView en el Linearlayout para presentar el banner como muestra la Fig. 3.


Fig.3 Entorno de diseño para la activity de integración utilizada.
Ahora veamos el código XML de implementación:

Fig. 4 Código XML del Layout donde se presenta el objeto AdView
Nota: recuerden que en el atributo ads:adUnitId deben incluir el id del banner a visualizar.

Finalmente la aplicación funcionando, lo que todo desarrollador hace a diario, compilación y en este caso a visualizar en el emulador.


Fig. 5 Visualización de la aplicación y el menú de ejemplo.
También podemos ver en la Fig.6 el ejemplo concreto de implementación para la opción 1 en donde se realiza la integración de forma programática.


Fig. 6. Resultado de la integración mediante modelo programático.
También podemos ver en la Fig. 7 el resultado de la integración mediante XML.

 
Fig. 7 Resultado de la integración mediante XML
Referencias:


Nicolás es director de relaciones para desarrolladores en Latinoamérica región sur para Google. El ha desarrollado comunidades académicas y de investigación en varios países de Latinoamérica sobre la plataforma de desarrollo web y mobile de Google. Además Nicolas es profesor universitario, donde trabaja fuertemente en arquitecturas de software, ambientes emergentes e innovación en modelos de ingeniería de software

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Entrada-Transformación-Salida-Resultados


Te presentamos un ejemplo de aplicación App Engine para mover tus datos de un lugar en la nube a otro, transformándolos al mismo tiempo. La aplicación Data Pipeline incluye ejemplos para permitirte empezar rápido y producir poderosos proyectos desde el comienzo. También tiene una sencilla API para ampliar su funcionalidad.
Data Pipeline es una aplicación Python que utiliza Google App Engine Pipeline API  para controlar tuberías de procesos de datos complejos. Las tuberías están construidas a base de etapas que pueden ser conectadas entre ellas para procesar grandes cantidades de datos, y con el trabajo haciéndose en paralelo. La aplicación viene con algunos ejemplos de etapas que usan muchos de los servicios de Cloud Platform. Puedes escribir fácilmente nuevas etapas para desarrollar procesamiento de datos personalizados.

La aplicación Data Pipeline viene con una funcionalidad incorporada que te permite leer datos de:
  • URLs via HTTP
  • Google Cloud Datastore
  • Google Cloud Storage
transformarlos en:
y volcarlos a:
  • BigQuery
  • Google Cloud Storage
Por ejemplo, uno de los flujos de datos incorporados lleva un archivo de un recipiente de Cloud Storage, lo transforma usando un trabajo MapReduce en Hadoop operando en Compute Engine, y carga el archivo de salida a BigQuery. Para lanzar el proceso, sólo tienes que pasar el archivo a Cloud Storage.

Esperamos que no solo vayas a usar las transformaciones incorporadas, sino que crearás etapas personalizadas para transformar datos de la forma que necesites. Puedes personalizar las tuberías fácilmente extendiendo el Python API, que está disponible aquí en Github.

También puedes personalizar la entrada  y salida, por ejemplo, puedes personalizar la salida para escribir en Google Cloud SQL.

Creas y editas tuberías en un archivo de configuración JSON en la aplicación UI. La aplicación comprueba que la configuración es sintácticamente correcta y que los prerrequisitos se cumplem. Después de que guardes el archivo de configuración, da clic al botón de Run para comenzar la ejecución del proyecto. Verás el progreso de la tubería que se está ejecutando en una nueva ventana.
*
Edición del archivo de configuración
El código fuente está en Github. Te invitamos a descargarlo y a empezar a armar tus propios proyectos hoy.

Post originalmente publicado por Alex K, Ingeniero de soluciones cloud

Google Developers Hackademy: Introducción al desarrollo web HTML5 con Google Drive


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!


Esto fue Developer Bus 2013


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

Post creado por +Francisco Solsona, gerente de relaciones para desarrolladores en América Latina norte para Google y +Nicolas Bortolotti gerente de relaciones para desarrolladores en América Latina sur para Google

PHP App Engine Apps y Conceptos File System


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.
 
Post original creado por Amy Unruh, Developer Programs Engineer


Así fue la última parada del Developer Bus 2013: Mountain View


Presentación del equipo Power Up (Brasil)



Convocatoria abierta para DevArt

¿Consideras que programar código es “un arte que dominas”? ¿Eres de los que piensa que a través de la computación se llega a un universo creativo infinito?
 
Entonces, sigue leyendo. Esto te interesa.
Google, junto al centro Barbican de Londres, quiere celebrar el uso creativo de la tecnología a través de la iniciativa DevArt - Art Made with Code y buscan un desarrollador que esté dispuesto a unir creatividad y tecnología para realizar una obra de arte inigualable. Además, habrá una galería interactiva como parte de la exposición Revolución Digital.

¡No dejes escapar esta oportunidad! Saca tu lado más creativo y acepta el reto. Puedes ver tu trabajo exhibido en el Barbican ante millones de personas de todo el mundo. Para participar lo único que necesitas es una idea, una cuenta Github y mostrar a los organizadores lo que podrías crear en g.co/devart

¿Junto a qué artistas estarías presentando tu trabajo? Nada más y nada menos que tres de los creadores interactivos más prestigiosos que están produciendo instalaciones para DevArt: Karsten Schmidt, Zach Lieberman, y el dúo Varvara Guljajeva and Mar Canet.
 
 
La exposición tendrá lugar este verano en el Barbican de Londres. Hasta entonces, visita g.co/devart, y envía tu proyecto. Si no eres el tipo de desarrollador “creativo”, visita la web de igual forma y sorpréndete con las increíbles creaciones artísticas que verás:  sigue paso a paso el proceso creativo de los artistas, desde el concepto y primeros borradores,  hasta la obra acabada.  Podrás descubrir todo lo que las nuevas tecnologías (incluyendo algunos productos de Google) permiten crear y puede que hasta encuentres inspiración y te animes a iniciar tu propia obra.
 
Si tuvieras la oportunidad de dejar tu marca en el mundo del arte contemporáneo, ¿qué crearías? No te lo quedes para ti, cuéntalo.