Grippo Blog

Clasificados Grippo ahora 100% Unicode, puede aceptar anuncios en cualquier idioma

2009-12-02T21:12:58Z

Cuando comenzó a funcionar www.grippo.com en los últimos meses de 1996, no había una manera práctica de poner en una misma página una frase en español y otra en hebreo, por poner un ejemplo. Tampoco español - coreano, español - chino mandarín, español - japonés o español - árabe, o directamente cualquier idioma sobre este mundo dentro de una misma página.

Eso cambió con Unicode, un estándar que venía trabajándose desde los ochenta, que recién en 1996 dió una versión Unicode 2.0 que hizo posible más tarde, cuando por ejemplo www.google.com salió a la luz, pudieran representarse cualquier combinación de idiomas en una misma página.

Hoy estoy orgulloso de anunciar que www.grippo.com fue actualizado a Unicode, lo que quiere decir que puede aceptar y mostrar avisos en cualquier combinación de idiomas que el azar y la globalización requieran.

Viene en un momento justo, ya que ya estaos recibiendo visitantes de muchos países asiáticos y de Europa del este que por el momento posteaban escuetamente sólo en español. Enfrentamos ahora algunos desafíos relativos a la internacionalización de Grippo, pero con una base tecnológica que ahora lo permite y antes no.

Los sitios nuevos o que comenzaron a desarrollarse hace poco, ya salen o salieron directamente en Unicode, con la codificacion UTF-8. Sin embargo Grippo tiene una base de datos con archivos de más de una década y la tarea de convertir esos datos a Unicode impuso cierta problemática que pude solucionar.

Estoy agradecido a los Perl Mongers de Buenos Aires por sus consejos, recetas y contribuciones desinteresadas que me asistieron en el proceso.

Si alguien se encuentra en la misma disyuntiva y tiene dudas al respecto, no tiene más que comentar esta nota.

Retrocediendo 15 años con la web movil

2009-11-23T19:33:30Z

Soy un joven suficientemente maduro para haber vivido la transición de los BBS a Internet de elite, con abonos de u$s 600 para conexiones dial-up de 1200 baudios. En esa época, el sistema operativo profesional era Windows 3.11, también conocido como WFWG o Windows For Work Groups. Rimbombante, y también espeluznante. Algunos años después cuando pude comprarle a mi hija que tendría no más de 9 años, un abono mensual para navegar a 19.200 baudios, el sistema operativo seguía siendo Windows 3.11, y un ratito después apareció Napster y sitios como ese, que permitían bajar mp3, pero los mp3 nunca bajaban, si tenían más de 1MB. Tampoco era sencillo navegar sitios como elsitio.com (por nombrar solo uno de ellos), que eran mucho mas elaborados que yahoo.com y por lo tanto tenían cientos de gifs y jpgs que tampoco terminaban nunca de bajar, y luego estaba el Internet Explorer que era una mierda peor que Netscape que era una basura.

Igual, así, poquito a poco, la Internet fue imparable. Aún así, llegamos a ser ahora 10? 12? o 15 millones? de argentinos navegando. Pero 92% parece seguir con dial-up, y solo 8% parece tener banda ancha. Lo cual me deja perplejo, porque aún hoy, con procesadores dual core, y 2GB RAM en la mayoría de las máquinas nuevas, navegar ciertos sitios debe seguir siendo insufrible.

Siendo que la navegación desde un terminal para nada delgado como es hoy en día cualquier laptop o PC, puede ser comparable a la de aquellos tiempos prehistóricos a los que hacia referencia al principio la navegación en la web movil.

En el Google DevFest que se hizo la semana pasada, se dijo que la misma página que tarda entre 1 o 2 segundos para ser presentada en una PC, puede tardar entre 20 y 40 segundos en un dispositivo movil: sea iPhone, BlackBerry o Android. Obviamente descartaron hablar de Windows Mobile, pero en ese terreno la cosa parece ser aún peor. Y obviamente también descartando problemas de conectividad. La razón es muy sencilla, los procesadores de los aparatos móviles son mucho mas lentos que los procesadores de una PC. Si una página contiene código Javascript (¿y como no va a contener?), la ejecución de ese código requiere tiempo del procesador y de ahi las demoras en el rendering en el móvil.

