Geek & Roll

El tema caliente de la semana es Google Buzz. Para muchos un quierosertwitter, para otros Twitter como debió ser desde el inicio. ¿Pero que opinan los Geek&Rollers del tema? Veamos:

Axel

No lo he checado porque me enmulé porque no hay en google apps for your domain, pero lo checo y te envío la opinión.

Rafyta

O sea que como no pego el wave a ver si con esta onda se arma?

Boynas

Cuantas veces hemos discutido en twitter y hemos sentido que es molesto para los que siguen nuestro timeline (respeto a los demas en contra de la funcionalidad).
La integracion a otros servicios tanto de fotografias, videos y contenido en general, se me hace menos forzada que la de twitter. Tiene mas features nativos.

Lo mas importante es que es mainstream. No necesito enseñar a un amigo a usarlo, es simple y amigable. A mi me interesa seguir a todo mundo no solo a geeks o a media freaks pesudo-periodistas, que son los que se meten a twitter. Esa es la unica razon por la que tengo FB!
Creo que Buzz es como twitter made right, tiene las threaded comments de FB sin las molestas apps; Sin embargo es ordenado no necesitas brincar de timeline en timeline para seguir una conversacion en la que comento una persona que no conoces.

Buzz esta tapando ese gap. Es lo que debio haber hecho twitter con su red de usuarios hace mucho tiempo.. Es perfectamente un twitter killer. (no mames, hasta rima)

César

Tiene más sentido que Twitter, para mi. Gmail siempre esta abierto en mi navegador. Ahora nomas falta que todos dejen de usar Hotmail y se pasen a Gmail, cosa que no se por qué no ha sucedido todavía. Ah, y que le arreglen eso de que se autorefresca el sitio pero te sigue marcando items no leídos. Y una opción para que cuando leo algo en Buzz, no me aparezca como no leído en la bandeja de entrada de Gmail.

Lo mejor de todo es que, en mi opinión, los clientes exclusivos van a perder relevancia, haciendo mucho más relevantes cosas como lo que está haciendo Ubuntu con su Me Menu y Gwibber. Si todo sale bien, vamos a estar un paso adelante. Eso si, su uso desde el Web siempre va a ser una mejor experiencia, como Google nos tiene acostumbrados.

¿De acuerdo? ¿Desacuerdo? Usen la caja de comentarios. Nos vemos en Buzz.

En el marco del Super Happy Dev House Hermosillo, mi colega y amigo ebobby dio una plática titulada “Why Microsoft is not so evil“, tratando algunos temas sobre economía y la percepción de la gente hacia algunas prácticas comunes dentro y fuera de la industria. Muy interesante la plática por cierto, llena de trivia y datos históricos.

Claro que el tema tocó una fibra sensible. Desgraciadamente no pude alzar la voz (literalmente, estaba afónico) en su momento. Es por eso que decidí responder por este medio al punto que más llamó mi atención: el uso de formatos cerrados como arma de mercado.

La idea es más o menos así: soy el creador de un programa que sirve para producir contenido, ya sea imágenes, documentos, música, etc. Como cualquier persona, quiero ganarme la vida con mi trabajo, y por lo tanto uno de mis objetivos es maximizar las ventas de mi producto. Obviamente entre más usuarios mejor, y por lo mismo no quiero que se vayan con la competencia, es por esto que el formato en el que produzco el contenido es un secreto. De esa manera prevengo la creación de productos que puedan competir con el mio.

Pero la idea anterior tiene dos fallas. Primero, los usuarios no van a migrar a otro sistema compatible por el formato (abierto o cerrado) sino por la funcionalidad del sistema. El sistema que cuente con más funcionalidad, sea más fácil de usar, más bonito, sea el que está de moda, este disponible en más plataformas o tenga un costo más accesible, es el que va a tener más usuarios. Fuera de los llamados “usuarios expertos” o de intereses especiales, el hecho de que un sistema use un formato abierto o cerrado por sí solo no va a ser un factor determinante. Segundo, un formato cerrado no protege de la creación de programas compatibles (la compatibilidad de OpenOffice.org con el formato .doc es un ejemplo. Otro es el Gimp y su compatibilidad con el formato cerrado de Photoshop)

En la plática, se dio el ejemplo de excel que en su primera versión ofreció compatibilidad con el estándar de facto de la época: Lotus 1-2-3, siendo esta la razón principal por la que los usuarios migraron hacia excel. Mientras que la compatibilidad con Lotus fue un factor importante, no fue determinante. Antes de excel ya existían otros competidores compatibles con Lotus, pero fue una combinación de factores: la tardanza de Lotus en traer su plataforma hacia Windows y la compatibilidad con su formato lo que permitió que excel tomara la delantera. En la actualidad, tanto el formato binario como el basado en XML de excel son formatos abiertos completamente documentados.

