Geek & Roll

Con todo el hype que hubo alrededor de Spotify (por lo menos yo me emocioné y lo sigo usando), nos dimos a la empresa de crear un sitio en el que la gente pudiera poner su código de invitación y que recibiera por e-mail sus datos de acceso sin tener que tomarse la molestia de crear una cuenta.

Por otro lado, si no tenías un código de invitación, hipotéticamente te podíamos dar una cuenta a cambio de un dólar. Sonaba a buen negocio, pero nunca logramos automatizar el proceso que se hacía detrás, por lo que incluso pensamos en cambiar el precio a dos dólares, pero por limitantes con los proxies que contratamos (entre otras cuestiones) no nos fue posible realizar el proyecto; así que, sólo nos resta sacarlo del pecho y desear tener más mañas la próxima vez.

Pantalla de Inicio 1

Pantalla de Inicio 2 (alt)

Pantalla de Error

Son tantas las cosas que se pueden comentar de The Pirate Bay. Tantos datos curiosos y tantas ironias.

Una de las ultimas: cuando decidieron poner un torrent de casi toda su base de datos para que la gente (osease la banda: tu, yo, nosotros) pudiéramos hacer una copia de tan controversial BT tracker.

¿Por que están las autoridades ensañadas con TPB si existen BTJunkie, NosequeNova, y muchos muchos mas?

Al ver que hay tantas copias de la base de datos de TPB, ¿no estaria atoda madre sincronizarlos de alguna manera “a la DNS”?  ¿Contra quien se ensañarian ahora?

Estamos hablando de torrentear los indexes de torrents. Es como cuando entras a un vestidor y que ves un espejo frente al otro. ¡Un pedo fractal! Como googlear “site:google.com google”; o como…

*perdido en el espacio infinito de la 11va dimension*

Últimamente he estado pensando en el principal problema de twitter (aparte de la estabilidad): el ruido. Es dificil separar la información “real” del ruido que llegamos a tener en nuestra timeline de un solo vistazo. Esta es una propuesta pequeñita de mejora:

Una de las principales fuentes de ruido son los hashtags (palabras “marcadas” que se utilizan para ayudar en la búsqueda). Hay gente que termina dedicando incluso más caracteres a los hashtags que al post en si.

Mi propuesta de 15 minutos no implica cambiar el funcionamiento de la publicación de hashtags, sino separarlos (por medio de programación) del contenido del post. Se entiende mejor con un ejemplo (click en las imágenes para ver a tamaño completo):

Este es un tweet normal:

Y este es uno con los hashtags separados del contenido del post.

A mi me parece que la diferencia, aunque en un sólo tweet se ve pequeña, sería de gran ayuda al leer Twitter por medio del sitio web.

No pretendo que esto llegue hasta twitter (ni que fuera la gran cosa), pero si a alguien le interesa, sería más o menos sencillo de implementar en un userscript de greasemonkey.

Antes de que digan cualquier cosa, si, ya estamos pensando en que cuando aparezca mi sección diga “tweet & roll” en el header.

Biz Stone, co-fundador de Twitter hace un post hoy platicando la nueva funcionalidad para retweets que están a punto de introducir. La idea no es mala, básicamente se trata de esto:

Para retweetear algo que uno de tus contactos publicó, en lugar de repetirlo todo en un tweet anteponiendole RT y luego la mención con @username (notación que por cierto, como casi todo en Twitter fue inventada por la comunidad),  vas a tener un botón  de “Retweet” similar al de menciones (replies). El mensaje en cuestión aparecerá como el original (es decir, sin RT @username al principio), pero con un texto al final aclarando que se trata de un retweet.

Si no se entendió nada, no es culpa solamente de mis habilidades de redacción, sino de la palabra “retweet”.

Mi comentario al respecto es: ojalá al hacer eso, el retweet no aparezca en los timelines de las personas que siguen al que publicó el mensaje originalmente. Eso aminoraría un poco el ruido, el gran problema de Twitter. Ejemplifico:

Supongamos que yo, @axel, sigo a @cesarolea Y a @rafyta. @rafyta hace un tweet que es muy interesante y @cesarolea decide hacerle un retweet. El retweet en cuestión no debería aparecerme a mi, @axel, ya que tuve oportunidad de leer su aparición original. En cambio, para gente que sigue a @cesarolea y no sigue a @rafyta este retweet puede ser de valor.

Prometo que mi próximo post no contendrá neologismos.

¿Comentarios?

El domingo se anunció el cierre de tr.im, un servicio acortador de urls de esos tan utilizados en Twitter, que seguramente tiene cientos de miles, si no es que millones de direcciones en su base de datos. Direcciones que el 31 de diciembre dejarán de funcionar.

