Tarjetas, seguridad e incentivos

Monedas En Why the US Doesn’t have Chip-and-PIN Credit Cards Yet nos recordaban que la seguridad no sólo se basa en tecnología o en recursos disponibles, sino que muchas veces se trata de una cuestión relacionada con los incentivos, amenazas, riesgos, costes…

Se habla del caso de la utilización de tarjetas con banda magnética en EEUU en lugar de las más modernas (y seguras) tarjetas con chip.

Y también los usos y costumbres de la gente. El ejemplo es Europa (territorios pequeños, con dificultades para perseguir a los defraudadores cuando cruzan la frontera) vs EEUU (un país grande, con ciudadanos que no salen tanto fuera) y las costumbres (y necesidades) de sus ciudadanos, las características de movimientos y viajes…

Una pata robótica

Esta entrada es más una ‘nota para mi mismo’ (note to self) que algo de valor real. Pero me encuentro con algunos pequeños avances, unas cuantas pestañas abiertas en el navegador y creo que es mejor compartirlo aquí para futura referencia que esperar a una (eventual) finalización de algo más avanzado. Quién sabe si puede servirle a alguien para algo.

En Una cámara móvil ya anticipábamos la posibilidad de hacer algo que se moviera. De hecho, ya se sugería la inspiración en Stubby. Full featured, miniature hexapod. También se puede ver información en Stubby the (Teaching) Hexapod.

Mi único problema con ese diseño eran las habilidades y herramientas necesarias: corte de madera, mecanizado… Estuve dándole vueltas a las alternativas realizables y pensé en tubos de madera. Con la idea de que sólo sería necesario cortarlos a la medida adecuada, perforarlos y montar el armazón adecuado.

También descubrí otros proyectos interesantes como A spider called “Chopsticks” que utilizaba palillos orientales para las patas y Popsicle Stick Hexapod R.I.P. que utiliza palos de helado, lo que iba más en la línea de lo que estaba pensando y me animó bastante. También había visto Build a 12-Servo Hexapod que tiene menos posibilidades pero que también es muy interesante.

Buscando en la red hay un montón de proyectos más, como Hexpider que sigue otro tipo de diseño (y es capaz hasta de escribir) y este otro 6-legged robot project que me han servido para tener algunas ideas sobre movimiento y configuración de las articulaciones (a nivel básico, todavía no he estado pensando demasiado en esa parte).

Con estas ideas me fui a la tienda de bricolaje más cercana a ver qué tenían. Aunque llevaba en la cabeza la idea de los tubos de madera allí encontré un tubo de plástico que me pareció muy adecuado: pensé allí mismo que sería más fácil de cortar y más ligero. También tenían tubos de aluminio que quedarían mucho más impactantes a la vista, pero de momento ese no es el objetivo.

Palo

A photo posted by Fernando Tricas García (@ftricas) on

Como suponía, el tubo de plástico es fácil de trabajar y podemos hacerle un agujero y poner un tornillo para sujetar un servo sin complicarnos mucho la vida, como puede verse en esta foto:

La pata #raspi #servo

A photo posted by Fernando Tricas García (@ftricas) on

La fotografía no es muy buena, pero creo que es suficiente para hacerse una idea de cómo se pueden unir las partes, es lo que más he agradecido ver en los proyectos de otra gente para copiar/inspirarme. Como puede verse, he elegido un diseño con tres servos

También podemos poner bridas de plástico para fijar una articulación con otra, aunque imagino que hará falta una sujección más sólida cuando llegue el momento de que todo esto se mueva. Pero nuevamente parece sencillo hacer rebajes y pegar unas piezas con otras cuando tengamos una idea más clara del proyecto.

Ha sido sorprendente para mi ver lo rápido que he podido llegar a tener esta configuración, ya veremos si después sigo avanzando tan rápido (con el inconveniente de que no tengo suficientes motores, así que hacen falta algunas compras y esas cosas).

Para el movimiento de las articulaciones ya teníamos la experiencia de Añadiendo movimiento: servos , si bien es cierto es que re-escribí casi todo el código siguiendo las ideas de PiCam; al fijar mejor la cámara (que es algo que no conté por aquí), el movimiento suave ya no era tan necesario.

Rápido-lento-rápido #raspi #err #errbot

A video posted by Fernando Tricas García (@ftricas) on

En la parte de los programas, por ahora, he hecho un par de programitas que están en servo.

El primero sirve para mover cada articulación de manera independiente desde la línea de órdenes (para poder establecer los puntos de referencia fácilmente): legOneMove.py.

Tenemos las tres articulaciones en los puertos GPIO correspondientes:

servoGPIO=[17, 23,15]

y utilizamos una función para transformar un ángulo en el pulso necesario para mover el servo:

def angleMap(angle):
    return int((round((1950.0/180.0),0)*angle)/10)*10+550

