Monthly Archives: noviembre 2008

escritorio para llevar

Posted on by
Reply

En petitinvention, muestran un concepto interesante, el pc de escritorio portátil:

La idea es reducir el tamaño de un minimac para poder llevártelo cómo si fuese un portátil. La ventaja de este ordenador sería que pesaría menos (no usaría baterías, ni teclado, ni pantalla) y nos permitiría tener nuestros datos y nuestro ordenador en cualquier lugar que podamos conectar nuestro ordenador (pero… necesitamos una pantalla y teclado dónde conectarlo).

Puede ser práctico para poder moverlo en casa, por ejemplo el eee box sigue una filosofía parecida, aunque no está diseñado tanto para poder moverlo fácilmente.

Si la idea es la movilidad de datos, otra opción más sencilla es usar un disco duro portátil con nuestros datos. Pero sigo pensando que estas soluciones son parecidas a la de llevar CD’s físicamente. Hoy en día es mejor pensar en red y que nuestros datos residan (protegidos) en servidores y que podamos acceder nuestro escritorio desde cualquier ordenador, algo parecido a eyeos.

moviendo un servo con arduino

Posted on by
1

Después de conectar con la librería windows live presence, el siguiente paso en el miniproyecto presencebot es controlar un servo con la tarjeta arduino.

Lo más fácil es seguir las indicaciones de la documentación de arduino que incluyen un ejemplo de control de un servo. Añadiendo un poco de código para leer el puerto serie, conseguimos un programa muy sencillo al que se le pueden enviar comandos con minicom para controlar el servo. Dado que presencebot sólo controla los eventos online/offline, por ahora sólo he implementaro los comandos de posición alta y posición baja y un comando que devuelve la posición actual del servo.

El único problema en la librería de control de servos es que limita la temporización de nuestro programa: no podemos poner las instrucciones delay que queramos. Existe una versión nueva de la librería (SoftwareServo) que obliga a hacer el refresco de forma implicita: hay que llamar a una función refresh cada 50ms para que el servo actualice su posición. También existe una librería de control de servos mediante hardware que no tiene la limitación de temporización, pero está limitada a 2 servos.

En mi caso estoy usando la librería software, aunque probablemente termine usando la librería hardware. Para resolver el problema de la temporización en el caso del encendido/apagado de un led, he creado una función que controla el momento en el que se encendió el led y si ha pasado el tiempo suficiente, lo apaga. Ésta función hay que llamarla periódicamente, pero aunque sería mejor tener interrupciones temporales, en arduino es normal tener un ciclo de control periódico.

Sobre el protocolo de comunicación, prefiero que sea lo más sencillo posible y preferentemente en modo texto, para que se pueda trazar leyendo el ASCII directamente. Aunque sea menos eficiente en el consumo de ancho de banda (por ahora no es una cuestión importante), prefiero saber qué está haciendo sin necesidad de interpretar instrucciones en hexadecimal.

La experiencia con arduino es buena, es una placa versátil y potente (y eso que tengo la versión NG que ya está algo desfasada), tiene un coste relativamente bajo y cada vez hay más código y ejemplos en internet para usar esta tarjetita.

geode y ubiquity

Posted on by
Reply

Dentro de la interesante serie de experimentos concept series de Mozilla Labs, además de prism, hay dos experimentos que me parece que pueden marcar el futuro de la navegación: geode y ubiquity.

Prism supone la integración de la web en el escritorio: ahora mismo, facebook, todoist, google calendar y yahoo mail están integrados en mi escritorio y los uso como aplicaciones windows gracias a prism.

Geode utiliza geolocalización a través de wifi. Lee las redes wifi que capta nuestro ordenador, las compara con una base de datos y calcula la posición en la que estamos. El servicio de localización se cómo un api para aplicaciones web, que pueden así usar la localización del usuario.

Pero me gusta todavía más la parte de api para aplicaciones web. Para Firefox 3.1 están desarrollando un Geolocation un api normalizado por el W3C y que permite que el usuario configure el mecanismo de localización que dispone wifi ó gps y yo añadiría localización aproximada por ip o lo que sea.

El otro proyecto interesante es ubiquity, que es un experimento en el área de HCI (Human Computer Interaction). Al navegador se le añade una interfaz por línea de comandos, con la idea de ejecutar comandos cada vez más complejos, que además se puedan personalizar.

Ya exiten comandos para buscar en google, escribir un correo, buscar en la wikipedia, añadir eventos al calendario google, etc. Todo desde la misma línea de comandos, con lo que tenemos una interfaz única para hacer de todo.