Desgraciadamente eso es lo que pasa con servicios que se lanzan para llevarse una tajada del mercado y al final, por la competencia no se la pueden llevar y se van a la tumba con todos los datos de los usuarios. Twitter eligió  a bit.ly como su acortador de URLs “oficial” hace unos meses, y esto es lo que está sacando del mercado a los demás servicios de ese tipo. Seguramente en las semanas próximas caerán algunos más detrás de tr.im, lo que nos deja con millones de enlaces muertos.

Soluciones para que esto no vuelva a pasar:

Utiliza los enlaces “normales” cuando sea posible. Twitter te acorta automáticamente algunos enlaces, pero mientras lo puedas controlar, trata de utilizar los enlaces originales. Claro, esto no nos salva de uno que otro link muerto de vez en cuando, pero ciertamente evita que miles de nuestros enlaces desaparezcan de repente, aunque los destinos en realidad sigan ahi.

Si tienes un dominio y hosting, instala tu propio servicio acortador, y usalo de manera privada. Esto tampoco evita el asunto de los links rotos, pero si algún día tu dominio deja de existir, los únicos enlaces que se pierden son los tuyos. Gran diferencia. @gonzalolopez publicó en Twitter (y con bit.ly :P) un buen link a 7 scripts para crear tu propio acortador de direcciones.

¿No tienes hosting? Google Apps for your Domain ofrece un servicio llamado Google Short URLs. Puedes comprar un dominio o utilizar el que ya tienes, hostearlo (completo o un subdominio) en Google Apps y tener también tu propio servicio listo en un ratito. Puedes ver un ejemplo aquí.

En fin, estas son mis sugerencias. ¿Alguna otra? bienvenidos sean sus comentarios.

UPDATE:

Al parecer las personas detrás de tr.im se arrepintieron, así que el servicio no morirá aún. Toda la información aquí: tr.im resurrected.

Nota: este post ha estado en el tintero por muchísimo tiempo. Originalmente la idea era hacer una demostración funcional utilizando algunos de los sensores con los que trabajaba en la maestría, algo que hubiera sido extremadamente cool.

Pachube es un servicio poco conocido, del que no se ha dicho mucho. No viene de una gran compañía como Google, Apple o Microsoft. La página inicial de Pachube te presenta con un mashup de Google Maps e información obtenida de sensores alrededor del mundo. Cada marca en el mapa representa una fuente de datos, al darle click te muestra la información básica de la fuente de datos y gráficas de cada canal.

Pero el fuerte del servicio no es ese mashup, sino la API que provee para crear y compartir tus propias fuentes de datos, o para consumir datos de otros sensores. Imagina lo siguiente: tienes un cuarto virtual (en Second Life, o Playstation Home, o World of Warcraft, o whatever) y conectas un sensor de luz a tu cuarto. Además, conectas el sensor de luz a tu computadora de tal manera que puedas detectar cuando la luz del cuarto esta encendida o apagada. Después, utilizando Pachube, “conectas” la información del sensor de luz a tu cuarto virtual, de modo que cuando enciendes o apagas la luz de tu cuarto real, se enciende y apaga la luz de tu cuarto virtual. How cool is that?

Bien, puede que el ejemplo sea algo simple. Después de todo, ¿Para qué quiero yo encender o apagar la luz de mi cuarto virtual? Y más aún, ¿Para qué demonios necesito Pachube? Si una vez con la información del sensor en mi computadora, lo más sencillo es utilizarla ¿cierto?

En parte. Lo interesante es que Pachube te proporciona una API para publicar la información de tus sensores. Esta API es muy sencilla de utilizar, tiene una interfaz REST y utiliza varios formatos de datos (XML, JSON, CSV, entre otros). Muy similar a otras APIs REST (como la de Twitter) a la que muchos Web Developers ya estan acostumbrados. Publicar datos de tus sensores, y consumir los datos de los sensores de otros nunca había sido tan sencillo. No solo eso, sino que la API también puede regresar gráficas y feeds RSS para integrar en aplicaciones o sitios Web.

Pachube divide las fuentes de datos en dos tipos: si tienes un sensor y quieres que los datos del sensor se encuentren disponibles a otras personas o sistemas, eso Pachube lo considera una entrada. Si quieres crear visualizaciones o responder a información proveniente de un sensor, eso Pachube lo considera una salida.

¿Y para que lo puedo utilizar?

Por ejemplo:

