El final esperado

Capítulo especial (no oficial) de El Correcaminos donde pasa lo que mucha gente estaba esperando.
Al fin y al cabo el Coyote tenía que ganar.

Django o Ruby on Rails?

Preguntandome si me conviene usar rails o django para programar un proyecto web me encontré con este artículo en mundogeek donde hace una comparación de ambos frameworks por categorías, espero que le sirva a quien tenga esta misma duda.

En vaporbase podemos encontrar una comparativa de 45 páginas entre Ruby on Rails y Django, los frameworks de desarrollo web más conocidos para Ruby y Python respectivamente. He resumido las conclusiones del autor, aunque no comparto varios puntos, para aquellos demasiado vagos para leerlo entero.

Comunidad

Ruby on Rails es más popular, debido entre otras cosas a que es open source desde un año antes que Django. Sin embargo, Django está ganando bastante popularidad últimamente. 4 puntos (sobre 5) para Ruby on Rails y 3 para Django.

Lenguaje de programación

Python es mucho más utilizado que Ruby. En occidente Ruby es conocido básicamente debido a Ruby on Rails, mientras que sólo en la web de setuptools se listan más de 10.000 librerías para Python. Según el autor programar en Ruby es más divertido, por lo que concluye dando a ambos 4 puntos.

Concepto del framework

Ambos siguen el patrón MVC (Modelo - Vista - Controlador). RoR tiende a hacer las cosas automágicamente, en Django se prefiere la transparencia en lugar del paternalismo. 4 puntos para Django y 3 para Ruby on Rails.

Instalación / estructura de directorios

Ambos son sencillos de instalar. Ruby on Rails fuerza a utilizar una estructura de directorios predeterminada que no tiene porque funcionar en todos los casos. Django es más flexible. 5 puntos para Django y 4 para Ruby on Rails.

Bases de datos y modelo

Ambos usan ORM, al estilo de, por ejemplo, Hibernate (correspondencias entre clases y tablas de una base de datos relacional). Mientras que en RoR se crea primero la base de datos y la clase modelo inspecciona la tabla para determinar los atributos, en Django se define primero la clase modelo y a partir de esta se crea la tabla o tablas en la base de datos.

Ruby on Rails proporciona alguna herramienta adicional interesante, como la migración del esquema de una base de datos automaticamente usando el comando migration que le sitúa con 4 puntos frente a los 3 de Django.

Redirección y controladores

Las correspondencias entre la URL solicitada y la clase controladora que tratará la petición se listan en ambos casos en archivos de configuración. Django permite utilizar expresiones regulares para definir las URLs. 4 puntos para Django, 3 para Ruby on Rails.

En lo que respecta al desarrollo de los controladores en sí, no existen diferencias significativas que no se traten en otros apartados, por lo que ambos obtienen 3 puntos en este apartado.

Plantillas, formularios

Sin diferencias substanciales. 3 puntos para cada uno en ambos casos.

Administración de los datos y los usuarios

Una de las cosas por las que Django es famoso es por poder generar una interfaz para crear, modificar, borrar y listar items de una clase de objetos del modelo de dominio a partir de la clase. Además también se puede buscar, filtrar y ordenar las listas. El problema es que estas páginas son difíciles de modificar, por lo que si necesitas algo que se salga de lo común tendrás que crear esta interfaz de gestión a mano, como siempre.

Rails permite algo similar a través de plugins, pero la alternativa de Django es algo mejor. La gestión de permisos es muy rudimentaria en ambos casos: 2 puntos para ambos.

De nuevo Django permite administrar usuarios permitiendo crear grupos y posibilitando registrar nuevos usuarios mientras que en Ruby on Rails esta misma funcionalidad se logra a través de plugins. Ambos distan mucho de ser perfectos: 2 puntos.

AJAX

En Ruby on Rails el uso de AJAX está totalmente integrado dentro del framework y encapsulan la funcionalidad de los toolkits prototype y Scrip.aculo.us de forma que se puedan añadir distintos efectos AJAX a las páginas sin necesidad de tocar una sola línea de Javascript.

En Django, por contra, se intenta facilitar el uso de toolkits AJAX, pero no se integra ninguno dentro del framework.

4 puntos para Ruby on Rails, 3 para Django.

Documentación

Ambos cuentan con excelente documentación, aunque la de Ruby on Rails es más abundante dado que actualmente es más conocido. 4 puntos para Ruby on Rails, 3 para Django.

