Creando extensiones para los navegadores

Como ya os he comentado, desarrollando mi nuevo proyecto NoMorePass, uno de los elementos fundamentales para que se usase la app era disponer de un plugin para el navegador que permitiese interceptar las páginas con usuario/password y entrar en las mismas con el protocolo seguro de NoMorePass. Aunque en principio solo quería hacer uno para demostrar lo que se podía hacer (el de chrome, por obvias razones), al final terminé desarrollando cinco para cubrir la mayoría de las necesidades. No voy a entrar en detalles ahora sobre la tecnología subyacente, lo que voy a hacer es contaros las principales diferencias entre cada uno de los ecosistemas para los que hice las extensiones y los problemas que nos vamos a encontrar.

Todas las extensiones que he programado han funcionado (que no es poco) y todas están en javascript, así que esa parte me la voy a saltar y voy a contaros los problemas que me encontré en orden cronológico.

Chrome

Aunque, a priori, creí que iba a ser el más complicado, porque partía de una base muy pobre en lo que a extensiones se refiere, al final no fue para tanto. La documentación que dispone en la web de developers de chrome es muy completa y con ejemplos que sirven para casi todo.

Probar la extensión es sencillo, solo hay que activar el modo desarrollador en la pestaña de extensiones y cargar el directorio en el que estamos trabajando… La depuración y lo demás es muy sencillo si estamos acostumbrados a inspeccionar o depurar páginas web.

La parte más “complicada” es cuando quieres distribuir la extensión. Hay una opción que te permite empaquetarla en un archivo .crx, peeeeeero, eso no sirve para nada ya que al abrir el crx con chrome te dice que no va a instalarte nada… Así que tienes que decirles a tus probadores que se descompriman el archivo y activen la parte de desarrollador (que es un rollo de explicar) o bien pasarlo al chrome web store… Es lo que hice y puedes dejar la extensión sin publicar para que lo usen tus probadores. Muy fácil y rápido. Eso si, te pueden banear la extensión (a mi me pasó) si la revisan y ven algo sospechoso. Lo bueno es que puedes explicar lo que pasa y como funciona y si todo está ok son muy rápidos en volverte a activar la extensión. Muy contento con esta parte.

Firefox

El segundo en preferencia es, como no, Firefox. Había oído que los .xpi ya estabán obsoletos y que ahora había que hacer extensiones más parecidas a las de chrome… Y tanto! El estandar webextension está bien documentado en la MDN y, el problema, es que no es un estándar maduro del todo. Está muy basado en las extensiones chrome a las que “copian” casi todo, por lo que es muy sencillo pasar de una a otra, pero con carencias importantes (que en mi caso me hicieron reescribir gran parte de la extensión). Lo prometedor del tema es que están avanzando y según los navegadores vayan incorporando las funcionalidades que faltan vamos a un escenario de muy, muy facil adaptación.

Mozilla te ofrece la función en el AMO (addons.mozilla.org) de subir tu extensión y que te la firmen para que la puedas dstribuir entre tus probadores sin que se queje mucho el navegador. Obviamente también puedes subirla a la página pública, pero ahí el tema varía mucho…. Subí una primera versión no del todo pulida y a los dos días me rechazaron la extensión y me dieron consejos para resubirla. Lo hice a los 30 minutos de recibir la respuesta pero, según lo que dicen, me metieron en la cola de revisión de los administradores y esa cola es EXAGERADAMENTE lenta. Hoy llevo ya 32 días esperando en esa cola y estoy todavía en el número 126:

A este paso a finales de mes igual tengo ya la extensión en la página de addons de Mozilla… Completamente desesperante.

Safari