Hablando de conectividad, por experiencia propia, muy rara vez veo el simbolito 3G cuando navego con mis moviles iPhone, Blackberry o Motorola c/Windows Mobile. La mayoría de las veces veo GPRS, del que solo sé que es el medio más antiguo y por lo tanto con mayor cobertura, y también insufriblemente lento y despreciable, al punto de creer que ningún móvil debería prestarse a navegar en Internet cuando el medio es GPRS. A veces EDGE que podría o no andar.

De todo esto se deduce que navegar con un smartphone es una experiencia para aquel que tiene mucha paciencia y algo de tiempo para perder. Me considero paciente, pero el tiempo prefiero perderlo de otras maneras. Me entusiasman los dispositivos moviles, pero no puedo entender que algunos sitios no adapten en forma automatica aunque sea sus style sheets para que puedan ser consumidos en un movil:

Uno de ellos es Wired. No lo entiendo, no puedo comprender que Wired se despliegue igual de ancho y con fuentes insignificantes en un BlackBerry.

El otro es blogger. Siendo que se publican millones de post todos los dias en Blogger, como no se adaptan automaticamente todos los blogs de blogspot.com a un formato legible en iPhone, Blackberry o Android?

En principio esos dos, no?

Y hablando de eso, este mismo post, hecho con Movable Type, con un plugin se puede ver de una manera en PC y adaptado a la pantalla pequeña de un móvil, en un celular. Bravo!

Cuidado con window.open()

2009-11-23T19:12:25Z

De casualidad me enteré el viernes pasado que Google me había indexado decenas de miles de páginas inútiles, cuya indexación nunca me había preocupado porque no había links normales en ninguna parte, sino simplemente llamadas con Javascript, específicamente la famosa window.open().

Como Google solamente indexaba links normales insertados con el tag A, los links codificados con window.open nunca fue una preocupación.

Sin embargo, como sucede a diario, un usuario pidió que una página sea removida, no solo de Clasificados Grippo sino también de Google. Como es rutina, sin discutir ni mu, elimino inmediatamente el contenido en Grippo.com y luego usando Google Webmasters Tools, pido la eliminación también de la página en el index de Google. Pero esta vez, se trataba de una página tipo tooltip que se usa ordinariamente para documentar los campos en un formulario, a la que le pasaba como parámetro el nombre de un usuario.

Ejemplo de una página cuya indexación es inútil.

Se había escuchado sin muchas precisiones desde hace unos meses que GoogleBot ahora podía entender cierto Javascript. Bueno encontré un ejemplo vivo de que estas páginas fueron descubiertas por GoogleBot en una llamada window.open y no en un link normal con el tag A. Si bien tiene sentido, y además conociendo como se ha comportado GoogleBot en otras oportunidades, esta manera de crawlear la web debe estar en etapa experimental, concretamente en mi sitio, de pronto veo decenas de miles de páginas inútiles, indexadas con contenido duplicado y me pregunto cuánto puede estar influyendo negativamente en la indexación de tantas otras páginas con contenido dentro del mismo sitio.

Finalmente la receta que usé fue insertar en esas páginas un meta tag:

<meta name="robots" content="noindex">

Consejo: revisen si sus páginas linkeadas con window.open deberían ser "noindexadas" y hagan como hice yo.

Desde ayer hay avisos más sexy, crocantes, jugosos y apetitosos

2009-11-12T20:45:28Z

Para luchar contra todo tipo de inadaptados, los avisos ingresados en Grippo siempre fueron "re-adaptados". Esto es: convertidos todo a minúsculas, y eliminados los caracteres repetidos, formateos, codigos html, javascript, y demás. El resultado era sencillo de leer.

