Interfaces multiplataforma basadas en electron

 

Introducción:

Cada vez queda más patente la necesidad de hacer aplicaciones multiplataforma
que se adapten a dispositivos de todos los tamaños de la forma más general posible para evitar en la medida de lo posible el tener que hacer varias versiones distintas y poder ahorrar tiempo y dinero.

Uno de los principales problemas que han tenido los desarrolladores de iOS, ha sido el ver como con el paso de los años, una única interfaz de tamaño determinado ha sufrido cambios y han tenido que adaptarse en este proceso. Por su lado, Android, abordaba esta temática con su sistema de layouts, no era ni es un sistema perfecto pero facilitaba bastante el desarrollo en un ecosistema tan variado como lo es el de Android.

Mientras tanto, Apple fué sacando sobre la marcha un sistema de constrains (restricción) que desde mi punto de vista era una chapuza que no solucionaba ni facilitaba la vida a los desarrolladores. Únicamente los más veteranos y centrados profesionalmente en esta tarea sacaron provecho en su trabajo. Sin duda, este sistema era insuficiente para los que no teníamos tantos desarrolladores con experiencia para afrontar desarrollos de un nivel de calidad alto.

Entre todo este jaleo, y aun siendo bastante reticente al paso web para usar como interfaces, me he fijado en la tecnología que ofrece electron y en sus posibilidades. La conocí a traves del editor de Software libre, Atom, y está enfocada a hacer interfaces siguiendo el MVC (modelo vista controlador)
que es justo la pieza que me faltaba en el desarrollo de aplicaciones multiplataforma (Android, iOS, escritorio...) donde se busca delegar la lógica de negocio a una librería en C++, scripts python, o directamente en una libreria javascript, puede tener sentido utilizar algo tan extendido como es la combinación de JS, HTML, Bases de datos, json, y muchas otras tecnologías web, que aun (a mi parecer) lejos de ser perfectas y todo lo ordenadas
y estrictas como a mi me gusta en un desarrollo, con una metodología adecuada y una buena organización creo que sería posible delegar algo tan importante como es hoy en día lsa interfaces rápidas y visualmente atractivas a una parte de una aplicación.

Estas tecnologías combinadas con la versión 2 del framework Angular 2  promete ser una poderosa herramienta para afrontar este reto. Este utiliza MongoDB para manejo de datos, Express.js como framework de servidor, y utiliza Nodejs como ayuda del entorno de ejecución. Angular pone énfasis en la programación declarativa, esto es el QUE quiero hacer, y no tanto COMO lo quiero hacer. De esta forma se puede generar interfaces de usuario que sin entrar en la complejidad del funcionamiento, pueden ser el complemento a
aplicaciones que si lo sean. La wikipedia ofrece algo más de información.

Con el tiempo os contaré mis impresiones tanto en los aciertos como en los fracasos, para todo aquel que pueda estar interesado en estos temas pueda tener un experiencia en la que apoyarse para tratar de usar esta tecnología
en la resolución de este complejo problema. Mi idea es utilizarlo en varios proyectos que tengo entre manos y que explicaré más adelante. Como ya he comentado, este post trata de rellenar el hueco de la parte `bonita` que deje en pendiente en el post de aplicaciones multiplataforma. También me gustaría experimentar con una idea del proyecto GNU llamada guile. Pero es algo que aun está en desarrollo y que aun no he podido explorar a fondo para sacar
conclusiones. Vi este proyecto interesante y estaré pendiente a los avances
que se den para ver lo que me puede interesar.

Cosas que te interesa saber sobre este framework

• El fichero main es el encargado de crear el objeto BrowserWindow. Puede haber varios y cada uno de estos objetos funciona en un proceso independiente con su propio ciclo de vida de aplicación. 
• Cada brower tiene un ciclo de vida que si ya lo has utilizado, tiene cierto
  parecido al de Android, aunque lógicamente es distinto.
• Existe gestión de input de usuario muy parecido al de Java de Android. Con eventos onClick, funcioner declaradas inline en los variables. En Java se podían declarar antes de ser usadas, en javascript no lo sé, así que tengo TODO  comprobar si se puede o no. Quizá no tenga sentido al ser interpretado o no haya diferencia.
• Existe gestión de excepciones y cuelgues para reaccionar ante problemas en la ejecución de una aplicación.
• El fichero renderer es el encargado de actualizar la interfaz y de recoger los
  eventos que suceden en ella.
