Se ha hablado muchísimo de Wikipedia, tanto que lo que escribo ahora no es ni nuevo ni original. Se trata simplemente de advertir, aunque ya lo sabéis todos, que no se puede tomar Wikipedia como una fuente de información absolutamente fiable.

El proyecto es una maravilla ya que permite que muchas personas contribuyan a los artículos aportando informaciones y enfoques difíciles de encontrar en una enciclopedia tradicional y a veces se crean artículos extraordinarios consecuencia del trabajo colaborativo entre destacados ususarios.

La otra cara de la moneda está en que esta libertad de edición propicia a veces la introducción de, en el caso menos grave, pasajes tórpemente redactados y artículos y frases no enciclopédicas. En los casos más graves, verdaderas intoxicaciones informativas y partidismo interesado. En otras ocasiones se introducen pequeños datos, muchas veces de extensión menor de una línea, que son absolutamente falsos. A veces son rumores, otras información no verificada o simplemente el fruto de la imaginación desbordada de un usuario. Las intoxicaciones y el vandalismo suelen ser reparados casi al instante por wikipedistas vigilantes. Sin embargo, el problema de las pequeñas mentiras es mucho más difícil de detectar, sobre todo cuando estas pasan desapercibidas o bien, por su aparente lógica, nadie duda de su veracidad. Sin ir más lejos, en estas últimas semanas he corregido varias mentirijillas que he encontrado en Wikipedia sobre temas sobre los que llevo muchos años estudiando y creo que tengo el dominio suficiente para poder decir con seguridad que esa frase es falsa.

Pequeñas mentiras e invenciones que pueden hacer mucho daño al tomar Wikipedia como una fuente completamente fiable a la hora, por ejemplo, de hacer trabajos para la Universidad o el Instituto. Por supuesto, un investigador serio deberá evitar la tentación del camino corto y acudir a fuentes originales verdaderamente fiables.