Extensiones

La instalación de plugins en Ruby on Rails es sumamente sencilla, en Django es más manual. Existen muchos más plugins para Ruby on Rails.

4 puntos para Ruby on Rails, 2 para Django.

Ciclo de desarrollo

Ambos cuentan con herramientas de depuración maduras. 3 puntos para ambos.

En Ruby on Rails las baterías de pruebas están más integradas en el ciclo de desarrollo. 4 puntos para Rails, 3 para Django.

Rails facilita más el proceso de despliegue de la aplicación: 4 puntos, frente a los 3 de Django.

Conclusión

Haciendo la media el autor da un 3.18 sobre 5 a Ruby on Rails y un 3.27 a Django en el apartado técnico.

Sin embargo, en lo relacionado con el soporte (comunidad, documentación, extensiones de los usuarios, …) Ruby on Rails se alza como claro vencedor con 3.67 puntos frente a los 2.83 de Django.

En conclusión, las notas finales son de 3.35 para Ruby on Rails y 3.12 para Django.

Esperemos que Django comience a alcanzar la popularidad que se merece y empiecen a cambiar las tornas dentro de poco

Querías actualizar la guia digital de Montevideo?

Lamentablemente no tenemos la nueva versión de este excelente programa. Lo que si tenemos (me enteré gracias al turko) es un hìbrido entre la guia digital y el google maps llamado MontevideoBus.com

MontevideoBus.copm es una nueva guía online mezcla de Google Maps y la famosa Guía Digital de Montevideo. Puedes ver (marcando en el mapa un origen y un destino) que ómnibus te sirven para ese recorrido, también puedes visualizar recorridos de un ómnibus en particular, y posee una herramienta para realizar correcciones en las paradas.

En la parte inferior de la pantalla se encuentra una sección de novedades donde día a día se actualiza con los nuevos recorridos y/o funcionalidades que se van agregando.

Hasta podés seleccionar la cantidad de cuadras que querés caminar desde tu casa a la parada!!

Sinceramente creo que esto es de gran utilidad para los ciudadanos de montevideo que tenemos acceso a una conexión web.

Saludos a los creadores! Felicitaciones!

Naná, sos la mejor

Robado de La Repíublica Digital

Naná inventó y registró dos dispositivos para sexo oral clitoriano y sexo oral anal

El dispositivo consiste en un círculo de silicona con otro concéntrico más pequeño, que es la parte que estará en contacto con la lengua por un lado, y con el ano o el clítoris por el otro. Está hecho el trámite ante el MSP como dispositivo de venta libre y ahora se encara su registro como dipositivo terapéutico.

Julio Guillot |

Patentado. Naná ya tramitó ante el Ministerio de Salud Pública la venta libre de su invento.

Demanda. "El problema que tenían las chicas era el sexo oral, por razones sanitarias".

Durante su convalecencia de una cirugía de cadera, Naná se iluminó y halló la barrera que evita contagios cuando se practica sexo oral. Del mismo modo que Carlos Mendive aprovechó una fractura de fémur para largarse a escribir, Naná se reveló como una ingeniosa inventora como consecuencia de su operación.

En el piso 14 de un céntrico apartamento, me espera Naná con refrescos y refrigerios para mostrarme y hablar de un singular invento del que es autora: una barrera protectora contra todo posible contagio de gérmenes, virus y bacterias ­además de ciertas zoonosis­ hasta hoy muy difícil de evitar cuando se practican variantes de la relación sexual como los contactos bucoclitorianos y bucoanales.

Pero antes de entrar en el tema específico que nos convoca, Naná nos cuenta cómo surgió la idea de este dispositivo profiláctico y toda la peripecia para concretarla.

­Cuando una está tranquila, empieza a rever todo lo que está pendiente. Y fue así que me di cuenta de que el problema que tenían las chicas en mi casa era el sexo oral, por razones sanitarias. Estamos hablando de sexo oral anal y sexo oral clitoriano, prácticas para las que no había medio adecuado de prevención de contagio.

El sexo oral anal hoy por hoy es mucho más común que hace treinta años, cuando yo comencé a trabajar en esto; no hay que olvidar que van surgiendo modas en la relación sexual, se incorporan prácticas nuevas y se abandonan otras. Desde hace un tiempo, el sexo oral anal se practica cada vez con mayor frecuencia, y el cliente puede pedirlo.