• Para cambiar el tema o los colores de tu sitio Web dependiendo del clima en tu ciudad. Obteniendo información de una fuente de datos con JavaScript, y cambiando el CSS de los elementos de decoración de tu sitio.
• Para desarrollar un juego que te permita interactuar con componentes del mundo físico
• O para controlar dispositivos de tu casa desde el trabajo, a través de Internet

Como dije, lo realmente novedoso es la manera en la que Pachube hace disponible los datos a través de una API sencilla de utilizar, permitiendo una especie de Twitter para sensores, del que podemos extraer los mensajes de un sensor y reutilizarlos de cualquier manera que se nos ocurra.

El pdf al que linkea la imagen es un release publicado el 1ro. de Abril en el blog the The Pirate Bay. En pocas palabras da la noticia de que Warner Brothers adquiere a TPB por la sospechosa suma de $13.37 billones de dólares.

Día de tontos, ji-ji-ji, ja-ja-ja y nadie le da importancia al asunto. Tres meses depués, despertamos con la noticia: The Pirate Bay será adquirida por más o menos $7.8 millones de dólares y entregará las operaciones del sitio en Agosto de 2009 (a.k.a. el próximo mes). Las acciones de los nuevos dueños, Global Gaming Factory subieron a más del 250% de su valor antes de anunciar la adqiuisición.

No puedo detener la ola de paranoicas elucubraciones, pero ¿será que los vatos de TPB (que iniciara en nuestro querido México) trataron de ablandarnos un poquito por cuestiones de conciencia?

El mejor browser del mundo ya está disponible en versión 3.5 en tu plataforma e idioma preferidos. Es una lástima que no soporte adecuadamente los dominios unicode, como Safari 4, el otro mejor navegador del mundo (cambia según si le preguntas a Steve Jobs o a cualquier geek no-maquero).

Cálenle: http://iñor.com

Firefox 3.5 lo cambia a algo espantoso, pero Safari 4 lo pone tal cual.

HTML 4 is also in direct competition with proprietary technologies, and it’s winning, hands-down. HTML5 is just continuing the battle, because if we don’t keep up, then the proprietary technologies will gain ground.

Hasta hoy, el video en la Web ha sido como foráneo en tierras extrañas. Siempre se ha requerido de “algo más” para agregar video en páginas Web, plugins que embeben un reproductor tradicional al navegador, utilizando codecs propietarios y dependiendo de la correcta instalación de los mismos previamente.

Con la popularidad de sitios como YouTube, en donde se comparte una cantidad impresionante de video, flash se convirtió en el estándar de facto en la Web. Es conveniente, ya que flash se encuentra instalado en una gran parte de los navegadores y su funcionamiento es transparente para el usuario. Basta con visitar una página con video flash , presionar play y listo.

¿El problema? que flash no es un estándar, y es tecnología privativa, de fuente cerrada. Esto representa serios problemas a la Web, más allá de filosóficos. Por mucho tiempo usuarios de GNU/Linux no podían ver videos embebidos con flash en páginas Web debido a que no contaban con flash para su OS. Entre más sitios se subían al vagón de flash, la Web abierta se volvía la Web no tan abierta.

Pero como suele suceder en programas abiertos, la comunidad propuso una solución en forma de una nueva etiqueta: la etiqueta video. La idea es tener una etiqueta, similar a la actual img, utilizada para insertar video. Simple y efectivo. La etiqueta video es posible gracias a que la Web en general es abierta, y busca cuidar esa misma característica al definir de una vez por todas cómo se debe insertar un video sin depender de plugins como flash, o codecs cerrados.

Firefox 3.5 tiene soporte para la etiqueta video, que es incluida en HTML5. Puede insertar un video codificado con ogg (un codec de video libre) en un documento HTML sin necesidad de depender de flash o de que se encuentre instalado algún reproductor en el sistema. Youtube tiene un demo de su sitio funcionando con HTML5, eliminando la dependencia de flash. Seguramente IE, Safari, Chrome, Opera y todos los demás navegadores implementarán HTML5 en sus versiones futuras.

Si deseas saber más de la etiqueta video puedes seguir los siguientes vínculos:

• La sección de la etiqueta video en el draft de HTML5
• Entrada en OSNews sobre la implementación por parte de Mozilla de la etiqueta video
• Entrevista con Ian Hickson, editor del draft de HTML5
• Cómo insertar un video OGG utilizando la etiqueta video

Los usos de lo que se dice en Twitter (por @boynas)

que el 95 porciento valen ve@#$.. y del 5 restante, 3 porciento sirve para empezar investigacion en wikipedia y el otro 2 porciento para empezar un chat con el que escribio el twitt