Hay 2 tipos de bots en Twitter, los que se activan al producirse un evento en el timeline público (un hashtag, una palabra, una mención,…) y los que responden a comandos enviados directamente al bot en forma de mención: @bot comando [parámetros]

En este artículo me voy a referir al segundo tipo, al de comandos, aunque con pequeñas modificaciones podríamos tener también el primero. Ojo con los bots que exploran el timeline y responden a eventos, tienen muchas papeletas para ser marcados como spam y ser eliminados por Twitter. No me voy a referir a ningún lenguaje en concreto, lo más sencillo es usar PHP pero eso es a gusto del consumidor.

Vamos a ver como podríamos crear un bot que responda a un par de peticiones sencilla, que nos diga la hora y que nos diga la fecha en la que estamos. Los usuarios para obtener la información enviarán al bot “@bot hora” y “@bot fecha” respectivamente.

Como ya he dicho antes, el bot que responde a comandos los recibe a través de menciones directas. lo primero que tenemos que hacer es comprobar la lista de menciones que recibe nuestro bot (@bot por ejemplo). Para ellos existe un método de la api que nos da las últimas menciones que recibe una cuenta Twitter: statuses/mentions

Ya tenemos las menciones de nuestro bot, pero nuestro bot no responde a todas las menciones, solo a aquellas que son directas (la mención aparece justo al principio, no en cualquier parte del tweet) y que contienen alguno de los comandos reconocidos. En nuestro ejemplo tendremos 2 comandos HORA y FECHA.

Deberemos pues aplicar 2 filtros y seleccionar solo aquellas menciones que comiencen por “@bot” y después las que a continuación especifican uno de los comandos reconocidos. Esto se consigue con un  simple parseo de las palabras del tweet. En caso de que el comando acepte parámetros también los obtendremos con el parseo usando el espacio ” ” como carácter delimitador.

Una vez tenemos una petición válida, almacenamos el nombre de usuario que envía la petición. Esto nos servirá para responderle con la información que pidió. Después, según el comando hacemos una llamada externa a un procedimiento que nos dará la información necesaria. Tomamos la información y componemos un tweet de respuesta con el siguiente formato:

@usuarioqueenviolapeticion Son las [hora actual]

Imaginemos que @fdelpozo envió “@bot hora”, el tweet de respuesta sería “@fdelpozo son las 9:24″

En el paso anterior he dicho que según el comando se hace una llamada externa que nos de la información. Para el ejemplo de la hora y la fecha al ser tan sencillos no sería necesario, pero imaginaos que nuestro bot envía el artículo más vendido del día de nuestra tienda online. Deberíamos desarrollar un procedimiento para nuestra tienda que al comprobar la fecha actual devuelva el artículo más vendido. El bot recogería este dato y se lo enviaría después al usuario en twitter:

El ejemplo podría ser este:

El usuario envía “@mitiendaonline tophoy”  TOPHOY es el comando del bot para saber el artículo más vendido.

Nuestro bot recoge la mención como ya he explicado y hace una llamada a un método de nuestra tienda online del tipo botmitienda_tophoy(). Este método le devuelve la información: “Super Mario para Nintendo DS http://url.al.articulo/en/cuestion”

El bot solo tiene que componer el tweet de respuesta y enviarlo “@usuario Lo más vendido hoy es Super Mario para Nintendo DS http://url.al.articulo/en/cuestion”

Para enviar el tweet se utiliza el método de la API de Twitter estatuses/update.

Hay algunas cosas a tener en cuenta, el proceso que ejecuta el bot debe ejecutarse a intervalos de 1 minuto como mínimo para asegurarnos de que los usuarios reciben sus respuestas rápido, en tiempo real. Una tarea cron en el servidor y listo.