­Perdón, Naná, una pequeña aclaración. El cliente que va a tu negocio, ¿pide que la chica le haga sexo oral anal a él, o también pide hacérselo él a ella?

­No, no es recíproco. El cliente quiere que la chica le haga sexo oral anal a él. Ahora, la cosa no es sencilla: hay problemas de olor, hay posibilidad de contagio. Eso hace que para la chica sea penoso tener que soportar el olor, además de la amenaza de contagio de alguna enfermedad al introducir su lengua en el recto del cliente. Para zanjar estos problemas, las chicas se ponían un condón en la lengua, pero eso era muy complicado, al cliente no le gustaba y al final la mayoría de las chicas se negaban a esa práctica.

Pero resulta que las chicas que trabajan en la calle, que están desesperadas por un dinero, lo tenían que hacer porque el cliente les ofrecía un pago extra. Era un problema que teníamos nosotras, porque las chicas de mi casa estaban en condiciones de negarse y de hecho lo hacían. Mucha gente me había planteado el problema: "Che Naná, ¿cómo podemos hacer?... porque fijate que nosotros recurrimos a las chicas que trabajan en el área del sexo para tener relaciones como las queremos tener, pero resulta que las chicas no quieren...".

Yo comprendo que cuando alguien paga, tiene derecho a exigir; pero mis chicas también tienen derecho a negarse. Fijate qué problema. Así que estando convaleciente, una tarde mientras miraba en lontananza, sumida en mis reflexiones, me vino la solución y lo vi como dibujado; fue un momento de inspiración. Agarré un lápiz y lo dibujé como pude.

(Naná me muestra el dispositivo que consiste en un círculo de silicona de cierto espesor en cuyo centro hay otro círculo concéntrico más pequeño y más delgado, que es la parte que estará en contacto con la lengua por un lado y con el ano o el clítoris del otro. Se usa un gel inocuo que se esparce sobre el círculo pequeño de modo de facilitar el desplazamiento de la lengua).

­No olvides que si el clítoris está seco, duele, pero con la lengua no es así, y se logra el orgasmo. En su último libro, Alessandra Rampolla se refiere a estas prácticas que suponen contactos bucoclitorianos y bucoanales, y sostiene que son prácticas sexuales que siempre deben realizarse con protección, y da algunos consejos sobre barreras caseras ya que no existe ningún elemento apropiado para esa función. Te das cuenta que antes de mi invento, no había ningún implemento específico para evitar contagios. Los dos los hemos probado en el negocio y funcionan a la perfección. Mis chicas los tienen a su disposición para cuando el cliente les pide sexo oral. Además, al ser de silicona, son perfectamente lavables y se pueden reutilizar.

--Me surge una duda: el hombre que practica sexo oral clitoriano lo hace para excitar a la mujer; obtiene placer al lograr que la mujer tenga un orgasmo. Pero hay una creencia, que no sé si es cierta o no, de que las prostitutas no se excitan y no gozan.

­Eso es un mito. Son mujeres, no son máquinas, pero eso sí, tienen que actuar, convertirse en actrices. La prostituta desempeña un papel. Tiene que parecer prostituta y sentir eso, esa emoción de la chica que trabaja. Hay muchos mitos, pero cuando a la mujer se le hace lo que se le debe hacer, por supuesto que siente, goza y llega al orgasmo.

­Está claro. Veo que en el otro, el que está previsto para la relación oral anal, el círculo central es un poquito más grande.

­Sí. Pero fijate que en los dos, la superficie que no está en contacto con la lengua es más gruesa para que no se arrolle en la piel; y el centro es más delgado para permitir un movimiento más libre de la lengua y por ende una sensación más plena. En la relación sexual oral anal, la punta de la lengua debe poder penetrar un poquito en la zona donde se encuentran las terminaciones nerviosas. Esto es algo que el hombre ha descubierto no hace mucho y que le da muchísimo placer; suele producir una erección rápidamente. Pero como te decía, las chicas por lo general se negaban porque les daba mucho asco. En una relación sexual que se da por amor, es decir que no es por dinero; en una pareja que se ama, pueden permitirse muchas cosas, pero no cuando hay dinero de por medio.

­Y después de la idea, ¿cómo siguió?

