Al escribir el post anterior me ha surgido la duda (bastante tonta) de si adiós llevaba o no tilde, así que he hecho lo que suelo hacer: lo he buscado en Google. XD ¿Y el primer resultando? ¡¡Un enlace de Google Maps!! Resulta que hay un pueblo en Navarra que se llama así, Adiós.
Many times the reason because a web server is slow and unresponsive is that it’s under “attack”, on purpose or not, by a bot. I’ve seen cases where Google Bot, bots from research engines from universities or some other kind of indexer were responsible for more than half the traffic of a site. These cases are not real DoS attacks, this traffic can be considered legitimate, but the result is that it brings the service down. You can instruct some of these bots not to visit your site so often, like Google Bot using the Google Webmaster Tools and the sitemaps and/or robots.txt files, but usually you can’t and have to consider filtering all this traffic at the firewall. But in any case, the first step is realizing that a single IP (or a couple of them) is responsible for most of your traffic, identifying this IP and using whois learn who it belongs to.
You can run something like this to list the top five IP addresses on your Apache’s access.log:
Street View es una de las funcionalidades más cañeras de Google Maps: permite moverse “a pie de calle” en *casi* 3D por unas cuantas ciudades de EEUU con imágenes reales de 360º, pudiendo avanzar por una calle, girar en una esquina, mirar hacia los lados, etc.
Google ha presentado recientemente Android, una plataforma de desarrollo para teléfonos móviles basada en Linux e integrada con todas sus aplicaciones (Google Maps por ejemplo), y han publicado un SDK para que cualquiera pueda desarrollar sobre ésta plataforma. Los móviles que sean capaces de ejecutar ésto van a ser una caña.
Mi cuenta desde luego ya lo tiene activo. Ahora me toca plantearme si migro de mi propio servidor a GMail. :-m
Trucos si en tu cuenta, en Configuración -> Reenvío y correo POP no aparece IMAP:
En General, cambiar el idioma a inglés. Parece que la traducción de las opciones de configuración aún no está lista y no sale, pero es sólo por eso. Verificar que esté activo el IMAP y volver a dejar el interfaz en español.
Cerrar la sesión y volver a logarse. Al principio de las pruebas del servicio mucha gente comentaba que hasta que no iniciaron una sesión nueva no apareció la opción de IMAP.
GMail is one of Google’s services that I admire the most: I administer several e-mail servers myself, so I know what it takes dealing with anti-SPAM filters, given all the crap that’s sent today in form of animated GIFs, PDFs, and such, which should be even more difficult (and interesting) given Google’s scale in number of e-mail accounts, messages received/processed and geographical distribution. Nevertheless I don’t use GMail, among other things because of its lack of IMAP support. I don’t like POP and despite GMail’s great webmail service, I still prefer to use a “standard” e-mail software on my desktop computer.
But now rumor has it that GMail could add IMAP support shortly, and in fact it seems they’re already activating it on several chosen accounts to test it. Just tried mine but it’s not there yet. Do’h!
By the way, my account space has been bumped from 2Gb to 4.something.
UPDATE: Slashdot is also running a story about IMAP on Gmail.
Llevo tiempo queriéndome acostumbrar a usar algún software de calendario para organizarme mejor, porque la verdad es que soy bastante desastre. El problema es que con un programa de escritorio sólo tendrás los datos en un ordenador, te vas p.ej. de casa al trabajo y ya no tienes el calendario accesible. Una solución on-line, como Google Calendar, está muy bien pero para ciertas cosas sigo prefiriendo un programa de escritorio, aparte de que tengo una conexión un tanto inestable que me puede dejar tirado en cualquier momento, con lo que no puedo confiar en una solución exclusivamente on-line.
Lo ideal para mí sería tener un programa que pueda sincronizarse con una aplicación on-line, preferiblemente Google Calendar, porque detalles como los avisos por SMS y la posibilidad de acceder con el móvil valen su peso en oro. El problema es que con la mayoría de programas, p.ej. iCal, te puedes suscribir a un calendario de Google pero no hacer modificaciones, sólo acceder a los datos. No me sirve: quiero poder hacer cambios en local y sincronizarlos, y si en ese momento no tengo conexión, que la sincronización se espere a cuando tenga acceso a la red. Y viceversa, claro, que si accedo desde fuera de casa a la aplicación web, los cambios que haga me aparezcan luego en el programa de escritorio.
Llevo un rato cacharreando con GCALDaemon, un programa en Java que sincroniza bidireccionalmente cualquier programa que use ficheros en formato iCal con Google Calendar. Hace bastantes más cosas, p.ej. permite acceder mediante LDAP local a los contactos de GMail, importar RSS en iCal, etc., pero por ahora sólo estoy usando la sincronización de calendarios y parece que funciona muy bien.
La instalación no es excesivamente complicada pero hay que meterse en consola y se configura en un fichero de texto, con lo que los usuarios más acostumbrados a arrastrar un icono a Aplicaciones pueden tenerlo chungo. Una alternativa para ellos (comercial, eso sí) puede ser Spanning Sync.
A coworker has sent me three interesting articles from High Scalability, a site I still didn’t knew but which I’ve already added to my Google Reader list. The articles talk about the design and computer/network architecture decisions taken at YouTube, Google and GTalk in order to handle the big load their services face. They also comment the current architecture in each site and their evolution over time:
Don’t try to fix everything with one single architecture or tool. Divide the problem, see if each sub-problem is CPU-, bandwidth- or IO-bound, and optimize it. Specialize server for each task and coordinate their work.
Think about externalizing some things, like hosting images or videos off-site. These elements may need more bandwidth that you currently have, and moving them off-site can be a good idea, even if it’s just a temporary measure while you manage to get more bandwidth. The service must run at all times.
Simplicity. Will let you make changes and evolve your architecture without screwing up.
Commodity-PC based clusters. They maximize the power/price ratio. Have a redundancy system in place so that when one node goes down or needs maintainence, the system keeps working without it. Have a system to easily install/change a node, also without affecting the service. And start planning the power and cooling problems ahead.
Programming today is much about libraries and frameworks. Don’t reinvent the wheel. Use a common framework in all your developments, homegrown or not. This way novel programmers will be able to start writting code faster, will be able to switch projects easily, won’t have to code the same things over and over again, and a system upgrade will benefit all your applications.
Think about the architecture you’ll need from the start. I’m sadly used to developers not caring about what their code runs on, or if their code will lead to CPU, IO or bandwidth problems. Google seems to face every new development looking at the architecture they’ll need to handle the service, and then develop the code arount that architecture. This is what settles Google appart from the rest.
Comentarios