• Tu aplicación puede tener un menu superior customizado a tu gusto, o puedes crearla sin menu. Solo ventana.
• La aplicación es capaz de acceder al sistema de ficheros del ordenador mediante el file manager del S.O
• También puede acceder al protocol handler para realizar acciones en otras aplicaciones, como por ejemplo lanzar un juego en Steam.
• Al igual que una web puedes acceder a información del ordenador, como sistema operativo, versión, y de la aplicación.
• Puedes personalizar los shortcuts de tu aplicación, en las referencias hay una pequeña guia para no sobreescribir los del sistema operativo que lo ejecute.
• Al igual que iOS y Android, puedes crear dialogos para dar o recibir información.
• También se puede crear un icono de aplicación para colocar en la barra de notificaciones.
• Está a disposición del desarrollador un modulo para comunicar distintos procesos, ya sea de forma asíncrona o síncrona. 
• Para más información puedes utilizar las demos del Electron API demos v1.0 (link) que contiene demos interesantes de lo que puedes hacer con electron y todo dentro de una aplicación generada con Electron.

 Organización

Una posible organización del proyecto debería estar más o menos organizada así:

• README.md, Información de la aplicación.
• LICENSE,md, Licencia
• index.html, página web de la interfaz del proyecto.
• renderer.js, renderizador de la web para los cambios a lo largo del tiempo.
• assets, carpeta con todas las imagenes y otros recursos necesitados por la app.
• scripts, carpeta con todos los scripts en javascript necesitados por la app.
• node_modules, carpeta con las dependencias de la app instaladas con npm

Conclusión

Espero que con esta entrada os hayais introducido en conceptos e ideas básicas del MVC para uso de interfaces y en el futuro podamos evaluar lo fácil o no que son de usar y si ahorran tiempo de desarrollo frente a otros métodos de interfaces. Alternativamente puedes hacer distinción usando MVP.

Software libre, hoy más importante que nunca

FSF Logo

Es un tema que está bastante trillado, pero que sigue sin entenderse completamente. Es como el funcionamiento de los punteros, muchos programadores saben usarlo, y con el paso del tiempo siguen aprendiendo cosas sobre ellos y puliendo su conocimiento. Con el Software libre ocurre lo mismo, voy a intentar arrojar un poco de luz sobre el tema. AVISO: Esta entrada va a mi rollo, puede no coincidir totalmente con la postura de la FSF u otros seguidores del software libre.

El llamado internet de las cosas, es....., el software está en todos lados, en pequeñas piezas de hardware que pueblan nuestra casa. Hasta que no llegó GNU + Kernel de Linux, no había ningún sistema operativo libre, todos eran privativos. Un S.O libre permitió el desarrollo de una gran comunidad como es la actual. El ecosistema se dividió en muchas distros distintas, algunas recomendados por la FSF por estas libre de programar y drivers privativos, y otras que no. Muy pocas son las que lo cumplen, y a veces se sacrifican valores para mejorar la experiencia del usuario, comprensible pero no es lo más adecuado.

Un problema habitual para los que juegan en GNU/Linux, es que los drivers gráficos más potentes son privativos, y las alternativas libres, que sacan funcionalidad gracias a la ingeniería inversa del hardware, los usuarios se ven obligados a elegir entre potencia y rendimiento, o ética, y muchas veces pierde la ética. Hay que valorar la libertad, y comenzar a exigir standares abiertos, APIs abiertos a hardware y programas libres para que cualquiera pueda mejorarlo y utilizarlo, en su máximo potencial, sin depender de una empresa o grupo.

Describo a continuación las principales premisas que infiero de las charlas y documentos que hay sobre el software libre.

