El pasado sábado día 27 se celebró el Android MeetUP en Barcelona. Este evento, que reunió a casi 70 programadores, estuvo organizado por los chicos de and.roid.es con la colaboración de 22@ y la UPC.


Tras la bienvenida de Luis Moreno, a las 10.15h comenzó la mesa redonda en la que se habló del presente, pasado y futuro de este software para móviles. Se debatió sobre los cambios que implicaría el salto al público de gran consumo, así como de las distintas versiones de terminales existentes en el mercado. Fue particularmente interesante la conversación que se estableció sobre el papel de los desarrolladores en el fomento de esta plataforma.

Tras un breve descanso, Israel Ferrer, portavoz de and.roid.es, lanzó al público una interesante pregunta: ¿Qué hace especial a Android?. Algunas de las ventajas que se apuntaron fueron, la portabilidad a cualquier arquitectura, los gráficos y sonidos, la simplicidad de uso para un público no experto, sus aplicaciones ... y por supuesto, que se trata de un software libre.

A continuación, Israel condujo un taller de iniciación en el desarrollo de aplicaciones para Android, para aquellos que no tuvieran experiencia previa. Tras ello, Rodrigo Silva-Ramos y Javier Agüero de Geeks' Phone, sorprendieron a toda la audiencia al presentar el primer terminar basado en Android desarrollado por una empresa europea: ONE. La verdad es que los allí presentes quedaron encantados ya que incluso tuvieron la oportunidad de "manosear" un poco este teléfono móvil en desarrollo.

Para finalizar, diversos asistentes nos mostraron las aplicaciones en las que está trabajando. A continuación os incluimos un pequeño resumen de las mismas:
  • Gerard Romans de Alt Tek nos presentó Scanner FM, una aplicación disponible en el market de Android para escuchar la radio.
  • Javier Pérez de Secuoyas, mostró la aplicación basada en los feeds de ABC, que lleva más de 1,200 descargas en tan sólo dos meses.
  • Alejandro Scandroli, presentó 2 aplicaciones, una para Páginas Amarillas, con un listado de negocios basados en la proximidad de los usuarios; y otra para Beloop, una guía turística que no necisita de conexión a Internet.
  • Joan Milagrosas, estudiante de tercer curso de ingeniería, nos mostró su parchís para Android, desarrollado en tran sólo 3 días.
  • Cerrando el turno de presentaciones, Julián Moreno, CEO de Droiders nos habló un poco de su empresa de reciente creación, centrada exclusivamente en el desarrollo de apps para Android. Algunas de sus aplicaciones son una red social con geoposicionamiento, un interesante traductor de mensajes de voz, así como una aplicación de streaming de grabaciones en directo.
Esperamos que a todos los asistentes les mereciese la pena renunciar a una mañana soleada de playa por este Community MeetUP.

Isabel Salazar, equipo de Marketing de Google

El pasado sábado día 27 se celebró el Android MeetUP en Barcelona. Este evento, que reunió a casi 70 programadores, estuvo organizado por los chicos de and.roid.es con la colaboración de 22@ y la UPC.


Tras la bienvenida de Luis Moreno, a las 10.15h comenzó la mesa redonda en la que se habló del presente, pasado y futuro de este software para móviles. Se debatió sobre los cambios que implicaría el salto al público de gran consumo, así como de las distintas versiones de terminales existentes en el mercado. Fue particularmente interesante la conversación que se estableció sobre el papel de los desarrolladores en el fomento de esta plataforma.

Tras un breve descanso, Israel Ferrer, portavoz de and.roid.es, lanzó al público una interesante pregunta: ¿Qué hace especial a Android?. Algunas de las ventajas que se apuntaron fueron, la portabilidad a cualquier arquitectura, los gráficos y sonidos, la simplicidad de uso para un público no experto, sus aplicaciones ... y por supuesto, que se trata de un software libre.

