PanelR

Ricardo Galli, nos muestra su 'frustación' por no haber podido sacar adelante su último vaporware.
Lo hizo con python y Google App Engine.

Gracias a su post llego a friendfeed y stackoverflow (guapo el diseño...).

Sobre Search Engines

Estoy un poco frustrado...
Que poca documentación hay sobre search-engines en general....
Es un campo como con un poco de oscurantismo.
Si ni siquiera la wikipedia tiene tablas comparativas de productos... hay que ver.
Si siquiera los listados estan completos.

La verdad... hacer cualquier cosa en este campo... lleva un coste de entrada alto... Precisamente por esta falta de documentación en general.

Mi experiencia hasta ahora sólo ha sido con Fast Data Search, y es mi referencia. Por lo que he visto, lo único realmente que se le aproxima sería Nutch. Por lo que así a bote pronto, si la tecnología y/o el lenguaje no es importante creo que la elección actual para montar algo debería ser Nutch.

Nutch viene con todo lo necesario: indexador, buscador y crawler. Pero ademas, permite ampliar el core, mediante pluggings. Algo fundamental...
Y algún producto adicional alrededor, como Solr.
Por todo ello es el candidato número uno a considerar.

El problema es si queremos usarlo desde python, ya que si que tenemos pylucene, pero no pyNutch.

Como alternativa a indexar/buscar de lucene tenemos xapian. Puede que tengamos claro que queremos xapian [un articulo] en lugar de lucene, por alguna característica diferenciadora del primero (de nuevo hecho en falta una tabla comparativa).
Si queremos montarnos un framework en python, con xapian puede que lo tengamos más fácil, pero será mucho mas curro que con Java.

Tenemos dos alternativas... sumarnos a la corriente y tirar por nutch, o montar una alternativa con python.
Incluso si tomamos la opción de la alternativa, todavía nos quedaría la decisión de decidir que indexador usar (pylucene o xapian) y que crawler.

A la hora de decidir que indexador usar ahí van unos enlaces (hay muy poca información de comparativas):

• una tablita
• Comparing Open Source Indexers. En este enlace no está ninguno de los dos de nuestro interés, pero muestra otras cosas existentes.
• El mejor: Search Engine Comparison. Sale muy bien parado Lucene.
• xapian vs lucene

¿Y nadie se ha planteado esto antes? Pues claro que si. De hecho ahí comentar un par de productos Lupy (ya extinto) y nucular.

Ya para acabar...
Meter unas notas sobre que mas cosas hay por ahí y que no considero.
En primer lugar referenciar la cutre pagina de la wikipedia, y otra mucho mejor.
Y unas cuantas search engines adicionales:

• sphinx: (C++) Es un producto activo. He leido que tinene bindings para python. No he visto que tenga crawler. Tiene pluggins para conectarse a diversas BDs, como MySQL. De hecho parece que es el uso que se le está dando principalmente, a buscar en BDs.
  
• YaCy: tiene un crawler, pero es como un sistema totalmente distribuido. Debe ser una cosa rara.. no he produndizado mas. (C)
• swish-e: No he leido nada en contra del producto. Por lo visto es muy sencillo. Tiene un crawler en perl, que genera datos en formato específico apra swish (C/perl). El crawler no tiene mala pinta... Hasta soporta callbacks. Hay una versión para C++. Refs: [1]. La versión actual tiene un problema gordo, no soporta unicode. Y la indexación no es incremental.
  
• Terrier: Incluye crawler (Java)
• egothor: Incluye crawler (Java)
• Zebra: Viendo el site, se puede apreciar que es un producto de calidad. Muy bien documentado. Parece que su punto diferenciador es que soporta el interfaz Z39.50. No tiene crawler. Creo que sólo soporta texto y XML. (C)
  
• zettair: No he visto que tenga crawler. (C)

Heritrix vs Nutch

Enlazando con el post anterior, ahí va este.
Como ya dije, me llevé una muy buena impresión de Heritrix. Esto unido a que no soy fun de Java, me hizo en un primer momento pensar que Heritrix era el mejor producto... Pero no es el caso...
Como ya he indicado en el post anterior, como almacena Heritrix los datos tiene su pega...
Es por ello que he procedido a buscar en la web comparaciones entre ambos...
En este post, adjunto lo que he encontrado.

De [1] (ojo, del 2005):
"The primary aim of Heritrix is to be an "archival crawler" --
obtaining complete, accurate, deep copies of websites. This
includes getting graphical and other non-textual content.
Resources are stored exactly as they were received -- no
truncation, encoding changes, header changes, etc.


Recrawls of the same URLs do not replace prior crawls in any
sort of running page database.