A partir de ayer se pueden postear avisos con poquitisimas restricciones. Se pueden colorear los fondos y las fuentes, agrandar las fuentes, agregar emoticones, e imagenes, copiar y pegar desde Word, y como resultado de eso, los anunciantes ahora se expresan con gran libertad.

Se están viendo todo tipo de diseños particulares, cada uno diferente, unico e irrepetible, como somos cada uno de nosotros.

Enjoy!

Te muestro mi robot

2009-11-06T06:10:41Z

,,Este es el mensaje que me envía mi robot cuando ha moderado avisos en Clasificados Grippo. Si en el asunto dice "Black List" es porque se ha cometido algun tipo de abuso, y el aviso tuvo que ser eliminado. Generalmente es por ofrecer cosas que en Internet no estan permitidas o simplemente por spam.

Vanina atrapa ladrón. Ismael observa desde ventana. Ladrón se va tranqui a su casa.

2009-10-29T17:48:11Z

¿En qué se han transformado las noticias hoy en día? Las nuevas tecnologías hacen posible que los hechos que les ocurren a amigos y gente cercana, sean más importantes que el flujo de noticias considerado principal por los medios. Aquí va el ejemplo de hoy:

Hoy poquito antes de las 13 hs, recibo en mi Twitter esta secuencia de noticias. Vanina, es ex compañera de trabajo hace un par de días compartimos un panel en un evento organizado por INADI. Con Ismael compartimos ayer mismo un evento en Google Argentina. A ambos los sigo en Twitter y leo sus blogs:

	Recién ladrón que escapaba me lleva por delante, caemos al piso y la gente lo atrapa. Le dan varias piñas.
	Fue en diag.norte y suipacha. Llegó la policía rápido pero la gente no lo soltaba. Susto #ladrón
	3 tipos redujeron a un chorro frente a la oficina a patadas en la cabeza! Lastima que el hijo de puta seguro entra y sale al toque.
	Que loco! El chorro al que cagaron a trompadas se habia chocado con @vanis antes! Y yo mirando desde la ventana y twitteando lo mismo :s

Ambos fueron testigos en el mismo lugar. Finalmente la crónica terminó así:

Al final el chorro se fue libre en la ambulancia porque la victima del robo se fue y los que lo cagaron a trompadas tambien!

Contra la discriminación en la web

2009-10-20T18:58:25Z

Voy a participar de un panel en el próximo jueves, junto a Vanina Berghella (blogs.clarin.com), Matías Botbol (Taringa.net), Sebastián Rozenfarb (Keepcon.com) y Eugenia Klein (Inadi.gov.ar).

El INADI organizó para el próximo jueves 22 de octubre, a partir de las 10:30hs, un serminario y lo denominó: Seminario Buenas Prácticas contra la Discriminacion en la Web. Se realizará en el Auditorio de la Comisión Nacional de Valores, en ese bello barrio de Buenos Aires tan parecido a Ciudad Gótica, en 25 de Mayo 175. El evento tiene cupo limitado, por lo cual si te interesa asistir debes realizar la inscripción, enviando un mensaje a inclusiondigital (arroba) inadi.gov.ar.

Pueden consultar el programa completo en INADI.

Completada la migración a Amazon AWS

2009-10-07T21:27:57Z

Se van a cumplir 90 días de que migré mis aplicaciones a Amazon AWS. El 30/set, hace justo una semana, desenchufamos, desatornillamos y retiramos los servidores del datacenter de Diveo / SkyOnline / Netizen.

Lo que ves en la imagen, es lo que me costo el consumo en Amazon AWS durante el mes de setiembre. Son 4 servidores EC2 small y uno medium. Mas S3 con CloudFront (unos 30 millones de hits), más un load balancer.
A quienes habían leído mis notas anteriores durante la migración, les debía un reporte de gastos de un mes normal. Representa un cuarto de lo que estaría pagando en el datacenter de siempre, sin ninguna de las capacidades especiales de cloud computing.

