via Google Open Source Blog by Ellen Ko on 1/20/10
The last few years have been an exciting time for dynamic language implementations. The latest generation of JavaScript engines – Mozilla TraceMonkey, WebKit SquirrelFish Extreme, and Google's own V8 – are all based on just-in-time (JIT) compilation, which has led to dramatic speedups for web applications. The Unladen Swallow project is building a JIT for Python based on LLVM. But you may not have heard of the dynamic language Lua or the one-man LuaJIT project, which released a beta of its long-awaited 2.0 two months ago, along with some very impressive benchmarks.

LuaJIT is developed by Mike Pall, an open source developer located in Germany. Since its first release in 2005, LuaJIT has been at the forefront of dynamic language performance. In 2008 Mike announced that he was working on a complete rewrite based on trace compiler technology. It breaks with a long tradition of method-at-a-time JIT compilers and seems especially well suited for compiling dynamic languages. As LuaJIT shows, this approach yields performance that can rival even offline, static language compilers.

We use Lua internally at Google, and are very happy to be sponsoring the port of LuaJIT 2.0 to x86-64 (the initial release was for 32-bit x86 only). The full list of sponsors can be found on the LuaJIT sponsors page. The x86-64 port will be released under the MIT/X license, just as previous LuaJIT releases have been. Many thanks to Mike Pall for his excellent work on LuaJIT.

by Joshua Haberman, Software Engineering Team

via Android Developers Blog by Megha Joshi on 1/20/10

You may recall that we announced IRC Office Hours for Android app developers back in December. We just want to provide a quick update that upcoming office hours will be held on Thursdays from 5 p.m. to 6 p.m. PST, instead of twice weekly. These will be held in the #android-dev channel on irc.freenode.net as before.

Please post your questions on Stack Overflow with "from-irc" tag in addition to "android" tag one day before office hours. We will follow up on those specific questions during office hours, and will also post answers after.

We hope to see you there!

via El Blog para Webmasters by Cristina, Equipo de Calidad de Búsqueda on 1/20/10
Os adelantamos que hemos creado un test para webmasters en español, que trata temas que vemos habitualmente en nuestro Foro para webmasters.

Hemos pensado que quizás esta sea una manera divertida de aprender las respuestas a todas esas preguntas que solemos ver en nuestro Foro y también de aprender otros datos menos conocidos.

Algunas cosas a tener en cuenta sobre este test:
  • La próxima semana se publicará el test en nuestro blog para webmasters.
  • Este test no trata todos los problemas con los que se pueda encontrar un webmaster. Simplemente, y como sucede con cualquier otro test, ¡es una manera divertida de probar tus habilidades como webmaster! Si necesitas ayuda para casos específicos, ¡pásate por nuestro Foro para webmasters!
  • Los resultados del test no aparecerán automáticamente, si no que publicaremos una entrada con las respuestas y su explicación, así como una lista de los participantes que hayan conseguido más puntos. Te recomendamos que guardes o imprimas tus respuestas antes de enviarlas. Así podrás comprobarlas cuando publiquemos las soluciones.
  • Ante todo, queremos pasar un rato divertido :)
¡Os esperamos la próxima semana!

Publicado por Charlene Perez, equipo de Calidad de búsqueda. Traducido por Cristina, equipo de Calidad de búsqueda.

via Google AJAX Search API Blog by Adam Feldman on 1/19/10
Over the last several years, you've helped make Google's AJAX APIs incredibly successful. Not surprisingly, however, there are some people who try to take advantage of these free APIs by using them in ways that they were not designed for, abuse which is prohibited by the Terms of Use. Specifically, some servers are making countless requests - requests not made on the behalf of an end-user - in an attempt to scrape data from the APIs.

To help us discourage this behavior without affecting legitimate developers, we're adding a new parameter to the RESTful interface, userip. With this parameter, developers have the option of supplying the IP address of the end-user on whose behalf they are making the API request. Doing so will help us distinguish this legitimate server-side traffic from the more abusive scraping in which there are no end-users.