A continuación, Israel condujo un taller de iniciación en el desarrollo de aplicaciones para Android, para aquellos que no tuvieran experiencia previa. Tras ello, Rodrigo Silva-Ramos y Javier Agüero de Geeks' Phone, sorprendieron a toda la audiencia al presentar el primer terminar basado en Android desarrollado por una empresa europea: ONE. La verdad es que los allí presentes quedaron encantados ya que incluso tuvieron la oportunidad de "manosear" un poco este teléfono móvil en desarrollo.

Para finalizar, diversos asistentes nos mostraron las aplicaciones en las que está trabajando. A continuación os incluimos un pequeño resumen de las mismas:
  • Gerard Romans de Alt Tek nos presentó Scanner FM, una aplicación disponible en el market de Android para escuchar la radio.
  • Javier Pérez de Secuoyas, mostró la aplicación basada en los feeds de ABC, que lleva más de 1,200 descargas en tan sólo dos meses.
  • Alejandro Scandroli, presentó 2 aplicaciones, una para Páginas Amarillas, con un listado de negocios basados en la proximidad de los usuarios; y otra para Beloop, una guía turística que no necisita de conexión a Internet.
  • Joan Milagrosas, estudiante de tercer curso de ingeniería, nos mostró su parchís para Android, desarrollado en tran sólo 3 días.
  • Cerrando el turno de presentaciones, Julián Moreno, CEO de Droiders nos habló un poco de su empresa de reciente creación, centrada exclusivamente en el desarrollo de apps para Android. Algunas de sus aplicaciones son una red social con geoposicionamiento, un interesante traductor de mensajes de voz, así como una aplicación de streaming de grabaciones en directo.
Esperamos que a todos los asistentes les mereciese la pena renunciar a una mañana soleada de playa por este Community MeetUP.

Isabel Salazar, equipo de Marketing de Google

Una breve entrada para comentaros que el próximo sábado día 27 tendrá lugar el Community MeetUp de Android organizado por el equipo de and.roid.es en colaboración con 22@ y la UPC.

Una breve entrada para comentaros que el próximo sábado día 27 tendrá lugar el Community MeetUp de Android organizado por el equipo de and.roid.es en colaboración con 22@ y la UPC.

La asistencia es totalmente gratuita, y puede ser una buena oportunidad para hacer networking y conocer aplicaciones de otros desarrolladores sobre este software. Todavía quedan algunas plazas, así que no lo dudéis!!!



Para más información: http://and.roid.es/meetup/

Isabel Salazar, equipo de Marketing de Google

Desarrollar un almacén de datos masivo y distribuido que pueda atender solicitudes con un rendimiento extremadamente alto es algo en lo que nos hemos enfocado en Google. Creamos algo llamado BigTable que subyace el almacén de datos en App Engine. El diseño para BigTable se enfocó en la escalabilidad a través de un sistema distribuido para que pueda funcionar un poco diferente a las bases de datos con las que has trabajado antes, como no soportar combinaciones. Esto no es un accidente, cuando se desarrolla un sistema que puede escalar al tamaño de BigTable no hay forma de hacer una combinación con un objetivo general en los conjuntos de datos de ese tamaño y que aún tengan alto rendimiento.

Google no es el único en ofrecer un almacén de datos no relacional para permitir el escalamiento. Por ejemplo, Amazon tiene SimpleDB: base de datos relacional agrupada tradicional requiere de un desembolso inicial de capital considerable, es complejo para diseñar y generalmente requiere de un administrador de bases de datos para darle mantenimiento y administrarla. Amazon SimpleDB es evidentemente más simple, no requiere de ningún esquema, indexa automáticamente sus datos y proporciona una API simple para su almacenamiento y acceso.

También tienes a tu disposición una gama de almacenes de datos no relacionales de código abierto, como CouchDB y Hypertable. Ésos sólo son dos ejemplos, aquí hay muchos más.

Aunque podrías pensar que todo esto es nuevo, realmente es un poco regresar al pasado. Como ves, hubo una época en la que el "RDBMS" no siempre era la respuesta independientemente de la pregunta que fuera. Cuando Codd publicó su estudio titulado "A Relational Model of Data for Large Shared Data Banks (Un modelo relacional de datos para grandes bancos de datos compartidos)", había muchos enfoques diferentes para los almacenes de datos. Fue tan sólo en los 80 que las bases de datos relacionales ganaron la mayor parte de la captación. Al haberse establecido en una sola metáfora, la industria ha desarrollado muchas herramientas y técnicas para facilitar el desarrollo de una base de datos relacional.

