Presentando node-firefox

14 mayo, 2015 4:07 por

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Marisol García Obando

Nota: Presentamos este proyecto el pasado domingo en el FOSDEM. Como no todos podrían llegar a Bruselas, aquí tienes un post explicando qué es node-firefox y cómo puede ayudar súpercargar el desarrollo de aplicaciones para Firefox OS!

En Mozilla siempre estamos buscando maneras de hacer que la vida de los desarrolladores sea más fácil. Cuando los aspirantes a desarrolladores de aplicaciones nos dijeron que era incómodo empezar a escribir Open Web Apps, trabajamos en convertir App Manager en un entorno más amigable para los principiantes, que a su vez dio paso a WebIDE. Esta herramienta simplificó muchas acciones que eran lentas y tediosas antes, como la creación de una nueva aplicación, la descarga y la instalación de simuladores o ejecutar y depurar aplicaciones.

Pero todavía había un segmento de desarrolladores que se sintió excluido: ¡los usuarios avanzados! Ellos ya tienen sus cadenas de herramientas (toolsets) de desarrollo basadas en node.js, con tareas tales como la optimización de recursos, sugerencias de código, o pruebas de ejecución. A menudo utilizan también herramientas como Browserify, y tal vez ni siquiera escriben JavaScript, favoreciendo alternativas como CoffeeScript en su lugar, pero todas estas herramientas requieren que se construya la app o sitio web antes de enviarlo nuevamente a un dispositivo o recargar el navegador.

En esencia, le estábamos diciendo a estos desarrolladores que abandonaran sus amadas líneas de comandos (o atajos de editor) para ir a WebIDE y hacer click para desplegar la aplicación, y luego regresar a su editor de elección. Por unanimidad contestaron: «¡A nosotros no nos gusta hacer click! ¡Nos gusta el terminal! »

¿Cómo lo podemos hacer más eficiente?

A los desarrolladores no les gustaba esto, dado que requería cambiar contexto. Si hay una cosa que a los ingenieros les gusta más que construir cosas nuevas, es probable que sea la optimización de los procesos.

Puesto que ya tenemos un script de construcción, el único paso que queda para conseguir nuestras aplicaciones en el ambiente de ejecución es desplegarlo, y eso es en lo que estamos utilizando el WebIDE. Así que la pregunta obvia sería: ¿podemos hacer lo que está haciendo WebIDE, pero mediante programación?

Servidores y actores

Todo ambiente de ejecución del Firefox tiene algo llamado el remote debugger server (servidor de depuración remota). Esto no está activado por defecto, por razones obvias de seguridad, pero cuando está activado, los clientes pueden conectarse a él y tomar ventaja de sus diversas funcionalidades, tales como la instalación de aplicaciones, el acceso a la consola, etc. Y esto es lo que WebIDE hace internamente.

Cada una de estas funcionalidades es proporcionada por un actor. Por ejemplo, supongamos que queremos un listado de las aplicaciones instaladas. Lo que hacemos es:

  • primero buscar el actor webApps
  • a continuación, ejecutar el comando getAll
  • y obtener una lista de aplicaciones como respuesta

Otro ejemplo sería la instalación de una aplicación empaquetada o packaged app. Los pasos serían:

  • primero descomprimir el contenido de aplicaciones, utilizando cualquier biblioteca o la manera que gustes
  • a continuación, obtener el actor webApps
  • llamar al comando uploadPackage con el actor webApps en el contenido del archivo ZIP
  • el resultado de esta llamada es un actor File
  • llamar al comando install en el actor webApps usando el actor File
  • ¡listo!

Por lo tanto toda la magia de la instalación de aplicaciones no está en WebIDE- ¡está en los servidores! Podemos aprovechar esta magia mediante programación, pero la construcción de un cliente desde cero implica establecer conexiones TCP y análisis de paquetes, que no es lo que queremos hacer: ¡deseamos escribir aplicaciones y descargarlas a los dispositivos en su lugar!

Pero no se desesperen, node-firefox traerá eso para ustedes. No es una pieza monolítica de código, sino una serie de módulos de node.js, cada uno de ellos realiza una tarea diferente, alojado en su propio depósito independiente y publicado en el npm-registry como buenos ciudadanos modulares. Podemos utilizar muchos de ellos como sea necesario en los scripts o en los ejecutores de tareas, y por lo tanto se puede finalmente construir y ejecutar una aplicación sin tener que abandonar las líneas de comandos.