• La premisa cero es, compartir es bueno, compartir debe ser legal, una ley que lo prohibe es antisocial y carece de valor ético. Pero ser libre implica mucho más, como vamos a ver. No tiene que ver con canciones o peliculas, deben ser compartibles y libres, pero no tienen porque ser gratis. Sin DRM, ni otras limitaciones que te impiden utilizarlo, obviamente.
• La primera premisa es mantener las 4 libertades de los usuarios, la posibilidad de usar, estudiar, distribuir, y adaptar el código que ejecutes. No estás obligado a ello, pero tienes que tener la posibilidad.
• La segunda premisa es respetar las licencias, nombra a los autores, mezcla software con licencias compatibles, no te apropies del trabajo que no es tuyo, haz lo que debes si usas software libre, etc.
• La tercera premisa es exigir privacidad, aunque no tengas nada que ocultar, las empresas, gobiernos, y otras personas no pueden monetizar o aprovechar tu información privada. Empresas y webs se dedican a hacerlo, como whatsup, facebook, instagram, entre otras. Si las usas, hazlo con precaución, y si navegas, usa extensiones como No-script, libreJS, ghostery, usa redes tor, etc.
• La cuarta premisa es, intenta no usar software privativo. No sabes lo que hace, no puedes saber que realmente hace lo que dice, puede tomar datos sobre ti sin decirtelo, puede espiarte, no puedes adaptarlo a tus necesidades... Hoy en día es casi imposible, pero es importante intentarlo. Yo fallo muchas veces en este punto, y espero mejorarlo.
• La quinta premisa es, software libre no es software gratuito. Puedes vender tu copia, o vender una copia que consigas, siempre que la sigas distribuyendo como software libre que respete las libertades del usuario. De esta forma nadie queda atado al autor original si se sigue respetando la licencia, y podrás adaptar el código a tus necesidades, resolver bugs, mejorarlo y venderlo, etc. Este punto tiene muchos matices, dedica unas horas a leerte el FAQ y las licencias. Pagar es un detalle pequeño respecto a si respeta o no tu libertad, esto último es más importante.
• La sexta premisa es, el mundo no cambia de la noche a la mañana, día a día puedes desarrollar software libre, participar en proyectos, instruir, quejarte a las empresas que pretenden que ejecutes código sin verlo, etc. Es dificil llevar a cambio el cambio pero el esfuerzo merece la pena.
• La séptima presima, por mucho que me duela, es que si usas software privativo, eres un ejemplo de alguien que no está dispuesto a hacer un esfuerzo en favor de su libertad. A día de hoy, no existen alternativas libres tan buenas y eficientes como algunos programar privativos. Hay que comenzar a cambiar, yo mismo uso para jugar software privativo, a veces en mis trabajos no he tenido más remedio que usarlo, es un aspecto a mejorar por cada uno de nosotros.
• Otra premisa importante es, que se deben aplicar las anteriores de forma legítima. Obligar al usuario a hacer ingenieria inversa para modificar el comportamiento del código NO es legitimo, hay que dar el código fuente e instrucciones razonables para hacerlo. En la práctica, se tiene que recurrir a estudiar el funcionamiento del software privativo, con ingeniería inversa, para poder desarrollar software libre. Es más costoso, pero es lo justo, es un buen trabajo muy demandado, y desde luego, legal. Lo ilegal debería ser no facilitar especificaciones para poder hacer tu propio software con la comunidad.

Algunas preguntas que puedes hacerte:

•  ¿Qué puedo hacer yo? Puedes colaborar, estudiar, ir adaptandote a estas premisas poco a poco e instruir a los demás de forma no agresiva. Es un tema complejo que conlleva aceptar una ética, y conseguir el cambio poco a poco. Es más fácil dejar de lado el tema, pero considera lo importante que es esto.
• ¿Es necesario usar licencias en mi código? Por supuesto que si, cuesta algo de trabajo leer sobre ellas y elegirlas, pero usar GPL o cualquier otra licencia libre, evitará que empresas puedan legalmente apropiarse de tu trabajo, contribuiras al desarrollo de la comunidad, y conseguiras que la gente pueda aprovechar tu trabajo para hacer obras derivadas.
• ¿Quien tiene el control de lo que hace mi ordenador, el programa, o el programador/usuario? El software libre hace que tengas TU el control sobre el programa. Si no puedes verlo, no puedes estar seguro de que hace lo que te dicen que hace.
• ¿El software en si mismo es bueno o malo? Obviamente no es malo, dependerá de como se use y como se puede utilizar, que se puede hacer con él, etc. El creador y el usuario son los que pueden usarlo para el bien o para el mal.
• ¿El software libre implica que tenga que leer y comprender todo el software que utilizo? Obviamente no, es un problema inabordable, pero la comunidad es grande, y hay organismos que lo vigilan, si detectas algo raro, tu mismo puedes leerlo, hay muchos métodos a parte de auditar el código para evitar leerlo todo por ti mismo, no estás solo.
• ¿Por qué llamarlo GNU/Linux y no solo Linux? El software libre empezó con con GNU, aportó gran cantidad de código, la ideología, etc. En su momento necesitaba un kernel donde ejecutar todo el código, un kernel que fuera de software libre. En un momento dado, Linus Torvalds licenció como software libre el kernel de Linux, y juntos, GNU/Linux, se convirtió en lo que es ahora.
• ¿Sabías que la / de GNU/Linux es para que NO SE MUERDAN? Parrafo 2. Gracias por el aviso Iñaki.
• ¿Los no programadores pueden colaborar? Por supuesto que si, alguien puede dar ideas, reportar bugs, y ayudar a los programadores aunque no lo haga directamente, participando en las decisiones, o incluso contratando a alguien que desarrolle lo que necesita. El que quiera colaborar es libre de hacerlo de cualquier manera.
• ¿Existe diferencia entre código abierto y código libre? Si, hay una gran diferencia, el movimiento que representa la FSF no sólo busca poder leer el código, sino en cumplir con las 4 libertades, para modificarlo, compartirlo, etc. Por eso es importante que siempre se respeten estas libertades.
• ¿Tiene un desarrollador la obligación de compartir el código? Obviamente no, tienes esa libertad pero no tienes porque ejercerla. Si te cansas de desarrollar un código y lo compartes, puedes dejar de mejorarlo, y otros usuarios podrán hacerlo o no, los usuarios no van a estar atados a ti por siempre como sucede en el software privativo, pero si mejoras un código para ti mismo o tu empresa, y no quieres compartirlo con la competencia, siempre que no distribuyas el binario, no tienes porque compartir el código de esas mejoras.
• ¿Me puedo fiar del software como servicio? Si una actividad puedes ejecutarlo tu mismo, en local, siempre va a ser mejor que confiar en sitios que ejecuten el código de lo que tu haces, para poder ser libre. No todo se puede ejecutar en local, para comunicarte, necesitas hacerlo con otros, pero existen mecanismos para cercionarte con quien hablas, si hay terceros escuchando la comunicación, etc. Utiliza siempre Https, ssh, y otros cifrados para impedir que perjudiquen tu libertad.
• ¿Debo desconfiar de todo lo que sea Smart? Como ya hemos dicho antes, cada vez más hardware controla nuestra vida, termostatos inteligentes, contadores de luz y gas que monitorizan datos, móviles con GPS y triangulación que te localizan exactamente (sino claro no funcionarían los telefonos), etc. Esta información es muy valiosa para las empresas, para facturar la luz basta con 1 lectura al mes, no cada segundo, con lo que se puede averiguar y/o aproximar patrones de consumo, cuanta gente hay... Desconfia de todo lo que no puedas auditar, ¿Imposible? Improbable más bien, complicado, pero toma las precauciones necesarias.
• ¿Debe ser la educación sobre software libre? Por supuesto que si, muchas escuelas y universidades usan licencias de windows, packs ofimáticos de pago por licencia, software privativo en las prácticas que te obligan a usarlo para aprobar. Esto debe cambiar, y debe hacerse poco a poco. Debería ser ilegal por ser anticompetitivo, y antieducativo, porque no puedes ver como se hacen las cosas y te obligan a pagar por algo que te quita libertad. Por inercia social la universidad forma usando software privativo, porque se usa en el mundo laboral, y vicerversa. Lo ideal, y a lo que tenemos que ir, es a una sociedad ética donde cada uno se forme con software libre, y si se quiere, en una empresa, te formen y paguen por usar software privativo. No es lo ideal, pero no se puede obligar a que otros no lo hagan, esto iría en contra de la libertad que se busca defender. Tienes más información para la educación en este post.
• ¿Puedo poner una licencia de explotación distinta a la GPL durante un tiempo y luego licenciar el código como GPL? Si eres dueño del código, puedes hacer lo que quieras. Esto incluye liberar el código con distintas licencias en distintos momentos, así que nada impediría que tengas software propietario, tuyo, y luego lo liberes. Tengo mis dudas, si sería posible aplicar a la GPL un tiempo de explotación donde no se deje compatir durante un periodo de tiempo (pongamos 3 años), para permitir la explotación comercial y que luego pase a ser un derecho. Técnicamente esto iría en contra de las libertades de los usuarios, aunque suena razonable para una empresa que desarrolla código único y especial. Nada te impide crear tu propia licencia, así que podría ser una solución de equilibrio para la situación actual de Software libre vs software privativo. He de añadir que seguramente a la FSF esto le parecería aberrante (no tengo la certeza y aún no lo he preguntado), pero en la práctica podría ser útil hacia un mundo de licencias libres.
• ¿Cuando se considera una obra derivada de una con licencia GPL, y tengo que licencias el resto de código como GPL? ... (Falta investigación)
•  ¿Cómo puedo hacerme de la FSF? Visita su web y hale, para adentro.
• ¿Existe realmente San Ignucio? ¿Es la religión verdadera? Existe, efectivamente, y la wikipedia explica todo muy bien. No puedo asegurar de que sea la verdadera, pero da algunas respuestas a la vida. Por suerte no requiere el celibato, aunque es muy dificil llevar una vida pura como exige su camino. Una lástima que no bendigan agua para exorcizar ordenadores poseidos por el demonio privativo.