Use of this new parameter is *not* required. However, if it is not included with server-side requests, those requests are more likely to be interpreted and automatically blocked as abuse, especially in situations where a server is sending a high volume of traffic to the API. Additional safeguards you can take include setting setting a valid HTTP referer (as required by our Terms of Use) and using an API key. These additional measures will help us contact you in case there are problems with your website or application (sometimes a programming error results in massive traffic, forcing us to block your access if we are unable to contact you). In choosing to utilize this parameter, please be sure that you're in compliance with any local laws, including any laws relating to disclosure of personal information being sent.

Check the documentation for usage of the new parameter. We'd love to hear any comments, questions or problems you're having in the support forum.

via AdWords API Blog by AdWords API Team on 1/19/10
Beginning today, you no longer need to provide us with an AdWords API Application Token to access the AdWords API (v13 and v2009). This change requires no action on your part. The Application Token will simply be ignored if it continues to be included with your API requests. Note that the Developer Token is still required. We hope that this makes your life a bit easier in working with the AdWords API.

As always, we are here to answer your questions, collect feedback, and assist with migration to the v2009 API.

-- Albert Cheng, AdWords API Team

via El Blog para Webmasters by Cristina, Equipo de Calidad de Búsqueda on 1/19/10
Los esfuerzos para combatir el malware por parte de Google están orientados tanto a los webmasters como a los visitantes del sitio web. Google escanea continuamente nuestro índice web, detectando las páginas que podrían ser peligrosas para los visitantes del sitio. Cuando encontramos este tipo de páginas, se marcan como perjudiciales en nuestros resultados de búsqueda y también se proporcionan estos datos a varios navegadores, para que los usuarios de esos navegadores reciban avisos directamente.

Nos comprometemos con este proceso como parte de nuestra filosofía de seguridad: creemos que si trabajamos todos juntos para identificar las amenazas y acabar con ellas, podemos hacer de la red un lugar más seguro para todos.

Si bien creemos que estos procesos son pasos importantes para ayudar a proteger a nuestros usuarios, también comprendemos la frustración que sienten los webmasters de los sitios marcados. Esta es la razón por la que se notifica a los webmasters, tan pronto como se descubre que sus sitios han sido comprometidos. Además, ofrecemos a los webmasters una herramienta para solicitar la revisión [inglés], una vez que se haya limpiado el sitio.

El proceso de revisión funciona de la siguiente manera:

Parte 1. La tarea del webmaster:

El primer paso es limpiar el sitio. El webmaster debe eliminar todo el contenido dañino del sitio. Somos conscientes de que puede ser difícil encontrar y eliminar todo el malware de un sitio web, pero los webmasters deben buscar a fondo si el aviso de malware persiste.

Ten en cuenta que si tu sitio contiene elementos de otro sitio web que se haya visto afectado por malware, tu sitio seguirá apareciendo marcado. Esto se debe a que tu sitio aún podría dañar a los visitantes.

Para evitar una nueva infección de malware, el webmaster debe identificar y corregir la vulnerabilidad de software subyacente que da lugar al ataque en primer lugar. Puedes consultar una guía sobre cómo hacer esto en la página stopbadware.org/home/security [inglés].

Una vez que el webmaster haya limpiado el sitio, puede solicitar una revisión de malware mediante las Herramientas para webmasters de Google. Ten en cuenta que una solicitud de revisión de malware no es lo mismo que una solicitud de reinclusión en el índice.

El proceso de revisión de malware es el siguiente:

2. Desde la página principal de las herramientas, haz clic en el enlace al sitio que está siendo marcado como malware. Esto te llevará al panel para ese sitio.
3. Debería haber un gran aviso rojo en la parte superior del panel, que dice: "Este sitio puede estar distribuyendo malware". Al hacer clic en el enlace que dice "Más Información", aparece una lista de páginas del sitio que se consideraron maliciosas.
4. Debajo de esta lista, hay un enlace para "Solicitar una revisión." Si el webmaster rellena este formulario y hace clic en "Solicitar una revisión", se iniciará el proceso de revisión.


