<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comentarios en: Nuevo buscador</title>
	<atom:link href="http://blog.meneame.net/2007/12/11/nuevo-buscador/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/</link>
	<description>blog oficial</description>
	<lastBuildDate>Sun, 27 Dec 2009 20:29:03 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Por: posavasos</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14584</link>
		<dc:creator>posavasos</dc:creator>
		<pubDate>Fri, 14 Dec 2007 13:36:04 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14584</guid>
		<description>Estoy de acuerdo con ashacz en que estaría muy bien tener un formulario con el que acotar las búsquedas como con los prefijos. Aunque yo creo que lo mostraría desde el primer momento y no como un &quot;buscador avanzado&quot;.

O sea, una vez realizada una búsqueda, mostrar algo asín: http://xs322.xs.to/xs322/07505/mnm-buscador.png

Y si algo así no es buena idea, como mínimo mostrar los prefijos o enlazar al wiki en los resultados de búsqueda de menéame.</description>
		<content:encoded><![CDATA[<p>Estoy de acuerdo con ashacz en que estaría muy bien tener un formulario con el que acotar las búsquedas como con los prefijos. Aunque yo creo que lo mostraría desde el primer momento y no como un &#8220;buscador avanzado&#8221;.</p>
<p>O sea, una vez realizada una búsqueda, mostrar algo asín: <a href="http://xs322.xs.to/xs322/07505/mnm-buscador.png" rel="nofollow">http://xs322.xs.to/xs322/07505/mnm-buscador.png</a></p>
<p>Y si algo así no es buena idea, como mínimo mostrar los prefijos o enlazar al wiki en los resultados de búsqueda de menéame.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: 2piR</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14549</link>
		<dc:creator>2piR</dc:creator>
		<pubDate>Thu, 13 Dec 2007 21:04:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14549</guid>
		<description>Repito lo mismo que en los comentarios de http://meneame.net/story/sonidos-del-espacio-1 . El nuevo buscador deja mucho que desear. No voy a entrar en consideraciones técnicas. Lo digo como usuario que pronto cumplirá un año en esto de Menéame. Espero que el funcionamiento del buscador mejore o que se vuelva al antiguo. A la experiencia me remito. El actual no me hace ninguna gracia ni me merece confianza. Repito a los comentarios de la noticia me remito. Saludos!!</description>
		<content:encoded><![CDATA[<p>Repito lo mismo que en los comentarios de <a href="http://meneame.net/story/sonidos-del-espacio-1" rel="nofollow">http://meneame.net/story/sonidos-del-espacio-1</a> . El nuevo buscador deja mucho que desear. No voy a entrar en consideraciones técnicas. Lo digo como usuario que pronto cumplirá un año en esto de Menéame. Espero que el funcionamiento del buscador mejore o que se vuelva al antiguo. A la experiencia me remito. El actual no me hace ninguna gracia ni me merece confianza. Repito a los comentarios de la noticia me remito. Saludos!!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Bug en el buscador¿</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14537</link>
		<dc:creator>Bug en el buscador¿</dc:creator>
		<pubDate>Thu, 13 Dec 2007 16:03:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14537</guid>
		<description>http://meneame.net/search/c%26</description>
		<content:encoded><![CDATA[<p><a href="http://meneame.net/search/c%26" rel="nofollow">http://meneame.net/search/c%26</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Estimados Larry y Sergei &#171; Ricardo Galli, de software libre</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14499</link>
		<dc:creator>Estimados Larry y Sergei &#171; Ricardo Galli, de software libre</dc:creator>
		<pubDate>Thu, 13 Dec 2007 01:59:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14499</guid>
		<description>[...] a la gente. Desde que Google existe no pueden fallar los buscadores unos pocos minutos ni siquiera durante una migración importante, si no encuentran algún número enseguida escriben un apunte, algún día nos reconocerán el [...]</description>
		<content:encoded><![CDATA[<p>[...] a la gente. Desde que Google existe no pueden fallar los buscadores unos pocos minutos ni siquiera durante una migración importante, si no encuentran algún número enseguida escriben un apunte, algún día nos reconocerán el [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Jose Peso</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14480</link>
		<dc:creator>Jose Peso</dc:creator>
		<pubDate>Wed, 12 Dec 2007 20:26:50 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14480</guid>
		<description>Tienes razón en eso. La actualización automática de los índices es el tema que más nos tiene pendientes del proyecto sphinxsearch a aquellos que lo usamos. Si bien es verdad que en muchos casos es solucionado con sistemas de main+delta en otros hace complicada su actualización. 

Aun así en muchos proyectos han apostado por sphinx a pesar de ese problema, por su capacidad de indizar y buscar contenidos en bases de datos realmente grandes (boardreader, mininova, thepiratebay) a una velocidad muy alta.

Un saludo</description>
		<content:encoded><![CDATA[<p>Tienes razón en eso. La actualización automática de los índices es el tema que más nos tiene pendientes del proyecto sphinxsearch a aquellos que lo usamos. Si bien es verdad que en muchos casos es solucionado con sistemas de main+delta en otros hace complicada su actualización. </p>
<p>Aun así en muchos proyectos han apostado por sphinx a pesar de ese problema, por su capacidad de indizar y buscar contenidos en bases de datos realmente grandes (boardreader, mininova, thepiratebay) a una velocidad muy alta.</p>
<p>Un saludo</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Jokin</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14458</link>
		<dc:creator>Jokin</dc:creator>
		<pubDate>Wed, 12 Dec 2007 09:19:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14458</guid>
		<description>la verdad que yo también lo he usado con mucho exito,  pero creo que tenerlo en la misma maquina que el servidor de bbdd es demasiado. Para que vaya bien es recomendable que tenga bastante memoria libre donde cachear los vectores de cada palabra de forma que no tenga que acceder practicamente a disco. Ademas, si usas el RAMdirectory, te maneja el indice en memoria con lo cual es mucho mas rapido, pero necesitas dedicarle al menos el doble del tamaño del indice en la memoria. 

Yo me inclinaria por utilizar solr. No es mas que una capa de abstraccion y webservices montada encima de lucene. Basta con definir el esquema de tu indice y puedes ponerte a añadir documentos y buscarlos. Ademas tienes una aplicación web para ver el estado del indice, y una serie de utilidades extra que no tiene lucene. (por ejemplo la ordenacion de floats, que es util si quieres filtrar por latitud y longitud.</description>
		<content:encoded><![CDATA[<p>la verdad que yo también lo he usado con mucho exito,  pero creo que tenerlo en la misma maquina que el servidor de bbdd es demasiado. Para que vaya bien es recomendable que tenga bastante memoria libre donde cachear los vectores de cada palabra de forma que no tenga que acceder practicamente a disco. Ademas, si usas el RAMdirectory, te maneja el indice en memoria con lo cual es mucho mas rapido, pero necesitas dedicarle al menos el doble del tamaño del indice en la memoria. </p>
<p>Yo me inclinaria por utilizar solr. No es mas que una capa de abstraccion y webservices montada encima de lucene. Basta con definir el esquema de tu indice y puedes ponerte a añadir documentos y buscarlos. Ademas tienes una aplicación web para ver el estado del indice, y una serie de utilidades extra que no tiene lucene. (por ejemplo la ordenacion de floats, que es util si quieres filtrar por latitud y longitud.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Jonathan</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14452</link>
		<dc:creator>Jonathan</dc:creator>
		<pubDate>Wed, 12 Dec 2007 02:58:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14452</guid>
		<description>Me ha gustado el funcionamiento del nuevo buscador aunado a la documentación, parece que evitará ese conflicto de duplicadas porque los resultados ofrecidos no mostraban la noticia que se iba a menear.</description>
		<content:encoded><![CDATA[<p>Me ha gustado el funcionamiento del nuevo buscador aunado a la documentación, parece que evitará ese conflicto de duplicadas porque los resultados ofrecidos no mostraban la noticia que se iba a menear.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: ashacz</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14450</link>
		<dc:creator>ashacz</dc:creator>
		<pubDate>Wed, 12 Dec 2007 02:21:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14450</guid>
		<description>El artículo en el wiki está muy bien y el buscador me gusta, el de antes si sabias usarlo cumplía pero al usuario de a pie si no le pones las cosas en los morros no las ve.

Los comandos de busqueda los usaremos los cuatro de siempre, el resto pasarán de ellos porque no los conozca.

Quizá sea buena idea crear un formulario para un buscador avanzado, donde marcando casillas el usuario puede acotar la busqueda igual que con los comandos.

Yo dejaría la interfaz como está y al buscar justo antes de los resultados pondría
algo como 

&quot;¿No has encontrado lo que buscabas? Prueba a usar nuestro buscador avanzado&quot;

y un enlace que te lleve a este buscador</description>
		<content:encoded><![CDATA[<p>El artículo en el wiki está muy bien y el buscador me gusta, el de antes si sabias usarlo cumplía pero al usuario de a pie si no le pones las cosas en los morros no las ve.</p>
<p>Los comandos de busqueda los usaremos los cuatro de siempre, el resto pasarán de ellos porque no los conozca.</p>
<p>Quizá sea buena idea crear un formulario para un buscador avanzado, donde marcando casillas el usuario puede acotar la busqueda igual que con los comandos.</p>
<p>Yo dejaría la interfaz como está y al buscar justo antes de los resultados pondría<br />
algo como </p>
<p>&#8220;¿No has encontrado lo que buscabas? Prueba a usar nuestro buscador avanzado&#8221;</p>
<p>y un enlace que te lleve a este buscador</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Esteve</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14436</link>
		<dc:creator>Esteve</dc:creator>
		<pubDate>Tue, 11 Dec 2007 22:51:55 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14436</guid>
		<description>&lt;i&gt;quizás la mayoría de los problemas son del Zend Lucene y no del original. Pero el hecho que no sea cliente-servidor ya tiene una desventaja enorme: carga todos los resultados parciales en memoria y chupa un mogollón para cada script (también CPU),&lt;/i&gt;

Tiene su ventaja, porque te permite crearte tu propio servidor si quieres, por si no te convence incrustar la librería en tu programa. Una ventaja del Lucene original es que puedes meter en cualquier aplicación y voilà, ya tienes full-text search. De todas maneras, en el mundo Java tienes Solr y en Python, por ejemplo NXLucene, que son servidores creados a partir de Lucene y PyLucene respectivamente.

&lt;i&gt;- El consumo de memoria es muy improtante, tienes que definir límites a la cantidad de resultados, pero resulta que lo hace antes del scoring o de busar por los otros términos, por lo que las búsqueda en estos caso es horrible.

- El consumo de memoria no sólo depende del número de resultados máximo que le pongas, si pones frases muy larga (o entre “”) el consumo se dispara una barbaridad.&lt;/i&gt;

¿Qué tipo de directorio tienes puesto? ¿FS o RAM?

&lt;i&gt;- No funcionan los comodines ni búsqueda por rangos en la versión 1.0&lt;/i&gt;

Eso es claramente un fallo de Zend.

En general, parece que el framework de Zend Lucene está un poco en pañales, los fallos que has comentado no están ni en Lucene, CLucene, Ferret o PyLucene (que son lo que he tocado).

Podrías usar la versión de Java o la de Python, la gente de la Wikipedia usa la versión Java y el Mediawiki está hecho en PHP. Si no te quieres complicar la vida, puedes usar los servidores de búsqueda que te he comentado (NXLucene y Solr), conectándolos con Menéame a través del webservice que exponen.</description>
		<content:encoded><![CDATA[<p><i>quizás la mayoría de los problemas son del Zend Lucene y no del original. Pero el hecho que no sea cliente-servidor ya tiene una desventaja enorme: carga todos los resultados parciales en memoria y chupa un mogollón para cada script (también CPU),</i></p>
<p>Tiene su ventaja, porque te permite crearte tu propio servidor si quieres, por si no te convence incrustar la librería en tu programa. Una ventaja del Lucene original es que puedes meter en cualquier aplicación y voilà, ya tienes full-text search. De todas maneras, en el mundo Java tienes Solr y en Python, por ejemplo NXLucene, que son servidores creados a partir de Lucene y PyLucene respectivamente.</p>
<p><i>- El consumo de memoria es muy improtante, tienes que definir límites a la cantidad de resultados, pero resulta que lo hace antes del scoring o de busar por los otros términos, por lo que las búsqueda en estos caso es horrible.</p>
<p>- El consumo de memoria no sólo depende del número de resultados máximo que le pongas, si pones frases muy larga (o entre “”) el consumo se dispara una barbaridad.</i></p>
<p>¿Qué tipo de directorio tienes puesto? ¿FS o RAM?</p>
<p><i>- No funcionan los comodines ni búsqueda por rangos en la versión 1.0</i></p>
<p>Eso es claramente un fallo de Zend.</p>
<p>En general, parece que el framework de Zend Lucene está un poco en pañales, los fallos que has comentado no están ni en Lucene, CLucene, Ferret o PyLucene (que son lo que he tocado).</p>
<p>Podrías usar la versión de Java o la de Python, la gente de la Wikipedia usa la versión Java y el Mediawiki está hecho en PHP. Si no te quieres complicar la vida, puedes usar los servidores de búsqueda que te he comentado (NXLucene y Solr), conectándolos con Menéame a través del webservice que exponen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: gallir</title>
		<link>http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14434</link>
		<dc:creator>gallir</dc:creator>
		<pubDate>Tue, 11 Dec 2007 21:39:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.meneame.net/2007/12/11/nuevo-buscador/#comment-14434</guid>
		<description>Jose Pelo, 
lo que no me ha gustado del Sphinx (estaba a punto de usarlo) es que aunque tienes los &quot;deltas&quot; debes regenerar la bbdd diariamente. Para el menéame eso es mucho. De todas formas lo probaré, proque me he quemado un poco con el Zend Lucene.

Esteve.
quizás la mayoría de los problemas son del Zend Lucene y no del original. Pero el hecho que no sea cliente-servidor ya tiene una desventaja enorme: carga todos los resultados parciales en memoria y chupa un mogollón para cada script (también CPU),

También tiene otros errores importantes:

- Siempre hace un chmod del fichero de lock, por lo que no puedes ejecutar desde otro usuario aunque todos los ficheros sean de lectura/escritura. Es un muy mal rollo, para ejecutar como www-data en la Debian tenía que hacer primero un &quot;sudo -s&quot; y luego como root hacer &quot;sudo www-data php5 script.php&quot;

- El consumo de memoria es muy improtante, tienes que definir límites a la cantidad de resultados, pero resulta que lo hace antes del scoring o de busar por los otros términos, por lo que las búsqueda en estos caso es horrible.

- El consumo de memoria no sólo depende del número de resultados máximo que le pongas, si pones frases muy larga (o entre &quot;&quot;) el consumo se dispara una barbaridad.

- Se hace un lío si no tienes locales con UTF-8 definidos, te obliga a definir uno para usar aunque tengas todo en UTF-8.

- No funcionan los comodines ni búsqueda por rangos en la versión 1.0

- La versión del SVN (la que será 1.1) peta de mala manera por problemas de concurrencia con el fichero de lock.

Y varios más que me volvieron loco...</description>
		<content:encoded><![CDATA[<p>Jose Pelo,<br />
lo que no me ha gustado del Sphinx (estaba a punto de usarlo) es que aunque tienes los &#8220;deltas&#8221; debes regenerar la bbdd diariamente. Para el menéame eso es mucho. De todas formas lo probaré, proque me he quemado un poco con el Zend Lucene.</p>
<p>Esteve.<br />
quizás la mayoría de los problemas son del Zend Lucene y no del original. Pero el hecho que no sea cliente-servidor ya tiene una desventaja enorme: carga todos los resultados parciales en memoria y chupa un mogollón para cada script (también CPU),</p>
<p>También tiene otros errores importantes:</p>
<p>- Siempre hace un chmod del fichero de lock, por lo que no puedes ejecutar desde otro usuario aunque todos los ficheros sean de lectura/escritura. Es un muy mal rollo, para ejecutar como www-data en la Debian tenía que hacer primero un &#8220;sudo -s&#8221; y luego como root hacer &#8220;sudo www-data php5 script.php&#8221;</p>
<p>- El consumo de memoria es muy improtante, tienes que definir límites a la cantidad de resultados, pero resulta que lo hace antes del scoring o de busar por los otros términos, por lo que las búsqueda en estos caso es horrible.</p>
<p>- El consumo de memoria no sólo depende del número de resultados máximo que le pongas, si pones frases muy larga (o entre &#8220;&#8221;) el consumo se dispara una barbaridad.</p>
<p>- Se hace un lío si no tienes locales con UTF-8 definidos, te obliga a definir uno para usar aunque tengas todo en UTF-8.</p>
<p>- No funcionan los comodines ni búsqueda por rangos en la versión 1.0</p>
<p>- La versión del SVN (la que será 1.1) peta de mala manera por problemas de concurrencia con el fichero de lock.</p>
<p>Y varios más que me volvieron loco&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