No voy a decir que fue sencillo, la verdad que no. Sobretodo para alguien que siempre usó FreeBSD y de golpe tiene que usar Debian, porque no hay opción FreeBSD todavía para XEN, que es el virtualizador de servidores. S3, CloudFront, ELB son sencillos. EC2 no tanto, hay que dedicarle tiempo a conocerlo. EC2 + EBS (la unidad de storage) es sensacional.

Tampoco voy a decir que es igual al servidor de "carne y hueso". Es bien diferente. Hay que dedicarle bastante tiempo a tunearlo y configurarlo adecuadamente. Ahora que ya pasó, estoy muy conforme, pero cada aplicación que moví, significaron días completos de problemas en la configuración que necesitaban ajustarse, para que la performance sea aceptable. Ahora todo anda mejor que óptimo. Y estoy muy contento y aliviado de haber traspasado todos los inconvenientes.

Escribiendo las notas durante la migración, encontré que mucha gente se había interesado. Luego caminando por esos mundos (reales), encontraba aquí y allá a quienes habían leído mis notas y me comentaban esto y aquello. Asique este reporte va para ustedes que venían siguiendo esta serie, se los había prometido.

También aquí y allá encontré varios sitios realmente grandes que estaban también migrando o ya habían migrado a Amazon y algunos de ellos compartieron valiosa información conmigo, les agradezco mucho!

Las proximas notas serán sobre EC2, que es lo que más problemas me trajo.

No puedo usar urls cortas y ELB al mismo tiempo

2009-09-05T06:59:41Z

ELB = Elastic Load Balancer.

El jueves pasado, cuando iba a entrar a ver Bastardos sin gloria, chequeé por un instante cómo funcionaba grippo.com en mi iphone, y encontré otro sitio en su lugar.

Ahora entiendo mejor, por qué pasó eso, y cuán equivocado estaba yo con respecto a los registros CNAME y a las direcciones IP de ELB.

Yo queria tener urls del tipo http://grippo.com/aviso/1234 y http://grippo.com/buscar/departamentos+en+mar+del+plata, es decir usar solo el dominio, sin www. Mi proveedor de DNS primario (www.mydomain.com), es un tipo de proveedor que permite poner CNAME del dominio completo (sin subdominio). Entonces siempre pensé que era legal. Pero en realidad yo no estaba entendiendo claramente qué significaba. Poner un CNAME en el dominio, si tu DNS primario te lo permite, es útil sólo cuando el dominio es efectivamente un alias 100% del host de destino del CNAME. De hecho, la primera semana de subirme a Amazon AWS, lo que hice fue poner algo asi como:

grippo.com IN CNAME grippo-2014187730.us-east-1.elb.amazonaws.com.

ya que ese es el nombre de mi load balancer. Al hacer eso, me quedé sin mails @grippo.com, porque no tenía caso haber configurado registros MX en mi archivo de zona de grippo.com, ya que ese CNAME invalidaba todo el resto. Tuve que averiguar entonces la IP de grippo-2014187730.us-east-1.elb.amazonaws.com, que era una hace unos dias, y es otra ahora, y convertir ese registro en

grippo.com IN A 123.45.67.89

Eso anduvo bien hasta que Amazon le cambio la IP a grippo-2014187730.us-east-1.elb.amazonaws.com. Eso trajo la pantalla extraña de esta historia. Ahora bien, siendo que uso un load balancer, ahora entiendo que está bien que Amazon me aconseje usar un CNAME apuntando a grippo-2014187730.us-east-1.elb.amazonaws.com, ya que eso hace que su load balancer sea más elástico, es decir que pueda ser redundante en caso de fallas, y derivar trafico por otros dispositivos, cuando el dispositivo original falla o simplemente para organizar mejor su trafico y dar un mejor servicio. Eso hace que los load balancers como grippo-2014187730.us-east-1.elb.amazonaws.com vayan ocasionalmente cambiando la direccion IP.

