Te has hecho esperar desde que empezamos con el reto amistoso, pero oye, ha merecido la pena la espera.

Antes de nada dos cosas: primero es darte las gracias por usar tu tiempo en ayudarnos, y la segunda es darte la enhorabuena por la idea que has tenido, muy interesante e ingeniosa.

Bueno, pues ahora la replica, jejeje, [redobles de tambor]

Carga de las 608 imágenes

Una de las características de TwitterPoster es la aletoriedad del poster, eso quiere decir que las imágenes de 72×72 (5) y las de 48×48 (10) se colocan en posición aleatoria. Por lo que el crear una imagen quita esa aleatoriedad, pero realmente, si la regeneramos cada 10 minutos, tampoco se notaría demasiado. Lo que si pasa es algo que considero muy importante y es la accesibilidad, si deshabilitamos los estilos, en tu versión no se verá ninguna imagen, mientras que en nuestra versión las imágenes de los usuarios siguen viéndose. Quizás en vez de usar un estilo con background se podría usar una imagen como tal y con estilos superponer la tabla con las imágenes, pero de esa forma no se asociarían imágenes a los tuiteros.

También si pensamos en nuevas funcionalidades o posibilidades, ahora existen varias redes (/network/…), por ahora una por continente y una para Benelux, pero en un futuro vete a saber cuantas redes va a haber (¿100? ¿1000?), supongamos que 100 (es que TwitterPoster es la caña y va a crecer cantidad :P), si hay que generar la imagen completa cada 10 minutos por cada uno de las 100 redes, pues puede que nuestros servidores sufran un poco, gd no es una librería demasiado ligera, y bajarse 608 imágenes y componer una imagen completa, puede ser muy costoso. Se podría guardar las imágenes en local en forma de caché, pero desgraciadamente a la gente le da por cambiar sus imágenes, por lo que cada cierto tiempo habrá que renovarlas, que tampoco supone mucho, pero es algo que sobrecargaría más aún los servidores. Si ahora tenemos 36mil usuarios, eso supondría más de 100mil imágenes. TwitterPoster es un proyecto pensado en necesitar pocos recursos, lógicamente no es el proyecto que vaya a darnos millones, por lo que meter mucha pasta en servidores no va a ser demasiado rentable.

Carga por Twitter Callback

Si, deberíamos obtener nosotros el último status de @poster, pero como bien dices, estamos en beta, jeje.

Sobre el multilenguaje, estamos trabajando en ello, la falta de tiempo nos obliga a no darle una alta prioridad, pero desde el inicio, el texto exite para español, inglés y casi en japonés, cambia el idioma de tu navegador y lo podrás comprobar.

Google Analytics

Tienes razón con lo de guardar en local el fichero urchin.js, aunque siendo sinceros, entre la velocidad de respuesta del servidor de Google y el nuestro… pues creo que Google puede ser más rápido.

Contenido comprimido

Si tu comentario es para mejorar el rendimiento en el cliente no se debería usar contenido comprimido mediante gzip, piensa que la información que se manda es poca, no merece la pena comprimirlo, ya que se manda poco y el navegador debe descomprimir lo enviado.

MooTools

Sin comentarios, no soy experto en frameworks de javascript, siempre hago las cosas a \”pelo\”, pero Dani que es nuestro experto en Javascript y diseño, prefiere MooTools, y a mí me parece perfecto, tampoco creo que vaya a haber demasiada diferencia.

Otras cosas

El tema de usar style en las etiquetas ya se resolvió, jeje, cosa de las prisas y culpa de IE, que te vuelve loco y por desesperación usé style, tu no sabes la guerra que me ha dado la transparencia con el IE.

Y no sé si se me escapa algo, pero bueno, de todas formas, muchas gracias por tu tiempo y tus ideas.

Saludos
Luis