Y la función que mueve el motor es muy sencilla:

def movePos(art, pos):
    servo = PWM.Servo()
    print art
    servo.set_servo(art, angleMap(pos))
    time.sleep(VEL)

Para mi vergüenza, notar sólo recientemente descubrí la necesidad del temporizador final, porque si no el programa no da tiempo a que el movimiento se complete. Finalmente, en

movePos(servoGPIO[int(sys.argv[1])], int(sys.argv[2]))

Directamente pasamos el primer argumento de la llamada como articulación que hay que mover (que se corresponderá, recordemos, con el GPIO adecuado) y el segundo es el ángulo de movimiento. No lo hagáis así, amiguitos: no os olvidéis nunca añadir en proyectos ‘reales’ los límites y comprobaciones adecuadas para no llevarnos más tarde sorpresas desagradables.

El segundo programa sería legServo.py que no es más que una simulación de lo que podrían ser los movimientos necesarios para que el hipotético robot ande: levantar un poco la pata, moverla hacia adelante, bajar la pata, moverla hacia atrás, … Y así sucesivamente. Seguro que hay que hacer ajustes después pero nos da una cierta idea de que hemos llegado a algún sitio.

A continuación podemos ver un vídeo de estos movimientos repetidos varias veces, que he grabado con ayuda de mi hijo

En movimiento #servo #raspi

A video posted by Fernando Tricas García (@ftricas) on

También podemos ver en el siguiente vídeo algunas pruebas previas, aprovechando el sensacional editor de vídeos de YouTube, con dos articulaciones y con tres:

Los siguientes pasos deberían ser hacer el resto de las patas (como mínimo cuatro, aunque creo que quedará mejor con seis) y ver si será necesario algún hardware adicional (para controlar los 18 motores y, tal vez, algo más las salidas dela Raspberry podrían ser insuficientes) y alguna idea adicional para el ‘cuerpo’ del robot. Seguiremos informando.

Cabeceras de seguridad HTTP que deberías estar usando

Ratón

Es difícil estar al día de todos los cambios que van añadiendo los diferentes sistemas con los que interactúan las aplicaciones (en este caso web). Por eso vienen bien recordatorios como el de 4 HTTP Security headers you should always be using donde se habla justamente de eso, de algunas cabeceras de seguridad que deberíamos añadir:

  • Content-Security-Policy
  • X-Frame-Options
  • X-Content-Type-Options
  • Strict-Transport-Security

Naturalmente, también conscientes de que es posible que el navegador de nuestro usuario no los conozca/use/respete/tenga en cuenta.

Fallos y seguridad

Bicho mirando

En Every Bug Has a Sad, Sad Song un comentario interesante sobre la relación entre bugs (fallos de programación) y fallos de seguridad.

Suele decirse que cuando un programa tiene bugs es posible que estos den lugar a vulnerabilidades, y a problemas de seguridad.

Pero el autor se queja del abuso que se hace de este ‘deslizamiento’ y que los que señalan esos fallos deberían ayudar a los desarrolladores a aprender sobre seguridad y no criticarlos sin más.

Aleatoriedad y juegos

Hablando de sorteos

Ya hemos hablado algunas veces de aleatoriedad desde el punto de vista de la seguridad. En algunos casos, la aleatoriedad necesaria tiene que ver con producir resultados suficientemente diversos, pero en otros casos hay que pensar en más cosas. En “Not So Random Randomness” in Game Design and Programming discuten sobre el tema y cómo puede ser interesante influir en la ‘aleatoriedad’ para tener un juego más interesante.

Habemus tags

Meta

Uno de los problemas que encontré con este alojamiento es que no tiene etiquetas (tags). De hecho, no sólo no las tiene sino que no está previsto que se incluyan fácilmente con la configuración actual porque no hay plugins disponibles Using Jekyll Plugins with GitHub Pages (Wow, un plugin de emojis, y otro de menciones!).

Pongo estas ideas aquí por si alguien me da pistas sobre cómo hacerlo mejor y/o por si alguien más puede aprovecharlas en su sitios.

Puesto que no puedo añadir plugins para las etiquetas y tampoco quiero generar todo el sitio estáticamente (quiero imaginar que es mejor utilizar jekyll en las github pages) pensé utilizar alguno de los plugins que hay para generar sólo las etiquetas. De los que encontré estoy probando jekyll-tagging que ha sido bastante fácil de instalar y configurar, como se explica más abajo. Hay más formas, como jekyll-tags-plugin, y en Tags In Jekyll hay otra explicación. Incluso llegué a pensar en hacerme un programita para generarlo pero me parecía demasiado trabajo tener que ver cómo va el sistema de plantillas y todo eso…

Primero, hago una nueva copia del sitio en local (con git clone): me servirá para generar el sitio con sus etiquetas y todo.