­Me puse a recorrer todos los lugares que me parecían adecuados para fabricar esto. Fui a una fábrica de globos, también fui a Funsa, pero por ahí me di cuenta de que el material no debía ser el látex, como los condones. Fui a dar a una fábrica de caños y tubos para enfermos, confeccionados en silicona. Pero antes de hacer una matriz gestioné la patente de invención, y sólo después de ese trámite, di con la fábrica adecuada, con un ingeniero especializado en el material. Después fue el turno de la gestión ante el MSP; hablé con la ministra, quien reconoció que mi invento era una prevención de salud; el hecho es que al cabo de casi un año, tengo la autorización para venderlo.

A fines de abril pienso convocar a una conferencia de prensa para lanzar el producto, porque mi meta es vender la patente, para lo cual estoy en contacto con Fox & Lapenne, una firma que se encarga de todo eso. La patente de invención ya la pagué para EEUU, Brasil y Argentina.

(En este punto se une a la charla el ingeniero químico Bruno Baselli, contratado por la empresa que fabrica el dispositivo. Es el responsable técnico de la fabricación).

­Hicimos el trámite ante el MSP como dispositivo de venta libre y estamos en la segunda etapa, que es registrarlo como dipositivo terapéutico, para lo cual es preciso observar la reglamentación y hacer ensayos. Si queremos venderlo como dispositivo protector, como barrera contra el sida y otras enfermedades, hay que hacer un estudio que lleva bastante tiempo y verificar que efectivamente impide todo tipo de contagio. O sea que mientras no demostremos que efectivamente previene el sida, será un dispositivo de venta libre. Pero por lo pronto es una barrera higiénica, sanitaria, que por ahora cumple esa función de aislar a las dos personas durante la relación.

Por otra parte, me interesa destacar la importancia de la patente de invención, porque eso quiere decir que el producto fue estudiado por una oficina de patentes y que no hay otro igual que cumpla la misma función.

­Me decía Naná que el material en que está confeccionado permite el lavado y la esterilización.

­Exactamente. La silicona resiste sin alterarse hasta 400 grados centígrados, pero por ahora las autoridades sanitarias uruguayas no quieren que sea reusable.

(Naná vuelve a tomar la palabra)

­Ahora que hablan de la patente, te cuento que tengo dispuesto que los derechos de propiedad intelectual del producto, es decir las regalías como inventora, el porcentaje que me corresponde de lo que se venda en Uruguay sea donado a Salud Pública o a otro organismo. A mí me queda la satisfacción de haber resuelto un problema práctico y contribuido a la promoción de la salud sexual.

Para terminar, me gustaría formular algunos agradecimientos a las personas que me asesoraron y apoyaron desde el principio: mi abogada, la doctora Hebe Martínez Burlé, el ingeniero Bruno Baselli, la ministra de Salud Pública, María Julia Muñoz, que creyó en mí y me facilitó todo lo referente al "tramiterío", y el Estudio Fox y Lapenne, responsable de lo que tiene que ver con el registro de la patente de invención.

Un poco de cultura, ¿cómo funciona google?

Siendo largamente tanto en tamaño como en calidad de resultados el mejor buscador de la red es hora de analizar como funciona Google. En esta nota analizamos el funcionamiento del motor, algoritmos y estructuras de datos utilizadas. Esta es una edicion revisada del articulo corregida por Ricardo Galli a quien le agradecemos enormemente

Como funciona Google
Richie Adler (Exclusivo de Maldita Internet)
Corregido por Ricardo Galli

Anatomia del sistema

En la siguiente figura se muestra un esquema general de la arquitectura del sistema:

Descripcion general

El motor de indexación de Google esta implementado en C/C++ por razones de eficiencia y puede correr tanto sobre Solaris como sobre Linux. En Google, el proceso de exploración (descargar las páginas a indexar) es realizado por varios exploradores distribuidos. Existe un proceso URLserver que envía listas de URLs a ser descargados a los exploradores. Las páginas que son descargadas son enviadas luego al storeserver. El storeserver comprime y guarda las páginas en un repositorio. Toda página tiene asociado un ID denominado docID que es asignado cada vez que un nuevo URL es interpretado desde una página. La función de indexación es llevada a cabo por un proceso indexador y un clasificador. El indexador lleva a cabo varias funciones: Lee el repositorio, descomprime los documentos y los interpreta, cada documento es convertido en un conjunto de ocurrencias de palabras llamadas hits o aciertos. Cada acierto registra la palabra, posición en el documento y una aproximación del tamaño de la fuente y si está o no en mayúsculas. El indexador distribuye estos aciertos en una serie de “barriles” (barrels) creando un índice. Además, el indexador interpreta todos los enlaces en cada página y guarda información importante sobre los mismos en un archivo llamado anchors, este archivo contiene información suficiente sobre origen y el destino del enlace, y cual es el texto del mismo.