Por lo tanto, mi idea de usar urls del tipo http://grippo.com/aviso/1234 no funcionaría junto con load balancer de Amazon. Debería usar mi propio load balancer, cosa que considero descartar, apostando a que Amazon va a manejar mejor mi load balancer que yo mismo, que pretendo deligarme de mas tareas, antes que tomar otras nuevas.

Nuevas lecciones aprendidas:

Usar CNAME de todo el dominio, solo es viable cuando no hay otros servicios como ser mails en el mismo dominio.
Sólo las urls del tipo http://subdominio.midominio.com/aviso/1234 funcionarían con Elastic Load Balancer, por lo que las urls del tipo http://grippo.com/aviso/1234 no son viables sin comprometer el servicio en momentos de sobrecarga, o sin sobrecargar al webmaster con una nueva tarea de administrador de load balancer

Cosas que pasan, extraña apariencia de Grippo.com

2009-09-03T23:10:26Z

Una de las leyes de Murphy dice, que una serie de eventos fallará en la peor combinación posible. Acaban de avisarme (Sebastián Querelos y Gabriela Maidana), que Grippo.com aparecía con esta extraña apariencia:

¿Qué pasó?

Lo primero que pensé fue esto: ¨me hackearon el sitio, por primera vez luego de 13 años".

Pero no.
Yo mismo fuí el culpable. La respuesta corta es que en el archivo de zona del DNS de grippo.com, en vez de poner un CNAME apuntando al load balancer de Grippo.com, puse una direccion IP (A). Mi proveedor, Amazon, le cambió la IP al load balancer, y ahora el load balancer de otro, está usando la IP que era de Grippo.com.

Como me siento muy culpable, no quisiera ahora también agregar este otro detalle: mi proveedor de DNS primario, tarda horas en propagar cada cambio. Asique por más que el arreglo ya está realizado, va a tardar horas en verse online.

Lecciones aprendidas:

usar un proveedor de DNS primario que te deje propagar un cambio en minutos, no hras
usar un proveedor de DNS que te permita modificar tus registros de acuerdo a tus necesidades, no las de ellos

Por razones históricas, los DNS primarios de mis dominios, estaban en www.mydomain.com, pero ahora es momento de buscar un proveedor profesional. Ya me habían recomendado ultradns.net, pero me demoré más de la cuenta en seguir esa recomendación.

Agregado el 5 Sep:

Ahora entiendo mejor.

Yo queria tener urls del tipo http://grippo.com/aviso/1234 y http://grippo.com/buscar/departamentos+en+mar+del+plata, es decir usar solo el dominio, sin www. Mi proveedor de DNS primario (www.mydomain.com), es un tipo de proveedor que permite poner CNAME del dominio completo (sin subdominio). Entonces siempre pensé que era legal. Pero en realidad yo no estaba entendiendo claramente qué significaba. Poner un CNAME en el dominio, si tu DNS primario te lo permite, es útil sólo cuando el dominio es efectivamente un alias 100% del host de destino del CNAME. De hecho, la primera semana de subirme a Amazon AWS, lo que hice fue poner algo asi como:

grippo.com IN CNAME grippo-2014187730.us-east-1.elb.amazonaws.com.

ya que ese es el nombre de mi load balancer. Al hacer eso, me quedé sin mails @grippo.com, porque no tenía caso haber configurado registros MX en mi archivo de zona de grippo.com, ya que ese CNAME invalidaba todo el resto. Tuve que averiguar entonces la IP de grippo-2014187730.us-east-1.elb.amazonaws.com, que era una hace unos dias, y es otra ahora, y convertir ese registro en

grippo.com IN A 123.45.67.89