Desafortunadamente esa mayor parte de la captación también es un problema porque mientras los RDBMS son útiles en muchas situaciones, no lo son en todas las situaciones. Su dominio en la captación significa que no se usan las alternativas útiles y grandes cantidades de tiempo y dinero se pueden desperdiciar en tratar de forzar problemas no relacionales en un modelo relacional.

Nos encontramos en medio de un renacimiento en el almacenamiento de datos con la aplicación de muchas ideas y técnicas nuevas; existe un gran potencial para tener un pensamiento innovador acerca del almacenamiento de datos solamente de una forma. Michael Stonebraker señaló en su estudio, "One Size Fits All": An Idea Whose Time Has Come and Gone (Talla única: una idea cuya época ha ido y venido), que existen casos de uso comunes de almacenes de datos, como el almacenamiento de datos y el procesamiento por flujos que no funcionan bien para los RDBMS de objetivo general y que abandonar los RDBMS de objetivo general puedan brindarle un aumento de rendimiento en uno o dos tipos de magnitud.

Es un momento emocionante y lo más importante aquí no es abandonar la base de datos relacional, que es una tecnología muy madura que funciona excelente en su dominio, sino estar dispuestos a ver fuera de los RDBMS para buscar soluciones de almacenamiento.

Desarrollar un almacén de datos masivo y distribuido que pueda atender solicitudes con un rendimiento extremadamente alto es algo en lo que nos hemos enfocado en Google. Creamos algo llamado BigTable que subyace el almacén de datos en App Engine. El diseño para BigTable se enfocó en la escalabilidad a través de un sistema distribuido para que pueda funcionar un poco diferente a las bases de datos con las que has trabajado antes, como no soportar combinaciones. Esto no es un accidente, cuando se desarrolla un sistema que puede escalar al tamaño de BigTable no hay forma de hacer una combinación con un objetivo general en los conjuntos de datos de ese tamaño y que aún tengan alto rendimiento.

Google no es el único en ofrecer un almacén de datos no relacional para permitir el escalamiento. Por ejemplo, Amazon tiene SimpleDB: base de datos relacional agrupada tradicional requiere de un desembolso inicial de capital considerable, es complejo para diseñar y generalmente requiere de un administrador de bases de datos para darle mantenimiento y administrarla. Amazon SimpleDB es evidentemente más simple, no requiere de ningún esquema, indexa automáticamente sus datos y proporciona una API simple para su almacenamiento y acceso.

También tienes a tu disposición una gama de almacenes de datos no relacionales de código abierto, como CouchDB y Hypertable. Ésos sólo son dos ejemplos, aquí hay muchos más.

Aunque podrías pensar que todo esto es nuevo, realmente es un poco regresar al pasado. Como ves, hubo una época en la que el "RDBMS" no siempre era la respuesta independientemente de la pregunta que fuera. Cuando Codd publicó su estudio titulado "A Relational Model of Data for Large Shared Data Banks (Un modelo relacional de datos para grandes bancos de datos compartidos)", había muchos enfoques diferentes para los almacenes de datos. Fue tan sólo en los 80 que las bases de datos relacionales ganaron la mayor parte de la captación. Al haberse establecido en una sola metáfora, la industria ha desarrollado muchas herramientas y técnicas para facilitar el desarrollo de una base de datos relacional.

Desafortunadamente esa mayor parte de la captación también es un problema porque mientras los RDBMS son útiles en muchas situaciones, no lo son en todas las situaciones. Su dominio en la captación significa que no se usan las alternativas útiles y grandes cantidades de tiempo y dinero se pueden desperdiciar en tratar de forzar problemas no relacionales en un modelo relacional.