Demuéstralo, no lo digas

Pero basta de hablar y describir; ¡veamos cómo escribir un script que inicia un simulador!

Primero instala el módulo en el proyecto, utilizando la npm:

npm install --save node-firefox-start-simulator

Y este es el script:

var startSimulator = require('node-firefox-start-simulator');
 
startSimulator({ version: '2.2' })
  .then(function(simulator) {
    console.log('Listening in port', simulator.port);
  });

¡Eso es todo! Con sólo unas cuantas líneas de código puedes iniciar una versión 2.2 del simulador programáticamente. No hay que preocuparse por la versión, puedes simplemente no pasar nada a startSimulator y se iniciara en el primer simulador que encuentre:

startSimulator().then(function(simulator) {
  // your code
});

Podemos verlo en acción. Aquí lo vemos iniciar un simulador, instalar una aplicación y ejecutarla, todo esto desde un script de node.js:

Ejemplo 1 - iniciar simulador

El código de este ejemplo es en realidad el ejemplo para el módulo de node-firefox-uninstall-app. Cada uno de los módulos de node-firefox vienen con una carpeta de ejemplos («examples») para que se pueda empezar rápidamente.

Como mencionamos al principio, muchos desarrolladores web que cambian a desarrollo de aplicaciones quieren seguir usando los task runners o ejecutores de tareas, por lo que también escribimos un ejemplo de cómo utilizar node-firefox con gulp.

Vamos a ejecutar la tarea default-one. Ésta inicia un simulador, despliega una aplicación y un para un poco más de reto también se mantiene atento a los cambios de estilo en CSS. Si editas y guardas cualquier estilo de la aplicación, el vigilante de archivo detectará el cambio, y enviará los nuevos contenidos de los archivos al ambiente de ejecución, que sustituirá sobre la marcha sin tener que parar, entrar y reactivar toda la aplicación. ¡Mira cómo cambio el color de fondo de azul oscuro austero al eterno rosa de Paul Rouget!

Ejemplo 2 - monitoreo de CSS

Recargar el CSS en vivo es realmente genial para crear y experimentar con interfaces de usuario.  No tener que recargar la aplicación y navegar a la sección en la que deseamos trabajar ahorra mucho tiempo – ¡ojalá lo hubiera tenido cuando estaba programando aplicaciones en Android!

Pero podemos superar esto. La tarea default-all hará lo mismo que default-one, pero para todos los simuladores instalados en el sistema, para que se puedan ver los efectos de los cambios de estilo CSS en todos los simuladores al mismo tiempo:

Ejemplo 3 - todos los simuladores

Desafortunadamente, hay un bug en los simuladores 2.1 y 2.2, y en ellos que no recargan  los cambios de estilo, pero ha sido presentado y será arreglado.

¿Qué podemos hacer hasta ahora?

El conjunto actual de módulos permite buscar puertos en los que están escuchando ambientes de ejecución, buscar e iniciar simuladores; conectarse a ambientes de ejecución; buscar, instalar, desinstalar e iniciar apps, y recargar los estilos.

Filosofía

Puedes haber notado un patrón ya, pero sólo en caso de que no sea lo suficientemente evidente, estamos tratando de escribir módulos deliberadamente simples. Cada módulo debe realizar una sola acción, regresar un Promise y utilizar el menor número de dependencias como sea posible.

Los módulos pequeños son más fáciles de entender, usarlos y probar. Además, la mayoría de las futuras APIs Web están diseñadas para trabajar con Promise, y queremos escribir código para el futuro, no para el pasado. Además, la reducción del número de dependencias también hace que sea más fácil para la gente nueva empezar a contribuir en un módulo, ya que hay menos nuevos elementos desconocidos a entender.

Por último, ya que todos los módulos funcionan de la misma manera, cuando sabes cómo usar un módulo sabes cómo utilizar el resto, lo único que cambia son los parámetros, y el resultado.

Ideas (o: lo que no podemos hacer aún)

Hay una serie de cosas que nos gustaría ver que suceda en el futuro. Algunas personas las llaman funciones, pero yo las llamo “ideas soñadas».