The focus has usually been dozens to hundreds of chosen
websites, but has begun to shift to tens of thousands or
hundreds of thousands of websites (entire national domains).


Crawls are launched, monitored, and adjusted via a (fairly
complex) web user interface, allowing flexible (and sometimes
downright idiosyncratic) definition of what URLs should be
visited and which should not.


My understanding is that with the Nutch crawler's alternate
aims, some of the things it does differently are:
- only retrieves and saves indexable content
- may truncate or format-shift content as needed
- saves content into a database format optimized for
later indexing; refetches replace older fetches
- run and controlled from a command-line
- emphasizes volume of collection under default conditions,
rather than exact satisfaction of custom parameters


I'm not up-to-date on the Nutch crawler, I could be missing
important features or distinctions.


It'd be nice to converge parts of the crawlers' architectures,
for example to share link-extraction or trap-detection
techniques."

Me preocupa sobre lo que dice que almacena y no nutch. Tengo que hacer pruebas de esto...

De [2] (del 2008):
"Here are a (few) dimensions that may help
with your investigation:

+ The Nutch crawler operates in a stepped, batch fashion. It runs
through a list of generated URLs fetching each individual URL until the
list is done. You then generate the next list to run after running
analysis of the most recent fetch. Heritrix just runs fetching until it
runs out of URLs that fit its defined scope.
+ The Nutch crawler is a MapReduce job. This means that distribution is
just a matter of adding nodes and tasks (Tasks are retried if they fail,
etc.). Heritrix distribution is the divvying up of the crawl-space
outlined above (but from what I've heard, on big crawls folks just don't
bother with the sort-and-insert step reasoning that eventually every
individual crawler will trip over its URLs if its let run long enough).
If a heritrix instance crashes, recovery is manual involving either the
rerunning of a pseudo-crawl 'journal' or revivification using the last
'checkpoint'.
+ Heritrix has more crawling features -- knobs and switches -- than the
crawler in Nutch and it is more 'dogged' about fetching content than
Nutch given its roots in an Archiving organization.

The latter feature you may not want and regards the former, its easy
enough adding whats missing given Nutch is pluggable, open source."

Como indican, la forma de distribuir el trabajo es totalmente diferente.
Voy a terminar el post, con dos graficos que muestran las arquitecturas de ambos crawlers:


Nutch



Heritrix




Notas:

• Consultando el API de Heritrix, puedo comprobar que hay mas de un 'processor' de escritura. Aparte de el de por defecto, ARCWriterProcessor , tenemos: Kw3WriterProcessor, MirrorWriterProcessor, WARCWriterProcessor (este formato parece que no ha pasado de la etapa experimental).
• Si realmente queremos acceder al crawler store desde python, quizás sea mejor opción Heritrix, aunque nos toque hacer un WriterProcessor a medida.
• El siguiente link explica como funciona Heritrix. Tomado del Developer Manual.
  

Open Source Crawlers

Estoy echando un vistazo a ver que que hay disponible Open Source, para crawlear.
Este post es un miniapunte, de lo que seguramente sea un artículo mas largo...

El punto lógico de entrada para mirar... pues la wikipedia.
He intentado encontrar algo mas allá... pero realmente no he encontrado nada interesante.

Sin hacer un análisis muy exhaustivo, os puedo decir que los tres principales candidatos a considerar serían (*1):

• httrack
• nutch
• heritrix

Los dos últimos son java, mientras que el primero creo es C.
nuch, está bien, porque es un producto con bastante apoyo, una documentación posiblemente por encima del resto (por ser de apache).

La alternativa sería hacer nosotros el crawler, pero esto sería una solución sólo a llevar a cabo si no nos queda mas remedio, ya que no es un tema trivial.

nutch
En principio no lo iba a considerar, por no haber entendido correctamente su arquitectura.
Pensaba que no tenía un crawler-store independiente de los indices. Pero no es así.
Si que lo tiene, y al igual que heritrix, en formato comprimido. Son lo que llaman segmentos.
Realemente lo que se almacena son objetos java, serializados y comprimidos.

httrack
El primero ya lo había usado para crawlear sites pequeñitos, pero aquí estamos hablando de usarlo para hacer crawleos potentes, de la web.
Todavía no lo he probado en serio en esta faceta, ya que sólo lo había usado en windows, y como he indicado para hacer crawleos de sites.
Pero el core del crawler es una librería con lo cual siempre vamos a poder acceder a ella desde python (esto siempre lo tengo en el punto de mira ;).

