Ideas4all es…, bueno mejor que contarlo nosotros aquí lo teneís en un vídeo que hay en su página web:

Enhorabuena a los promotores del proyecto.

Pere Rovira propone un interesante experimento en este post: medir el tráfico que generan en una web las búsquedas por su long-tail de palabras clave. Es decir, dejando a un lado las diez claves que más tráfico generan, calcular el porcentaje de tráfico que atraen el resto de palabras y, en base al resultado, decidir cómo aumentarlo.

¿Porqué? Si pensamos en nuestra web, www.aspgems.com, y simplificamos el experimento, podemos pensar que las tres palabras que más tráfico atraen son aspgems, scrum y saas. Parece difícil pensar en una estrategia que haga que estas tres palabras generen aún más tráfico hacia nuestro site. Pero puede que el tráfico que generen las palabras rubyonrails, asp y menosesmás, siendo poco relevante en la actualidad, se vea incrementado de manera considerable.

Como muestra este ejemplo .
Salud y rocanrol!

Enhorabuena.

• En la RailsConf 2008 han presentado el hasta ahora misterioso proyecto MagLev. Se trata de un intérprete de Ruby basado en la industrial-strengh máquina virtual de Smalltalk Gemstone que promete no sólo velocidades muy superiores a MRI, sino sobre todo un sistema de persitencia de objetos distribuido y transaccional que toda lo blogosfera coincide va a revolucionar el panorama por completo. Hay unos cuantos posts acerca de este tema, por ejemplo éste está bien.
• Como ya se sabía en círculos de desarrollo railero, coincidiendo con la conferencia se ha publicado también una nueva versión de Rails, la 2.1. Éste es el anuncio oficial de David con punteros a blogs y screencasts donde se explican las novedades más sobresalientes.
• Y por si no eran pocas cosas a digerir, acaba de salir la versión 1.8.7 de Ruby. En el mensaje hay punteros interesantes.

Menudo fin de semana.

TuneUp es un plugin que te dice dónde está funcionando con lentitud tu aplicación Ruby On Rails, y es capaz de señalarte las “queries” inadecuadas que has lanzado contra la base de datos. El informe generado se envía a un sitio web para que puedas compartirlo y revisarlo con otros programadores o miembros del equipo (de ahí su denominación “social”).

Visto en TechCrunch.

1. Un espacio de trabajo adecuado para el equipo
2. Ciclos de trabajo cortos
3. Pon el trabajo a prueba (test driven development)

Más en Pymecrunch

Algunos, como Chad Fowler, ya lanzan las campanas y al vuelo, y afirman que “en el plazo de un año, Rubinius será usado en los desarrollos de producción y, a partir de ahí, pronto se convertirá en el estándar de Ruby”.

Muchas de las miradas están puestas ahora en IronRuby, la apuesta de Microsoft en este campo. Parece que ellos también están trabajando en la misma dirección.

Más info en InfoQ y en RubyInside.

Rails Cells: desarrollo orientado a componentes para Rails

El objetivo de Rails Cells es “trasladar las ventajas del desarrollo orientado a componentes a la plataforma de aplicaciones web Ruby on Rails, pero sin los problemas asociados al subsistema propio de Rails”. Una “celda” es una especie de controlador ligero con vistas asociadas. Cells quiere insertarse en la tradición de los WebObjects de Apple y el Seaside de Smalltalk.

• YouTube Architecture
• Amazon Architecture
• Flickr Architecture
• Google Architecture
• PlentyOfFish Architecture

Me llaman la atención dos cosas:

• La predominancia absoluta del software libre en estas plataformas
• Todas son aplicaciones en modo como servicio

Quizás algún día las grandes empresas españolas entenderán que el camnio está claro:

Aplicaciones en modo servicio en grandes datacenters basados en software libre.

Los ingenieros de seguridad ven el mundo de una forma muy diferente al resto de ingenieros. En vez de centrarse en cómo funcionan los sistemas, se centran en cómo esos sistemas fallan; no sólo eso, también tienen que pensar en cómo otros pueden hacer que esos sistemas fallen y, por supuesto, en cómo impedirlo. Y es que la práctica totalidad de las “vulnerabilidades” de software ni siquiera aparecen en las operaciones más comunes. Sólo surgen cuando un “atacante” las aprovecha. Así que los ingenieros de seguridad necesitan pensar como los atacantes.

En ocasiones, la gente sin esta mentalidad cree que puede diseñar productos de seguridad, cuando en realidad no está capacitada. Y los resultados de esta ineficacia se pueden ver en muchos ámbitos: sistemas de encriptación fraudulentos, programas de software, protocolos de Internet, sistemas de votación, tarjetas, sistemas de pago, etc. Muchos de estos sistemas cuentan con un responsable de la seguridad, sí, pero ese responsable simplemente no es capaz de pensar como un “atacante”.