Algoritmos de Yahoo: Flickr Interestingness™ es un post realmente interesante, que explica en detalle cómo (supuestamente, pues todo es ingeniería inversa y una patente) hace Flickr para dotar de relevancia a las fotos que sube la gente y crear la sección Interesting, que seguro habéis visitado alguna vez y conocéis por lo espectacular de sus fotos.

Dicha selección se realiza automáticamente, en base a una serie de baremos que maneja Flickr, como pueden ser el número de vistias a la foto, desde dónde se ha visitado, el número de meta-datos y la calidad de los mismos, o incluso la cercanía de la foto a la ciudad donde has dicho que resides.

Pero en realidad, lo que nos debería de hacer reflexionar este algoritmo es cómo han resuelto un problema, para mí abierto, que es el de la relevancia social de los contenidos generados por los usuarios, ya sean fotos, enlaces, posts, vídeos, etcétera.

Y es que si por algo se caracteriza esta época de Internet que estamos viviendo es por la cantidad de dicho contenido, que obliga a filtrarlo si queremos seguir teniendo vida social, familiar y laboral. Y ahí está el problema, en filtrar lo relevante de lo menos relevante.

Criterios como:

• número de enlaces entrantes (veces que te han citado)
• número de visitas
• número de comentarios
• tags asociados al contenido
• karma del autor del contenido
• o el reciente sistema de clasificación por votos

no aseguran, para nada, dar en el clavo y asegurarnos la interestingness, pero de momento es con lo que nos podemos conformar.

Por suerte cada escenario plantea unas características inherentes a él diferentes, lo que permite elaborar criterios específicos mucho más precisos.

Por ejemplo, todos conocemos del.icio.us y su sistema de recomendación de URLs a través de tu red social. ¿Qué es relevante para ti? Lo que te recomiendan tus amigos. Nada más.

Por otro lado tenemos digg o <pon aquí tu clon>, que cuanto más populares se hacen, el sistema de votaciones se vuelve más permisivo, y se convierten en medios más genéricos, con lo cuál abarcan más usuarios, pero éstos están más insatisfechos con los contenidos. ¿La solución? Más contenido en portada, con lo cuál volvemos a tener que filtrar el resultado del filtro (votos, en este caso)

Y por último, tenemos la fusión de estos dos conceptos en coRank, como se puede ver en este pequeño gráfico incluído en su web:

Problemas:

• tienes que convencer a tu red social de que lo utilice
• es un concepto que requiere mucha más labor activa por parte del usuario, que la que puede requerir del.icio.us, pues el filtrado va implícito al uso de la herramienta (sino para qué utilizarla, pudiendo utilizar un agregador convencional), con lo cuál el usuario se va a cansar y va a terminar abandonándola
• tiene, además, el peligro de que los primeros siempre serán los primeros, es decir, que los que están ya arriba en el ránking, van a seguir estando por mucho tiempo

Y esto es de lo más nuevo en filtrado colaborativo que se ha hecho últimamente, y la lista de aplicaciones que han fracasado no es corta, precisamente (¿recordáis Rojo?)

Concluyendo: que es un problema difícil, y lo es más, cuanto más se intenta abarcar. Supongo que pronto irán surgiendo nuevas ideas, cada vez más basadas en redes de confianza, pues si al final el uso de internet se está extendiendo tanto éstas cada vez serán más numerosas, y ¿qué mejor forma de que te digan tus "amigos" qué tienes que leer?

Wordpress.com es un popular servicio de hosting de blogs basado en Wordpress y que aloja a casi 700.000 blogs.

Ayer, debido a una pequeña caída del servicio Matt contó algunas características del hardware detrás de este sistema:

• 152 CPUs físicas es decir, no cuenta los doble núcleo integrados
• 511 Gigabytes de RAM
• 174 discos duros que suman varios Terabytes

¿Alguien se aventura a dar un número de servidores aproximado? Como mínimo 100, con una media de 4 Gigabytes de RAM por servidor. Y para ser servidores de aplicaciones ejecutando PHP, con contenido cacheado no está mal. A mí me parece demasiado, incluso.