Los formatos abiertos nos benefician a todos. El beneficio a los usuarios finales es obvio, pero el beneficio a las empresas no lo es tanto. ¿Por qué yo como empresa basaría mi producto en un formato cerrado? Porque expando mi base de usuarios, y entre más usuarios mejor. Al usar formatos abiertos, me aseguro de ser una opción viable para todos los grupos de usuarios posibles: los que se preocupan por el formato y a los que no les importa, organizaciones de gobierno, universidades y amas de casa, los que usan Linux y los que los corrigen diciendo “es GNU/Linux”, los que usan software de la manzana, de la ventana y del demonio.

En estos tiempos de software social y de Web 2.0, compartir datos es el centro de la interacción entre usuarios virtuales. Compartir datos es un acto social, y los efectos de este acto no se reducen al usuario original, sino también a todos los usuarios que compartirán estos mismos datos. Los formatos abiertos son, por definición, formatos de intercambio: aseguran la posibilidad de intercambio, la interoperabilidad y la longevidad de los datos. Un formato cerrado no es una estrategia de mercado.

Ú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.

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

Cada vez que digo en público que el sentido del humor del que se enorgullecen la mayoría de los mexicanos es unas de las cosas que nos tienen jodidos, encuentro miradas de desaprobación por aqui y por allá. Y es que los mexicanos nos aferramos al sentido del humor como si fuera la característica más valiosa del mundo. Esto último es comprensible, en un mundo donde somos altamente discriminados, un cumplido que se repite y se refuerza de vez en cuando se vuelve un gran orgullo.

Pero ¿por qué digo que nos tiene jodidos? Porque cada vez que pasa algo fuerte, digamos, políticamente, el proceso es mas o menos este:

1. Suceso grave. Indignación.
2. Surgen los chistes respecto al suceso grave (a veces en minutos)
3. La gente se rie del suceso grave, gracias a los chistes, y la indignación poco a poco se va
4. El suceso grave dejó de ser taaan grave. Si hasta nos estamos riendo de eso.

Por eso dicen que los mexicanos no tenemos memoria histórica. Gracias a este proceso del que tan orgullosos nos sentimos, nos pueden hacer una y otra vez lo que quieran.

¿Y qué tiene que ver todo esto con la temática de este blog?

Con todo este asunto de la influenza porcina, hoy por la mañana estuve leyendo posts, algunos de méxico, otros de USA, donde decían que Twitter, esa red de la que tan orgullosos nos sentimos porque sirve para comunicarnos de manera instantánea, de manera distribuída y bla bla bla, era, más que algo confiable, una fuente impresionante de desinformación.

Obvio, mi primera reacción fue enojarme y preguntarme cómo era posible que dijeran eso… pero tristemente, es cierto. ¿Y saben qué es lo peor? que somos nosotros los mexicanos, mayormente, los que estamos haciendo esto.

Salvo algunas excepciones, no estamos usando twitter para informar e informarnos, sino para echar desmadre y hacer chistes al respecto. Es cierto, al principio era obvio y estuvo bien, pero que una semana después se sigan haciendo chistes y chistes y chistes cuando lo importante sería estar reportando información confiable, que nos sirva para protegernos mejor, es una mamada.

Si no me creen, chequen el hashtag #influenza. Muy pocas cosas de valor, mucha estupidez. La gente le pone el hastag a cualquier idiotez que sale de su cabeza. Supongo que para ganar popularidad, aunque la actitud que yo noto es que todo esto se trata de echar desmadre.

Ahora comparenlo con el hashtag #swineflu, en inglés. Aunque se cruzan (a veces se usan ambas tags), la diferencia es notoria al momento de escribir esto. Encuentras rapidito consejos, links a reportes y comunicados oficiales, etcétera.

No es malinchismo, es vergüenza.

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

Hoy por la mañana descubrimos el sitio www.tikkia.com, el cual es una red social enfocada a profesionistas del área de las TI en Latinoamérica, creada por el mismo grupo responsables de la Super Happy Dev House México. Después de probar un poco el sitio que se encuentra en fase Beta decidimos hacerle una pequeña entrevista a Santiago Zavala, programador de Tikkia y responsable de asuntos internacionales del sitio. La entrevista después del salto.

Leer el resto de este post.