Categoría: Herramientas

Cada vez es menos habitual transportar información en dispositivos físicos. Lo normal es compartirla por Internet, ya sea subiéndola a un servicio de hospedaje de archivos o bien mandándola directamente por correo electrónico. Pero hay veces que tenemos varias gigas de material y utilizar este tipo de servicios no es práctico, por lo que recurrimos a otros sistemas de almacenamiento de datos, como un disco externo, que deberemos transportar físicamente.

Incluso tomando las precauciones adecuadas puede suceder que nos olvidemos, perdamos o nos roben el dispositivo de almacenamiento. Probablemente a nadie le interese un pepino nada de nuestros proyectos, pero si el material es delicado no está de más poner algún tipo de barrera para que esta situación no se nos vaya de las manos.

La buena noticia es que los sistemas operativos más utilizados ya llevan mecanismos para hacer esta función: en el caso de Windows es BitLocker y en Mac es FileVault. Ambos permiten convertir nuestro disco, o parte de él, en un almacenamiento cifrado que al ser conectado a nuestro equipo desbloquearemos mediante una contraseña u otros métodos criptográficos. A partir de ese momento podremos utilizarlo de forma convencional, realizándose el cifrado y descifrado sobre la marcha.

El principal problema de estos sistemas es que son exclusivos de cada sistema operativo. BitLocker sólo funciona en Windows (integrado a partir de Windows 7 y con una aplicación llamada BitLocker To Go Reader disponible para Windows Vista y XP) y FileVault sólo en Mac.

Si no usáis el mismo sistema operativo que vuestro cliente podéis probar la alternativa libre VeraCrypt, un sucesor del más conocido TrueCrypt, actualmente abandonado, que está disponible para Windows, OSX y GNU/Linux. Aunque usar VeraCrypt tiene un inconveniente importante: tendréis que ser administradores del equipo de vuestro cliente para poder instalarlo (o para simplemente ejecutarlo si lo lleváis en vuestro disco), lo que en muchos casos como supondréis no es algo viable.

Si no sabéis qué equipo tendrá vuestro cliente y queréis la tranquilidad de llevar los datos cifrados, mi consejo es utilizar un disco con tres particiones: una cifrada con BitLocker, otra con FileVault y otra sin cifrar por si las moscas (donde podéis incluir VeraCrypt u otra aplicación de cifrado de archivos).

Todos estos sistemas, especialmente FileVault y BitLocker (que son privativos, de código cerrado), son susceptibles de tener agujeros de seguridad, pero siempre serán un buen disuasivo para aquél que encuentre un disco al lado de la taza del café que nos acabamos de tomar.

Actualización: Desde que escribí esta entrada se han hecho cambios que afectan a mi opinión sobre este servicio: Google ya no requiere la utilización de tu nombre real ni la vinculación obligatoria con una cuenta de Google+. 

Cada vez es más habitual que algunos de mis clientes utilicen Google+ Hangouts para su mensajería instantánea y videoconferencia.

Y siempre hay un silencio incómodo cuando yo les digo, tímidamente, que no quiero utilizar Google+ Hangouts.

No tengo nada especial en contra Google. Al menos nada que no tenga contra otras muchas empresas. Tengo un teléfono Android, una cuenta de Gmail y miro vídeos de gatos en Youtube. Y cada vez me importa menos que Google sea una empresa que eluda el pago de impuestos en España, que abuse de su posición dominante para entrar en otros sectores, que lógicamente acate las peticiones de censura de los gobiernos de turno o que contribuya a nuestro humano sesgo de confirmación de forma artificial. Todo esto es lo mismo que hace Microsoft, Apple o Amazon. Son problemas importantes, pero no son mi preocupación principal.

Lo que me molesta es que el precio a pagar por usar un servicio aparentemente gratuito sea nuestra privacidad.

Puede parecer anecdótico, pero Google+ Hangouts guarda todas las conversaciones textuales que hacemos a no ser que indiquemos lo contrario. Esto significa que aunque a nosotros no nos interese guardar una conversación, puede que nuestro interlocutor sí lo esté haciendo. Esta información se guarda con su perfil de Google y ayuda a la empresa a seguir definiendo una identidad digital para esa persona.

Nada impide técnicamente, obviamente, que Google haga lo propio en un futuro con las conversaciones de voz.