De hecho ya hay un módulo python disponible, httrack-py, que permite implementar ciertos callbacks en python.
Pero si lo que queremos es integrar completamente la librería en python, me temo que no vamos a tener nada disponible... Eso si, siempre podemos hacer nuestros propios bindings; para ello disponemos del código fuente...

El producto la verdad, está bastante documentado.
Ya para acabar indicar que lo que nos interesa realmente, no es la estructura de mirroring que genera el comando (al estilo de wget, vamos...) sino los datos cacheados.
Estos datos estan en unos tar.gz, a los cuales tendremos que acceder a través de una librería ya que directamente casi seguro nos van a dar problemas en la descompresión...

Total... que para poderlo usar algún desarrollo vamos a tener que hacer...

heritrix
El que esté detras de este crawler archive.org, ya es una garantía de que el producto va a estar bien.
La documentación es un poco pobre, pero para lanzar una prueba básica te apañas.
Indicar que tuve problemas para lanzarlo en windows, pero en linux ninguno.
El interfaz para la configuración es web (el crawler corre un servidor web de configuración), y soporta la gestión de crawlers distribuidos.

A la hora de definir el 'job' de crawleo, tenemos muchas opciones a configurar. Es aquí donde la documentación es mas pobre. Seguramente tengamos que recurrir al API java y a la documentación para desarrolladores para ampliar el tema. La de usuario no lo cubre.

Como resultado del crawleo se guardan los documentos en unos archivos ARC, comprimidos. De todo el proceso se van generando datos. Que podemos consultar tando desde el GUI, como desde diferentes archivos.

Con la instalación, se incluye el comando arcreader, que nos permite acceder a los contenidos de los archivos arc.
En la web, se indica que hay readers/writers en python para los archivos ARC, dentro de la herramienta hedaern

Conclusión
No tengo nada claro que producto usar. Es una conclusión inconclusa...
En principio descartgaría httrack, ya que su función es mas limitada. Está mas bien diseñado para crawlear sites, en lugar de la web. Pero es un producto que fácilmente podemos integrar con python.

Con respecto a los otros dos... dificil cuestión. Heritrix, me ha parecido realmente potente.
Tanto por la forma de trabajar como por todos los datos que te ofrece.
En este aspecto me ha llamado mas la atención que nutch. También es posible nutch te muestra esa información, pero de momento no haya accedido a ella, ya que sólo lo he lanzado modo comando.
Quizás el mayor problema de heritrix, es que está orientado a conseguir una imagen de la web en un momento dado. Si recrawleamos, un mismo documento, no va a sustituir a la versión anterior.
Estaría duplicado (*2).

Heritrix tiene una ventaja con respecto a nutch, y es que el formato del crawler-store es tal que podriamos acceder desde cualquier lenguaje. Por el contrario al crawler-store de nutch sólo podemos acceder desde java, ya que lo que se almacenan son objetos java serializados y comprimidos.
Con ambos productos, podemos extraer documentos vía comando.

(*1) Son los que me han parecido mas usables
(*2) al menos con el comportamiento por defecto; y creo que sin defecto, ya que los archivos ARC llevan implicito un timestamp. Para poder decidir si un documento está en un crawler-store o no habría que recorrelos enteros...

Manejando HTML entities

Estoy haciendo un pequeño proyecto personal en python, para lo cual estoy parseando html con BeatifulSoup. Me he decantado por él por los siguientes motivos:

• Probarlo mas a fondo
• No quiero tener dependencias que no sean python (descartado entonces lxml/libxml2)
  
• No necesito la solución más rápida

Sobre BeatifulSoup ya postearé alguna cosilla...
Pero este post va sobre el manejo de entidades de html. Al tratar el texto con BeatifulSoup, no me las transformaba a texto unicode. Por lo que me puse a indagar...
Por lo que he podido ver en el rato que he estado buscando parece que no hay nada en las librerías estándares para pasar entre entidades html y cadenas. Se me hace raro...

Enseguida encuentras que en el módulo htmlentitydefs, que tiene las definiones que necesitas pero no tiene ninguna función que realice el trabajo... Se me hace raro...

Buscando un poco mas encontré un thread, donde proporcionan como hacerlo (vamos..., que no vamos a reinventar la rueda...): Convert from unicode chars to HTML entities [encode][decode].

Pero BeatifulSoup, ya se encarga de ello, si pasas en el constructor el parámetro adecuado.

soup = BeautifulSoup(data,convertEntities=BeautifulStoneSoup.HTML_ENTITIES )

Mas info aquí.

Corriendo Linux en el portatil

Necesito tener disponible un linux... Y las alternativas que tengo son:

• que me den algun usuario en alguna máquina
• utilizar algun hosting (que ya tengo)
  