Parte 2. Nuestro turno:

Al recibir una solicitud de revisión de malware, un conjunto de algoritmos automatizados comprueba que el sitio ha sido limpiado. Estos algoritmos comprueban un subconjunto de páginas maliciosas y no maliciosas que fueron escaneadas cuando el sitio fue marcado como malware originalmente. Además, estos algoritmos también prueban algunas páginas que no se escanearon inicialmente. Si no se encuentra contenido malicioso en ninguna de las páginas comprobadas, se considerará que el sitio es seguro y las advertencias se retirarán de los resultados de búsqueda. Una solicitud normalmente necesita unas horas para completarse, aunque en algunos casos el proceso puede tardar hasta un día.

Además de la tramitación de las solicitudes por parte de los webmasters, también se vuelven a examinar los sitios que se han visto afectados de forma periódica.

Animamos a los webmasters de los sitios infectados a que limpien rápidamente sus páginas web y a que activamente soliciten la revisión mediante las Herramientas para webmasters. Una vez que se haya limpiado y revisado completamente el sitio, ya no se mostrará el aviso en las páginas de resultados de búsqueda de Google, ni a través de los navegadores que hacen uso de nuestros datos.


Publicado por Lucas Ballar y Ke Wang, Anti-Malware Team. Traducido por Cristina, equipo de Calidad de búsqueda.

via El Blog para Webmasters by Cristina, Equipo de Calidad de Búsqueda on 1/18/10
"¡Utiliza Google para ganar miles de dólares!" o "Dinero fácil con Google: ¡Podrías estar ganando hasta 978 dólares al día trabajando desde casa!" Es posible que hayas visto ofertas como estas que usan el nombre o el logotipo de Google y que parecían demasiado buenas para ser verdad. Desafortunadamente, casi todas son fraudes y, a pesar de cientos de quejas de consumidores y de nuestros propios esfuerzos por evitar que estos sitios engañen a personas, algunos de los fraudes continúan. Para combatirlo, estamos trabajando para detener diversos negocios fraudulentos como "Google Money", y se presentó una demanda contra Pacific WebWorks [inglés] y otros acusados no identificados.

Google no ha creado ni apoya a ningún sitio como los arriba mencionados. Estos anuncios engañosos tratan de aprovecharse de los consumidores, en medio de una situación económica difícil, y al empeorar la economía el problema se vio agravado. Por ahora, lo que podemos decir es que se ha engañado a miles de personas [inglés] para que realicen un pago con el fin de recibir información adicional, y a las que posteriormente se les han realizado cargos de origen dudoso.


A pesar de que estamos tomando medidas legales para tratar de cortar el problema de raíz, seguimos trabajando constantemente en la eliminación de URL fraudulentas de nuestro índice, y vamos a desactivar permanentemente las cuentas de AdWords que ofrecen una experiencia de usuario pobre o nociva, utilicen o no las marcas comerciales de Google de forma ilegal. Dicho esto, no podemos garantizar que los sistemas de este tipo no aparezcan en algún otro lugar en línea, ya sea en una red diferente o con un nombre diferente.

Podemos resolver sólo una parte del problema, pero el resto también depende de ti. De la misma manera que se debe tener cuidado a la hora de facilitar datos bancarios, también hay que ser escéptico y revisar cualquier oferta antes de enviar información, y estar siempre alerta cuando se presenta una oferta que parece demasiado buena para ser cierta. A continuación encontrarás una lista muy reducida de algunos nombres que sabemos que son sospechosos. Para obtener más consejos sobre cómo detectar un fraude en línea o qué hacer si crees que tu o alguien conocido ha sido engañado, echa un vistazo a esta entrada.

Aunque no hay ningún kit secreto que garantice la riqueza, muchas personas realmente hacen dinero en línea. Basándonos en nuestra experiencia, la mejor manera de construir un negocio en la web es realmente ofrecer un servicio a tus usuarios; ofrecer productos y servicios útiles; o escribir sobre algo que te apasiona. Si te estás preguntando si alguna oferta que hayas visto es legítima, ten en cuenta que los servicios empresariales y de publicidad de Google se pueden encontrar en nuestro sitio web. Y el mejor lugar para encontrar puestos de trabajo reales en Google es en http://www.google.com/intl/es/jobs/index.html