A petición de mis amigos mac-queros estudié la posibilidad de realizar una extensión para Safari. Dejadme que os diga una cosa, es un puto infierno. Apple ha cambiado la forma de construir una extensión para que tengas que escribir parte del código en Xcode (Objective-c o swift) y otra parte en javascript y que tengas que utilizar un sistema infame de empaquetado para subirlo al itunes y que aparezca disponible. El caso es que lo hice, siguiendo todas sus intrucciones, y después de conseguir que funcionase en mi mac me encontré con la maraña de certificados, firmas, perfiles, etc. que me obligaron a cambiar el proyecto un poco… Con tan mala suerte que una vez subido a itunes resulta que no funcionaba ¡¡!!

Así que, recuperé la forma antigua de hacer las extensiones, puramente en javascript y con un esquema muy parecido a las de chrome y las webextensions y un empaquetado mucho más sencillo… Y generé un archivo que Safari puede instalar sin problemas y que puedo distribuir sin problemas… Una pena que Apple se empeñe con todo su alma en hacer las cosas difíciles a los desarrolladores.

Opera

Ya con todos los deberes hechos me pareció interesante ver el nivel de compatibilidad de las webextensions entre navegadores… Y decidí hacer la extensión para Opera. Mi sorpresa fue mayúscula cuando vi que la misma extensión de chrome funcionaba sin apenas cambios en opera (quité un par de cosas del manifest.json y poco más). Así que, ole por Opera! El proceso de publicación, no obstante, sigue siendo bajo revisión y tienes que subirlo (con mucha más info de la que deseaba) en https://addons.opera.com/developer/ y ahí sigue esperando revisión… El problema es que no se en qué puesto de la cola estoy ni cuanto tiempo va a tardar en llegar a estar disponible.

Edge

Y llegamos a la gran esperanza “windowsera”, visto que, según la documentación, edge permitía un esquema muy parecido a las webextensions de firefox me lancé al ruedo y, con una máquina virtual de windows10 profesional, empecé a adaptar la extensión de firefox.

La definición correcta para las extensiones de Edge es: ¡niseteocurraporDios! Después de un montón de horas lidiando con actualizaciones del sistema, con cuelgues, con malos funcionamientos del sistema de depuración y con mi bisoñez en el sistema conseguí que la extensión funcionase en desarrollo en mi máquina… Bueno, ahora distribuirlo…

Pues no es tan sencillo, ni mucho menos, después de gastarme 90 euros (75+iva) en darme de alta como desarrollador de microsoft para reservarme el nombre de la aplicación y poder subirla a la tienda de windows.. Resulta que la tienda no admite extensiones. ¡¡¡¡¡!!!!! y, lo que es peor, para distribuir el appx que consigo generar tengo que firmarlo con unos certificados que no tengo y que solo se pueden generar con extraños comandos que no te explican de donde salen (si al menos te dijeran como hacerlo con openssl) y luego el usuario tiene que instalarse el certificado en su máquina antes de instalar la extensión.. En suma, no se cómo distribuir esta extensión ni si merece la pena….

Según microsoft esto es lo que pasa:

Así que hay que pedir por favor, por favor, que te tengan en cuenta en esta url: http://aka.ms/extension-request

Y esperando estoy…

 

 

NoMorePass

¿Alguna vez habéis sentido como que se os olvidaba algo importante? ¿y si ese algo era un password de los que podías necesitar en cualquier momento? ¿y si el proceso para recuperar el password perdido fuese tan tedioso y largo que le quitasen las ganas a cualquiera? ¿y si habéis perdido, lo que es peor, el password de la cuenta de correo con la que teníais ligada esa password rebelde?

Todos esos problemas, y más me acuciaban día si y día también. Para asegurar tendía a poner el mismo password (o variaciones triviales) en todos los servicios en los que me registraba que eran, por cierto, incontables… Que si foros, que si demos, que si nuevos servicios, que si sitios oficiales, que si… Total, que al final solo confiaba en mi navegador para que me guardase los passwords, peeeeero, ¿y si alguien me pedía un rato el ordenador para cualquier cosa? ¿tendría acceso a mis passwords? Claro que si, por eso es tan seguro dejar el password en el navegador como en pos-it pegado en la pantalla… Un desastre, vamos.