Nos encontramos en medio de un renacimiento en el almacenamiento de datos con la aplicación de muchas ideas y técnicas nuevas; existe un gran potencial para tener un pensamiento innovador acerca del almacenamiento de datos solamente de una forma. Michael Stonebraker señaló en su estudio, "One Size Fits All": An Idea Whose Time Has Come and Gone (Talla única: una idea cuya época ha ido y venido), que existen casos de uso comunes de almacenes de datos, como el almacenamiento de datos y el procesamiento por flujos que no funcionan bien para los RDBMS de objetivo general y que abandonar los RDBMS de objetivo general puedan brindarle un aumento de rendimiento en uno o dos tipos de magnitud.

Es un momento emocionante y lo más importante aquí no es abandonar la base de datos relacional, que es una tecnología muy madura que funciona excelente en su dominio, sino estar dispuestos a ver fuera de los RDBMS para buscar soluciones de almacenamiento.


Joe Gregorio, Equipo de Google App Engine

Seguramente sabrás que en el último Google I/O que tuvo lugar en San Francisco hace un par de semanas (y sobre el que escribimos en este mismo blog), se anunció el lanzamiento de Google Wave. Por ello, nos gustaría, con esta breve entrada, ayudaros con las APIs de este nuevo producto.

Google Wave es una nueva herramienta de comunicación y colaboración que permite a la gente que trabaja junta ser más productiva en la Red. Si todavía no has visto la demo, te recomendamos que visites: http://wave.google.com/.

Las APIs de Google Wave vienen en dos sabores: Embeber y Extensiones y Embeber. Con la opción de Embeber, podrás incluir Waves en tu propio sitio web con un sencillo API en JavaScript. Por ejemplo, incluir una Wave en tu página web es una buena forma de fomentar el debate entre tus usuarios visitantes. Con las Extensiones, tendrás la posibilidad de escribir programas, que están agrupados en forma de Robots o Gadgets, y que proporcionan una gran gama de ricas aplicaciones dentro del Google Wave del cliente.

Los robots son participantes automáticos que están escritos en el lado del servidor, ayudan a desarrollar tareas en beneficio de los usuarios, incluyendo la coordinación de datos con otros servicios. Hasta el momento, los Robots están alojados en Google App Engine, y tenemos una biblioteca para clientes disponible en lenguaje Java y Python. Ahora mismo estamos trabajando para conseguir Robots API que puedan ser respaldados por cualquier servidor en la Red. Como ejemplo de algo que podrías construir, y para que te puedas hacer una mejor idea, aquí tienes un robot al que llamamos cariñosamente "Tweety," este robot te ayuda a utilizar Twitter de forma muy sencilla dentro de Google Wave.



Si quieres saber más sobre las APIs de Google Wave: pide acceso al sandbox, visita el los ejemplos de código, y únete a nosotros en Google Wave API forum.

Seguramente sabrás que en el último Google I/O que tuvo lugar en San Francisco hace un par de semanas (y sobre el que escribimos en este mismo blog), se anunció el lanzamiento de Google Wave. Por ello, nos gustaría, con esta breve entrada, ayudaros con las APIs de este nuevo producto.

Google Wave es una nueva herramienta de comunicación y colaboración que permite a la gente que trabaja junta ser más productiva en la Red. Si todavía no has visto la demo, te recomendamos que visites: http://wave.google.com/.

Las APIs de Google Wave vienen en dos sabores: Embeber y Extensiones y Embeber. Con la opción de Embeber, podrás incluir Waves en tu propio sitio web con un sencillo API en JavaScript. Por ejemplo, incluir una Wave en tu página web es una buena forma de fomentar el debate entre tus usuarios visitantes. Con las Extensiones, tendrás la posibilidad de escribir programas, que están agrupados en forma de Robots o Gadgets, y que proporcionan una gran gama de ricas aplicaciones dentro del Google Wave del cliente.

Los robots son participantes automáticos que están escritos en el lado del servidor, ayudan a desarrollar tareas en beneficio de los usuarios, incluyendo la coordinación de datos con otros servicios. Hasta el momento, los Robots están alojados en Google App Engine, y tenemos una biblioteca para clientes disponible en lenguaje Java y Python. Ahora mismo estamos trabajando para conseguir Robots API que puedan ser respaldados por cualquier servidor en la Red. Como ejemplo de algo que podrías construir, y para que te puedas hacer una mejor idea, aquí tienes un robot al que llamamos cariñosamente "Tweety," este robot te ayuda a utilizar Twitter de forma muy sencilla dentro de Google Wave.