Si le añadimos un interfaz gestual, sólo tendríamos que mapear gestos con órdenes. Y si añadimos un reconocedor de voz, habría que mapear palabras con órdenes. Sería algo muy simple (las órdenes son muy simples), pero podríam mejorar mucho la usabilidad al integrar muchos servicios en una sóla línea comandos.

pruebas con Windows Live Presence API

Posted on by
1

Estoy empezando a hacer algunas pruebas con presencebot, un experimento sencillo que consiste en reflejar de forma física la presencia virtual en messenger de microsoft.

Para obtener el estado online de una persona, estoy utilizando la librería Windows Live Presence API, que no es más que un api json para obtener el estado online de un usuario de messenger, que previamente se tiene que haber registrado. Usar este api tiene la ventaja de que es web y por lo tanto accesible desde cualquier lugar con conectividad a internet y la desventaja de que al ser web es más lento que un plugin local de messenger.

Otra ventaja es que el funcionamiento del api es muy sencillo, sólo hay que seguir los siguiente pasos:

1. Aceptación de condiciones: Antes de usar el API, la aplicación debe hacer que el usuario se inscriba en el servicio y acepte las condiciones de uso. El registro se hace en la siguiente url:

http://settings.messenger.live.com/applications/websignup.aspx?returnurl=[URL]&privacyurl=[URL]

Los parámetros que debemos enviar son returnurl con la dirección de vuelta una vez que el usuario ha aceptado (ó rechazado) la entrada en el servicio y privacyurl que debe apuntar a un texto explicativo de las condiciones de privacidad de nuestra aplicación.

Si el usuario acepta, es envíado a returnurl, cón los siguientes parámetros id y result. Result nos informa del resultado del registro: Accepted si acepta registrarse, Declined si rechaza el registro, NoPrivacyUrl si privacyurl no es válida. Id nos devuelve el identificador del usuario, que se necesitará para hacer la consulta propiamente dicha.

2. Consulta del estado: Después del registro, el estado del usuario se puede consultar en la siguiente url:

http://messenger.services.live.com/users/[ID]/[resource]

Id es el recibido en returnurl y sirve para identificar al usuario. Hay que tener en cuenta que es case sensitive así que cuidado con las mayúsculas/minúsculas. Resource puede tomar los valores presence ó presenceimage. En el primer caso se obtiene un objeto json con el estado online del usuario y en el segundo la url de una imagen que representa el estado online.

En esta url se pueden encontrar los elementos devueltos en el objeto json. El que me interesaba en este caso es “status” que puede tener los valores conocidos de msn:

Online, Away, Idle, BeRightBack, Busy, OutToLunch, OnThePhone, Offline

Con ruby se puede hacer un programa que chequee el estado online en apenas 15-20 líneas, cuando tenga terminado el proyecto publicaré el código fuente.

Realmente es un api muy sencillo de usar, con la única pega de que una vez que el usuario se ha registrado, cualquier aplicación puede acceder a esta url para consultar el estado del usuario, lo que no es demasiado bueno de cara a la privacidad.

open source en la nube

Posted on by
1

En unas declaraciones recientes, Richard Stallman avisa de que el cloud computing es una trampa. Hay parte de verdad en esta advertencia, pero no debemos cogerla cómo una negación del cloud computing.

Por un lado, es innegable que se trata de un término comercial. Como dice Stallman es un nombre nuevo a algo antiguo. Por otra parte, creo que necesitamos nombres nuevos cuando cambia algún aspecto antiguo. Dónde antes teníamos software embebido para terminales móviles, software de escritorio y programación web, ahora tenemos aplicaciones en nube. El objetivo debe ser unificar la programación en la medida de lo posible, la aplicación es única. Por ejemplo, el dúo outlook + blackberry, por mucha integración que haya no es comparable a acceder a gmail desde cualquier dispositivo.

Por otra parte, el miedo a la pérdida de privacidad es una cuestión de confianza, las empresas deben demostrar a los clientes que son dignas de su confianza.

Pero cuando Stallman habla de trampa, se refiere a que el software no es modificable, no sabemos que procesamiento de nuestros datos se estarán haciendo. Esto es un peligro inerente al software propietario y es independiente de si un software se usa en nube, en escritorio o en web. La solución es sencilla: frente a blogger, tenemos wordpress. Uno es cerrado y no sabemos cómo se manipulan nuestros datos, el otro es abierto y tenemos acceso al código fuente.

El peligro no es la nube, sino el software propietario. Al igual que linux se extendió lo suficientemente en un momento en que microsoft dominaba el mercado, surgirá la correspondiente aplicación libre en caso de que lo necesitemos.