Una charla completa interesante, para bien o para mal, en youtube con codec privativo:

No olvides pasarte por esta entrada para aprender un poco más sobre las licencias. Si quieres saber más, puedes adquirir el libro de ensayos Richard en la web de la FSF. También hay muchas universidades con información abundante sobre el tema.

Licencia de este post, CC no derivados porque es una opinión o punto de vista.

Enlaces de interés:
- Diferencia SW libre y Open Source, fuente genbeta, via RDCH106

Compilando con CMake

¿Que es?

Es una herramienta para multiplataforma para generar Makefiles a partir de scripts y poder compilar proyectos escritos en C, C++, Objective-C o Fortran usando un lenguaje más elevado que el propio Makefile o proyectos de IDEs comunes.

¿Para que sirve y porque usarlo?

Tiene capacidad para generar proyectos de Eclipse, Visual Studio, o plain Makefiles a partir de dichos scripts (CMakeLists.txt) para facilitar el desarrollo de un proyecto. Además, al estar orientado a cualquier plataforma y enfocado a facilitar la crosscompilación mediante toolchains, facilita la compilación en cualquier plataforma GNU/Linux, MAC y Windows con cualquier target (x86, ARM).

Hay que tener en cuenta que no hace magia, el propio código siempre tiene que estar adaptado a cada plataforma, tener precondiciones para que funcione en todas, etc. No obstante, usar CMake facilita mucho la adaptación si tienes en cuenta ciertos detalles que se adquieren con la experiencia.

Organización

A la hora de organizar un proyecto, lo primero que se tiene que tener claro es como lo vamos a organizar. Recomiendo usar control de versiones git, ya sea administrado por nosotros mismos o usando uno de los servicios populares: Github o Bitbucket. Sugiero utilizar diversas carpetas para separar conceptualmente las distintas partes del código, por ejemplo:

Proyecto general:

Constará con la configuración del proyecto en lineas generales, y la organización del código. Se recomienda tener unos ficheros básicos en la carpeta raiz del proyecto:

• CMakeLists.txt principal que configure el proyecto usado por CMake.
• README.md que explique que hace el proyecto, autores, datos de interés...
• Contributing.md, fichero opcional para informar al que quiera contribuir en el proyecto.
• License, fichero con la licencia del código, aunque este en las cabeceras de el source code, es importante dejarlo claro.

Y las carpetas con el contenido separado del proyecto:

• Modules: Carpeta con las distintas librerias, bien sean estáticas o dinámicas que componen nuestro proyecto. Contendrán todo el código de la librería separado conceptualmente en distintas sublibrerías si procede. No debe contener ejecutables.
• 3rdParty: Carpeta con todo el código de terceros, ya sea en submodulos de git
• Samples: Carpeta con minimo código para crear ejecutables de ejemplo de funciones básicas de la libreria, o ejemplos complejos ilustrativos.
• Test: Carpeta con todos los test unitarios para probar los módulos si son necesarios. Esta carpeta es opcional. Por ejemplo usando GTests
• cmake, carpeta con los módulos y otros scripts de cmake utiles para compilar el proyecto.