Uno recurrente es la WebCLI: una contrapartida equivalente a WebIDE, donde todo lo que puedes hacer con WebIDE se podría hacer con una herramienta de línea de comandos. Yo sigo alternando entre «esta es una buena idea» y «tal vez no necesitamos esto en absoluto y una biblioteca de tareas es suficiente», pero a la gente parece gustarle la idea, ¡así que tal vez no es tan mala!

Otra gran característica sería la capacidad de adjuntar el depurador DevTools a una aplicación que fue iniciada desde la línea de comandos, pero acaba de hacer crash. El iniciar aplicaciones desde la línea de comandos es bueno, pero los depuradores de línea de comandos no son tan emocionantes. ¿Por qué no usar lo mejor de ambos mundos?

O tal vez sería estupendo poder controlar cualquier navegador desde la línea de comandos, a través de Valence!

Y, por último, mi idea favorita: ediciones personalizadas de Firefox OS. Imagínate si pudiéramos escribir un script que creara un Firefox OS «en blanco», poner nuestras aplicaciones favoritas y ajustes, y generar una imagen completa de Firefox OS que pudiéramos entonces instalar en dispositivos. Y ya que no es un binario sino un script, podríamos publicarlo en su repositorio, y otras personas podríamos remezclar y construir ediciones propias de Firefox OS.

¿Cómo hacemos para llegar allí?

Todavía hay un largo camino por delante, y muchas áreas que necesitan trabajarse. Quizás la tarea más urgente es conseguir un mejor soporte multiplataforma. De momento sólo podemos interactuar con ambientes de ejecución a través de la red, pero no con dispositivos físicos. Además, el soporte en plataformas distintas de Mac OS carece en gran medida.

Las pruebas es otro aspecto importante. Si realizamos pruebas temprano, frecuente y profundamente vamos a ser capaces de detectar problemas como el fallo en CSS que he encontrado cuando construía el demo con gulp. Queremos que estos módulos se ejecuten en varias plataformas y que conecten con otras plataformas diferentes, incluyendo los dispositivos físicos.

¡Por supuesto que necesitamos más módulos, y más ejemplos! Para asegurarnos de que no hay dos personas escribiendo el mismo módulo, estamos discutiendo y proponiendo nuevos módulos en la sección de incidencias (issues) del proyecto principal. Y nos encantaría ver más ejemplos, o incluso sólo mejores ejemplos que se enganchan a la funcionalidad existente en otros módulos de node con nuestro código. Por ejemplo, se podría añadir la validación de manifiesto a través del módulo firefox-app-validator-manifest.

Y, como siempre, te necesitamos. No somos tú, así que no podemos saber qué necesitas o qué pensamientos pasan por tu mente. Y ciertamente no podemos utilizar el software de la misma manera que lo utilizas. ¡Necesitamos tu opinión y tus aportes!

Estamos deseando ver lo que se crea con node-firefox. Reporta incidencias, o habla con nosotros en el IRC si tienes preguntas. Estamos principalmente en los canales #apps y #devtools en irc.mozilla.org.

Gracias

Sería deshonesto no dar las gracias a Nicola Greco, fui su mentora el verano pasado, cuando fue pasante en Mozilla. Se le ocurrió la idea inicial de la construcción de módulos de node individuales que ayuden a desarrollar aplicaciones Firefox OS. Vean su presentación final de prácticas, ya que es muy entretenida e ilustrativa.

Muchas gracias a todos los (infinitamente pacientes) DevToolers Ryan Stinnett, Alexandre Poirot, Jeff Griffiths y Dave Camp, quienes ayudaron a encontrar el camino en servidores remotos, los actores y otras cosas, y enormes gracias a Heather Arthur que escribió firefox-client e hizo que la escritura de node-firefox fuera más agradable de lo que hubiera sido de otra manera.

The following two tabs change content below.

jorgev

AMO Product Manager at Mozilla
Jorge trabaja para el equipo de complementos de Mozilla, y se dedica a Mozilla Hispano y Mozilla Costa Rica en su tiempo libre. Actualmente está encargado del blog de Mozilla Hispano Labs.

Compartir artículo:

  • ¡Participa!

    Colabora con la comunidad »
    En Mozilla lo importante son las personas. Descubre cómo puedes colaborar.

    Boletín Firefox

    Suscríbete al boletín de novedades de Firefox.

  • Descargas

    Descarga los programas de Mozilla.

    Lo más visto

    cc-by-sa