Sería ideal registrar en base de datos las estadíticas del bot, peticiones realizadas, respondidas con éxito, comandos erróneos, usuarios que realizaron las peticiones, fechas y horas de estas, etc. Que nos ayudarán a conocer el nivel de uso del servicio y a su mejora (puede que los comandos elegidos no sena buena idea y la gente los confunda a menudo).

Es buena idea el programar un comando genérico llamado “HELP” que envíe una pequeña ayuda o un enlace al usuario con nuestra lista de comandos y una pequeña explicación sobre su funcionamiento. Este mismo mensaje se puede enviar cuando el usuario comete un error con los comandos o sus parámetros.

Elige comandos cortos, sencillos y fáciles de recordar. Te aconsejo no pedir más de 1 parámetro, esto es Twitter no un terminal Linux.

He dejado el bot del ejemplo funcionando en la cuenta @spotifm.

Para pedir la hora enviad “@spotifm time” os devolverá la hora de España.

Para pedir la fecha enviad “@spotifm date” os devolverá la fecha actual.

Para pedir ayuda sobre su funcionamiento enviad “@spotifm help“.

También podéis probar el bot @topusers que programé hace días de la misma forma que he comentado en este post. El bot envía

información extraída de My Twitter Cloud sobre nuestro usuario Twitter o bien nos envía rankings de usuarios para un término

determinado. No garantizo su funcionamiento ya que el servidor donde está alojado pasa más tiempo caído que online.

Los comandos son:

@topusers top [término] Ejem: @topusers top seo /Envía los 3 usuarios más relevantes para un término y un enlace para ver el resto.

@topusers tags [usuario Twitter sin @] /Envía los tags más relevantes para un usuario en concreto, para saber las nuestras usad “@topusers tags me” Ejem: @topusers tags fdelpozo

Otro bot para que probéis es @weather_info que nos envía la información del tiempo (de momento del mismo día) de una ciudad en concreto. El comando es:

@weather_info TODAY ciudad,país

Nos devolverá en un tweet las temperaturas y las condiciones de la zona.

A mi me gusta especialmente el último, innovar. Cuando hablamos de innovación en Internet siempre nos viene a la mente la tecnología. Pero se puede innovar en muchos ámbitos. La tecnología es sin duda el más importante y el que más recursos consume, pero hay más.

Se puede innovar en el modelo de negocio. El freemium innovó en su día frente al clásico sistema cerrado con cobro por servicio. Se puede innovar en la forma en que vendes tus productos, zapatos se han vendido toda la vida de Dios, pero nadie los vendió como Zappos hastas ese momento.

BuyVip Vente Privee innovó en la forma de vender a través de Internet, frente a la venta clásica con stock, se inventaron un sistema de venta rápida sin stock y a precios muy competitivos. En ninguno de estos ejemplos se innovó con tecnología.