Módulo individual: 

Será todo aquel en un subdirectorio del proyecto general. Puede ser un ejecutable o una librería de nuestro proyecto general. Se sugiere que conste con:

• CMakeLists.txt: Fichero con la configuración de ese subproyecto concreto.
• src: Carpeta con todos los ficheros *.cpp, *.c, *.m del subproyecto.
• include: Carpeta con todos los ficheros *.h, *.hpp del subproyecto

Por supuesto, esto es un esquema recomendado, cada proyecto tiene sus propias pautas, normalmente explicadas en el README, la wiki, o la página oficial del proyecto. Yo por ejemplo siempre utilizo una carpeta build fuera de el código fuente. Las razones varias, aunque con gitignore puedes evitar añadirla al repositorio, ayuda a no hacerlo. Eclipse da problemas si tiene build anidado en el source. Ayuda a separar diversas compilaciones si necesitas copias sin emborronar la carpeta del código.

Por ejemplo, yo suelo tener una carpeta con el proyecto que contiene:

• git, carpeta con todos los repositorios relacionados con el proyecto.
• doc, carpeta con toda la documentación o referencias relacionadas.
• build, carpeta con todas las plataformas compiladas, pruebas, Doxygen documentation output, etc.

Variables importantes:

CMake dispone de muchos comandos y variables importantes, que pueden ser consultadas en su referencia, y que nos ayudarán a configurar nuestro proyecto. Por supuesto, puedes crearte tus propios comandos, o macros si lo prefieres, llamar a ejecutables como hacen los Makefiles, y muchas cosas más.

• CMAKE_CONFIGURATION_TYPES, configura Release, debug... en proyectos como VS

• PROJECT_BINARY_DIR, variable que apunta a la base de la carpeta build

• CMAKE_VERBOSE, información extra al generar el proyecto-

• CMAKE_DEBUG_POSTFIX, sufijo en el caso de target debug

• CMAKE_CURRENT_SOURCE_DIR, el proyecto donde se ejecuta el actual CMakeLists.txt  

Comandos importantes:

• cmake_minimum_required(VERSION 2.8.8), versión minima probada de los scripts

• PROJECT(${PROJ_MAIN_NAME}), Crea un proyecto con el nombre de la variable PROJ_MAIN_NAME.

• ADD_SUBDIRECTORY, añade una subcarpeta al script actual, para revisar su CMakeLists.txt

• ADD_EXECUTABLE, A partir del código proporcionado después del comando PROJECT, crea un ejecutable.

• ADD_LIBRARY, lo mismo que ADD_EXECUTABLE pero creando una librería estática o dinámica según la opción proporcionada. 

• LINK_DIRECTORIES, provee paths que contentan librerías que necesita el proyecto

• TARGET_LIBRARY, provee el nombre de las librerías necesitadas.

• MESSAGE, comando para printear información, datos o variables.

Para los más avanzados:

Tengo un pequeño repositorio en Github de código abierto llamado CMake-supporter. Utilizado como submodulo en un repositorio o simplemente copiando el código en la carpeta cmake, puede ser usado para manejar toolchains que compilan código en C++ para iOS y Android, también tiene templates de los proyectos principales y está perfectamente documentado como usarlos. Si no tienes mucha idea de CMake, pueden serte de utilidad tanto para no pensar en organizar un proyecto, como para aprender n poco sobre este sistema.

Un ejemplo:

Puedes ver el funcionamiento de un proyecto de prueba más avanzado que lo usa como submodulo en este repositorio. Simplemente haz:

git clone --recursive https://github.com/vgonisanz/cmake-supporter-sample

Configura y ejecuta el proyecto, y trata de compilarlo.

Trabajo futuro:

A parte de que mejoraré CMake-supporter, y el ejemplo, estoy pensando como generar automáticamente con unos pocos datos la estructura del proyecto, ya adaptada para no tener que copiar los templates y renombrar a mano, crear las carpetas, etc. Os mantendré informados.

Otros enlaces utiles:

• http://www.cmake.org/cmake-tutorial/
• http://outcoldman.com/en/archive/2014/05/02/xcode-and-cmake/
• http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/