Hablando, además, con un sobrino mío que también utilizaba el método de tener una libreta con todos los passwords (pues anda que no pierdo yo libretas, o que no son propensas a ser hojeadas por cualquier visitante inesperado), llegué a la conclusión de que debía hacer algo… Y lo he hecho, se llama nomorepass y te permite guardar de manera segura todas tus contraseñas en tu móvil, protegidas por una contraseña maestra y/o los sistemas biométricos (huella) del dispositivo y, lo que es mejor, te permite olvidarte de ellos sin problema, ¿cómo? Muy sencillo, nunca más tendrás que teclear un password, así que nunca te inportará qué password es y, por eso, podrás generar un password distinto para ca web o servicio, que ya se encarga el móvil de guardarlo y enviarlo a quien lo necesite.

¿Es seguro? 

Un montón, es imposible interceptar los datos necesarios para recomponer la password que estás usando.

Además, podrás sacar una copia de seguridad de tus passwords con la seguridad de que solo tu desde tu aplicación podrás volver a recuperarla, ya sea en tu teléfono o en otro nuevo (ya sabes, suele caer en sitios muy húmedos)

¿Es sencillo?

Apuntar con el movil a la pantalla y listo… No hay nada más facilito. Además, tendrás siempre contigo tus passwords, sin importar en qué ordenador estés.

Pero entonces, ¿me tengo que fiar de tus servidores?

No, te recomiendo que no te fies de nadie, ni siquiera de mi. Tus passwords nunca salen de tu móvil (al menos nunca en claro) y no se pueden almacenar en otro sitio y nunca está la clave de encriptación junto a los datos encriptados (ni siquiera en los backups)… Así que, no, no te fíes. Simplemente usa la app y se dueño de tus passwords, se acabaron los hackeos, filtraciones y demás problemas.

Me mola… ¿Qué hago para probarlo?

Directo a https://www.nomorepass.com allí tienes todos los enlaces e instrucciones…

La épica del informático

programmingHoy toca una entrada para alabar la tarea de nuestros trabajadores del conocimiento (eufemismo clase Dios) que son, como no, ninguneados e ignorados silenciosamente por el público en general y por sus jefes en particular. Pero esperad, antes de eso, un “mea culpa”… ¿Porqué los profesionales de la informática son tan despreciados en esta, una sociedad construida en base a su esfuerzo? Os diré mi opinión… Porque acostumbramos mal a nuestros clientes. Nos piden lo imposible y se lo damos, nos quejamos, nos revolvemos contra la ignoracia atrevida del que nos pide la luna pero finalmente cedemos y eso es lo que nos conduce inexorablemente a las mazmorras de nuestro propio talento.

Si alguien pide un presupuesto a un fontanero para que le ponga un grifo debajo de la cama (por estúpido que eso sea) y consigue un profesional que no se descojone de su ocurrencia y le de el presupuesto lo más normal es que consiga su grifo y nada más. Imaginemos la conversación:

  • Cliente: ¿Qué es esto que me has puesto aquí?
  • Fontanero: un grifo
  • Cliente: pero está debajo de la cama, ¿cómo voy a poder usarlo así?
  • Fontanero: es lo que pidió
  • Cliente: si, claro, pero es de sentido común que un grifo debajo de la cama debe tener algo que permita que se use desde encima de la cama
  • Fontanero: eso no es mi problema
  • Cliente: venga, no me vengas con esas, un grifo que no se puede usar no te lo voy a pagar.
  • Fontanero: es lo que has pedido y es lo que tienes que pagar
  • Cliente: ya, pero al menos harás que se pueda usar desde la cama
  • Fontanero: solo tienes que bajar de la cama y amorrate al caño
  • Cliente: eso no es práctico
  • Fontanero: ya ¿y?
  • Cliente: venga, me haces un apaño para que pueda usarlo desde la cama y luego te contrato la pila del baño
  • Fontanero: ni de coña, aquí tiene la factura.
  • Cliente: bueno, vuelve dentro de un mes y te pago junto con el resto de..
  • Fontanero: ahora
  • Cliente: esto…
  • Fontanero: ¿Pagas o me llevo el grifo y se te inunda la casa?