Si quieres saber más sobre las APIs de Google Wave: pide acceso al sandbox, visita el los ejemplos de código, y únete a nosotros en Google Wave API forum.


Douwe Osinga, Software Engineer, Google Wave APIs

Mientras el programa para desarrolladores de Google continúa creciendo, actualmente con casi 60 API y herramientas en Google Code, pensamos que este crecimiento se debe no sólo al "boca a boca" sino también a vuestros comentarios y sugerencias.

Por todo ello, hoy nos complace introducir
Mientras el programa para desarrolladores de Google continúa creciendo, actualmente con casi 60 API y herramientas en Google Code, pensamos que este crecimiento se debe no sólo al "boca a boca" sino también a vuestros comentarios y sugerencias.

Por todo ello, hoy nos complace introducir Google Code Labs como un hogar para productos de desarrolladores que aún se encuentran en las etapas tempranas de desarrollo. Por supuesto, nuestra esperanza es que todos nuestros productos para desarrolladores lleguen a ser grandes éxitos, pero sabemos que no todos llegarán a esa meta. El programa Labs ofrece a los equipos de ingeniería en Google y la comunidad de desarrolladores una oportunidad para explorar ideas e involucrarse tempranamente.

Con esos antecedentes, también anunciamos que varias de nuestras API y herramientas más conocidas y utilizadas se encuentran dentro del primer conjunto de "graduados" de Google Code Labs, inclusive App Engine, Google Web Toolkit, AJAX Search API, Maps API, Earth API, Calendar Data API, YouTube APIs y más. Consulta la lista completa de graduados en la página de Google Code Labs.

Para estos graduados, aumentamos nuestro compromiso con las políticas publicadas de desaprobación y otros servicios de soporte fundamentales. Los términos de la API de visualización, los términos de la API de datos de contactos y los términos del API de datos de Picasa Web Albums incluyen buenos ejemplos de políticas de desaprobación transparentes. Establecen que brindaremos soporte a cada versión por lo menos 3 años a partir de la fecha en que se desapruebe o cuando se introduzca una versión más reciente. Estamos trabajando para publicar políticas también para otros graduados, aunque el periodo de tiempo puede variar un poco entre productos. Para la mayoría serán 3 años, pero podría ser menos para algunos. Por ejemplo, la API de AdWords tiene una política de brindar soporte a versiones anteriores durante 4 meses.

Por supuesto, hasta los productos establecidos necesitan una forma para experimentar con nuevas características. Teniendo eso en mente, algunos productos tendrán características designadas como "experimentales", eso podría cambiar (o hasta eliminarse) en cualquier momento, mientras que el resto de la API está cubierta por una política de desaprobación con soporte a largo plazo.

Existen obstáculos adicionales para que una API se gradúe de Labs. Incluyen requisitos como tener un equipo de ingeniería constante y dedicado y un conjunto integral de pruebas. También deseamos hacer cosas como el System Status Dashboard de App Engine para más productos.

Finalmente, deseamos despedirnos de uno de nuestros productos para desarrolladores, la venerable SOAP Search API. Desde 2006 fue desaprobada, cuando dejamos de aceptar nuevos desarrolladores para la API y finalmente está colgando la toalla y jubilándose el 31 de agosto. Su uso ha estado en constante declive durante los dos últimos años y creemos que la mayoría de casos de uso se manejan suficientemente por la AJAX Search API más integral (que no sólo soporta la búsqueda Web, sino noticias, imágenes, videos locales y mucho más). Para aquellas personas interesadas en migrar, pueden encontrar más detalles en el blog de AJAX API.

Gracias por hacer un éxito de estos más de cinco años. Esperamos con expectación hacer cosas estupendas con Google Code Labs y esperamos que se una a nosotros para felicitar a los nuevos graduados.

Tom Stocky, Director, Productos para desarrolladores de Google