(Viene de http://carlinux.com.es/[…]cancela-cuentas-parte-2-de-3.html)

Concluimos hoy la serie iniciada hace unos días sobre los posibles motivos de cancelación de cuentas de Adsense. En esta última entrega, os comentaré mis impresiones sobre las precauciones que se pueden tomar para evitar la cancelación.

Hay un caso triste, y es el de aquellos que fueron aceptados en su día en Adsense mostrando una web y a los que posteriormente se les echó del sistema habiendo cumplido estrictamente con las normas, sin haber hecho click fraud, observando las posiciones de los anuncios para no incitar al click, etc. ,etc. La explicación puede estar en que Google aceptó la web porque el revisor de turno, creyó en principio era válida para el programa (no suelen ser muy exquisitos, la verdad) pero pasado un tiempo, durante una revisión rutinaria cuando las ganancias de la web se acercan a los 100 dólares, decide que no representa los estándares mínimos de calidad que exige o bien algún anunciante de Adwords se queja.

Lógicamente, Google debe tratar bien a quien le da más del 99,99% de sus ganancias, que no es otro que sus queridos anunciantes de Adwords. Si un anunciante dice “¡Pero… qué diablos! ¿Cómo has podido poner mi anuncio en este sitio?”, Google deberá complacerle para conservar al cliente. Por otro lado, expulsar a un pobre editor que ha reunido 100 dólares en cinco meses no supone ningún problema para Google. Sabe que tiene miles de webmasters en la recámara ansiosos por trabajar con Adsense.Lo más importante de un sitio web es su contenido. El anunciante de Adwords paga principalmente por que su anuncio aparezca en los resultados de búsqueda y, secundariamente, en sitios web de calidad.

Los foros es uno de los sitios típicos que suelen ser expulsados de Adsense. ¿Los motivos? Seguramente estén lejos de ser el tan traído y llevado click fraud. Un foro genera muchas impresiones pero pocos clicks en los anuncios y aún menos conversiones a venta. Al anunciante le interesa llegar a un público genuinamente interesado en su producto. Por otro lado, el dueño del foro es responsable del 100% del contenido pero es el autor de una diminuta porción. La mayor parte del contenido la generan terceras personas. En un foro se genera mucha literatura pero generalmente suelen ser discusiones sin interés para alguien ajeno al mismo y su calidad por el interés y nivel cultural y conocimientos de sus participantes es muy desigual. En resumen, un foro no es quizá el lugar más atractivo para gastar dinero en un sistema publicitario caro como es Adwords. Sin embargo, quizá Adsense debería ser más estricto al principio y no aceptar ciertos sitios desde el primer momento.

Me he centrado en los foros pero hay otros tipos de sitios que no son rentables para Adsense.

Es una situación muy injusta ya que Adsense debería rechazar desde el primer momento los sitios que posteriormente suele anular. Así se evitarían muchos desengaños y sería incluso positivo para los webmasters, quienes se verían obligados a mejorar la calidad de sus sitios para poder trabajar con Adsense.

Hoy me he encontrado con esta advertencia al iniciar sesión en Analytics. Era justo la excusa que estaba esperando para definitivamente desinstalar Google Analytics de mis sitios web. Si aceptamos esta nueva configuración, los datos de Analytics se compartirán con Adwords y Adsense. A mí particularmente me aterra ver que Google pueda llegar a tener tanto conocimiento al detalle de nuestros sitios web. Es una información tan precisa que no sabemos si la podrá utilizar en nuestra contra en algún momento.

Se me ocurre de momento que potencialmente la podría emplear para encontrar patrones por los que decidir penalizarnos en las posiciones del buscador o ajustar éstos en función de las palabras clave por las que nuestros usuarios llegan a nuestro sitio o jugar con ventaja con la competencia y acentuar su ya marcado monopolio haciendo uso de la información priviegiada con gran detalle que dispone acerca de las visitas procedentes de otros buscadores. También podría tomar acciones contra nuestra cuenta de Adsense si ve que no le cuadran las estadísticas de Analytics y el propio Adsense… Las posibilidades son infinitas.

Lo primero que he hecho es decir no, que no quiero que Analytics comparta información con ningún otro servicio. El siguente será desinstalar Analytics de todos mis sitios. Pierdo las gráficas más vistosas del mercado pero realmente no las necesito. Gano en independencia. Statcounter y Awstats me dan todo lo que necesito para mis análisis (sobre todo con este último, que no depende de ningún proveedor externo).

Hablando de todo un poco, ahora Google está intentando que accedas a Adsense con la misma cuenta a la que accedes al correo Gmail, Blogger y Analytics. ¿Estás dispuesto/a a darle toda la información sobre ti mismo/a y tu profesión/afición a Google?

Hace un año os contaba mi mala experiencia con las últimas betas y release candidates de Asp.net Ajax, conocido anteriormente como codename Atlas. Pues bien, la versión definitiva, aunque planteaba sustanciales mejoras en estabilidad, usabilidad y consistencia con respecto a las betas, seguía conteniendo los mismos defectos de éstas:

Excesivo tamaño y excesivo número de los archivos a descargar por el navegador, lo cuál se traduce en una lentitud manifiesta a la hora de cargar toda la página. Si a esto le unimos el factor de tener un alojamiento compartido que no destaque precisamente por su velocidad de conexión o, en el otro lado, una conexión lenta (RDSI o módem) o saturada, acabaremos con la paciencia de nuestros valiosos visitantes, quienes probablemente se acabarán yendo a otro sitio de la competencia por aburrimiento, por mucha interactividad y vistosas animaciones que hayamos incorporado a nuestra web.

La causa de esta lentitud, como hemos avanzado antes, se debe a que Asp.Net Ajax genera de dos a tres archivos javascript, los cuáles son, incluso aunque se autocomprimen con Gzip, gigantes incluso para las conexiones de hoy día: 80kb el más grande. A ésto debemos añadir que cada carga individual de archivo produce una ligera latencia, provocándose en el navegador la sensación de que el navegador “descansa” un instante entre cada archivo descargado. Por otro lado, si probamos el proyecto en local, nos dará la falsa sensación de una gran velocidad, debido a que la carga directa desde el disco es muchísimo más rápida que cualquier red de datos, no está sujeta a las mismas saturaciones y la latencia es mínima.

De ahí el asombro de los desarrolladores cuando tras probar con gran éxito y rapidez la aplicación en nuestro querido localhost, desesperamos de lentitud al probarla por primera vez en nuestro servidor de producción con una conexión a Internet real. Las siguientes cargas son más rápidas debido a qu los archivitos gigantes de javascript son almacenados en la caché de nuestro navegador para no tener que descargarlos de la web cada vez. Sin embargo, esto no es solución puesto que ya sabemos que en la web, muchas veces la primera impresión es la que queda y algunos usuarios no tendrán paciencia suficiente para permitir la carga completa.

Si agregamos las funcionalidades adicionales que nos brinda el Microsoft Ajax Control Toolkit, nos saldrá hasta barba de esperar a que cargue la página. Esos estupendos controles facilísimos de utilizar y en algunos casos espectaculares (dropdowns que se autocompletan, animaciones, capas, etc.) nos saldrán, valga la redundancia, espectacularmente caros en cuanto a recursos de red consumidos y tiempo de espera. Incluso con la última novedad que une en un solo archivo todos los necesarios para el Control Toolkit que utilicemos, aunque no une por desgracia la funcionalidad básica, no servirá de mucho. Apenas alivia un poco las latencias.

Como en muchas otras ocasiones, Microsoft tiene el mérito de consiguir lo mismo que otros fabricantes al precio de únicamente requerir el doble de memoria y procesador y ofreciendo un producto que es al final apenas tres ó cuatro veces el tamaño de los de la competencia (sarcasmo).

No puedo menos que cerrar el artículo recomendándoos alternativas mucho más ligeras que la de Microsoft para el mismo marco de trabajo de Asp.Net.

La primera de ellas es Athem.net. Hablaré en detalle de esta magnífica librería en otra ocasión pero simplemente deciros que (al menos a mí) me parece tan fácil de usar como la de MS pero generando unos archivos muchísimo más pequeños y teniendo un rendimiento muy superior. También conviene echar un vistazo a JQuery, si bien no es específica de .Net sino multiplataforma y extremadamente útil y ligera.

(Viene de http://carlinux.com.es/[…]-cancela-cuentas.html)

En primer lugar, algunos de los que se quejan en los foros de la cancelación no cuentan toda la verdad sobre sus cuentas. Cuando les tiras un poco de la lengua, descubres que muchos han hecho click en sus anuncios alguna vez o han pedido a algún(os) familiar(es) o amigo(s) que hagan click, lo cuál está terminantemente prohibido por las condiciones de servicio. Google tiene métodos de inteligencia artificial que reconoce patrones de comportamiento de los usuarios con los anuncios, con lo que estas acciones suelen ser detectadas y penalizadas.

Por otro lado, muchos usuarios contravienen las normas incluyendo Adsense en páginas que no están permitidas por las condiciones de uso, otros incitan al click con letreros como “ayuda a mi sitio” o cosas peores y algunos integran tanto los anuncios con el contenido que es prácticamente imposible distinguirlos. Todo esto está prohibido y aun así, muchos se saltan la norma, hasta que llega la sorpresa… Aunque otros tantos, infringen las normas de continuo y no les ocurre nada. Aun así, es demasiado arriesgado. Hay que jugar según las reglas.

En estos casos anteriores, la expulsión del sistema es justa y favorece a aquellos que siguen las normas, quienes hacen un esfuerzo superior y no tienen ya que compartir su trozo del pastel publicitario con los tramposos.

(Concluye en http://carlinux.com.es/[…]cuentas-parte-3-y-ultima.html)