En este sitio sigo las instrucciones de los desarrolladores del plugin README para instalarlo. En particular, instalar la gema, generar el fichero Gemfile, poner el código en el directorio _plugins y modificar el _config.yml.

  • Genero el sitio con jekyll build --watch y en _site lo tengo en estático.
  • Copio al sitio donde mantengo el repositorio local (donde edito, genero y publico los posts) el directorio _site/tags a la raíz (parte estática pages) , lo añado con git add y publico.
  • Ahora tengo el sitio servido por jekyll con las etiquetas en modo estático.

Los problemas de esta forma de trabajar parecen evidentes: necesito dos copias en local del sitio, el flujo de trabajo complicado (aunque se puede automatizar). ¿Las ventajas? Tratar de mantener en la medida de lo posible el funcionamiento en github.io obteniendo la funcionalidad que nos ofrezcan. Veremos si es acertado o será mejor cambiar más adelante pero … ¡Tachán! Tenemos etiquetas.

Próximamente: Entiendo que podremos generar las categorías de una forma parecida (espero que no haga falta una tercera copia). Nunca he recibido muchos comentarios, pero espero poder incluirlos de alguna forma: la gente utiliza sitios como disqus pero fantaseo con algo más cercano a GitHub (¿tal vez a través de las issues? Veo que no soy el primero que lo piensa en GitHub hosted comments for GitHub hosted blogs. La limitación será entonces que para usarlo será necesario estar registrado en GitHub pero … ¿Saben por qué me apunté yo aquí? ¡Justo! Porque alguien me sugirió que lo hiciera (vimblog.vim: publicar en wordpress.com fácilmente).

Seguiremos informando.

Leer código de otros y buenos consejos de programación

Letras en la terminal

Esta entrada casi es una promesa a mi futuro yo porque no he leído el código de Doom ni es algo que prevea que vaya a poder hacer próximamente.

En The Exceptional Beauty of Doom 3’s Source Code hablan justamente de eso, el código de este juego y muestran ejemplos de codificación e ideas que tal vez podrían resultarnos útiles.

Siempre me ha interesado leer guías de estilo de codificación y ese tipo de cosas de diversas empresas y proyectos porque es útil para saber lo que queremos (o no querríamos) hacer con nuestro propio estilo. Sí que leo con cierta frecuencia código de otros en GitHub y en los proyectos de programación de nuestros estudiantes, que de todo el mundo se aprende.

El código de los proyectos de software libre (y las normas/consejos) de los propios proyectos nos pueden servir para leer un buen montón de código que es algo que, me temo, no hacemos con la suficiente frecuencia.

Mostrar la contraseña en el formulario o no

Entrada

Aunque es un tema que trato de traer a la discusión cuando se habla del diseño del proceso de identificación/autentificación con un formulario, veo que sólo enlazamos hace algún tiempo en Algunas ideas para simplificar el proceso de identificación y autentificación a Innovative Techniques To Simplify Sign-Ups and Log-Ins donde se habla de eso y alguna cuestión más.

Se trata de la idea (extendida y aplicada) del enmascaramiento de contraseñas cuando nos estamos autentificando en un sitio. Lo cierto es que puede ser una buena idea, pero para muchos usuarios es una molestia y, seguramente, es mejor darles la oportunidad de decidir si están en un entorno donde la contraseña debería enmascararse o no. De eso habla Luke Wroblewski en Showing Passwords on Log-In Screens continuando con algo que ya anticipó en Mobile Design Details: Hide/Show Passwords y que es un nuevo factor al que deberíamos darle algunas vueltas antes de diseñar nuestro sistema.

Muestra varios ejemplos y aprovecha también para introducir algunas ideas nuevas relativas a la identificación biométrica (con los iPhones, fundamentalmente).

Una buena lectura si te interesan estos temas.

Publicar en Facebook las entradas de este sitio usando Python

Enlaces en Página de Facebook

Ya anticipamos esta entrada hace un par de semanas en Extraer enlaces de una página web. Allí hablábamos de formatear una entrada de este sitio (u otro que proporcione RSS) para publicarla en Facebook (o donde nos parezca, claro). También en Publicar en Twitter las entradas de este sitio usando Python vimos algunas ideas sobre este tema, entonces para Twitter.

En este caso utilizamos el API oficial de Facebook y un paquete no oficial que la implenenta en Python, Facebook Python SDK.

Podemos instalarlo

fernand0@aqui:~$ sudo pip install facebook-sdk

Para su correcto funcionamiento necesita BeautifulSoup y requests y tal vez algunos módulos más. Si no están instalados en nuestro sistema, recibiremos las ‘quejas’ correspondientes.

Para obtener las credenciales tenemos que registrar nuestra aplicación en Facebook My Apps. Hace falta ir al menú avanzado (es más fácil registrar aplicaciones web, la verdad) y se nos asignarán algunos identificadores (fundamentalmente el token OAUTH, que podemos mirar en https://developers.facebook.com/tools/explorer/APPID/?method=GET&path=me%3Ffields%3Did%2Cname&version=v2.2, donde APPID es el que nos hayan asignado), que en nuestro caso almacenamos en ~/.rssFacebook y leeremos desde el programa.

El programa es muy sencillo, se puede descargar en rssToPages.py V.2015-01-26 (enlazo a la versión actual por si en el futuro hago algún cambio).

Como decíamos arriba, empezamos leyendo la configuración relativa a los blogs de los que queremos leer para elegir uno. Si sólo hubiera uno se elegiría directamente:

config = ConfigParser.ConfigParser()

config.read([os.path.expanduser('~/.rssBlogs')])

print "Configured blogs:"

i=1
for section in config.sections():
	print str(i), ')', section, config.get(section, "rssFeed")
	i = i + 1

if (int(i)>1):
	i = raw_input ('Select one: ')
else:
	i = 1

print "You have chosen ", config.get("Blog"+str(i), "rssFeed")

Esta configuración debe contener una sección por blog y para cada uno de ellos contendrá la fuente RSS, el nombre de la cuenta de Twitter y el nombre de la cuenta de Facebook. Para este sitio tendría el siguiente aspecto:

[Blog1]
rssFeed:http://fernand0.github.io/feed.xml
twitterAc:mbpfernand0
pageFB:fernand0.github.io

También puede contener un campo más, linksToAvoid que se usa en el programa de extraer los enlaces para evitar algunos de ellos (lo uso en otro blog para eliminar los enlaces a las categorías).

if (config.has_option("Blog"+str(i), "linksToAvoid")):
	linksToAvoid = config.get("Blog"+str(i), "linksToAvoid")
else:
	linksToAvoid = ""

Leemos la última entrada del blog y extraemos el texto y los enlaces de manera similar a como hacíamos en Extraer enlaces de una página web.

Y para evitar los enlaces que no queríamos a la hora de generar el contenido de la página:

		print linksToAvoid
		print re.escape(linksToAvoid)
		print str(link['href'])
		print re.search(linksToAvoid, link['href'])
		if ((linksToAvoid =="") 
			or (not re.search(linksToAvoid, link['href']))):
			link.append(" ["+str(j)+"]")
			linksTxt = linksTxt + "["+str(j)+"] " + link.contents[0] + "\n"
			linksTxt = linksTxt + "    " + link['href'] + "\n"
			j =  j + 1

Finalmente, buscamos si la entrada contiene alguna imagen. Si no la hay no pondremos nada, pero Facebook lo hará su cuenta (puede ser nuestra foto, un botón, lo primero que haya). Tal vez podríamos configurar una por defecto cuando nuestra entrada no tenga una, si no nos gusta la que sale por defecto (en mi caso es mi foto; como no me gusta verla allí esto me obliga siempre a pensar en una foto para el post):

pageImage = soup.findAll("img")
#  Only the first one
if len(pageImage) > 0:
	imageLink = (pageImage[0]["src"])
else:
	imageLine = ""

Leemos la configuración para Facebook y empezamos a trabajar, solicitando la lista de páginas de las que somos administradores (el nombre de la página en la que queremos publicar lo habremos puesto en ~/.rssBlogs):

config.read([os.path.expanduser('~/.rssFacebook')])
oauth_access_token= config.get("Facebook", "oauth_access_token")

graph = facebook.GraphAPI(oauth_access_token)
pages = graph.get_connections("me", "accounts")

El fichero de configuración tiene este aspecto en este caso:

[Facebook]
oauth_access_token:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Podría haber más cuentas de Facebook, pero no lo he probado así que no garantizo que todo vaya a funcionar correctamente.

De las páginas que gestionamos se elige la que queremos (que se pone en el apartado de configuración del blog, ~/.rssBlogs).

for i in range(len(pages['data'])):
	if (pages['data'][i]['name'] == pageFB):
		print "Writing in... ", pages['data'][i]['name']
		graph2 = facebook.GraphAPI(pages['data'][i]['access_token'])
		graph2.put_object(pages['data'][i]['id'], 
			"feed", message = theSummary, link=theLink, 
			picture = imageLink, 
			name=theTitle, caption='',
			description=theSummary.encode('utf-8'))

statusTxt = "Publicado: "+theTitle+" "+theLink

Ya llevo más de un mes probando con un par de blogs y la solución parece que funciona bastante bien. Lo más molesto fue conseguir las credenciales y dar de alta la aplicación (con un ‘falso’ paso a producción; falso porque no la usa nadie más, al ser de escritorio).

Dudas, comenarios, ideas… ¡Hazme un pull request o un issue!