Hace unos días se me abrían las carnes al ver rodando por Twitter una frase que un emprendedor de éxito lanzó en un Iniciador (no recuerdo el nombre), la frase en espanglis decía “Don`t  innovate, fusilate”.

Que queréis que os diga, no me parece un buen consejo. No digo que haya que innovar sí o sí para tener éxito, pero aconsejar a los jóvenes aspirantes a emprendedores que copien no me parece un buen consejo.

Si todos hubiesen seguido los consejos de este señor, aún estaríamos conectándonos a Fidonet con el modem de 14400 bps, Internet nunca hubiese existido y por supuesto ninguno de los servicios y herramientas que hoy día nos hacen la vida más sencilla.

Eso sin tener en cuenta que para “fusilar”, alguien tiene que crear algo nuevo que podamos copiar.

Para innovar hay que apostar fuerte, si vas muy justo de recursos y necesitas resultados rápidos olvídate del tema. La vas cagar muchas veces. Antes de conseguir clonar a la oveja Dolly se cargaron más de 100 ovejas.

La innovación no obtiene resultados rápidos, si quieres resultados rápidos haz aquello que ya les funciona a otros  e intenta conseguir un trozo de la tarta. Hay que estar preparados desde le punto de vista estratégico, económico (importante) y de mentalidad.

La innovación, a corto plazo es una gastona de recursos, prueba y error. Pero a largo plazo es muy competitiva, si funciona, tendrás un producto de éxito y único en el mercado. Hasta que venga el señor de Iniciador y sus discípulos y lo fusile, pero para eso están las patentes, las marcas y las protecciones legales.

Una buena forma de trabajar cuando los recursos destinados a innovación son escasos, es la de trabajar en proyectos con resultados probados y seguros y destinar parte de esos beneficios a la investigación de nuevas ideas. Financiarnos de algún modo la innovación a través de modelos clásicos con probada eficacia.

No todo el mundo entiende la innovaciónen Internet ni apuesta por ella en serio. Es necesario cambiar nuestra mentalidad orientada a resultados a corto plazo. Repito, si quieres resultados a corto plazo, olvidate de innovar.

Tengo muchas ganas de trabajar, muchas cosas por hacer, por inventar, por aprender, profesionales por conocer…Trataremos pues de trabajar en ese plan B, plan en el que puedo dedicar ahora todos mis esfuerzos.

Imagen: Planbenlauba

Lo más evidente es el diseño y la usabilidad, es un placer navegar por él. La lista de mejoras es la siguiente:

• Nueva imagen y diseño: Mejoramos notablemente, tanto el aspecto como la usabilidad de la web.
• Más rápida: La nueva web es mucho más rápida que la anterior. Estrenamos un nuevo motor de búsquedas.
• Más resultados: Hemos aumentado de forma significativa el número de usuarios indexados.
• Portadas de todos los países del mundo: Mostramos una portada por cada país con las categorías más importantes.
• Muliidioma: Ahora te ofrecemos la web en nada menos que 6 idiomas (Español, inglés, francés, aleman, italiano y portugués).
• Gestión de tu cuenta Twitter: Hemos añadido varias funcionalidades para que puedas realizar acciones con tu cuenta Twitter sin moverte de la web (follow/unfollow de usuarios, publicar estados en Twitter, etc.)

Os invito a todos a entrar con vuestra cuenta Twitter , actualizar vuestro usuario (flecha azul de la caja de login). Podreis ver vuestros tags, quizás os llevéis una sorpresa :)

Teneis más información sobre su funcionamiento en ¿What is My Twitter cloud? (Está en 6 idiomas)

Además estoy probando estos días el widget para blogs de nuestro perfil en My Twitter Cloud, a la derecha podéis ver el mío, si alguien quiere probarlo en su blog que me deje un comentario.

Ha llevado más tiempo del deseado pero el resultado ha sido muy bueno. La presentación oficial y en exclusiva se hizo desde el programa Twision en el canal VEO7. Fue una presentación muy atípica, un sábado a la 1:00 de la madrugada :)

Agradecimientos a Javier Ábrego (@fjabrego), presentador que dio la exclusiva y a todo el equipo de Twision.

Os dejo con el clip de vídeo donde se presento el buscador en Twision.

He leído esos cambios y no es tan grave, básicamente Twitter prohibirá que se utilice su timeline (envío de tweets) promocionales de pago. Tiene su lógica, quieren preservar la calidad de SU contenido y los únicos tweets promocionales de pago que habrá, serán los de su propia plataforma, promoted tweets.

Cuando pensaron en promoted tweets lo hicieron de forma que los usuarios no se vean invadidos por tweets de publicidad sin más, intentaron que estos fuesen de interés y en caso contrario saldrían del timeline, todo gracias a su algoritmo de resonancia.

Como no son capaces de asegurar la calidad de los tweets promocionales de terceros (y por que la guitarra es mía y toco lo que quiero) lo prohíben y punto.

¿Y que pasa con el resto de servicios y aplicaciones en torno a Twitter y que hacen uso de su API? Algunos estaban empezando a generar modestos ingresos que les permitía al menos amortizar gastos y hacerlos crecer. Pues en principio no tiene porque pasar nada, si no usas su timeline para anunciar no hay problema.

Generalmente hay tres formas (hay más) de generar ingresos en los servicios relacionados con Twitter, mostrar la publicidad de toda la vida de Dios, cobrar suscripción por el servicio (herramientas social media, métricas, etc.) o promocionar perfiles de Twitter.

Una red que se dedicaba a promocionar perfiles de Twitter (featuredusers.com)se ha puesto en venta justo estos días, dicen que debido a los cambios de los TOS de la API pero el dueño lo desmiente. Realmente no incumple siquiera esas nuevas condiciones que anuncian.

Otra posibilidad que está en el aire es la de compartir ingresos con Twitter. Si se diese el caso me parece justo, usas mi contenido para ganar dinero y quiero mi parte. Esto provocaría una importante criba de aplicaciones y servicios quedando solo aquellos de mejor calidad y que generan ingresos realmente interesantes. Una aplicación que da $300 al mes y le tiene que dar $150 a Twitter no tiene sentido.

Veremos como evoluciona todo esto, veremos esos nuevos términos bien detallados y como afecta a la gran comunidad de desarrollo en torno a twitter. Y veremos sobretodo, si Twitter no se dispara en el pie, 50.000 aplicaciones desarrolladas gratis para tu plataforma no es ninguna tontería.

Los beneficios de la publicación de una API son enormes. Un buen API puede hacer que el uso de tu servicio o aplicación crezca de forma notable. Tenemos varios ejemplos de servicios cuyo API se ha convertido en el verdadero valor y la aplicación inicial (interface web) han pasado a ser una interface más, en ocasiones mejorada y superada por terceros, gracias al uso de su API.

El servicio de moda es el mejor ejemplo, la web de Twitter.com ha sido superada por otras aplicaciones web de terceros en cuanto a funcionalidad, potencia y facilidad de uso, todo gracias a la publicación de su API. La cantidad de clientes que han surgido para todas las plataformas es ingente y han  contribuido a la popularización y extensión del servicio a un coste bajo.

El core de Twitter es su API y su valor el contenido, todas esas aplicaciones y clientes surgidos a partir de ella aportan 55 millones de tweets al día con un coste cero de desarrollo. Sólo un pequeño porcentaje se realiza a través de la web original, la de Twitter.com.

Una API debe ser muy fácil de utilizar, atraerás a muchos programadores sin son capaces de tener algo funcionando en una tarde. Atraerás a muchos programadores sin no les mareas cambiando una y otra vez las especificaciones, no van a estar reprogramando su aplicación cada poco tiempo, no usarán tu API.

Planifica bien tu API, piensa bien qué quieres que sea capaz de hacer (y de no hacer) y como quieres que lo haga. El día que decidas publicarla no hay vuelta atrás.

• Enumera los distintos objetos de tu aplicación (perfiles, búsquedas, etc.)
• Enumera los distintos métodos de cada uno de estos objetos ( perfil: Leer, Crear, Modificar,…)
• Fija un sistema de autenticación para los usuarios de tu API, el más habitual es el API key, también se puede utilizar el clásico par de usuario/contraseña o el cada vez más habitual OAuth.
• Fija límites en las peticiones. Limita el número de peticiones que un usuario de tu API puede hacer por día o por hora. Un uso abusivo podría hacer caer tu servicio o penalizar el rendimiento del resto de usuarios.
• Limita la cantidad de datos que entregas en cada petición, unido al límite de peticiones por día asegurará que no pierdas el control de tus datos. Una solución es el paginado de la información o entregas en bloques. Analiza cuidadosamente cada método, este no debe ser capaz de entregar por ejemplo todos los perfiles del sistema en una sola petición.
• Mide su uso. Establece un sistema de métricas sobre el uso que se realiza de tu API. Al igual que mides el uso de un interface web (las estadísticas de tu página), mide también tu API.
• Documenta MUY BIEN tu API. Si tu API no está debidamente documentada y de forma sencilla, los usuarios no programarán para ella. Los sistemas Wiki son los más sencillos de utilizar por los programadores y fáciles de mantener por nuestra parte. Genera una documentación sencilla, si generas 200 páginas, no las leerá nadie.
• Habilita un sistema de foros donde los usuarios puedan plantear sus dudas, sugerir mejoras,… y ayúdales.
• Vigila los posibles agujeros. Asegúrate de que tu API no podrá hacer nada más que aquello para lo que fue publicada. Tenemos que tener especial cuidado con los métodos relacionados con los borrados de información y con la privacidad.

Antes de terminar quería comentar que en España ha surgido una empresa que se encarga de hacer todo este trabajo por nosotros, se llama 3Scale y me encanta su negocio. Se encargan tanto de desarrollar nuestra API como de hospedarla, realizar las métricas, etc.

Hace unos días le regalé a mi mujer un HTC Tattoo. Buscaba un Android de gama baja pequeño y este es si duda el más adecuado, no hay Androids de gama baja.

Es un terminal bastante majo, como digo pequeño y manejable. Tiene buenos acabados, como todos los HTC e incorpora HTC Sense como el Hero, Legend o Desire.

La versión de Android que lleva es la 1.6 pero ya incorpora actualizaciones OTA (Over the air) no como mi Hero, que aún tendré que actualizar el firmware ví­a cable borrando todo el teléfono. El Tattoo pronto se actualizará a la 2.0 como el resto de terminales HTC.

Lo peor del Tattoo es la pantalla, es resistiva y no capacitiva como el resto de Androids de HTC. Esto hace que la respuesta táctil no sea tan buena como los demás, hay que pulsar más fuerte y el brillo y calidad de imagen es peor.

En una pantalla resistiva se puede pulsar con un dedo o con cualquier objeto, en una capacitiva solo con los dedos de forma que no responde a roces accidentales con la ropa por ejemplo. La respuesta de las capacitivas es mucho mejor. Aquí tenéis las diferencias entre ambas.

La relación calidad precio es buena ya que son 200€ libre en Expansys, el resto de HTC de más calidad no bajan de 400€ libres.

Además del teléfono compré una carcasa, la que trae es muy triste y el Tattoo permite cambiar la carcasa por unas prediseñadas o por una diseñada por tí mismo.

Sorry, nothing found for your search terms

“Sabes innovar, pon tus sueños a trabajar”

Las más interesantes quizás sean las que organiza Iniciador en lo que han dado en llamar, el I congreso nacional de emprendedores Iniciador.

Yo estaré por allí el día 27, aún no sé seguro si también el 26. Os dejo información sobre los programas de ambos días:

• Programa del día del emprendedor que amablemente me envió @arrola
• Programa del I congreso nacional de emprendedores Iniciador

En Internet se puede ganar dinero desde el primer momento sin arriesgar, te dedicas a hacer lo que ya les funciona a otros. La dificultad está en abrirte paso entre tanta competencia, pero no tienes que convencer a nadie de lo que haces, todo el mundo lo conoce y además funciona. Se trata más de un problema de inversión en promoción de tu producto, más que de otra cosa.

Cuando innovas, la gente, a priori, no está preparada para consumir tu producto, tienes que convencerles. Tienes que demostrarles que realmente necesitan eso que has creado…o crearles la necesidad.

¿Alguien realmente necesitaba contar que estaba pasando o que estaba haciendo en 140 caracteres antes de la aparición de Twitter?

¿Y hacerte alcalde del bar de tu barrio y contarlo además en Twitter?

En España no se ayuda a la innovación, muy pocos, por no decir ninguno, invertirá en tu idea si no lleva asociada una garantía de producir dinero, somos así de temerarios. En sus inicios, ningún banco hubiese dado dinero a Twitter en España, ni a Google cuando solo era un buscador en una universidad (sin adwords), en USA les dieron 1M de dólares.

En España el modelo ideal podría ser la mezcla de ambos, proyectos seguros que funcionan para así poder financiar la propia innovación. Hay empresas jóvenes Internet que están siguiendo este modelo y me gustan mucho.

No concibo trabajar en Internet sin innovar, admiro a los que sin hacerlo ganan mucho dinero, crean puestos de trabajo y riqueza. Pero a quien de verdad admiro es a aquellos que llevan a cabo sus buenas ideas sin garantías de éxito, ojo, llevando a cabo, que ideas las tenemos todos muy buenas.

El uso de este tipo de APIS no suponen ninguna preocupación ni APIdependencia ya que en cualquier momento podemos desarrollar esa funcionalidad o generar ese contenido por nuestra cuenta, sin demasiados recursos o esfuerzo. En este grupo estarían también los mashup, la pérdida de una de las funcionalidades no afecta al proyecto en sí, incluso podemos tener varias alternativas de API que nos proporcionen el mismo servicio.

En otras ocasiones no hay alternativa posible, el API en cuestión nos proporciona una información o un servicio cuyo desarrollo por nuestra parte sería totalmente inviable. Un ejemplo claro es el API de Google Maps.

Cientos de miles de proyectos web se apoyan en la funcionalidad de Google Maps, ya en otro tiempo se usaba Geofactory. La mayoría lo usan para agregar valor a su contenido como por ejemplo los portales inmobiliarios. Si no pudiesen hacer uso de su API, ninguno se plantearía el abordar un desarrollo de ese calibre solo para añadir una funcionalidad accesoria a su proyecto. Simplemente prescindirían de ella y no estaríamos hablando de APIdependencia.

Y por último tenemos aquella aplicación donde nuestro desarrollo está directamente relacionado con ese API. Sin el API, nuestro proyecto no vale nada y su razón de ser no es otra que complementar a ese otro servicio.

Aquí la APIdependencia es total. Si ese servicio cierra sus puertas o decide no seguir publicando su API, nuestro proyecto está muerto, no vale nada. Depender totalmente de un servicio de terceros tiene mucho riesgo, más cuando este servicio es gratuito y las condiciones del servicio les permite dejar de prestarlo en cualquier momento sin ninguna responsabilidad por su parte.

Otro riesgo importante es que la empresa que presta su API decida implementar el mismo servicio que tú, ejemplos tenemos montones todos los días. Un servicio de éxito decide implementar una novedad y ese mismo día 500 aplicaciones de terceros se van a la basura.

Las incidencias que pueda tener su servicio, son incidencias en nuestro servicio, sin ningún control por nuestra parte ni medios para solucionarlo, salvo la posibilidad de enviar un ticket a soporte.

Pero no todo es tan negativo, hay una serie de precauciones que nos pueden ayudar a no estrellarnos en caso de que decidamos APIdepender de otros.

Las APIS gratis están muy bien, pero como dije antes, suelen prestar su servicio sin ninguna garantía. Un API de pago contará con unas condiciones de prestación del servicio y un soporte de mejor calidad. Haz cuentas y comprueba si te es rentable.

El pago no nos asegura la disponibilidad del API más allá de lo que marca el plazo del contrato, nuestro socio de API puede cerrar su servicio a posteriori y nos quedaremos con un desarrollo en el que hemos invertido muchos recursos y que ya no vale nada. Es más que recomendable utilizar APIs de servicios con demostrada solvencia y solidez, dormiremos más tranquilos.

El uso de APIs de servicios aparentemente solventes y de éxito hacen que nuestro proyecto también tenga más posibilidades de triunfar, pero cuando se trata de servicios aún por explotar, nos sitúa en una posición privilegiada. Las aplicaciones complementarias más utilizadas (que hacen uso de las APIS de más éxito), no siempre son las mejores, pero fueron las primeras.