Eso anduvo bien hasta que Amazon le cambio la IP a grippo-2014187730.us-east-1.elb.amazonaws.com. Eso trajo la pantalla extraña de esta historia. Ahora bien, siendo que uso un load balancer, ahora entiendo que está bien que Amazon me aconseje usar un CNAME apuntando a grippo-2014187730.us-east-1.elb.amazonaws.com, ya que eso hace que su load balancer sea más elástico, es decir que pueda ser redundante en caso de fallas, y derivar trafico por otros dispositivos, cuando el dispositivo original falla o simplemente para organizar mejor su trafico y dar un mejor servicio. Eso hace que los load balancers como grippo-2014187730.us-east-1.elb.amazonaws.com vayan ocasionalmente cambiando la direccion IP.

Por lo tanto, mi idea de usar urls del tipo http://grippo.com/aviso/1234 no funcionaría junto con load balancer de Amazon. Debería usar mi propio load balancer, cosa que considero descartar, apostando a que Amazon va a manejar mejor mi load balancer que yo mismo, que pretendo deligarme de mas tareas, antes que tomar otras nuevas.

Nuevas lecciones aprendidas:

Usar CNAME de todo el dominio, solo es viable cuando no hay otros servicios como ser mails en el mismo dominio.
Sólo las urls del tipo http://subdominio.midominio.com/aviso/1234 funcionarían con Elastic Load Balancer, por lo que las urls del tipo http://grippo.com/aviso/1234 no son viables sin comprometer el servicio en momentos de sobrecarga, o sin sobrecargar al webmaster con una nueva tarea de administrador de load balancer

Bilinkis entrevista a Galperín

2009-08-07T20:19:20Z

9 minutos y medio de video imperdibles.

Hoy migré la aplicación con mayor tráfico a Amazon EC2

2009-08-06T19:30:11Z

Un sueño hecho realidad, y muchas horas despierto, esperando que el desastre ocurra en cualquier momento. Pero no ocurrió nada grave. La aplicación con mayor tráfico (Clasificados Grippo), fue migrada anoche con éxito a Amazon EC2.

Dispuse un redirect de clasificados.grippo.com.ar a grippo.com que es el dominio donde se sirven ahora las páginas, para tener el mínimo de downtime posible. La aplicación estuvo fuera de línea solo 15 minutos que es lo que tardó en migrarse la database de un lugar al otro. Comprimido 0,4GB, descomprimido 2,2GB.

La capacidad tanto del MySQL server, como de los application servers (dos detrás de un load balancer) era en teoría equivalente a un procesador Intel P4 dual core, u Opteron del 2007. Así dice la doc. de Amazon. Tienen 1.7GB de RAM. Son tamaño small, luego hay medium y large. Luego hay medium high performance y large high performance, yo tengo 3 small. Asique tenía mis dudas respecto a cómo iban a responder cuando llegue el pico de 30 requests por segundo.

Finalmente, responde muy bien, y ahora puedo decir que podrian absorber hasta 300 resquests por segundo los application servers, aunque el MySQL server voy a tener que partirlo en un master donde hacer los inserts y updates, y un slave en principio para los selects para estar tranquilo y permitir que el tráfico pueda crecer sin preocupaciones. Luego ante mayor demanda la estrategia es darle mas potencia al master y agregar más slaves para los selects.

así se ven los top en los 3 servers que están en servicio en este momento. Tengo instalado munin-node que es como MRTG pero mas sencillo de instalar, que va recolectando el usage de los recursos y me los muestra en gráficos acumulando información cada 5 minutos. Por ejemplo el uso de la CPU, que debe estar por debajo de 80 el 95 por ciento del tiempo (system + user + nice) .

Conclusión: muy contento porque todo ha salido bien y no hay que dar marcha atrás. Muy pronto: adiós final al tradicional datacenter.

¿Innovación? Me acordé de Sil haciendo Al Pacino

2009-08-05T20:00:00Z