Nombres con los que hay que ser cauteloso: Google Adwork, Google ATM, Google Biz Kit, Google Cash, Earn Google Cash Kit, Google Fortune, Google Marketing Kit, Google Profits, The Home Business Kit for Google, Google StartUp Kit y Google Works.

Publicado por Jason Morrison, Support Engineer (Search Quality Team) y Stacey Wexler, Senior Litigation Counsel. Traducido por Cristina, equipo de Calidad de búsqueda.

via Google Open Source Blog by Ellen Ko on 1/15/10
This year's linux.conf.au is in Wellington, New Zealand. It's starting this weekend, Sunday January 17th, and runs all week, through Saturday, January 23rd. We'll have members of the Open Source Team at the conference all week. And we're especially excited about giving a talk next Saturday at Open Day!

Stop by to visit us at our Open Day table if you're in the area: it's free and open to the public (not just for conference-goers). Ask questions, meet people in the open source space, or just hang out and hack with us. We'll be giving a talk called "Open Source for Newbies" and we'd love to get your questions about the open source community, what you can do for open source, or how to get started in open source even if you don't know anything about it. It should be a fun day with activities for kids, lots of speakers and booths, and a hackfest going on. There's even going to be some electric cars there!

Check out the Open Day wiki on the Linux.conf.au website to learn some more. It's being held at the Wellington Town Hall. Here's the details:

Where: Wellington Town Hall
Date: Saturday January 23, 2010

Time: Doors open at 11.00 am and close at 2.00 pm

For those of you attending the conference, members of our team Leslie Hawthorn, Cat Allman, and Jeremy Allison will all be giving talks on Thursday (schedule here). Come listen to them speak on a variety of topics for the open source community today. Finally, we're having a miniconf on Google Wave™ on Monday, January 18, that is also available to all conference attendees.

Hope to see you there!

by Carol Smith, Open Source Team

via El Blog para Webmasters by Cristina, Equipo de Calidad de Búsqueda on 1/15/10
¡Hola a todos! Hoy os traemos un nuevo vídeo de nuestro experto, Matt Cutts, con subtítulos en español. Como todos sabéis, los subtítulos en español van a aparecer por defecto en el vídeo a continuación, pero podéis seleccionar otras opciones o desactivarlos en el menú que hay en la esquina inferior derecha de la pantalla.

Matt Cutts habla hoy sobre los informes de spam que recibimos de nuestros usuarios y cómo se procesan. Si quieres conocer más detalles, te animamos a que veas el siguiente vídeo.




Transcripción de ¿Cómo se priorizan los informes de spam?

Tenemos una buena pregunta de Neil M. Hancock de Newcastle. Pregunta: "¿Hay un número mínimo de informes de spam recibidos para un dominio o SERP antes de que Google lo revise? En teoría recibís miles de informes de spam al día, ¿se clasifican estos de alguna manera para revisarlos? Los más populares primero,por ejemplo".

Sí que los clasificamos. Normalmente pensamos cual es el impacto en el usuario y definitivamente actuamos, digamos, si tienes uno de un sitio que van a consultar muchos usuarios, pues éste recibirá más atención que un sitio que no reciba casi ninguna visita. Así que sí que miramos muchos informes de spam. Actuamos con muchos de ellos y también los utilizamos para ayudar a priorizar o adelantar la nueva versión de nuestros algoritmos y cómo deberían hacerse cargo de las cosas. Pero cuando revisamos informes de spam intentamos pensar "¿Cómo puedo utilizar nuestros recursos de la mejor manera? Y una de las maneras es mirar los informes y ver los que más afectan a los usuarios. Así que esta es una de las maneras que tenemos de consultar los informes de spam.

Publicado por Cristina, equipo de Calidad de búsqueda.