• instalarme linux (descartado, ya que no puedo permitirme enredar a ese nivel con el portatil; ya me cargué el XP en un par de ocasiones....)
• usar cygwin
• usar vmware

Y la opción ganadora es... vmware. Además tenemos dos versiones que son forfree: vmware player y wmware server.
De momento para lo que yo quiero me bastaría con el wmware player (ya que no necesito más de un SO virtual; si necesitame mas de uno tendría que usar wmware server, o pillar un workstation piratilla; porque no voy a pagar por ello...).

Pasando pagina...

Ayer, viernes 31 fue mi último día de trabajo en el 'proyecto' (averigua) que me ha tenido ocupado unos 3 añitos... Se dice pronto...

Puedo decir, que personalmente ha sido el mas gratificante, a pesar del tiempo que he estado en él. Seguramente podría haber estado otros 3 añitos. ¡Ojo! con esto no quiero decir que no haya habido crisis... que ha habido unas cuantas (en una apuntito estuve de largarme...). Pero ya se sabe... lo malo se olvida y perdura lo bueno. Y lo bueno es que me lo he pasado bien, he tenido unos compañeros geniales y hemos aprendido mucho.

Hasta ahora le mejor experiencia había sido cuando con 2 compañeros desarrollé NQOS en Dycsa.
En parte se repite la historia, aunque de distinta manera. No he logrado ver a ambos sistemas en producción. Con NQOS porque fuimos a parar a otra compañía, como la mayor parte de la empresa (despachados a Indra).

En el caso de averigua, se repite un poco la historia. Un equipo pequeño, y lo dejo antes de que realmente esté en producción. Si es que alguna vez lo llegara a estar...
Y el problema no es del proyecto, que es lo que da mas pena, sino de factores externos, interés en él real, la existencia de enemigos en la casa... en fin... muchas cosas que al final nada tienen que ver con la calidad del producto.
El 'adolestente' que es ahora, no ha tenido una infancia fácil. Nació en la familia de un buscador, y estaba destinado a tener un futuro en esa familia.
Pero la vida da muchas vueltas y antes de llegar a la 'adolescencia' se tuvo que buscar la vida por su cuenta, o perderla... como pasó con el buscador.
Fruto de esas vueltas es que en este momento, no este en un estado mas saludable; pero es lo que tiene la calle... hay que buscarse la vida... y sobrevivir siempre pendiente del enemigo no es fácil... (ni que decir tiene que es mucho mejor criarte arropado en una familia que te quiere y te guía).

No se que será de su futuro, pero no pinta bien. De momento se queda al 'trantran', con un equipo mínimo para subsistir, hasta que decidan darle cerrojazo por completo, o para que se den cuenta de que 'averigua mola'. O mejor... sean capaces de darle uso; en fin...

La verdad... que mal funcionan las empresas españolas. Son de lo peor! No llegan a apostar al 100% con ideas novedosas, no apuestan por la gente, racanean siempre con eso, y luego se gastan la pasta en chorradas, o maquinas que luego no usan; guerras internas, envidias, directores que no valen para lo que hacen,... en fin.. un asco.

Una pena para los que abandonamos el barco ahora, sobre todo para su ideólogo y yo; ya que somos de los que quedabamos, los que sentamos la base de lo que es ahora la criatura (en cuanto arquitectura, que en cuanto a lingüistica hay mucha chicha, y esa no era mi guerra).

Pero por otro lado, se abren nuevo horizontes. ¿Cual será el próximo reto? No espero mucho de la consultora en la que trabajo. ¿Intentará meterme ahora en cualquier gena, con tal de dejar de ser un coste para ella... ?
Si pasas por aqui de vez en cuando, y lees estas lineas y sabes de algo que me pudiera intersar, pues dedirte que estoy en modo 'escuchar ofertas interesantes' ;).

Building Scalable Web Sites

Building Scalable Web Sites, de Cal Henderson, es el libro que me tengo ahora entre manos.
Me quedé con la copla de él, leyendo el blog de kirai, y una dia de estos me dio el pronto y lo pillé en amazon.

Por lo visto los capitulos estrella, son el 8 y sobre todo el 9. Podeis leer críticas sobre él en el link de amazon, o también en slashdot.

El libro está bien escrito y cubre muchos temas de desarrollo web. El código escrito está principalmente en php (pongamos un 95%), pero no importa si no usas php, ya que lo importante no esta en el código...

Aquí podeis acceder a prácticamente todo el contenido del libro.

Desde mi punto de vista (y sin haberlo leido todavía entero) es de lectura recomendable. Pero mejor echar un vistazo a las críticas de amazon y slashdot...

Y unos links para acabar...

• Database War Stories (flickr)
• LAMP