Leyendo la nota sobre innovadores de Alec, me acordé de Silvio, de la banda de Tony Soprano, imitando a Al Pacino en el Padrino III. Este es Al Pacino, tratando de salir del mundo del crimen. Pero no lo dejan:

Y este es Sil, imitándo a Al Pacino para alegrar a los otros capos:

Versión en inglés.

Un ejemplo de por qué cuesta tanto innovar a las corporaciones.

Salvando las distancias entre la mafia y una corp., se tracciona con más fuerza para mantener el status quo, que para cambiarlo.

Usá site:tudominio para encontrar problemas

2009-08-05T18:19:33Z

El comando site, sirve para restringir la búsqueda en Google a un dominio o subdominio en particular. Es decir, en vez de buscar en toda la web, busca solo en el dominio especificado. Por ejemplo, ingresando en el buscador lo siguiente:

auto site:grippo.com.ar

Sólo busca "auto" en el dominio grippo.com.ar. Ahora bien, si sólo busco:

site:grippo.com.ar

entonces obtengo información interesante. En este instante me dice que el index de Google tien 2.260.000 páginas de grippo.com.ar. Ese dato es muy variable de todas maneras, ya que Google siempre está mezclando versiones viajes del sitio con versiones más nuevas, asique oscila mucho. De todas maneras, mirando los resultados (te recomiendo entrar en preferencias y ajustar el valor a 100 resultados por página), siempre se encuentran problemas a simple vista.

Por ejemplo, páginas indexadas que no deberían estar indexadas, como ser plantillas o documentos, o listings de directorios que quedaron dentro del espacio virtual de la web. En la próxima imagen, el segundo resultado es una versión en japonés de la documentación de Apache, que descubrí indexada hace más de un mes, y todavía no lo logro:

Google había indexado otras 100 páginas en japonés, correspondientes a la documentación de Apache. Este otro ejemplo es muy triste, por alguna razón faltaban los index.html:

Muchas veces así se indexan cartas de alguna novia/o al/la cual ya no seguimos, o alguna foto comprometedora que sin querer quedó al descubierto. El comando "site:" viene en nuestra ayuda para descubrir todos esos problemas a simle vista.

¿Por qué problema y por qué SEO? Porque muchas veces con este comando site: descubrimos duplicación de contenidos. La mayoría de los programadores somos vagos, y cuando empezamos algun proyecto nuevo, tratamos de basarnos en alguno anterior que sea parecido, abusando del copiar y pegar. A medida que unos proyectos avanzan, otros siempre quedan en la cola. Mientras están en la cola, podrían estar siendo indexados por Google. Eso me pasó y acabo de descubrir 100 mil urls indexadas duplicadas. OMG.

Mi solución siempre que quiero hacer desaparecer algo de Google, consiste en:

Hacer que el http server responda "410 Gone" a todo request que quiero eliminar del index de Google.
Ir a Webmasters Tools, e incrementar la velocidad de crawling al máximo.

No ser canuto: probá ahora con tus dominios y comentá qué macana te mandaste!

La Gaceta de Tucumán tuvo que suspender sus clasificados

2009-08-04T22:43:42Z

Según se anunció hoy oficialmente, en la sección de Opinión (?), el servicio de avisos clasificados en la web de la Gaceta de Tucumán fue suspendido por un período que puede llegar hasta un mes. Yo aplaudo a la tranquilidad con la que se trabaja en ese equipo, no especialmente la gente de sistemas de quienes presupuestar tiempos en internet de esta manera no me sorprende en absoluto, sino quienes en un diario son responsables de un servicio de avisos clasificados, que tradicionalmente es una fuente de ingresos importante. Inevitablemente debo preguntarme: ¿les preocupa algo Internet?

Pareciera que no, que el negocio de los clasificados en papel es eterno.

Para otros no tan despreocupados, especialmente para quienes hace SEO, les cuento que tengo comprobado que un downtime de horas puede hacer estragos en el flujo de referers desde buscadores, imaginen lo que puede hacer un mes completo!