Bueno, algo así… Los clientes suelen ser más razonables con los fontaneros que con los informáticos, porque, total, seguro que a los informáticos les gusta hacer mal su trabajo y no ponen todas las cosas que tienen que poner porque son vagos.

¡Pues no!

Los informáticos, y los programadores principalmente, son héroes. Gente que consigue lo imposible, que cumple con requisitos inverosímiles, que estira el tiempo disponible hasta lo absurdo para conseguir terminar algo que, probablemente, luego sea mal juzgado por algún ignorante en la materia. Los programadores más experimentados crean obras de arte en unas líneas de código que, aunque podrían ser admiradas en museos donde otros programadores no puedan más que deshacerse en halagos, al final son ejecutados una vez por alguien que no está preparado ni para programar una lavadora y obtienen un comentario estúpido sobre el número de clicks que hay que hacer… Estos héroes anónimos mueven nuestro mundo, allí donde mires hay un programa que escribió alguien, que hace más sencilla tu vida, o que te permite hacer cosas impensables hace solo unos años. Estos héroes sin nombre que, por lo menos en España, están mal pagados, mal vistos (como si picar código al azar en un editor fuese programar), mal dirigidos por gente sin criterio y sin empatía. Formando parte de hojas excel que los mide en kilos de carne y los vende y los compra a otros patanes con ínfulas que creen que hacer informática es un simple problema de coste.

Por todo ello, amigo gerente, si alguna vez un programador te intenta explicar lo difícil que es conseguir algo, entiéndelo como un cumplido que te hace intentando dejar que veas una porción pequeña de su complejo mundo interior. Intenta comprender que no te está intentando dar una excusa, sino describiéndote el peligroso campo de batalla en el que va a meterse en tu nombre y dar hasta su última gota de sudor y sangre para acabar con el enemigo y conseguir esa funcionalidad que tu describes en una frase pero que eres completamente incapaz de explicar en sus detalles (o, simplemente, no quieres hacerlo por pereza).

Día a día, proeza a proeza, sin parar, sin esperar recompensa, sin aparecer en los libros de historia (ni siquiera viendo reconocida su propiedad intelectual muchas veces), el programador anónimo sigue siendo el motor de esta sociedad y, desde aquí mi más sincero agradecimiento a todos ellos. Y, por favor, dejad de tratar a los gerentes como niños, que ellos no quieran escuchar los problemas no significa que estos no estén ahí y que merezcan verlos con sus ojos… Igual así despiertan y os empiezan a tratar como lo que sois, los nuevos magos de la tecnología moderna.

Internacionalizar una web en php

main_icoDespués de muchos meses trabajando en una aplicación que, por azares del destino, alguien decidió que se realizase en php utilizando como frontend Drupal (del que solo se utiliza el sistema de registro y poco más) y después de infinitos test de usuarios (que nunca son suficientes) y después de generar un proyecto con 31.000 líneas de código propias (el total sin contar drupal suma más de 203.000) llega el momento de venderlo.

El primer cliente siempre es el peor, pero es que el segundo ¡es holandés! y, claro, lo quiere en inglés… Y algún lumbrera le asegura que tendrán la versión en inglés ¡¡en una semana!!. Lo bonito del tema es que cuando aseguró eso no preguntó a nadie del equipo de desarrollo. ¿Para qué? Las fechas las ponen ellos, qué más da que sea algo imposible.