Pero claro, no tienen porqué estar aprovechados al 100% los servidores.

Zed Shaw, autor de Mongrel, en la lista de correo Deploying Rails:

The current status on Pound and Pen though is they're only good
for small setups at around 3-5 mongrels. I've ran into a few folks who
were trying to push Pound toward 30-40 or more and it was killing them.

Sin Pen / Pound, el balanceo entre servidor web y servidor de aplicaciones cuando en éste último hay mongrels funcionando se está quedando sin alternativas:

• lighttpd: su mod_proxy está muy poco recomendado, ya que ha dejado de desarrollarse y da problemas con algunos tipos de balanceo, como el round-robin
• apache 2: apache vuelve a estar en boca de todos gracias a Mongrel, y es que su mod_proxy sí que funciona bastante bien, por lo que dices
• nginx: el gran desconocido y el más peculiar de todos, que tan de moda se ha puesto, y que también parece que funciona muy bien

Nosotros, para hacer funcionar The-Shaker, utilizamos lighttpd + pound + fastcgis, como contaron mis compañeros en la presentación de La Coctelera y The Shaker. Una de tantas combinaciones posibles.

¿Cuál es la tuya?

Desde hace varias semanas, en La Gran Corporación nos hemos acostumbrado a intercambiarnos enlaces a través de del.icio.us, con la maravillosa convención for:amiguito, con la ventaja de ahorrarnos un e-mail, y de hacernos más fácil la incorporación del mismo en nuestra lista de enlaces favoritos.

Además, con las nuevas funcionalidades de red social es mucho más fácil gestionar contactos.

Así que si sois usuarios de del.icio.us y queréis jugar conmigo a intercambiar enlaces mi usuario es ferblape.

Los que tengáis alguna aplicación Rails funcionando en Dreamhost posiblemente tengáis el FastCGI modificado para evitar los repentinos errores 500.

Hoy, sin embargo, he encontrado un plugin que lo sofistica aún un poquito más.

Si no os queréis bajar el plugin podéis modificar vuestro dispatch.fcgi añadiendo las siguientes líneas:

require 'fcgi_handler'

class RailsFCGIHandler
 # Dreamhost: changes TERM signal handling so your site isn't 
 # killed while handling a request
 private
   def busy_exit_handler(signal)
     dispatcher_log :info, "busy: asked to terminate during \ 
       request signal #{signal}, deferring!"
     @when_ready = :exit
   end
   def term_process_request(cgi)
     install_signal_handler('TERM',
       method(:busy_exit_handler).to_proc)
     Dispatcher.dispatch(cgi)
   rescue Exception => e
     raise if SignalException === e
     dispatcher_error(e)
   ensure
     install_signal_handler('TERM', 
       method(:exit_now_handler).to_proc)
   end
   alias_method :process_request, :term_process_request
end

Nota: el título del post es un homenaje a las machine tags de flickr, que tan bien han comentado mis compañeros: manuel, limalimon y otra vez manuel.

Me envía Furilo una entrevista a Stewart Butterfield, co-fundador de Flickr y de la que me gustaría rescatar esta cita:

Web 2.0 means that barriers have been lowered on the Internet and new opportunities to work with real customers are sprouting every day...

...y sigue...

What will make the biggest difference is how businesses react to the changing expectations of customers who have new power online thanks to changing perceptions about the Web.

Y para completar este post sigue por aquí.

Esto es una pregunta al aire:

¿Conocéis alguna herramienta que te diga, dado un dominio (ejemplo: inwebwetrust.net) y una cadena a buscar en Google (i.e. "Blat"):

1. te diga si hay algún resultado para el dominio,
2. y, de ser afirmativo, que te diga en qué posición?

¿Se podría hacer con la API de Google?

O mejor formulado: ¿Google ofrece API para búsquedas?

Si alguien lo sabe le regalamos un sticker para su Shuffle.

Incitado por mamuso.