El URLresolver lee registros del archivo de enlaces y convierte URLs relativos en URLs absolutos (por ejemplo si el enlace es desde http://foo.bar/index.htm hacia images/bar.gif el URL absoluto es http://foo.bar/images/bar.gif). Luego convierte los URLs absolutos en docIDs. Pasa el texto del enlace al índice y los asocia con el docID apuntado por el enlace. También genera una base de enlaces que son simplemente pares de docIDs de la forma “desde-hasta”. La base de enlaces es luego usada por el algoritmo de PageRanking para determinar la importancia de cada documento.

El proceso clasificador toma los barrels que están ordenados por docId y los reordena por wordID para generar un índice invertido. Esto es realizado en el mismo lugar para ahorrar espacio auxiliar. El clasificador produce también una lista de wordIDs y desplazamientos al índice invertido. Un programa denominado DumpLexicon toma la lista junto con el léxico producido por el indexador y genera un nuevo léxico para ser usado por el buscador. El buscador es invocado por el servidor web y usa el léxico construido por DumpLexicon junto con el índice invertido y los PageRanks para resolver las búsquedas.

Estructuras de datos

Las estructuras de datos de Google están optimizadas de forma tal que enormes colecciones de documentos puedan ser exploradas, indexadas y buscadas con poco o casi ningún costo.

BigFiles

Un BigFile es un archivo que puede ocupar varios sistemas de ficheros y que se puede direccionar por un desplazamiento de 64 bits, la distribución del archivo en múltiples sistemas de ficheros es manejada automáticamente por la biblioteca de Bigfiles. La biblioteca da al programador una interfaz abstracta que permite manejar los BigFiles como si fueran archivos comunes encargándose de todo el proceso interno necesario para almacenar archivos inmensos.

Repositorio

El repositorio contiene el HTML completo de cada página. Cada página es comprimida usando Zlib. En el repositorio, los documentos se almacenan comprimidos uno a continuación del otro en un archivo secuencial simple y esta prefijados por el docId, longitud y URL como puede verse en la figura 2. El repositorio no requiere otras estructuras para ser usado y accedido. Esto ayuda a darle consistencia al sistema ya que todo el motor de Google y toda la base pueden reconstruirse únicamente a partir del repositorio. Así mismo, el repositorio permite que toda página devuelta por el buscador luego de una consulta pueda ser mostrada al usuario aunque ya no esté disponible en línea. Esto se logra con la opción cached-page del buscador, sumamente útil para sitios antiguos que ya no están, o fueron actualizados, o incluso para los que están fuera de línea en el momento de hacer la consulta.

Document Index

El document index guarda información sobre cada documento. Es un archivo secuencial indexado ISAM ordenado por docID. La información almacenada en cada entrada incluye el estado del documento, una referencia al documento dentro del repositorio, un checksum y varias estadísticas. Si el documento que ha sido explorado contiene también un puntero a un archivo de tamaño variable llamado docinfo que contiene el URL y el título del documento. En el caso contrario, el puntero apunta al URLlist que contiene sólo el URL. Adicionalmente, existe un archivo que es usado para traducir URLs en docIDs, es una lista de URL checksums con sus correspondientes docIds y está ordenada por checksum. Para encontrar el docId de un URL especifico se calcula el checksum del URL y luego se hace una búsqueda binaria dentro de este archivo para encontrar el docID que corresponda al checksum. Los URLs puede ser convertidos en docIDs en lotes haciendo un refundido con este archivo. Esta técnica es usada por el URLresolver para convertir URLs en docIDs. Este modo lotes de actualización es crucial en cuanto a la eficiencia del sistema.

Lexico

El léxico tiene varios formatos diferentes. Un cambio importante es que el léxico puede manejarse en memoria a un precio razonable. El léxico consta de 14 millones de palabras y esta implementado en 2 partes. Una lista de palabras concatenadas entre sí y separadas por NULLs, Y una tabla de hash (dispersión) de punteros. Para varias funciones adicionales, la lista de palabras tiene alguna información auxiliar que esta mas allá del nivel de explicación de este informe.

Hit Lists

Las hit lists (lista de aciertos) es una lista con las ocurrencias de una determinada palabra en un documento en particular incluyendo la posición, fuente y si está o no en mayúsculas. Las hit lists ocupan la mayoría del espacio necesario para los índices, por tal razón deben almacenarse en forma eficiente. Los detalles de codificación de las hit lists se muestran en la siguiente figura:

Este formato de codificación usa dos bytes por cada hit. Hay dos tipos de hits, fancy-hits y plain-hits. Fancy-hits son aquellos que ocurren dentro de una URL, titulo, anchor o meta-tag. Plain-hits son todos los demás. Un plain-hit consiste en un bit que indica si la palabra esta en mayúsculas o minúsculas, tamaño de la fuente y 12 bits para la posición de la palabra en el documento. Todas las posiciones mayores a 4095 se rotulan 4096. El tamaño de la fuente se representa en forma relativa al resto del documento usando 3 bits. Solo 3 valores se usan porque 111 representa un fancy-hit. Un fancy-hit almacena el bit de mayúsculas/minúsculas, el tamaño de la fuente fijada en 111, 4 bits para indicar el tipo de fancy-hit y 8 bits para la posición del mismo. Para enlaces, los 8 bits de posición se separan en 4 bits de posición dentro del texto del anchor y 4 bits para un clave (hash) del docId del documento en el cual esta el enlace.

La longitud de cada hit-list es alamcenada antes de la lista misma.

El índice

El índice sin invertir está en realidad parcialmente ordenado. Está distribuido en barrels (se usan 64 barrels). Cada barrel guarda un rango de wordIDs. Si un documento contiene palabras que corresponden a un determinado barrel, los docIds son registrados en el barrel seguidos de una lista de wordIDs con hit-lists que corresponden a dichas palabras. Este esquema requiere un poco mas de espacio al duplicar los docIDs, pero la diferencia es muy chica por un numero razonable de buckets y salva mucho tiempo y complejidad de programación en la fase final de indexación.

El índice invertido

El índice invertido consiste en los mismos barrels que el índice pero ya procesado por el clasificador. Para cada wordId válido, el léxico contiene un puntero al barrel correspondiente a la palabra. El puntero apunta a una lista de docIDs junto con sus correspondientes hit-lists. Esta lista representa las ocurrencias de la palabra en todos los documentos indexados.

Procesos

Exploración (crawling)

Ejecutar los web exploradores es un proceso complejo. Hay asuntos altamente intrincados referidos al rendimiento y confiabilidad de los procesos y hasta existen problemas sociales involucrados. El proceso de exploración es sin dudas la más frágil de las aplicaciones ya que implica interactuar con cientos de miles de servidores web y servidores de nombre que están mas allá del campo de control del sistema. Para escalar a miles de millones de páginas, Google usa un sistema veloz de exploración distribuido. Un solo URLserver sirve listas de URLs a un numero de exploradores (típicamente 3). Tanto el URLserver como los exploradores están implementados en Python. Cada explorador abre unas 300 conexiones HTTP simultáneamente, esto es necesario para poder bajar páginas a un ritmo razonable. En momentos pico el sistema puede descargar 100 páginas por segundo usando 4 exploradores. Esto implica unos 600KBytes por segundo de datos. Un punto mayor de estrés es el DNS lookup, cada explorador mantiene su propio cache de DNS de forma tal de no tener que hacer un DNS lookup antes de explorar cada documento. Cada una de las cientos de conexiones puede estar en un determinado estado: looking up DNS, conectándose al servidor, enviando solicitud o recibiendo respuesta. Estos factores hacen del explorador un componente complejo en el sistema. Se usa IO asincrónica para manejar eventos y un numero de colas para mover las URLs solicitados de un estado a otro.

Los exploradores utilizados por Google respetan estrictamente el protocolo “robots.txt” para exclusión de robots en algunos sitios y, además, esperan 1 segundo entre conexión y conexión para un mismo servidor web de forma tal de no alterar significativamente el rendimiento de los mismos.

Indexación

Lo primero necesario para indexar páginas web es interpretarlas. El proceso de interpretación debe contemplar un gran, enorme, numero de posibles errores que varían desde errores en etiquetas HTML, miles de ceros en medio de un tag, caracteres no-ASCII, etiquetas mal anidadas y no cerradas, etiquetas anidados en forma casi infinita y gran variedad de otros errores. Para maximizar la velocidad Google usa flex para generar un analizador léxico que se alimenta con su propia pila. El desarrollo de este intérprete, que debe correr a una velocidad razonable y ser muy robusto, involucra gran cantidad de trabajo. Una vez interpretado cada documento es codificado en los barrels. Cada palabra es convertida en un Word-Id usando una tabla de hashing mantenida en memoria, o sea, el léxico. Nuevos agregados a la tabla de hashing del léxico son registrados en un archivo. Una vez que las palabras son convertidas en wordIDs sus ocurrencias en el documento son traducidas a hit-lists y son almacenadas en los barrels. La mayor dificultad con la paralelización de la fase de indexado es que el léxico debe compartirse. En lugar de compartir el léxico, Google escribe un registro de todas las palabras extras que no están en el léxico base que se fijó en 14 millones de palabras. De esta forma múltiples indexadores pueden ejecutarse en paralelo y luego el archivo de registro puede ser procesado por el último indexador.

Para generar el índice invertido, el indexador toma cada uno de los barrels ordenándolo por wordID para producir un barrel invertido. El proceso de ordenamiento también es paralelizado para usar tantas máquinas como se pueda simplemente corriendo múltiples ordenadores que pueden procesar diferentes buckets al mismo tiempo. Dado que los barrels no caben en memoria, el clasificador los subdivide en baskets ordenando cada basket en memoria y volcando el contenido combinado al barrel.

Búsqueda (Searching)

El objetivo del proceso de búsqueda es proveer una búsqueda de calidad y eficiente. Muchos de los grandes buscadores comerciales han hecho grandes progresos en cuanto a la eficiencia, por lo que Google se ha concentrado en proveer calidad en los resultados. El proceso de consultas de Google involucra 4 pasos: interpretar la consulta, convertir palabras en wordIDs, buscar el principio de la doclist en el barrel que corresponde a cada palabra. Buscar en los doclists hasta que se encuentre un documento que contiene todos los términos buscados y finalmente computar el orden (ranking) correspondiente de cada documento.

El sistema de ranking

Para ordenar documentos (decidir su importancia respecto de una consulta) Google utiliza un algoritmo propio denominado PageRank. El algoritmo de PageRank está basado en el grafo de enlaces de la web que como tal es un recurso sumamente importante y largamente ignorado en la mayoría de los buscadores. Google dispone de tablas con miles de millones de enlaces de la forma (docID desde-docID hasta), lo cual constituye una buena representación de la web como un grafo de enlaces.

El concepto básico del algoritmo PageRank es que una página es más importante en la medida en que mas páginas apuntan hacia ella. El algoritmo de PageRank extiende este concepto computando no solamente la cantidad de enlaces, sino también normalizando de acuerdo a la cantidad de enlaces en una página, y propagando infinitamente de forma tal que la importancia de una página depende de: cuantas páginas apuntan a ella, de la cantidad de enlaces en estas páginas, y de cuantas y que tan importantes son las páginas que apuntan a las que apuntan a la página. El algoritmo se resume así:

Asumimos que una página "A" tiene páginas T1..Tn que la apuntan. El parámetro d es un parámetro probabilístico que vale entre 0 y 1. Google usa d=0.85. Se define C(A) como la cantidad de enlaces que salen de la página (A). El PageRank de A se calcula como PR(A)=(1-d)+d(PR(T1)/C(T1)+ ... + PR(Tn)/C(Tn))

Notar que los PageRanks forman una distribución probabilística sobre las páginas, la suma de los PageRanks de todas las páginas da 1. El PageRank de una página puede calcularse usando un simple algoritmo iterativo, el PageRank de 26 millones de páginas se puede calcular en pocas horas en una maquina modesta. Dadas n páginas se comienza con PR(Ai)=1/n y luego simplemente se corren x pasadas del algoritmo que calcula el PageRank de cada página hasta que los valores se estabilizan, esta es una técnica comúnmente usada en algoritmia para simplificar algoritmos recursivos.

Justificación intuitiva

El método de PageRank puede verse como un modelo del comportamiento del usuario. Supongamos que tenemos a un navegador aleatorio (random surfer) que dada una página aleatoria elige enlaces y clickea sin usar el botón back, pero eventualmente se aburre y comienza desde otra página aleatoria. ¡La probabilidad de que el visitante llegue a una página es su PageRank!. Y el valor d es la probabilidad de que en una página dada el visitante se aburra y empiece de nuevo desde otra página.

Conclusiones

Google esta diseñado para ser una herramienta de búsqueda escalable eficiente y con un sistema altamente avanzado de ranking de páginas. El uso del algoritmo de PageRank le da una gran calidad a los resultados de búsquedas “comunes”, la enorme cantidad de datos, de lejos la colección mas grande de páginas web del mundo, le permiten resolver eficazmente búsquedas “difíciles” mientras que el repositorio de páginas asegura que los resultados devueltos pueden ser accedidos y consultados por el usuario siendo a su vez de enorme valor como una colección histórica de los documentos en la web.

Una anciana surcoreana se presentará por 772 vez al examen de conducir

Seúl, 5 feb (EFE).- Una mujer surcoreana de 68 años se presentará esta semana al examen teórico de conducir por 772 vez, tras haber suspendido la última prueba este lunes, informan hoy medios de Corea del Sur.

Según el diario Joongang Ilbo, la anciana, identificada por su apellido Cha y residente en la ciudad sureña de Wanju, suspendió hace tres días el último examen desde que se presentó por primera vez a esta prueba en abril del 2005.

Al examen teórico, un test de 40 preguntas, se pueden presentar los surcoreanos una vez al día y los resultados se conocen de forma instantánea.

La anciana obtuvo una calificación entre 30 y 50 puntos cuando el aprobado en el examen se sitúa en 60 puntos.

Hasta ahora la anciana se ha gastado cerca de 3.000 dólares tras presentarse prácticamente todos los días de la semana, salvo festivos y fines de semana.

Un inspector de tráfico aseguró al diario que la anciana mantiene su firme voluntad de obtener el carné, pese a sus constantes fracasos, pues lo necesita para su trabajo, la venta de productos.

Concierto por la Paz y la Tolerancia en febrero

Desde el 12 al 17 de febrero de 2009 se llevará a cabo el Concierto por la Paz y la Tolerancia. Durante los seis días se presentarán distintas bandas y artistas nacionales e internacionales de renombre que tocarán para el público en La Rambla de Punta Carretas.

El jueves 12 será la apertura oficial del Concierto y arrancará con la presencia de Emil Montgomery – Uruguay – que siempre se ha caracterizado por las increíbles puestas de escena en el marco de su perfil de música New Age. 

Es la segunda vez que se realiza un espectáculo pro la paz y la tolerancia en Uruguay. El primero tuvo lugar en las escalinatas del Palacio Legislativo, en 1995, y fue considerado el mayor espectáculo de la historia del país. Montgomery ya se había presentado en esa primera edición y vuelve a hacerlo varios años después. 

Venta de tickets y abonos a partir del jueves 18 de diciembre, 30% de descuento por tiempo limitado en locales Abitad de todo el país. 
  
Cronograma de presentaciones

Jueves 12 (Apertura oficial)
Emil Montgomery (Uruguay)

Viernes 13 
Los Fabulosos Cadillas (Argentina)
Gabriel O Pensador (Brasil)
Las Pelotas (Argentina)
Auténticos Decadentes (Argentina)
Vox Dei (Argentina)
Buitres (Uruguay)
Leonardo (Brasil)

Sábado 14 
Café Tacaba (México)
Jota Quest (Brasil)
Fabiana Cantilo (Argentina)
Kevin Johansen (Argentina)
Hilda Lizarazu (Argentina)
Virus (Argentina)
El Bahiano (Argentina)
La Dulce (Uruguay)

Domingo 15
Daniela Mercury (Brasil)
Molotov (México)
Los Pericos (Argentina)
Rescate (Argentina)
Los Rancheros (Argentina)
La Tabaré (Uruguay)
Daniel Drexler (Uruguay)
La Trampa (Uruguay)
Lunes 16
Paralamas (Brasil)
Miranda (Argentina)
Alejandro Lerner (Argentina)
Frejat (Brasil)
Los Cafres (Los Cafres)
Arbol (Argentina)
Kananga (Argentina)
Chala Madre (Uruguay)
Triple Nelson (Uruguay)
Jaime Roos (Uruguay)
Mónica Navarro (Uruguay)

Martes 17
Deep Purple (Inglaterra)
Catupecu Machu (Argentina)
Intoxicados (Argentina)
Ratones Paranoicos (Argentina)
Bersuit (Argentina)
Ruben Rada (Uruguay)
Trotsky Vengaran (Uruguay)
Rey Toro (Uruguay)
Martín Buscaglia (Uruguay)

Fuente: espectador.com.uy