Pero esto es sólo la punta del iceberg. Quien quiera unirse a una reunión con Google+ Hangouts debe tener una cuenta de Google+. Vamos, que el asistente acaba:

• Con una cuenta de correo electrónico de Google (Gmail)
• Dado de alta en una red social generalista como Google+ (ya no), donde es requisito utilizar el nombre real (ya no) y donde el perfil obligatoriamente es público.
• Aceptando unos términos y condiciones que, entre otras cosas, dan el consentimiento a la empresa a utilizar datos personales explícitos (datos introducidos) e implícitos (datos recogidos como la posición geográfica, historial de búsquedas, etc.) para ofrecer resultados de búsqueda relevantes y publicidad personalizada.

Yo he pasado por todo esto. He hecho reuniones vía Google+ Hangouts. He creado perfiles falsos en Google+. Pero el tema está en que no quiero volver a hacerlo. Me molesta. Me indigna vender mi privacidad para algo tan mundano como una videoconferencia. Pero este mi problema, mi decisión. Lo verdaderamente grave es contribuir a que otras personas se sientan prácticamente obligadas a hacer lo mismo en un entorno donde es tan complicado decir “no” como es el profesional.

Y me encantaría acabar ofreciendo la solución, esa perfecta alternativa a Google+ Hangouts de protocolo abierto, descentralizada, libre, extendida y útil.

Pero si existe no la conozco.

¿Pero implica eso no hacer nada? Existen opciones cojas pero que, al menos, no obligan a los participantes de la reunión a registrarse en ningún sitio. Todos conoceréis cuáles son.

Si hay algo que me revienta de las herramientas de prototipado en general, y de Axure RP en particular, es el sistema de creación de layers.

En Axure RP si queremos crear un layer dinámico, esto es, una simple capa o ventana modal que aparece o desaparece según ciertas condiciones, nos vemos obligados a que al prototipar esté presente en el diseño de la pantalla que lo usa.

Esto, hasta donde yo sé, es inevitable, pero utilizo algunos “trucos” para hacerlo más llevadero:

1. Cada layer es un master que contiene un dynamic panel oculto predeterminadamente (“Set hidden”) con todos los contenidos dentro.
2. Si hay algún elemento dentro el propio layer que lo cierra vía OnClick, se define la interacción dentro el propio master con dos acciones: ocultar el panel dinámico de marras y enviarlo al fondo (“Hide Panel” y “Send Panel to Back”)
3. Todos los layers usados habitualmente se introducen en un nuevo master “padre” con un comportamiento “Place in background”.
4. Se incorpora el master “padre” a las pantallas necesarias.
5. Cuando se deba mostrar un layer se define una interacción que muestre el panel dinámico, lo mande a primer plano y lo mueva al punto requerido (“Show Panel”, “Bring Panel to Front” y “Move panel”).
6. Toda interacción que deba existir entre el layer y la ventana se define mediante raised events.

Todo esto puede parecer un poco engorroso, pero…

• Tener un panel dinámico en el propio master permite que ocultar el layer sea responsabilidad del propio layer, así definimos la interacción una sola vez.
• Tener todos los masters juntos permite agilizar la creación de nuevas pantallas. De esta forma no tenemos que estar continuamente añadiendo masters y en el momento de definir una interacción están todos presentes.
• Que el master sea un “Place in background” nos permite trabajar con la pantalla sin que sus layers nos molesten.
• Usar el z-indez (“Bring Panel to Front” y “Send Panel to Back”) asegura que el layer no se sitúe por debajo de otros elementos interactivos cuando está visible o quede accidentalmente por encima cuando está oculto.
• Usar el “Move panel” nos permite que la posición del layer sea dinámica y a la vez tener todas las ventajas anteriores.

Y recordad que las interacciones no es necesario definirlas una y otra vez. Los casos (“case”) se pueden copiar/pegar o, incluso, introducir en un image map que, a su vez, podría ser un master. Este último ya me parece especialmente rebuscado y no lo he hecho nunca, pero imagino que si se quiere trabajar a un nivel de interacción de muy alta fidelidad puede ser útil.

En Axure RP 7 hay interesantes novedades sobre este tema, así que con un poco de suerte esto se vuelve obsoleto en poco tiempo.