Total, que, de casualidad, nos enteramos de que hay que hacer este “pequeño” cambio, las traducciones no serán un problema, porque tenemos gente que puede hacerlo bien y rápido, pero, ¿cómo internacionalizamos el php? La parte que cubre Drupal (y que podría traducirse desde el mismo sistema) es mínima, en total tenemos 425 archivos php donde hay textos en castellano en cualquiera de ellos, además, parte en html, parte en php y parte en javascript… Cualquier otro programador hubiese presentado su carta de renuncia o hubiese pedido una baja laboral. Además, ya nos han dicho que no piensan pagarnos las horas extras y que si cometemos errores tendremos que arreglarlos en nuestro tiempo libre.. ¡Eso si que son condiciones laborales y no las de los mineros de asturias!

Sin embargo mi responsabilidad como profesional me obliga a atender las peticiones por absurdas que sean e intentar dar soluciones… Así que os pongo un resumen de lo que hicimos:

Problema número 1: qué sistema de internacionalización usar.

Al contrario que Java, que dispone de un sistema i18n con properties desde el principio, php adolece de este mecanismo estandar. Después de valorar varias opciones (muchas usadas en programas populares como prestashop, etc.) descubrimos que lo mejor es utilizar gettext.

Gettext es un proyecto GNU que, afortunadamente, es utilizado muy ampliamente en Linux para proporcionar internacionalización a sus programas. Es por ello que está presente en la mayoría de las distribuciones (incluyendo las que usamos para desarrollo y pruebas) y, además, tiene un módulo para php que también está normalmente incluida en las instalaciones normales de php (incluso en XAMPP está).

¿Cómo funciona gettext? Básicamente se basa en localizar todas las cadenas de texto ya escritas y sustituirlas por una función que la traduce. En el caso de php esta suele ser la función gettext(‘cadena’) o, abreviada _(‘cadena’). De esta forma, el texto en html:

<p>Esto es un texto</p>

Lo modificaremos en:

<p><?php _("Esto es un texto")?></p>

Luego el sistema localizará, según los parámetros de idioma, su traducción y la escribirá. Si no encuentra ninguna escribirá esa misma cadena.

Así que el primer, y más tedioso, problema es sustituir todas las cadenas de texto en nuestro programa por estas sustituciones. No hay una forma única y automatizada de hacerlo, porque podemos encontrarnos texto dentro del código php, dentro de etiquetas html o incluso dentro de código javascript y dependiendo de dónde se encuentre esa cadena deberá traducirse (o no).

Problema número 2: traducir las cadenas

Una vez que tenemos “marcadas” todas nuestras cadenas, deberemos generar un archivo con las traducciones… Esto ya es más sencillo de automatizar porque podemos utilizar herramientas que ya existen. La más adecuada es poedit. Esta herramienta nos permite escanear directorios de fuentes y almacena las cadenas que no están traducidas en un catálogo para después permitir que un traductor las vaya traduciendo sin tener que saber nada de php.

Antes de utilizar poedit es muy recomendable que establezcamos las rutas de los directorios donde vamos a guardar los catálogos traducidos. Generalmente esto se hace en el directorio raiz de la aplicación creando estos directorios:

locale/xx_XX/LC_MESSAGES

donde xx_XX es el código del idioma y país (en_GB en nuestro caso). Dentro de cada uno de esos directorios almacenaremos los .po (y .mo que compilamos) que generaremos con poedit.

Una vez creados los directorios, arrancamos el poedit y lo configuramos indicando que el directorio principal será “.” y los directorios a escanear serán ../../../ (suponiendo que hemos respetado la estructura que os he comentado). También es importante el tema de los plurales que, en caso del español sería:

nplurals=2; plural=n != 1;\n

Una vez todo en su lugar solo tendremos que actualizar para que poedit busque en todos los archivos y nos encuentre todas las cadenas que se pueden internacionalizar. Utilizando el mismo programa podemos hacer que los traductores nos traduzcan las cadenas y nos devuelvan el mismo .po ya traducido.

Problema número 3: hacer que el sistema use el idioma del usuario

Para que funcione gettext para php hay que incluir las siguientes líneas al principio del script:

putenv("LC_ALL=$locale");
setlocale(LC_ALL, $locale, 'english');
bindtextdomain("messages", __DIR__."/Locale");
bind_textdomain_codeset("messages", 'UTF-8');
textdomain("messages");

Lo relevante ahí es que $locale ha de contener el idioma (en_GB) messages es el nombre que tiene el catálogo poedit (así tendremos un messages.po en el directorio correspondiente) y que a bindtextdomain hay que pasarle el directorio donde hemos colocado nuestros locales.

Para el caso de drupal vamos a utilizar el idioma que el usuario ha puesto en su perfil, por lo que el código adicional a utilizar es:

global $language;
$locale = $language->language;
if ($locale=='en')
    $locale="en_GB.utf8";
else
    $locale = 'es_ES.utf8';

Esto es así porque los locales han de ser tal como están en el sistema operativo y, sin embargo, los idiomas en drupal solo indican el idioma y no el locale.

Seguimos en ello (hay muchos archivos) y además, nos queda pendiente la internacionalización de los correos y de los informes que generamos… Seguiremos informando.

Los errores SI se pagan

Tengo un jefe que dice que su empresa no paga errores y que las tareas dedicadas a depurar y corregir errores deben hacerse en el tiempo libre.

human-error-in-finance-640x324A mi, que no soy muy dado a cometer errores y que tampoco dispongo de mucho tiempo libre eso me parece simplemente una barbaridad, y no solo porque estemos hablando de ingeniería del software, sino porque estamos hablando, en general, de trabajo hecho por humanos. Es completamente imposible asegurar que el 100% de un trabajo realizado por un ser humano está exento de errores, enmiendas u omisiones. Decir que solo se paga por el trabajo “perfecto” es como decir que te están pagando solo una fracción del tiempo que dedicas. Y eso, simplemente, es explotación.

Según Frederik P. Brooks, Jr. El autor, entre otros, del conocidísimo libro “The mythical Man-month” y autoridad donde las haya en el campo de la ingeniería del sofware, el 50% del tiempo total de un proyecto software debe dedicarse a pruebas, depuración y corrección de errores. ¡Un 50%! más tiempo que el dedicado a programar o a cualquier actividad de gestión. ¿Eso significa que si se hubiese aplicado la política de “yo no pago errores” el software habría salido por la mitad de precio? No, significa que los errores en el software son inevitables y que el buen software no es el que se construye sin cometer errores sino el que se hace teniendo siempre presente que los errores están ahí y hay que corregirlos antes de sacar nada al mercado.

Escudarse en la excusa de que un programador experimentado es el que no comete errores, es una falacia completa. El programador experimentado es aquel que ya ha cometido más errores y, por tanto, tiende a no volver a cometerlos o, al menos, a reconocer los errores cuando los encuentra más rápidamente que otro programador que no ha tenido esa experiencia. Además, muchos “errores” no son más que malas interpretaciones de requisitos o malas integraciones de sistemas distintos que no se habrían podido evitar sin cambiar las políticas de comunicación de la empresa (¿alguien recuerda el pufo de las distintas unidades de medida en la Mars Climate?).

Por más controles que se pongan, por mejores herramientas que se utilicen, por más que estemos concentrados en lo que hacemos el 100%, es imposible evitar la introducción de errores en el código que se produce. Las tareas de pruebas y depuración son muy importantes y determinantes a la hora de medir la calidad del resultado final. Intentar no pagar por esas horas es como invitar a alguien a comer y decir que los entremeses y el postre lo tiene que pagar él. ¿Qué invitación es esa?

Espero que vosotros no os encontréis esta situación que, por otra parte, no debería darse entre gestores formados y experimentados en el campo de la ingeniería del software. Hora que trabajas, hora que se paga. Si eres malo en lo que haces te pagarán menos por cada hora y terminarás en la calle, pero si eres bueno, igualmente cometerás errores (y los corregirás) en horas pagadas acorde a tus habilidades. El resto son milongas.