[Electronjs][Desktop-web] Inbit, un ejemplo hola mundo para aprender nodejs y electron

[Obijuan]

Hola,

  Llevo tiempo queriendo aprender un poco de las tecnologías web para escritorio. Como yo necesito aprender haciendo, he comenzado por este mini-proyecto: Inbit

https://github.com/FPGAwars/InBit

Os adjunto un video de su funcionamiento, y pongo una caputra:



Al hacer click con el ratón, se cambia el estado de la señal DTR, que se usa como bit de entrada para tus circuitos. Vamos, que es una entrada más, pero virtual desde el PC
Las instrucciones de cómo probarlo están en el readme del repo

Esto lo hago por aprender, en mi tiempo libre, y por experimentar

Saludos, Obijuan

PD.- Todos los días recibo entre 40 y 50 peticiones de gente preguntándome cosas, pidiendo explicaciones, que les resuelva sus dudas (sobre impresión 3D, Diseño Freecad, robótica, FPGAs, Tutoriales...) Y por supuesto me es imposible hacerlo. De vez en cuando resuelvo algunas si se pueden responder rápido, o porque esté en mi lista de prioridades. El efecto secundario de esto es que a los dos días recibo otros 20 correos adicionales de gente cabreada porque no les he respondido. Lo siento. No me da la vida. Y en mi tiempo libre... pues priorizo hacer cosas antes que responder. El SAV maker me puede, lo siento

[1138-4EB]

Muchas gracias, Obijuan, por compartir este proyecto básico sobre nodejs y electron como primera introducción a la infraestructura de icestudio.

Algunos detalles que, creo, podrían mejorarlo ligeramente. Por favor, indícame si quieres aplicarlos por tu cuenta, en una sola PR o una PR por cada uno:

• En https://github.com/FPGAwars/InBit/blob/master/renderer.js#L10 se ha colado un mensaje en castellano.
• Sería interesante utilizar yarn en lugar de npm. En principio, el reemplazo es directo; no tienes que cambiar el package.json ni ninguna otra fuente, sólo las instrucciones del README. Tiene características adicionales, como por ejemplo yarn.lock, que permite garantizar que todos los desarrolladores/contribuidores utilizan exactamente las mismas versiones de las librerías. Además, permite ejecutar apps CLI locales (léase grunt o bower), sin necesidad de pelearse con la PATH: https://yarnpkg.com/en/docs/cli/ . No es algo necesario en este mini-proyecto, pero sí útil en el camino hacia icestudio. Aquí información sobre cómo migrar: https://yarnpkg.com/en/docs/migrating-from-npm Como detalle, algunas versiones de npm tienen problemas cuando una dependencia se define como un repo de github con un filtro de versión. yarn no.
• Crear una imagen docker, como solución multiplataforma rápida alternativa a empaquetar nativamente para windows y mac. En caso de utilizar yarn, se puede utilizar alpine linux como base y simplemente hacer `apk add yarn git && git clone ... ./ && yarn`. Eso debería installar nodejs, electron y todo lo necesario.
• Al intentar instalarlo en Alpine Linux, como he comentado en el punto anterior, he obtenido un error porque se necesitan Python, make, g++ y linux-headers. Creo que es debido a serialport. Estaría bien una referencia a https://www.npmjs.com/package/serialport#installation-special-cases en el README.
  

[Diego Fernandez Gonzalez]

Muchas gracias Juan.

No sólo dedicas tu tiempo libre a aprender cosas nuevas, si no que además lo compartes para ayudarnos a los demas. En ningún momento veo justificado exigir tu ayuda, con todo lo que das de forma voluntaria.

Eres una gran motivación y un ejemplo a seguir.

Un saludo.

[Jose Luis V]

Muchas gracias Juan por todo lo que haces y compartes, si alguien es capaz de cabrearse contigo es que no te conoce, ni caso maestro.

Por cierto, me parece muy interesante esto, yo ya lo he probado y lo tengo funcionando en Mac. Mola un montón.

Y de nuevo, muchas gracias por todo lo que das.

El viernes, 5 de enero de 2018, 10:23:47 (UTC+1), Obijuan escribió:

[Juanma Rico]

Buenas a todos,

Como no quería que el esfuerzo que hace Obijuan y los comentarios de Unai cayeran en saco roto y como realmente estoy muy interesado en intentar entender la estructura de programación de icestudio para poder aportar algo de funcionalidad al mismo, esta semana pasada (con todo el dolor de mi corazón) he dejado de lado la TinyFPGA y el poco tiempo del que he dispuesto se lo he dedicado a desentrañar este ejemplo InBit de Obijuan.

Creo que he llegado a entenderlo y a sacar algunas conclusiones (espero que no sean equivocadas). Por otra parte, he probado lo que recomendaba Unai en sus comentarios y efectivamente (como normalmente sucede) tenía razón. Yarn es muy fácil de instalar, funciona igual que el gestor npm y al parecer es más fiable y rápido. No me extrañaría que en un tiempo no muy lejano Nodejs lo termine adoptando como su gestor por defecto.

Como me ha costado bastante el entender el ejemplo y los conceptos que tiene detrás (más bien por falta de tiempo que por complejidad del mismo ejemplo), he decidido redactar en la wiki del fork mis impresiones y descubrimientos a modo de notas.

Le faltan algunos gráficos que lo hagan un poco más ameno, pero si estáis interesados lo podéis encontrar aquí: https://github.com/juanmard/InBit/wiki
Espero que mis notas os sirvan para poder avanzar un poco más rápido de como yo lo he hecho estos días y para animaros a probar el ejemplo.

Saludos
Juan Manuel Rico

[1138-4EB]

Muchas gracias Juanma, por detallar las explicaciones.

En cuanto a yarn, me alegra saber que funciona como esperaba. Yo intenté utilizarlo en un contenedor docker, como comenté. Sin embargo, no pude hacerlo funcionar porque parece ser que electron y docker no se llevan muy bien. Es decir, no tuve problemas con yarn en sí, pero electron se instalaba a medias (al menos, no de forma funcional).

[Jose Pico]

Muchas Gracias!

Vamos  pillando un poco de culturilla general de nuevos conceptos para mí como son "yarn,npm,electron,nodejs..."

Saludos

El sábado, 20 de enero de 2018, 0:52:08 (UTC+1), Juanma Rico escribió:

[Juanma Rico]

De nada Unai, gracias a ti por darnos siempre otro punto de vista tan bien argumentado.
Yo simplemente hago lo que puedo para aportar algo con mis escasos conocimientos de programación... aunque eso sí, con el SAV de un apasionado por ella...  :)))

A mi personalmente me costaría mucho trabajo encontrar esos puntos de vista tan distintos ya que no puedo dedicar demasiado tiempo al tema, aún así, cuando descubro algo que creo importante, me termino dando cuenta que lo mismo que encontré ya lo anticipabas tú en uno de esos interminables post que escribes... jajajajajajajajajaj :)))

Eso mismo me acaba de ocurrir este fin de semana con Bower.

Sigo investigando la tecnología web que hay detrás de icestudio y hoy me he encontrado que al actualizar los módulos para incluir los últimos cambios que ha introducido Jesús, el propio desarrollador de Bower te avisa en la propia actualización del mismo para que vayas cambiando de gestor de paquete... cosa curiosa que ya anticipabas...



Incluso haciendo referencia a Yarn como tú también anticipabas (y yo me unía a ello torpemente tras comprobar su funcionamiento... :)))
Investigando en el tema encontré este interesante artículo en el que explica como actualizar a Webpack para los paquetes del frontend del que saqué la captura anterior:
 
https://medium.com/netscape/bye-bye-bower-or-how-to-migrate-from-bower-to-npm-and-webpack-4eb2e1121a50

Sin embargo me surge la duda... según todo lo que leo hay proyectos que usan los dos gestores:  npm (o Yarn en un futuro) para los paquetes del backend, donde en el servidor no hay problemas de latencia o de espacio, pero que su estructura anidada es demasiado pesada para el frontend, el cliente, y por eso se necesita usar otro gestor de paquetes menos anidado (más plano) para el mismo... y de ahí el uso de otro gestor de paquetes como Bower (a estinguir como ya sabemos) o Webpack... y por mucho que leo no consigo encontrar qué sentido tiene mantener los dos gestores de paquetes en un proyecto donde el backend y el frontend se encuentra en la misma máquina, como ocurre en el software de escritorio basado en web (icestudio).

¿Habría alguna ventaja en este caso de mantener los dos gestores cuando está claro que la diferencia entre backend y frontend es meramente conceptual y no es real al estar ambos en la misma máquina y por tanto, tener la misma latencia y espacio?

Ahí dejo la duda... jejejejejeje

Si alguien sabe responder que deje constancia, si yo averiguo algún motivo me autoresponderé en este mismo hilo...  :))))

Saludos

Juan Manuel Rico

[Juanma Rico]

De nada José por la parte que me toca... si me toca algo... :)))

Se trata de eso... de aprovechar y aprender "haciendo" (como dice Obijuan) y de aprender los unos de los otros los nuevos conceptos.
Y aprenderlos de la forma más fácil que se pueda, aprovechando "la experencia de los mayores que ya han estado allí" (como dice Unai).

Y si yo ya he estado allí... ¿Por qué no exponer los problemas que he encontrado, así como mis conclusiones y hacerlo más fácil a los demás?  :)))
Yo también he aprendido muchos conceptos de control gracias a ti... Así que "quid pro cuo"... jejejejeje

Saludos
Juan Manuel Rico

[1138-4EB]

Juanma, una vez más, lo que sucede es que utilizar "tecnologías web para escritorio" está muy cogido por los pelos, cuando lo que se quiere decir es que se utiliza sólo JavaScript para escribir una app; y, por lo tanto, se está hablando de nodejs/electron exclusivamente.

Sucede, además, que el submundo JavaScript reune las peores derivadas del software libre: muchísimo contenido incompleto, duplicado, no mantenido, volátil... Viniendo del hardware, y de proyectos más o menos estructurados, a mí también me costó entender el porqué de tanto gestor de paquetes. De hecho, todavía pienso que es "mejor" una lista de repositorios de git + curl/wget en un script en shell. Pero, no estamos aquí para explicar el contexto que nos ha llevado a esta situación. Intentemos entender qué hacen las herramientas y por qué lo hacen, sin meternos en por qué se hace de esa forma en concreto.

Olvídemonos de icestudio, inbit, y de nodejs/electron. Pensemos en una aplicación web "de verdad", de hace 10 años, con partes claramente diferenciadas:

- Frontend, que se ejecuta en el navegador del usuario, el cliente: HTML, CSS, JS...
- Backend, que se ejecuta en la máquina que contiene el servicio, el servidor: PHP, C, Java, Python, Golang...
- Comunicación frontend-backend: AJAX.

Para cada una de las partes de la app hace falta diferentes librerías. Cada librería hay que descargarla de la página que corresponda. Cuando el desarrollador de la librería publica una nueva versión, hay que enterarse de ello, volver a descargarla y comprobar que nada se rompa (es decir, revisar el changelog para ver si es una actualización menor o mayor -con breaking changes-). En ese contexto digamos que a los desarrolladores de npm se les ocurrió lo siguiente:

NOTA: no, no se les ocurrió a ellos, sino que se basaron en CPAN o CTAN. Mas, asumamos este discurso en aras de facilitar el seguimiento de la historieta.

- Crear un servidor centralizado al que cualquiera puede añadir un paquete/librería.
- Crear un formato de archivo en el que defines el nombre de una librería y defines también qué versión o qué rango de versiones de la misma quieres utilizar.
- Una aplicación cli que mira tu fichero, comprueba el servidor central y actualiza tu copia local de la librería, si procede.
 
La ventaja principal, en principio, es que todas las actualizaciones sin breaking changes se pueden aplicar automáticamente. Lo cual es decir mucho, porque presupone que te fías del buen criterio de todos los mantenedores de todas las librerías a la hora de cambiar los números de versión. En cualquier caso, cuando las librerías estaban publicadas cada una de forma diferente, el servidor central cumplía su función. Hoy día, que la inmensa mayoría (por no decir todas) las librerías están en GitHub, el servidor central deja de tener sentido. De hecho, tanto npm como yarn admiten hoy en día la utilización de repos de github en lugar del registro central de npm. Por ejemplo, ver angular-google-analytics, splitargs o toastr en https://github.com/portainer/portainer/blob/develop/package.json

NOTA: algunas versiones de npm no permiten mezclar el formato de repo de github con los "filtros" de versión (~, ^, etc.).

Si no me equivoco, npm es totalmente jerárquico y duplica las dependencias aunque sean compartidas. Por eso surgió bower y seguramente esto es lo que has leído sobre "flat": bower comprueba si varias librerías tienen dependencias comunes e intenta averiguar si son necesarias varias versiones diferentes de las dependencias comunes o si puede descargar una sola. Por ejemplo, supongamos que la librería A depende de JQuary 3.2.1 y la librería B depende de JQuery 3.2.2. En principio, las dos funcionarán con una sola copia de cualquier versión 3.2.x (sea .1, .2 o .9), por lo que bower sólo decarga una.

Por otro lado, en lo que respecta al frontend, más tarde se extendieron conceptos como minification, uglification, transcoders, etc. No voy a entrar en detalles. Sólo explicar que el objetivo es coger todos los ficheros que componen el frontend (tu código y todas las librerías) y empaquetarlo en uno sólo. Las razones son varias:

- Reducir el peso del contenido que el usuario/cliente/navegador tiene que descargar para ver la página/app.
- Simplificar la lógica para acelerar la ejecución.
- Facilitar el uso en múltiples navegadores, con diferentes niveles de soporte de los estándares.

Nótese que estos pasos requieren modificar el código fuente de nuestra app hasta dejarlo irreconocible. Este proceso es, en mi opinión, una de las razones por las que los autores de bower han "matado" el proyecto. ¿Qué sentido tiene preocuparse por mantener una esctructura "sencilla" de ficheros si al final se van a coger sólo los que hacen falta y se van a juntar/empaquetar en uno? Total, a los desarrolladores JavaScript, en general, no les preocupa mucho tener el equipo lleno de basura de dudosa utilidad.

Esta es la razón también por la cual inicialmente npm se utilizaba para gestionar las dependencias del backend y bower para las del frontend, pero ya no. Si la única ventaja de bower deja de tener sentido ¿por qué no utilizar npm para ambos grupos? En el package.json de portainer puedes ver cómo "dependencies" son las librerías que hasta hace un mes se gestionaban con bower (las del frontend) y "devdependencies" son las que no son del frontend.

A partir de aquí, ¿qué aporta yarn? La verdad es que "poco" con respecto a npm, pero muy importante. Principalmente que gestiona los repo git sin problemas (incluso aplicando los filtros de versión a tags/branches) y que asegura que todos los desarrolladores/colaboradores van a utilizar exactamente la misma versión de cada librería. Con npm las versiones utilizadas son equivalentes o compatibles, pero no hay un mecanismo que garantice que son exactamente las mismas fuentes. Esto naturalmente sólo es relevante en proyectos con más de un desarollador activo. Tiene poca o ninguna utilidad en proyectos individuales que se hacen públicos.

Y, ¿qué aporta webpack? Es un empaquetador, no un gestor de librerías. Es una de las herramientas que se puede utilizar la minification, uglification, transcoding, etc. Es decir, npm + webpack o yarn + webpack.

Fíjate que hasta hora me he centrado en el frontend. ¿Por qué? Porque JavaScript es un lenguaje de scripting para frontends web, así se diseñó y para eso es "bueno". Cuando Google publicó su JavaScript engine (aka V8) y basado en ello se publicó nodejs, se rompieron un poco los esquemas:

Por un lado surgieron herramientas escritas en JavaScript que no eran para el frontend, sino para gestionar/automatizar el desarrollo. Algunos nombres conocidos son grunt o gulp. ¿Qué diferencia hay entre estos y un conjunto de scripts en shell? Absolutamente nada. Bueno, sí, que para usar una shell hay que saber usar una shell. De hecho, los desarolladores web con cierta experiencia tienen suficiente con npm/yarn y scripts. Más aún, casi todos los gruntfile que he visto por ahí tienen alguna parte en shell.

Por otro lado, V8 y nodejs incluyen librerías escritas en JavaScript que permiten ignorar la característica principal que diferencia el frontend del backend: el backend puede acceder al sistema de ficheros en el que se está ejecutando, el frontend no. Como derivada, no hay que saber cómo se transmite la información en la web, sino que son llamadas a funciones sin más.

Para rizar más el rizo, todas las librerías JS, ya sean para frontend, backend, comunicación o automatización, se gestionan de forma idéntica. No hay siquiera alguna etiqueta orientativa para nuevos usuarios.

La caja de pandora ya está abierta y el marketing es impecable: escribe un programa completo en JS sin saber nada en absoluto sobre arquitectura de aplicaciones ni sobre qué es una comunicación entre dos aplicaciones. De hecho, sin tener ni idea de las muchas capas que hay desde tu script hasta el código máquina. Va a ser pesado, ineficiente, y habrá bugs imposibles de depurar, pero como el target es quien sabe poco o nada de programación, tampoco va a saber apreciarlo. Si una librería no funciona, cambiará a otra o copiará algún otro snippet que encuentre por ahí.

En conclusión, si quieres aprender "tecnologías web", huye de nodejs/electron como plataforma. Escribe un frontend en HTML/CSS/JS y escoge el lenguaje que más te guste para el backend (yo voto por golang porque es estúpidamente sencillo, pero te sirven Python, Java...). Hazlo a mano, es decir, sin grunt ni gulp ni similares. Cuando hayas entendido qué gestores y empaquetadores necesitas para el frontend, cuáles para el backend y cómo puedes comunicar ambas partes, sólo entonces, y sólo si lo necesitas, cambia a nodejs/electron. ¿Para qué necesitas nodejs/electron en este caso? En realidad para nada, porque ya tienes un navegador en cualquier equipo que utilices. Pero puede que quieras ponerte "elegante" y querer que tu app esté empaquetada en su propia ventana y con su propio ejecutable, además de no tener que preocuparte por el soporte en navegadores diferentes de Chrome. Ver, por ejemplo, Syncthing y Synctrayzor.

¿Por qué te recomiendo este camino y no el sugerido en Inbit? Para tratar de evitar que llegues a la situación de icestudio: una aplicación escrita con tecnologías web que no puede utilizarse en la web sin reescribirse prácticamente por completo (porque quién sabe dónde está la línea entre el frontend y el backend). El hecho de que se utilicen uno o varios gestores de paquetes y el cacao mental que eso te pueda producir es más o menos irrelevante en comparación con este hecho. Léase: dejar de utilizar bower es trivial, hacer un icestudio cliente-servidor no. Estudiar tecnologías web para al final darte cuenta de que no vas a poder hacer una web (single page application) es un chasco.

Ahora bien, si no tienes inconveniente en que tu aplicación esté limitada a su uso en el escritorio y si realmente tienes claro en qué parte estás trabajando en cada momento, a pesar de hacerlo todo en JavaScript, adelante. Aún así, si estas en esta situación, ¿estás seguro de querer utilizar tecnologías web? ¿Por qué no gtk/Qt/QML con los bindings que más te gusten (digamos Python)? Conozco la respuesta, sólo son preguntas retóricas para dar a entender que HTML/CSS/JS son una alternativa razonable a Qt/QML, no a C++. Donde "alternativa razonable" incluye tanto rendimiento/eficiencia como tiempo de desarrollo.

Saludos

[Juanma Rico]

Buenas Unai, como siempre encantado de leer un post tuyo.
Veo que me confirmas conclusiones a las que llego en mi investigación y me abres otras puertas. Siempre de agradecer. :))

Intento responder/preguntar entre tus párrafos.

El lunes, 22 de enero de 2018, 18:56:21 (UTC+1), 1138-4EB escribió:

Juanma, una vez más, lo que sucede es que utilizar "tecnologías web para escritorio" está muy cogido por los pelos, cuando lo que se quiere decir es que se utiliza sólo JavaScript para escribir una app; y, por lo tanto, se está hablando de nodejs/electron exclusivamente.

Sí, tienes razón... me surgen muchas dudas de conceptos a los que no les veo lógica ninguna (la pregunta de mi post anterior es solo una de ellas).

Ahora estoy investigando el código más reciente de icestudio y, por lo poco que llevo visto, creo entender que usa el dúo nodejs/angular en lugar de nodejs/electron. Además de, por supuesto, Grunt para la automatización de tareas y Bower como gestor de paquetes del frontend. (Cuando tenga claro este punto del dúo de actores lo confirmo... por ahora tengo los pies de barro en este tema... es solo una creencia mezclada con especulación... :))) ).

Sucede, además, que el submundo JavaScript reune las peores derivadas del software libre: muchísimo contenido incompleto, duplicado, no mantenido, volátil... Viniendo del hardware, y de proyectos más o menos estructurados, a mí también me costó entender el porqué de tanto gestor de paquetes. De hecho, todavía pienso que es "mejor" una lista de repositorios de git + curl/wget en un script en shell. Pero, no estamos aquí para explicar el contexto que nos ha llevado a esta situación. Intentemos entender qué hacen las herramientas y por qué lo hacen, sin meternos en por qué se hace de esa forma en concreto.

Olvídemonos de icestudio, inbit, y de nodejs/electron. Pensemos en una aplicación web "de verdad", de hace 10 años, con partes claramente diferenciadas:

- Frontend, que se ejecuta en el navegador del usuario, el cliente: HTML, CSS, JS...
- Backend, que se ejecuta en la máquina que contiene el servicio, el servidor: PHP, C, Java, Python, Golang...
- Comunicación frontend-backend: AJAX.

Para cada una de las partes de la app hace falta diferentes librerías. Cada librería hay que descargarla de la página que corresponda. Cuando el desarrollador de la librería publica una nueva versión, hay que enterarse de ello, volver a descargarla y comprobar que nada se rompa (es decir, revisar el changelog para ver si es una actualización menor o mayor -con breaking changes-). En ese contexto digamos que a los desarrolladores de npm se les ocurrió lo siguiente:

NOTA: no, no se les ocurrió a ellos, sino que se basaron en CPAN o CTAN. Mas, asumamos este discurso en aras de facilitar el seguimiento de la historieta.

- Crear un servidor centralizado al que cualquiera puede añadir un paquete/librería.
- Crear un formato de archivo en el que defines el nombre de una librería y defines también qué versión o qué rango de versiones de la misma quieres utilizar.
- Una aplicación cli que mira tu fichero, comprueba el servidor central y actualiza tu copia local de la librería, si procede.
 
La ventaja principal, en principio, es que todas las actualizaciones sin breaking changes se pueden aplicar automáticamente. Lo cual es decir mucho, porque presupone que te fías del buen criterio de todos los mantenedores de todas las librerías a la hora de cambiar los números de versión. En cualquier caso, cuando las librerías estaban publicadas cada una de forma diferente, el servidor central cumplía su función. Hoy día, que la inmensa mayoría (por no decir todas) las librerías están en GitHub, el servidor central deja de tener sentido. De hecho, tanto npm como yarn admiten hoy en día la utilización de repos de github en lugar del registro central de npm. Por ejemplo, ver angular-google-analytics, splitargs o toastr en https://github.com/portainer/portainer/blob/develop/package.json

NOTA: algunas versiones de npm no permiten mezclar el formato de repo de github con los "filtros" de versión (~, ^, etc.).

Un ejemplo muy claro de otra de las dudas que tenía.... ¿Por qué un servidor central "exclusivo" para el código JavaScript? :))

Si no me equivoco, npm es totalmente jerárquico y duplica las dependencias aunque sean compartidas. Por eso surgió bower y seguramente esto es lo que has leído sobre "flat": bower comprueba si varias librerías tienen dependencias comunes e intenta averiguar si son necesarias varias versiones diferentes de las dependencias comunes o si puede descargar una sola. Por ejemplo, supongamos que la librería A depende de JQuary 3.2.1 y la librería B depende de JQuery 3.2.2. En principio, las dos funcionarán con una sola copia de cualquier versión 3.2.x (sea .1, .2 o .9), por lo que bower sólo decarga una.

Por otro lado, en lo que respecta al frontend, más tarde se extendieron conceptos como minification, uglification, transcoders, etc. No voy a entrar en detalles. Sólo explicar que el objetivo es coger todos los ficheros que componen el frontend (tu código y todas las librerías) y empaquetarlo en uno sólo. Las razones son varias:

- Reducir el peso del contenido que el usuario/cliente/navegador tiene que descargar para ver la página/app.
- Simplificar la lógica para acelerar la ejecución.
- Facilitar el uso en múltiples navegadores, con diferentes niveles de soporte de los estándares.

Nótese que estos pasos requieren modificar el código fuente de nuestra app hasta dejarlo irreconocible. Este proceso es, en mi opinión, una de las razones por las que los autores de bower han "matado" el proyecto. ¿Qué sentido tiene preocuparse por mantener una esctructura "sencilla" de ficheros si al final se van a coger sólo los que hacen falta y se van a juntar/empaquetar en uno? Total, a los desarrolladores JavaScript, en general, no les preocupa mucho tener el equipo lleno de basura de dudosa utilidad.

Efectivamente, eso es lo que creía haber leído... me alegra confirmarlo.  :))

 

Esta es la razón también por la cual inicialmente npm se utilizaba para gestionar las dependencias del backend y bower para las del frontend, pero ya no. Si la única ventaja de bower deja de tener sentido ¿por qué no utilizar npm para ambos grupos? En el package.json de portainer puedes ver cómo "dependencies" son las librerías que hasta hace un mes se gestionaban con bower (las del frontend) y "devdependencies" son las que no son del frontend.

Gracias Unai, esto en parte me responde a la duda que planteaba en el mensaje anterior. La cuestión es que está claro que no se necesitan dos gestores distintos, menos en una "web de escritorio"... y el enlace de ejemplo lo confirma (mis ideas y dudas tienen al menos una lógica... no estoy tan loco como pensaba... jajajajajajaja)

A partir de aquí, ¿qué aporta yarn? La verdad es que "poco" con respecto a npm, pero muy importante. Principalmente que gestiona los repo git sin problemas (incluso aplicando los filtros de versión a tags/branches) y que asegura que todos los desarrolladores/colaboradores van a utilizar exactamente la misma versión de cada librería. Con npm las versiones utilizadas son equivalentes o compatibles, pero no hay un mecanismo que garantice que son exactamente las mismas fuentes. Esto naturalmente sólo es relevante en proyectos con más de un desarollador activo. Tiene poca o ninguna utilidad en proyectos individuales que se hacen públicos.

Y, ¿qué aporta webpack? Es un empaquetador, no un gestor de librerías. Es una de las herramientas que se puede utilizar la minification, uglification, transcoding, etc. Es decir, npm + webpack o yarn + webpack.

Algo que no me dio tiempo a investigar en profundidad... la misión de Webpack. Si estaba claro que no es necesario más que un gestor de paquetes y ya tenemos a Yarn... ¿Qué aportaba de diferente Webpack ante Bower si este se eliminaba? Contestado... aporta lo que no es... no es un gestor, es un empaquetador. Perfecto, duda resuelta. Gracias. :)))

 

Fíjate que hasta hora me he centrado en el frontend. ¿Por qué? Porque JavaScript es un lenguaje de scripting para frontends web, así se diseñó y para eso es "bueno". Cuando Google publicó su JavaScript engine (aka V8) y basado en ello se publicó nodejs, se rompieron un poco los esquemas:

Por un lado surgieron herramientas escritas en JavaScript que no eran para el frontend, sino para gestionar/automatizar el desarrollo. Algunos nombres conocidos son grunt o gulp. ¿Qué diferencia hay entre estos y un conjunto de scripts en shell? Absolutamente nada. Bueno, sí, que para usar una shell hay que saber usar una shell. De hecho, los desarolladores web con cierta experiencia tienen suficiente con npm/yarn y scripts. Más aún, casi todos los gruntfile que he visto por ahí tienen alguna parte en shell.

¡Pues otra duda más resuelta!. :))))

Una duda que me surgió investigando las herramientas que usa icestudio... ¿Para qué se usa Grunt si simplemente realiza tareas de shell cuando se podrían usar los scripts desde la línea de comandos directamente? Según tu párrafo anterior...está claro, realmente no sería necesario. Es una carga más de código de biblioteca, con una dependencia más de versiones que, además, se podría evitar si se quisiera. :(

Por otro lado, V8 y nodejs incluyen librerías escritas en JavaScript que permiten ignorar la característica principal que diferencia el frontend del backend: el backend puede acceder al sistema de ficheros en el que se está ejecutando, el frontend no. Como derivada, no hay que saber cómo se transmite la información en la web, sino que son llamadas a funciones sin más.

Para rizar más el rizo, todas las librerías JS, ya sean para frontend, backend, comunicación o automatización, se gestionan de forma idéntica. No hay siquiera alguna etiqueta orientativa para nuevos usuarios.

Sí, estoy contigo... todo un lío cuando tienes código JavaScript en ambos entornos y para colmo, en el escritorio lo tienes todo en la misma máquina y ya no hay "conexión física" entre frontend y backend. Esto también me volvió un poco loco los primeros días de investigación... gracias por dejarme claro que no todo era "culpa mía" y de mi torpeza para entender qué código JavaScript se ejecutaba en qué momento y sobre qué ámbito.... por lo menos ya me puedo volver a auto-engañar y decir que no me estoy volviendo tonto por momentos y con la edad... jajajajajajaja

 

La caja de pandora ya está abierta y el marketing es impecable: escribe un programa completo en JS sin saber nada en absoluto sobre arquitectura de aplicaciones ni sobre qué es una comunicación entre dos aplicaciones. De hecho, sin tener ni idea de las muchas capas que hay desde tu script hasta el código máquina. Va a ser pesado, ineficiente, y habrá bugs imposibles de depurar, pero como el target es quien sabe poco o nada de programación, tampoco va a saber apreciarlo. Si una librería no funciona, cambiará a otra o copiará algún otro snippet que encuentre por ahí.

De acuerdo en todo, la sensación de modificar algo para probar (hablo ahora de Icestudio), echar a ejecutar la tarea con Grunt y ver en consola "grunt serve" sin ningún mensaje más.... y dos minutos después aparece una ventana y al otro minuto aparece por fin el título de la misma, el menú y el entorno... no tienes más que pensar y preguntarte,... "¿Por qué tarda tanto? (Esto es pesado... ),  ¿Y todo esto para mostrar una ventana y un menú? (Ineficiente...) y sin saber qué está pasando mientras tanto... ¿Qué pasa si hay un bug?¿Cómo sé en que punto encontrarlo?... Por si acaso hago pruebas de poco a poco...y entre prueba y prueba me da tiempo a apuntar mis ideas... por si acaso y por aprovechar los tiempos muertos..." :))

En conclusión, si quieres aprender "tecnologías web", huye de nodejs/electron como plataforma. Escribe un frontend en HTML/CSS/JS y escoge el lenguaje que más te guste para el backend (yo voto por golang porque es estúpidamente sencillo, pero te sirven Python, Java...). Hazlo a mano, es decir, sin grunt ni gulp ni similares. Cuando hayas entendido qué gestores y empaquetadores necesitas para el frontend, cuáles para el backend y cómo puedes comunicar ambas partes, sólo entonces, y sólo si lo necesitas, cambia a nodejs/electron. ¿Para qué necesitas nodejs/electron en este caso? En realidad para nada, porque ya tienes un navegador en cualquier equipo que utilices. Pero puede que quieras ponerte "elegante" y querer que tu app esté empaquetada en su propia ventana y con su propio ejecutable, además de no tener que preocuparte por el soporte en navegadores diferentes de Chrome. Ver, por ejemplo, Syncthing y Synctrayzor.

El problema y la cuestión es que realmente no quiero aprender "tecnologías web" porque sí,... no es que las vaya a utilizar en mi día a día... si por algo me interesan es porque son estas tecnologías las que utiliza icestudio y solo me interesan por eso (a día de hoy)... porque me gustaría poder modificar y ampliar icestudio para intentar plasmar alguna de mis ideas con las FPGA y eliminar así parte de las limitaciones que le veo a la herramienta aprovechando las virtudes que tiene (que son muchas)... y por lo que veo y a la conclusión que he llegado durante estos dos años es que la única forma de hacerlo es "empaparme" de estas tecnologías por mi cuenta y desentrañar el código fichero a fichero, para poder modificar mínimamente el sistema, que el sistema haga lo que me interesa que haga y todo esto sin que se "desmorone" por completo al primer intento...  ;)))

Esa es otra duda que se me planteó... Si esto son tecnologías web... ¿Para qué necesito pasar por Electron para las pruebas?¿No podría hacer las pruebas con un navegador y luego, si quiero "ponerme elegante" como dices, utilizar Electron o similar?

Incluso más allá... ¿Podría separar el código de icestudio para ejecutar el backend en una máquina separada y distinta de la que corre el frontend? Esto último estaría muy interesante... :)))

A parte de esto...¿Se te ocurre otra forma de poder modificar y añadir una funcionalidad (aunque sea mínima) a icestudio sin morir en el intento, sin necesitar "empaparse" en estas tecnologías hasta el detalle y sin tener que reescribir el código en un programa distinto? :)))

Sinceramente creo que no... bueno, de hecho estoy convencido de que las barreras las voy a tener que bajar yo solo, por mi cuenta y a cabezazos... jajajajajajajaja

¿Por qué te recomiendo este camino y no el sugerido en Inbit? Para tratar de evitar que llegues a la situación de icestudio: una aplicación escrita con tecnologías web que no puede utilizarse en la web sin reescribirse prácticamente por completo (porque quién sabe dónde está la línea entre el frontend y el backend). El hecho de que se utilicen uno o varios gestores de paquetes y el cacao mental que eso te pueda producir es más o menos irrelevante en comparación con este hecho. Léase: dejar de utilizar bower es trivial, hacer un icestudio cliente-servidor no. Estudiar tecnologías web para al final darte cuenta de que no vas a poder hacer una web (single page application) es un chasco.

Vale, ya no tengo que esperar a tu siguiente post... ya me has contestado... jejejejejeje
Por lo que leo... No es trivial convertir icestudio en un cliente-servidor porque está todo mezclado... frontend y backend. ¿Qué solución existe? ¿Tan complicado sería tomar el código JavaScript y reordenarlo para poner los paquetes de npm en el backend (y solo en el servidor) y los de bower en el frontend? ¿Qué paquetes son los que hacen tan difícil esta separación si en principio están separados conceptualmente desde el inicio?

Sé que es un poco recurrente todo esto y te pido disculpas... pero debe haber alguna forma de "reciclar" el código...¿No? :(((

¿O cúal es tu consejo? ¿Que directamente ni lo intente? ¿No tiene solución icestudio? ¿No podré sentirme nunca verdaderamente libre con icestudio por mucho que me esfuerce en intentar comprenderlo y asimilarlo, aunque sea desde el propio código, para finalmente poder y tener la capacidad de modificarlo?  :(((  

Me lo pones muy mal si es así... :_(((

Ahora bien, si no tienes inconveniente en que tu aplicación esté limitada a su uso en el escritorio y si realmente tienes claro en qué parte estás trabajando en cada momento, a pesar de hacerlo todo en JavaScript, adelante. Aún así, si estas en esta situación, ¿estás seguro de querer utilizar tecnologías web? ¿Por qué no gtk/Qt/QML con los bindings que más te gusten (digamos Python)? Conozco la respuesta, sólo son preguntas retóricas para dar a entender que HTML/CSS/JS son una alternativa razonable a Qt/QML, no a C++. Donde "alternativa razonable" incluye tanto rendimiento/eficiencia como tiempo de desarrollo.

Menos mal que has aclarado que eran retóricas,... ya te iba a responder... ¡Para una que me sabía!... jajajajajaja

Saludos

Muchas gracias como siempre por tus posts. Se aprende mucho. ;)

Saludos

Juan Manuel Rico

 

[1138-4EB]

Fileteado:

Juanma Rico escribió:

Buenas Unai, como siempre encantado de leer un post tuyo.

Un placer. Me viene muy bien para afianzar conceptos y ver si soy capaz de explicarlo tan claro como parezco tenerlo.

 

Sí, tienes razón... me surgen muchas dudas de conceptos a los que no les veo lógica ninguna (la pregunta de mi post anterior es solo una de ellas).

Ahora estoy investigando el código más reciente de icestudio y, por lo poco que llevo visto, creo entender que usa el dúo nodejs/angular en lugar de nodejs/electron. Además de, por supuesto, Grunt para la automatización de tareas y Bower como gestor de paquetes del frontend. (Cuando tenga claro este punto del dúo de actores lo confirmo... por ahora tengo los pies de barro en este tema... es solo una creencia mezclada con especulación... :))) ).

Cuando escribo nodejs/electron me refiero a usar uno o el otro. De hecho, en la práctica, me refiero sólo a electron, siendo el prefijo nodejs sólo para subrayar que electron utiliza nodejs por debajo: https://github.com/electron/electron/blob/master/docs/development/atom-shell-vs-node-webkit.md

AngularJS es una librería para frontend. Concretamente, para crear single-page applications (SPAs). Otras librerías/framework similares son Vue.js, React, Ember... El objetivo de estas librerías es facilitar la descripción de múltiples páginas HTML, sin tener que crear cada una por separado. No tienen nada que ver con nodejs/electron. Por ejemplo, en el caso de portainer puedes ver que hay una carpeta "app" con todas las fuentes referentes al frontend angular, y otra carpeta separada llamada "api" que contiene el backend en golang. Se podría reescribir "api" en JS y utilizar electron para empaquetarlo, sin cambiar el frontend (angular).

Por lo tanto, icestudio utiliza electron para el "backend" y angular para el "frontend". Mi recomendación anterior sobre analizar las tecnologías web por separado va en esta línea. En principio, no necesitas saber sobre electron para trabajar en el frontend, y tampoco necesitas saber sobre angular para trabajar en el backend.

 

Un ejemplo muy claro de otra de las dudas que tenía.... ¿Por qué un servidor central "exclusivo" para el código JavaScript? :))

Creo que la pregunta sería, ¿por qué más de un servidor central "exclusivo"? Que haya uno no es tan raro. He ahí CPAN o CTAN, proyectos muy exitosos y longevos ya. Lo extraordinario era que bower tuviera el suyo y npm otro diferente. ¿Podríamos vivir sin CPAN, CTAN y npmjs? Por supuesto. Pero no creo que esté de más un espacio independiente de servicios de hosting con características específicas (como GitHub).

¡Pues otra duda más resuelta!. :))))

Una duda que me surgió investigando las herramientas que usa icestudio... ¿Para qué se usa Grunt si simplemente realiza tareas de shell cuando se podrían usar los scripts desde la línea de comandos directamente? Según tu párrafo anterior...está claro, realmente no sería necesario. Es una carga más de código de biblioteca, con una dependencia más de versiones que, además, se podría evitar si se quisiera. :(

Si, pero no XD. Para la complejidad que estamos tratando en este hilo, es como dices. Pero, para ser sinceros, hay ciertos plugins de grunt que hacen cosas no tan directas. Más concretamente hay proyectos que no utilizan webpack, por lo que las tareas de concatenación/merge de ficheros + renombrar los paquetes resultantes para que tenga un nombre único (filerev) + reemplazar las líneas de tipo include en el HTML... se hacen en grunt. Todo esto podría hacerse mediante scripts, pero no conozco ninguna alternativa escrita en un lenguaje que no sea JS.

Por lo tanto, así como quitar bower es sencillo y directo, dependiendo de la complejidad del proyecto dejar de usar grunt puede no serlo tanto. Por otro lado, si necesitas instalar nodejs porque vas a utilizar npm o yarn como gestor de paquetes, ¿qué más da instalar otro paquete más? Dejar de usar grunt sólo tendría sentido si descargas los paquetes mediante scripts y si tu aplicación no utiliza nodejs.

De acuerdo en todo, la sensación de modificar algo para probar (hablo ahora de Icestudio), echar a ejecutar la tarea con Grunt y ver en consola "grunt serve" sin ningún mensaje más.... y dos minutos después aparece una ventana y al otro minuto aparece por fin el título de la misma, el menú y el entorno... no tienes más que pensar y preguntarte,... "¿Por qué tarda tanto? (Esto es pesado... ),  ¿Y todo esto para mostrar una ventana y un menú? (Ineficiente...) y sin saber qué está pasando mientras tanto... ¿Qué pasa si hay un bug?¿Cómo sé en que punto encontrarlo?... Por si acaso hago pruebas de poco a poco...y entre prueba y prueba me da tiempo a apuntar mis ideas... por si acaso y por aprovechar los tiempos muertos..." :))

En realidad, que sea pesado y/o ineficiente no creo que sea lo peor. Demostrado está que para el nivel de exigencia de los usuarios de icestudio es suficiente. La eficiencia sería relevante para trabajar en proyectos medianamente reales, pero parece ser que ese no es el target de icestudio ni está en el roadmap.

Lo "peor" de Grunt es que se lo come todo sin rechistar. Es decir, tú le dices que quieres concatenar diez ficheros, y si no existen simplemente los ignora y junta los que si haya. De esto no te das cuenta hasta que no lanzas la app y ves que sólo aparece una página en blanco. Te vas a la consola del navegador y empiezas a ver errores (de carga de librerías) por todas partes. Es un "bug" muy entretenido para perder un par de tardes, porque funcione bien o funcione mal el proceso de build siempre acaba sin errores.

 

El problema y la cuestión es que realmente no quiero aprender "tecnologías web" porque sí,... no es que las vaya a utilizar en mi día a día... si por algo me interesan es porque son estas tecnologías las que utiliza icestudio y solo me interesan por eso (a día de hoy)... porque me gustaría poder modificar y ampliar icestudio para intentar plasmar alguna de mis ideas con las FPGA y eliminar así parte de las limitaciones que le veo a la herramienta aprovechando las virtudes que tiene (que son muchas)... y por lo que veo y a la conclusión que he llegado durante estos dos años es que la única forma de hacerlo es "empaparme" de estas tecnologías por mi cuenta y desentrañar el código fichero a fichero, para poder modificar mínimamente el sistema, que el sistema haga lo que me interesa que haga y todo esto sin que se "desmorone" por completo al primer intento...  ;)))

Por supuesto. No me refería a hacer una app de verdad completa. Sino a uno o varios juguetes, como inbit, en los que analices cada cosa por separado. Por ejemplo, una app en angular (utilizando como backend Apache o cualquier otro servidor web). El objetivo final es que tengas claro cuales son las "trampas" que hacen nodejs/electron antes de entrar en un proyecto que parece ser monolítico. No importa que icestudio tenga el frontend y el backend mezclados, si tú eres capaz de saber qué estás haciendo en cada momento. Pero es difícil que seas capaz si no tienes claro cómo se haría por separado.

BTW, aguita con AngularJS. Tienes que hacer las cosas "al estilo angular". Una vez que lo pillas, está bastante bien. Hasta que lo haces, te pegas continuamente cabezazos contra la pared. Es muy muy muy poco intuitivo para alguien que venga de hacer webs a mano o en PHP. En este sentido Vue.js o Ember son menos invasivos (también son más a bajo nivel). Una vez más, no sugiero que reescribas icestudio con uno de estos frameworks. Simplemente creo que el camino natural es empezar por un juguete en HTML + CSS, después meter algo de JS vanilla, luego utilizar jQuery, probar algún framework no invasivo y finalmente pasar a AngularJS. Yo hice este "recorrido" en un par de tardes (una para documentarme y otra para cacharrear) y tengo que admitir que es bastante satisfactorio, en el sentido en que ves tu progresión muy claramente, en vez de desesperarte porque no "entiendes" el paso final sin haber dado los anteriores.

NOTA: me refiero en todo momento a Angular 1.x, AngularJS o como quiera que se llame la versión vieja escrita en JS, que es la que he utilizado y la que creo que utiliza icestudio. La versión actual (Angular, Angular 2.x, Angular 2+...) está escrita en TypeScript. Resumamoslo en que no queremos meternos en el fregado de ECMAScript 5, ECMAScript 6 y el soporte desigual de los navegadores. Si quieres remangarte y meterte en ello, esto es a lo que me referia con transcoding/transcompilation y la posibilidad de utilizar webpack.

 

Esa es otra duda que se me planteó... Si esto son tecnologías web... ¿Para qué necesito pasar por Electron para las pruebas?¿No podría hacer las pruebas con un navegador y luego, si quiero "ponerme elegante" como dices, utilizar Electron o similar?

Incluso más allá... ¿Podría separar el código de icestudio para ejecutar el backend en una máquina separada y distinta de la que corre el frontend? Esto último estaría muy interesante... :)))

Respondo debajo.

 

A parte de esto...¿Se te ocurre otra forma de poder modificar y añadir una funcionalidad (aunque sea mínima) a icestudio sin morir en el intento, sin necesitar "empaparse" en estas tecnologías hasta el detalle y sin tener que reescribir el código en un programa distinto? :)))

 

Aquí tengo una limitación personal. Tengo cierta necesidad vital por entender lo que hago, por lo que casi nunca meto mano a algo sin haberme "empapado" antes. Necesito interiorizar la tecnología que estoy utilizando para no tener cierta ansiedad por sentir que me estoy dejando algo o que voy a atascarme en un bug estúpido por no tener claro el marco en el que estoy. Así que, en este sentido, poco puedo ayudarte, salvo en facilitarte los recursos y explicaciones que me ayudaron a empaparme.

En cuanto a reescribir el código en un programa distinto, como he comentado, me refería a juguetes para tu proceso de aprendizaje. Entiendo que, una vez que hayas aprendido por separado, podrás ir al código de icestudio y estudiar su estructura lógica que es lo que te interesa. Necesitas educar el ojo y la cabeza primero, para quitar la paja al mirar el código, es decir, para no desviar tu atención en cuestiones de sintaxis o detalles de uso de librerías.

 

Sinceramente creo que no... bueno, de hecho estoy convencido de que las barreras las voy a tener que bajar yo solo, por mi cuenta y a cabezazos... jajajajajajajaja

Básicamente. Es cierto que para aprender a utilizar electron, angular, bower, npm, yarn, grunt... te darás cabezazos, pero tienes muchísima información y ejemplos en internet, libros sobre ello, videotutoriales... Algo bueno tiene que tener tanto hype.

Sin embargo, aunque consigas dominar todas esas herramientas, seguiras sin saber cómo está estructurada la aplicación, qué funciones hay, cuáles son los puntos de entrada, cuáles las auxiliares, por qué hay algunas directivas y no otras, qué funcionalidades deben ir en icestudio y cuáles en apio... Facilitar toda o parte de esta información depende del arquitecto de la aplicación. Ojo, que no estoy exigiendo nada. De hecho, es posible que haya herramientas para obtener información automáticamente. Simplemente creo que es la clave entre un proyecto que busca proactivamente la colaboración y uno que no.

Vale, ya no tengo que esperar a tu siguiente post... ya me has contestado... jejejejejeje
Por lo que leo... No es trivial convertir icestudio en un cliente-servidor porque está todo mezclado... frontend y backend. ¿Qué solución existe? ¿Tan complicado sería tomar el código JavaScript y reordenarlo para poner los paquetes de npm en el backend (y solo en el servidor) y los de bower en el frontend? ¿Qué paquetes son los que hacen tan difícil esta separación si en principio están separados conceptualmente desde el inicio?

Sinceramente, es un brindis al sol. No he analizado icestudio con suficiente detalle como para evaluar cómo de fácil o difícil es la conversión. Mi afirmación viene motivada por las respuestas que ha dado Jesús cuando se le ha preguntado por ello: de memoria, algo así como "icestudio está hecho con tecnologías web, por lo que podría convertirse" e "icestudio es un proyecto abierto y cualquier colaboración es bienvenida". Yo lo interpreto como "no lo pensé cuando empecé a escribir icestudio y no voy a ponerme a pensar en ello ahora".

¿Sería complicado reordenar el código para tener las tareas/funciones relativas al frontend por un lado y las del backend por otro? En principio, no.

¿Qué paquetes son los que lo hacen difícil? Ninguno.

¿Cuál es el problema entonces? El acceso a disco y, por consiguiente, a los ejecutables disponibles nativamente. En otras palabras, si a icestudio le quitas "el enlace" a apio, yosys, icestorm, etc. ya puedes utilizar icestudio como una app cliente sólo (angular), y servirla desde cualquier servidor web. Esto responde a cómo puedes probar icestudio sin electron. Desde mi punto de vista seguiría siendo útil, porque utilizaría icestudio para cargar un fichero ICE, editarlo y guardar el resultado (exportado a verilog). Después, en local, ejecutaría las herramientas adecuadas con el resultado descargado. Sin embargo, entiendo que tener opciones en el menú para sintetizar y programar las placas directamente es una de las características principales de icestudio, teniendo en cuenta el público objetivo.

Pongamos un ejemplo sencillo. Tenemos un formulario web con un botón y dos campos de texto: uno contiene "Hello world" y el otro contiene la ruta absoluta o relativa a un fichero (pongamos que es /home/user/hello_world.txt). Queremos que al pulsar el botón el fichero se guarde en el disco. Nótese que, aunque sea sintácticamente diferente, es irrelevante hacerlo con JS vanilla, angular o cualquier otro framework frontend. Tres formas de guardar el fichero:

- Sin backend. Cuando le doy al botón, el navegador descarga el fichero. Depende de cómo esté configurado el navegador, irá directamente a Descargas o me preguntará dónde quiero guardarlo. En cualquier caso el segundo campo de texto (la path) no sirve para nada, porque el usuario lo decide al "guardar como". No es posible que una aplicación cliente guarde ficheros sin intervención del usuario. Bueno, estrictamente se puede guardar información en las cookies y en la caché del navegador, pero no en una path arbitraria del disco del usuario. Es fácil entender que esto es una limitación inherente a todos los navegadores web para evitar que cualquier página web pueda instalar malware sin más.

- Con "backend" nodejs/electron. Cuando le doy al botón, el pseudo-navegador (JS engine) utiliza una función equivalente a printf para guardar el fichero directamente en la path indicada. Como el backend se ejecuta en la misma máquina que el frontend, esa path corresponde al disco del usuario.

- Con un "backend" real. Cuando le doy al botón, la aplicación cliente (el frontend) crea una estructura con al menos dos campos (el texto y la path) y hace una llamada POST mediante AJAX (jQuery) a una URL (e.g. localhost/guardarfichero o miapp.com/guardarfichero). El backend está "escuchando" en esa URL, y cuando recibe el POST, extrae el texto y utiliza printf (o equivalente) para guardarlo. Como el backend no tiene por qué estar ejecutándose en la misma máquina que el frontend, el fichero no se guarda en el disco del usuario, sino en el servidor. Evidentemente, si lanzas el backend en tu misma máquina, el resultado es equivalente al caso anterior.

 

Las opciones 1 y 3 se pueden combinar. A veces queremos que el usuario se descargue un fichero a su equipo. Otras veces queremos que se guarde en el servidor. ¿Cuándo queremos que se guarde en el servidor? Cuando el paso inmediatamente posterior es hacer otra llamada POST o GET que ejecute por ejemplo yosys (teniendo yosys instalado en el servidor, y no en el cliente). ¿Cuándo queremos que se lo descargue el usuario? Cuando el fichero es un producto/resultado, por ejemplo, el resultado de la ejecución de yosys.

Esto tiene un poco más de miga, porque por un lado las llamadas AJAX son, en principio, asíncronas. Esto quiere decir que el fichero no se guarda exactamente cuando hago la llamada AJAX (POST) desde el cliente. Cuándo se ejecute la instrucción realmente depende de cuánto tarde el backend en responder. No es que el tiempo sea apreciable por el usuario, sino que a nivel de ejecución secuencial del código tu cliente va a seguir ejecutando pasos posteriores antes de que se haya terminado de escribir el fichero. Si el paso posterior necesita el fichero, fallará. Por lo tanto, es necesario pensar la lógica del cliente para que espere, si tiene que esperar, o que hagas otras cosas mientras tanto.

Por otro lado, POST y GET no son las únicas formas de pasar información. También se puede hacer a través de la URL, por ejemplo, localhost/guardarfichero?text='hello world'&path='/home/user/hello_world.txt'. Nota, no estoy seguro del uso de las comillas aqui, pero creo que se entiende la idea.

En cualquier caso, la idea básica es que hay que añadir un paso/función para transmitir la información del frontend al backend, considerando que cada parte puede estar escrita en un lenguaje totalmente diferente.

Sé que es un poco recurrente todo esto y te pido disculpas... pero debe haber alguna forma de "reciclar" el código...¿No? :(((

¿O cúal es tu consejo? ¿Que directamente ni lo intente? ¿No tiene solución icestudio? ¿No podré sentirme nunca verdaderamente libre con icestudio por mucho que me esfuerce en intentar comprenderlo y asimilarlo, aunque sea desde el propio código, para finalmente poder y tener la capacidad de modificarlo?  :(((  

Me lo pones muy mal si es así... :_(((

No me seas agorero, hombre. Icestudio tiene solución, puedes reciclar todo lo que quieras, y podrás sentirte libre con esfuerzo. Lo que tienes que tener claro son las limitaciones inherentes a las decisiones tecnológicas que ya se han tomado y el esfuerzo necesario para entender la arquitectura indocumentada. Por ejemplo, para convertirla en cliente-servidor, tendrías que:

- Revisar todo el código para identificar todos los puntos en los que se accede a disco (manipulación de ficheros o llamadas a herramientas).

- Cambiar todas las llamadas directas (e.g. printf) por dos funciones intermedias. Inicialmente, pueden ser funciones dummy, es decir, reemplazar printf por mi_printf, que mi_printf sólo contenga una llamada a mi_backend_printf y que ésta sólo llame a printf.

- Mover la definición de todas esas funciones intermedias a un mismo directorio, o a un grupo de directorios, para tenerlas localizadas.

A partir de ahí, reemplazar el contenido de mi_printf por una llamada AJAX, e implementar mi_backend_printf como la rutina de respuesta a la llamada. Este paso en concreto no sé si puedes hacerlo con nodejs/electron o si necesitas un backend de verdad. Si fuera así, debería haber dos versiones de las funciones, una para utilizar cuando se compile en eletron y otra para un supuesto backend de verdad. Grunt se podría utilizar para decidir cuándo usar unas y cuándo otras.

 

Por lo tanto, mi consejo es que ni intentes esto ahora. Vas a tener que hacer suficientes modificaciones como para agarrarte un buen cabreo si luego no se incluye en el repositorio oficial, y será pesado de mantener forkeado. Si estás trabajando solo, ponte metas más asequibles. Lo ideal sería que tuvieras una lista de cosas que te gustaría cambiar, y que Jesús, que conoce el código, pudiera recomendarte por cuál(es) empezar y qué ficheros empezar a mirar.

Si aun así quieres intentarlo, yo también estoy muy interesado en una solución cliente-servidor. Creo que en algún hilo (no sé si de Lorea) ya comenté que sería muy interesante tener icestudio, apio y el resto de herramientas instaladas en un solo ordenador de un aula/centro educativo y que el alumnado pueda utilizarlo desde tablets o desde sus propios móviles. Lo que sucede es que no tengo la motivación para empollarme la app entera. Sin embargo, si hubiera un listado de funciones/tareas que deba soportar un backend para funcionar con icestudio (lo que se denomina comunmente API, ver swagger.io), me gustaría intentar implementar un backend alternativo para que nodejs/electron sea una opción, pero no la única.

Sólo por exponer la imagen completa, mi objetivo final es poder quitar apio de la ecuación también, y quedarme "solo" con el frontend de icestudio. Así, la alternativa a nodejs/electron sería una única imagen docker que ya incluya todas las herramientas precompiladas. Esa imagen sería única por arquitectura (x86_64, arm...) pero independiente del sistema operativo.

Muchas gracias como siempre por tus posts. Se aprende mucho. ;)

A ver si saco tiempo un día de estos para implementar inbit sin nodejs/electron. Tengo un par de demos muy similares, pero están adaptadas para ciertos contenidos que no son públicos, por lo que tengo que "limpiarlas". Estoy convencido de que puede resultarte muy didáctico para "ver" los detalles expuestos en estos mensajes.

 

Saludos

[Juanma Rico]

Trinchado... :)))

1138-4EB escribió:

Fileteado:

Juanma Rico escribió:

Buenas Unai, como siempre encantado de leer un post tuyo.

Un placer. Me viene muy bien para afianzar conceptos y ver si soy capaz de explicarlo tan claro como parezco tenerlo.

Y yo encantado de que así sea... :))

 

Sí, tienes razón... me surgen muchas dudas de conceptos a los que no les veo lógica ninguna (la pregunta de mi post anterior es solo una de ellas).

Ahora estoy investigando el código más reciente de icestudio y, por lo poco que llevo visto, creo entender que usa el dúo nodejs/angular en lugar de nodejs/electron. Además de, por supuesto, Grunt para la automatización de tareas y Bower como gestor de paquetes del frontend. (Cuando tenga claro este punto del dúo de actores lo confirmo... por ahora tengo los pies de barro en este tema... es solo una creencia mezclada con especulación... :))) ).

Cuando escribo nodejs/electron me refiero a usar uno o el otro. De hecho, en la práctica, me refiero sólo a electron, siendo el prefijo nodejs sólo para subrayar que electron utiliza nodejs por debajo: https://github.com/electron/electron/blob/master/docs/development/atom-shell-vs-node-webkit.md

AngularJS es una librería para frontend. Concretamente, para crear single-page applications (SPAs). Otras librerías/framework similares son Vue.js, React, Ember... El objetivo de estas librerías es facilitar la descripción de múltiples páginas HTML, sin tener que crear cada una por separado. No tienen nada que ver con nodejs/electron. Por ejemplo, en el caso de portainer puedes ver que hay una carpeta "app" con todas las fuentes referentes al frontend angular, y otra carpeta separada llamada "api" que contiene el backend en golang. Se podría reescribir "api" en JS y utilizar electron para empaquetarlo, sin cambiar el frontend (angular).

Por lo tanto, icestudio utiliza electron para el "backend" y angular para el "frontend". Mi recomendación anterior sobre analizar las tecnologías web por separado va en esta línea. En principio, no necesitas saber sobre electron para trabajar en el frontend, y tampoco necesitas saber sobre angular para trabajar en el backend.

Bien, ha quedado claro que no es que tuviera los pies de barro... es que no había barro. Por no haber no había ni pies... jajajajajaja

Habia mezclado churras con merinas... sorry.

Investigando en el enlace veo que Electron y NW.js hacen lo mismo, llevar al escritorio la tecnología web. Pues bien, he buscado las dependencias en icestudio y no he encontrado ninguna dependencia con Electron, pero sí con NW.js, lo que me ha hecho recordar algún post antiguo en el que se hablaba del tema y estoy por afirmar (casi con rotundidad... o no... que sé yo... :) ) que icestudio no usa Electron, sino NW.js.

Para intentar confirmarlo, en el fichero de package.json he encontrado la siguiente línea:

devDependencies: {

       .....

       "nw": "^0.12.3"

       .....

}

Y sin embargo ninguna a Electron, como se puede ver en el fichero completo (https://github.com/FPGAwars/icestudio/blob/develop/package.json)

Casi seguro que esta vez no me equivoco... casi... :))

 

Un ejemplo muy claro de otra de las dudas que tenía.... ¿Por qué un servidor central "exclusivo" para el código JavaScript? :))

Creo que la pregunta sería, ¿por qué más de un servidor central "exclusivo"? Que haya uno no es tan raro. He ahí CPAN o CTAN, proyectos muy exitosos y longevos ya. Lo extraordinario era que bower tuviera el suyo y npm otro diferente. ¿Podríamos vivir sin CPAN, CTAN y npmjs? Por supuesto. Pero no creo que esté de más un espacio independiente de servicios de hosting con características específicas (como GitHub).

Bien, aceptamos entonces servidor central exclusivo para JavaScript....(pero solo uno)  :)))

¡Pues otra duda más resuelta!. :))))

Una duda que me surgió investigando las herramientas que usa icestudio... ¿Para qué se usa Grunt si simplemente realiza tareas de shell cuando se podrían usar los scripts desde la línea de comandos directamente? Según tu párrafo anterior...está claro, realmente no sería necesario. Es una carga más de código de biblioteca, con una dependencia más de versiones que, además, se podría evitar si se quisiera. :(

Si, pero no XD. Para la complejidad que estamos tratando en este hilo, es como dices. Pero, para ser sinceros, hay ciertos plugins de grunt que hacen cosas no tan directas. Más concretamente hay proyectos que no utilizan webpack, por lo que las tareas de concatenación/merge de ficheros + renombrar los paquetes resultantes para que tenga un nombre único (filerev) + reemplazar las líneas de tipo include en el HTML... se hacen en grunt. Todo esto podría hacerse mediante scripts, pero no conozco ninguna alternativa escrita en un lenguaje que no sea JS.

Por lo tanto, así como quitar bower es sencillo y directo, dependiendo de la complejidad del proyecto dejar de usar grunt puede no serlo tanto. Por otro lado, si necesitas instalar nodejs porque vas a utilizar npm o yarn como gestor de paquetes, ¿qué más da instalar otro paquete más? Dejar de usar grunt sólo tendría sentido si descargas los paquetes mediante scripts y si tu aplicación no utiliza nodejs.

Bien, aceptamos entonces también Grunt como "mal necesario"... ¿no estamos recogiendo hilo más rápido del que lanzamos? jajajajajajajaja

De acuerdo en todo, la sensación de modificar algo para probar (hablo ahora de Icestudio), echar a ejecutar la tarea con Grunt y ver en consola "grunt serve" sin ningún mensaje más.... y dos minutos después aparece una ventana y al otro minuto aparece por fin el título de la misma, el menú y el entorno... no tienes más que pensar y preguntarte,... "¿Por qué tarda tanto? (Esto es pesado... ),  ¿Y todo esto para mostrar una ventana y un menú? (Ineficiente...) y sin saber qué está pasando mientras tanto... ¿Qué pasa si hay un bug?¿Cómo sé en que punto encontrarlo?... Por si acaso hago pruebas de poco a poco...y entre prueba y prueba me da tiempo a apuntar mis ideas... por si acaso y por aprovechar los tiempos muertos..." :))

En realidad, que sea pesado y/o ineficiente no creo que sea lo peor. Demostrado está que para el nivel de exigencia de los usuarios de icestudio es suficiente. La eficiencia sería relevante para trabajar en proyectos medianamente reales, pero parece ser que ese no es el target de icestudio ni está en el roadmap.

Lo "peor" de Grunt es que se lo come todo sin rechistar. Es decir, tú le dices que quieres concatenar diez ficheros, y si no existen simplemente los ignora y junta los que si haya. De esto no te das cuenta hasta que no lanzas la app y ves que sólo aparece una página en blanco. Te vas a la consola del navegador y empiezas a ver errores (de carga de librerías) por todas partes. Es un "bug" muy entretenido para perder un par de tardes, porque funcione bien o funcione mal el proceso de build siempre acaba sin errores.

Eso de la página en blanco, esperar, esperar... y que no aparezca el entorno de aplicación...  me ha pasado más de una vez haciendo pruebas... no sabía que Grunt era el culpable... ya sé a quién maldecir, todo un avance... jejejejeje

Otro avance es saber que puedes consultar la consola del navegador para ver los errores... no se me había ocurrido... yo como tonto esperando que los errores aparecieran en la consola de bash, sabiendo que es javaScript... jajajajaja (Nota mental: Ya sé como se activa en Electron las herramientas de desarrollador... buscar como se activa en NW.js... :)))

-----------------------

NOTA para los lectores interesados: Mientras escribía y antes de publicar el post, he hecho una búsqueda rápida y es más sencillo de lo que parece. Simplemente activar la barra de menú y utilizar el botón que en ella se incluye.

Para ello cambiar en el fichero de definición de la ventana en app/package.json a true la toolbar.

https://github.com/FPGAwars/icestudio/blob/0d895a58539ead7e695c1678e5e5fea73915bde5/app/package.json#L15

Esto permite investigar el código de forma más fácil y dinámica... (además de cambiar colorines, letras, tamaños y demás en tiempo real... jejejejejeje)

Hay otras formas de activar estas herramientas, incluso en modo remoto al parecer... podéis encontrar más información en estos enlaces:

https://github.com/nwjs/nw.js/wiki/debugging-with-devtools

http://docs.nwjs.io/en/latest/For%20Users/Debugging%20with%20DevTools/

(A mi el método de pulsar F12 dentro de icestudio, como dicen en el segundo enlace, no me ha funcionado. :(( )

-----------------------

 

El problema y la cuestión es que realmente no quiero aprender "tecnologías web" porque sí,... no es que las vaya a utilizar en mi día a día... si por algo me interesan es porque son estas tecnologías las que utiliza icestudio y solo me interesan por eso (a día de hoy)... porque me gustaría poder modificar y ampliar icestudio para intentar plasmar alguna de mis ideas con las FPGA y eliminar así parte de las limitaciones que le veo a la herramienta aprovechando las virtudes que tiene (que son muchas)... y por lo que veo y a la conclusión que he llegado durante estos dos años es que la única forma de hacerlo es "empaparme" de estas tecnologías por mi cuenta y desentrañar el código fichero a fichero, para poder modificar mínimamente el sistema, que el sistema haga lo que me interesa que haga y todo esto sin que se "desmorone" por completo al primer intento...  ;)))

Por supuesto. No me refería a hacer una app de verdad completa. Sino a uno o varios juguetes, como inbit, en los que analices cada cosa por separado. Por ejemplo, una app en angular (utilizando como backend Apache o cualquier otro servidor web). El objetivo final es que tengas claro cuales son las "trampas" que hacen nodejs/electron antes de entrar en un proyecto que parece ser monolítico. No importa que icestudio tenga el frontend y el backend mezclados, si tú eres capaz de saber qué estás haciendo en cada momento. Pero es difícil que seas capaz si no tienes claro cómo se haría por separado.

Ok, me parece perfecto. Ese ejemplo con Angular lo voy a hacer... parece fácil... a ver qué me sale... :))

 

BTW, aguita con AngularJS. Tienes que hacer las cosas "al estilo angular". Una vez que lo pillas, está bastante bien. Hasta que lo haces, te pegas continuamente cabezazos contra la pared. Es muy muy muy poco intuitivo para alguien que venga de hacer webs a mano o en PHP. En este sentido Vue.js o Ember son menos invasivos (también son más a bajo nivel). Una vez más, no sugiero que reescribas icestudio con uno de estos frameworks. Simplemente creo que el camino natural es empezar por un juguete en HTML + CSS, después meter algo de JS vanilla, luego utilizar jQuery, probar algún framework no invasivo y finalmente pasar a AngularJS. Yo hice este "recorrido" en un par de tardes (una para documentarme y otra para cacharrear) y tengo que admitir que es bastante satisfactorio, en el sentido en que ves tu progresión muy claramente, en vez de desesperarte porque no "entiendes" el paso final sin haber dado los anteriores.

NOTA: me refiero en todo momento a Angular 1.x, AngularJS o como quiera que se llame la versión vieja escrita en JS, que es la que he utilizado y la que creo que utiliza icestudio. La versión actual (Angular, Angular 2.x, Angular 2+...) está escrita en TypeScript. Resumamoslo en que no queremos meternos en el fregado de ECMAScript 5, ECMAScript 6 y el soporte desigual de los navegadores. Si quieres remangarte y meterte en ello, esto es a lo que me referia con transcoding/transcompilation y la posibilidad de utilizar webpack.

jejejejejeje, ya estoy recuperando mi servidor olvidado de Apache en Debian... a mi seguramente me lleve más de dos tardes... posiblemente dos meses... jejejeje, pero haré el recorrido ese... al final me va a gustar y todo .... :))

Parece que tienes razón, en las dependencias se marca la 1.6:    "angular": "^1.6.0"

 

Esa es otra duda que se me planteó... Si esto son tecnologías web... ¿Para qué necesito pasar por Electron para las pruebas?¿No podría hacer las pruebas con un navegador y luego, si quiero "ponerme elegante" como dices, utilizar Electron o similar?

Incluso más allá... ¿Podría separar el código de icestudio para ejecutar el backend en una máquina separada y distinta de la que corre el frontend? Esto último estaría muy interesante... :)))

Respondo debajo.

 

A parte de esto...¿Se te ocurre otra forma de poder modificar y añadir una funcionalidad (aunque sea mínima) a icestudio sin morir en el intento, sin necesitar "empaparse" en estas tecnologías hasta el detalle y sin tener que reescribir el código en un programa distinto? :)))

 

Aquí tengo una limitación personal. Tengo cierta necesidad vital por entender lo que hago, por lo que casi nunca meto mano a algo sin haberme "empapado" antes. Necesito interiorizar la tecnología que estoy utilizando para no tener cierta ansiedad por sentir que me estoy dejando algo o que voy a atascarme en un bug estúpido por no tener claro el marco en el que estoy. Así que, en este sentido, poco puedo ayudarte, salvo en facilitarte los recursos y explicaciones que me ayudaron a empaparme.

Y yo que te lo vuelvo a agradecer... no sabes la de "cabezazos" que me evitas... y la de posibilidades que me abres con un solo párrafo tuyo...  :)))

En cuanto a reescribir el código en un programa distinto, como he comentado, me refería a juguetes para tu proceso de aprendizaje. Entiendo que, una vez que hayas aprendido por separado, podrás ir al código de icestudio y estudiar su estructura lógica que es lo que te interesa. Necesitas educar el ojo y la cabeza primero, para quitar la paja al mirar el código, es decir, para no desviar tu atención en cuestiones de sintaxis o detalles de uso de librerías.

 

Sinceramente creo que no... bueno, de hecho estoy convencido de que las barreras las voy a tener que bajar yo solo, por mi cuenta y a cabezazos... jajajajajajajaja

Básicamente. Es cierto que para aprender a utilizar electron, angular, bower, npm, yarn, grunt... te darás cabezazos, pero tienes muchísima información y ejemplos en internet, libros sobre ello, videotutoriales... Algo bueno tiene que tener tanto hype.

Sin embargo, aunque consigas dominar todas esas herramientas, seguiras sin saber cómo está estructurada la aplicación, qué funciones hay, cuáles son los puntos de entrada, cuáles las auxiliares, por qué hay algunas directivas y no otras, qué funcionalidades deben ir en icestudio y cuáles en apio... Facilitar toda o parte de esta información depende del arquitecto de la aplicación. Ojo, que no estoy exigiendo nada. De hecho, es posible que haya herramientas para obtener información automáticamente. Simplemente creo que es la clave entre un proyecto que busca proactivamente la colaboración y uno que no.

Pues sí, pero para que no se diga que por lo menos uno no lo ha intentado y ha puesto su esfuerzo... :))

Y quién sabe, igual algún día... :))

Vale, ya no tengo que esperar a tu siguiente post... ya me has contestado... jejejejejeje
Por lo que leo... No es trivial convertir icestudio en un cliente-servidor porque está todo mezclado... frontend y backend. ¿Qué solución existe? ¿Tan complicado sería tomar el código JavaScript y reordenarlo para poner los paquetes de npm en el backend (y solo en el servidor) y los de bower en el frontend? ¿Qué paquetes son los que hacen tan difícil esta separación si en principio están separados conceptualmente desde el inicio?

Sinceramente, es un brindis al sol. No he analizado icestudio con suficiente detalle como para evaluar cómo de fácil o difícil es la conversión. Mi afirmación viene motivada por las respuestas que ha dado Jesús cuando se le ha preguntado por ello: de memoria, algo así como "icestudio está hecho con tecnologías web, por lo que podría convertirse" e "icestudio es un proyecto abierto y cualquier colaboración es bienvenida". Yo lo interpreto como "no lo pensé cuando empecé a escribir icestudio y no voy a ponerme a pensar en ello ahora".

Me suena... :))

¿Sería complicado reordenar el código para tener las tareas/funciones relativas al frontend por un lado y las del backend por otro? En principio, no.

¿Qué paquetes son los que lo hacen difícil? Ninguno.

¿Cuál es el problema entonces? El acceso a disco y, por consiguiente, a los ejecutables disponibles nativamente. En otras palabras, si a icestudio le quitas "el enlace" a apio, yosys, icestorm, etc. ya puedes utilizar icestudio como una app cliente sólo (angular), y servirla desde cualquier servidor web. Esto responde a cómo puedes probar icestudio sin electron. Desde mi punto de vista seguiría siendo útil, porque utilizaría icestudio para cargar un fichero ICE, editarlo y guardar el resultado (exportado a verilog). Después, en local, ejecutaría las herramientas adecuadas con el resultado descargado. Sin embargo, entiendo que tener opciones en el menú para sintetizar y programar las placas directamente es una de las características principales de icestudio, teniendo en cuenta el público objetivo.

Pongamos un ejemplo sencillo. Tenemos un formulario web con un botón y dos campos de texto: uno contiene "Hello world" y el otro contiene la ruta absoluta o relativa a un fichero (pongamos que es /home/user/hello_world.txt). Queremos que al pulsar el botón el fichero se guarde en el disco. Nótese que, aunque sea sintácticamente diferente, es irrelevante hacerlo con JS vanilla, angular o cualquier otro framework frontend. Tres formas de guardar el fichero:

- Sin backend. Cuando le doy al botón, el navegador descarga el fichero. Depende de cómo esté configurado el navegador, irá directamente a Descargas o me preguntará dónde quiero guardarlo. En cualquier caso el segundo campo de texto (la path) no sirve para nada, porque el usuario lo decide al "guardar como". No es posible que una aplicación cliente guarde ficheros sin intervención del usuario. Bueno, estrictamente se puede guardar información en las cookies y en la caché del navegador, pero no en una path arbitraria del disco del usuario. Es fácil entender que esto es una limitación inherente a todos los navegadores web para evitar que cualquier página web pueda instalar malware sin más.

- Con "backend" nodejs/electron. Cuando le doy al botón, el pseudo-navegador (JS engine) utiliza una función equivalente a printf para guardar el fichero directamente en la path indicada. Como el backend se ejecuta en la misma máquina que el frontend, esa path corresponde al disco del usuario.

- Con un "backend" real. Cuando le doy al botón, la aplicación cliente (el frontend) crea una estructura con al menos dos campos (el texto y la path) y hace una llamada POST mediante AJAX (jQuery) a una URL (e.g. localhost/guardarfichero o miapp.com/guardarfichero). El backend está "escuchando" en esa URL, y cuando recibe el POST, extrae el texto y utiliza printf (o equivalente) para guardarlo. Como el backend no tiene por qué estar ejecutándose en la misma máquina que el frontend, el fichero no se guarda en el disco del usuario, sino en el servidor. Evidentemente, si lanzas el backend en tu misma máquina, el resultado es equivalente al caso anterior.

 

Las opciones 1 y 3 se pueden combinar. A veces queremos que el usuario se descargue un fichero a su equipo. Otras veces queremos que se guarde en el servidor. ¿Cuándo queremos que se guarde en el servidor? Cuando el paso inmediatamente posterior es hacer otra llamada POST o GET que ejecute por ejemplo yosys (teniendo yosys instalado en el servidor, y no en el cliente). ¿Cuándo queremos que se lo descargue el usuario? Cuando el fichero es un producto/resultado, por ejemplo, el resultado de la ejecución de yosys.

Esto tiene un poco más de miga, porque por un lado las llamadas AJAX son, en principio, asíncronas. Esto quiere decir que el fichero no se guarda exactamente cuando hago la llamada AJAX (POST) desde el cliente. Cuándo se ejecute la instrucción realmente depende de cuánto tarde el backend en responder. No es que el tiempo sea apreciable por el usuario, sino que a nivel de ejecución secuencial del código tu cliente va a seguir ejecutando pasos posteriores antes de que se haya terminado de escribir el fichero. Si el paso posterior necesita el fichero, fallará. Por lo tanto, es necesario pensar la lógica del cliente para que espere, si tiene que esperar, o que hagas otras cosas mientras tanto.

Por otro lado, POST y GET no son las únicas formas de pasar información. También se puede hacer a través de la URL, por ejemplo, localhost/guardarfichero?text='hello world'&path='/home/user/hello_world.txt'. Nota, no estoy seguro del uso de las comillas aqui, pero creo que se entiende la idea.

En cualquier caso, la idea básica es que hay que añadir un paso/función para transmitir la información del frontend al backend, considerando que cada parte puede estar escrita en un lenguaje totalmente diferente.

Como siempre un ejemplo perfecto y clarificador de como funcionan el frontend y el backend. Gracias.

Me seduce la idea de tener centralizado en un equipo el sintetizado con yosys y demás... se me está ocurriendo una posibilidad futura de levantar un servidor para el grupo FPGAwars... con todos los proyectos y las herramientas centralizadas... :)))

Incluso creo recordar que tú propusiste también en algún post centralizar las herramientas en un aula... lo buscaré... Abriría muchas posibilidades de colaboración. :)))

Sé que es un poco recurrente todo esto y te pido disculpas... pero debe haber alguna forma de "reciclar" el código...¿No? :(((

¿O cúal es tu consejo? ¿Que directamente ni lo intente? ¿No tiene solución icestudio? ¿No podré sentirme nunca verdaderamente libre con icestudio por mucho que me esfuerce en intentar comprenderlo y asimilarlo, aunque sea desde el propio código, para finalmente poder y tener la capacidad de modificarlo?  :(((  

Me lo pones muy mal si es así... :_(((

No me seas agorero, hombre. Icestudio tiene solución, puedes reciclar todo lo que quieras, y podrás sentirte libre con esfuerzo. Lo que tienes que tener claro son las limitaciones inherentes a las decisiones tecnológicas que ya se han tomado y el esfuerzo necesario para entender la arquitectura indocumentada. Por ejemplo, para convertirla en cliente-servidor, tendrías que:

- Revisar todo el código para identificar todos los puntos en los que se accede a disco (manipulación de ficheros o llamadas a herramientas).

- Cambiar todas las llamadas directas (e.g. printf) por dos funciones intermedias. Inicialmente, pueden ser funciones dummy, es decir, reemplazar printf por mi_printf, que mi_printf sólo contenga una llamada a mi_backend_printf y que ésta sólo llame a printf.

- Mover la definición de todas esas funciones intermedias a un mismo directorio, o a un grupo de directorios, para tenerlas localizadas.

A partir de ahí, reemplazar el contenido de mi_printf por una llamada AJAX, e implementar mi_backend_printf como la rutina de respuesta a la llamada. Este paso en concreto no sé si puedes hacerlo con nodejs/electron o si necesitas un backend de verdad. Si fuera así, debería haber dos versiones de las funciones, una para utilizar cuando se compile en eletron y otra para un supuesto backend de verdad. Grunt se podría utilizar para decidir cuándo usar unas y cuándo otras.

 

Por lo tanto, mi consejo es que ni intentes esto ahora. Vas a tener que hacer suficientes modificaciones como para agarrarte un buen cabreo si luego no se incluye en el repositorio oficial, y será pesado de mantener forkeado. Si estás trabajando solo, ponte metas más asequibles. Lo ideal sería que tuvieras una lista de cosas que te gustaría cambiar, y que Jesús, que conoce el código, pudiera recomendarte por cuál(es) empezar y qué ficheros empezar a mirar.

jajajajajaja... Haces bien en frenarme... yo ya me estaba lanzando... jajajajajaja

Si aun así quieres intentarlo, yo también estoy muy interesado en una solución cliente-servidor. Creo que en algún hilo (no sé si de Lorea) ya comenté que sería muy interesante tener icestudio, apio y el resto de herramientas instaladas en un solo ordenador de un aula/centro educativo y que el alumnado pueda utilizarlo desde tablets o desde sus propios móviles. Lo que sucede es que no tengo la motivación para empollarme la app entera. Sin embargo, si hubiera un listado de funciones/tareas que deba soportar un backend para funcionar con icestudio (lo que se denomina comunmente API, ver swagger.io), me gustaría intentar implementar un backend alternativo para que nodejs/electron sea una opción, pero no la única.

¿Ves? a mi me sonaba que tú habías comentado esto del aula... :)))

Sí, estoy interesado... quiero intentarlo... :)))
Estas últimas semanas le estoy robando un ratito al sueño para, por lo menos, intentarlo... :)))

Y si estudiando el código y haciendo el esfuerzo, no solo se consigue la capacidad de modificarlo sabiendo lo que se hace sino, además, de poder disponer de una solución cliente-servidor para icestudio el esfuerzo merecerá la pena....así queeee...  ¡p'a lante! jejejejejejeje :))

Sólo por exponer la imagen completa, mi objetivo final es poder quitar apio de la ecuación también, y quedarme "solo" con el frontend de icestudio. Así, la alternativa a nodejs/electron sería una única imagen docker que ya incluya todas las herramientas precompiladas. Esa imagen sería única por arquitectura (x86_64, arm...) pero independiente del sistema operativo.

Bueno... esto ya sería la "repanocha".... ¡A por ello! (fréname, fréname que me lanzo....jajajajajaja)

Muchas gracias como siempre por tus posts. Se aprende mucho. ;)

A ver si saco tiempo un día de estos para implementar inbit sin nodejs/electron. Tengo un par de demos muy similares, pero están adaptadas para ciertos contenidos que no son públicos, por lo que tengo que "limpiarlas". Estoy convencido de que puede resultarte muy didáctico para "ver" los detalles expuestos en estos mensajes.

Perfecto, muchas gracias, te lo agradezco.

Mientras tanto yo seguiré estos días investigando el código (sin profundizar demasiado para no ofuscarme) e intentaré hacer el recorrido que me has propuesto con el frontend y el backend, haciendo esos ejemplos sencillos para amueblar la cabeza... a ver cuanto tardo en llegar al final de este recorrido. :)))

Muchas gracias como siempre por tu guía.

 

Saludos

Saludos.

Juan Manuel Rico

[1138-4EB]

Investigando en el enlace veo que Electron y NW.js hacen lo mismo, llevar al escritorio la tecnología web. Pues bien, he buscado las dependencias en icestudio y no he encontrado ninguna dependencia con Electron, pero sí con NW.js, lo que me ha hecho recordar algún post antiguo en el que se hablaba del tema y estoy por afirmar (casi con rotundidad... o no... que sé yo... :) ) que icestudio no usa Electron, sino NW.js.

Efectivamente, así es. Aunque Jesús ha comentado alguna que otra vez que le gustaría probar a cambiar a Electron, parece ser que no se ha hecho: https://github.com/FPGAwars/icestudio/wiki/Wishlist:-proposed-features#wishlist

 

jejejejejeje, ya estoy recuperando mi servidor olvidado de Apache en Debian... a mi seguramente me lleve más de dos tardes... posiblemente dos meses... jejejeje, pero haré el recorrido ese... al final me va a gustar y todo .... :))

En realidad, con 50 líneas de golang tienes lo mismo que con Apache. Mencioné Apache porque supuse que es lo que más familiar te resulta, y que podrías tenerlo ya configurado. Pero, en serio, si tienes que instalarlo no merece la pena complicarte. Ver demo debajo.

 

Parece que tienes razón, en las dependencias se marca la 1.6:    "angular": "^1.6.0"

Ten en cuenta el prefijo "^". En realidad se pueden estar utilizando 1.6.5 o 1.6.7.

Me seduce la idea de tener centralizado en un equipo el sintetizado con yosys y demás... se me está ocurriendo una posibilidad futura de levantar un servidor para el grupo FPGAwars... con todos los proyectos y las herramientas centralizadas... :)))

Esto lo puedes hacer ya. Sólo tienes que ignorar icestudio. Es decir, puedes escribir un backend con una API que reciba un tarball con las fuentes (verilog), ejecute yosys y devuelva el resultado en otro tarball. Más adelante, si se quiere, icestudio podría adaptarse para usar esa infraestructura en lugar de la instalación local.

Incluso creo recordar que tú propusiste también en algún post centralizar las herramientas en un aula... lo buscaré... Abriría muchas posibilidades de colaboración. :)))

Así es. Pero mi propuesta estaba centrada en que no sea necesario un PC para cada usuario. No es tanto para abrir posibilidades de colaboración, sino para posibilitar el uso de las herramientas en centros educativos donde no tienen un equipo por alumno, pero si un smartphone o tablet. Por descontado, que puedan jugar/aprender desde casa, no sólo en clase.

En cuanto a la colaboración, hice otra propuesta, relacionada con el formato ICE, para identificar IP-cores de forma única. La idea es añadir un nombre de librería, un nombre de diseño y un número de versión, de forma que no sea conflictivo que el mismo diseño con pequeñas variaciones esté alojado en diferentes repos.

Bueno... esto ya sería la "repanocha".... ¡A por ello! (fréname, fréname que me lanzo....jajajajajaja)

La imagen docker con yosys + arachne-pnr + icestorm + iverilog + gtkwave + graphviz ya está lista https://github.com/1138-4EB/elide/tree/master/docker. Falta la API que he comentado (y que icestudio use la API, claro).

Perfecto, muchas gracias, te lo agradezco.

https://github.com/1138-4EB/InBit/tree/golang-backend

Sólo necesitas tener golang instalado para compilar el backend. La compilación cruzada en golang es "gratis" por lo que da igual cuál sea tu plataforma o SO objetivo: x86, x86_64, arm, armhf, gnu/linux, windows, darwin...

git clone -v golang-backend https://github.com/1138-4EB/InBit
cd InBit
go get ./...
go build

 

Fíjate que en el caso de go la gestión de dependencias está integrada en el lenguaje. 'go get ./..' se descarga las últimas versiones de github.

Una vez compilado, simplemente ejecuta ./InBit, abre el navegador y vete a 'localhost'. Abre la consola del navegador y pulsa el botón/interruptor:

- Cuando pulsas, se muestra un mensaje en la consola.

- Cuando el mensaje llega al backend, se muestra un mensaje en la terminal.

- Cuando se ejecuta setDTR en el backend, se muestra un segundo mensaje en la terminal.

- Cuando el backend responde, se muestra un segundo mensaje en la consola.

Notas:

- He mantenido exactamente el mismo style.css y switches.svg que Obijuan, por lo que estéticamente la app es idéntica.

- He eliminado main.js y renderer.js. Las 10 líneas de JS que hacen falta las he metido en index.html.

  - He reemplazado las 'alert' por 'console.log', simplemente porque me resulta molesto andar cerrando las ventanas emergentes.

- No he comprobado la comunicación serie con la placa. Puedes ver que el código está escrito al final de main.go, pero comentado. Estoy en un congreso en el extranjero esta semana y no tengo ninguna placa con la que probarlo.

- El ejecutable acepta tres parámetros:

  - '-v' es verbose, y el resultado es que el backend mostrará en la terminal las peticiones HTTP. Si arrancas el backend antes de abrir el navegador, verás que inicialmente hay tres peticiones GET correspondientes a index.html, style.css y switches.svg. A partir de ahí, cada vez que pulses el botón en el frontend, se mostrará una nueva petición POST.

  - '-p' es port. Por defecto es el puerto 80, pero si lo tienes ocupado, puedes cambiarlo por cualquier otro. Naturalmente, si lo cambias deberás navegar 'localhost:<port>' en lugar de 'localhost'.

  - '-d' es dir, dónde se encuentran las fuentes del frontend. Por defecto es './public', por lo que debes ejecutar InBit desde la raíz del repo. Si lo ejecutas desde fuera, tienes que especificar -d en coherencia.

Sin duda, este ejemplo puede mejorarse significativamente:

- Comentarios.

- Más parámetros (como el nombre del puerto serie a usar).

- Otras formas de hacer la petición. He utilizado POST, pero podría utilizarse GET y pasar la variable en la URL.

- He utilizado JS vanilla. Pero en una aplicación real, seguramente utilizaría jQuery para hacer la petición GET/POST.

- ...

Sin embargo, creo que puede ser suficiente para que "veas" las explicaciones que he expuesto en mensajes anteriores.

Como nota final, el backend tiene dos procesos escuchando en paralelo (uno para las peticiones AJAX y otro para servir los ficheros): https://github.com/1138-4EB/InBit/blob/golang-backend/main.go#L77-L78 Esto quiere decir que, si eliminas la línea 77 y todo lo que hay de la línea 82 hasta el final, te queda un servidor web "equivalente" a Apache (pero compilable para "cualquier" plataforma y SO -yo estoy en Win10 ahora-). En otras palabras, puedes usar este mismo binario y poner en public cualquier frontend o página web que quieras (léase AngularJS). ¿Todavía quieres desempolvar tu instalación de Apache?

Segunda nota final. gorilla/mux se utiliza para rutar por separado las peticiones '/ y '/ajax/'. Si eliminas la parte ajax, puedes prescindir de ello.

Tercera nota final. https://github.com/1138-4EB/InBit/blob/golang-backend/main.go#L35-L48 es para que al navegar 'localhost/public' el navegador no liste los ficheros que hay en ese directorio. Es el equivalente a añadir un index.html vacío (lo que hace Apache). Por lo tanto, también lo puedes quitar.

Última nota final. Si aplicas las tres notas anteriores, main.go se queda en unas 50 líneas. Pero me ha parecido más últil mantenerlo "todo", para ahorrarte tiempo si quieres hacer algo más que sólo probar el ejemplo básico.

Mientras tanto yo seguiré estos días investigando el código (sin profundizar demasiado para no ofuscarme) e intentaré hacer el recorrido que me has propuesto con el frontend y el backend, haciendo esos ejemplos sencillos para amueblar la cabeza... a ver cuanto tardo en llegar al final de este recorrido. :)))

¡Ánimo y suerte!

Saludos

[Juanma Rico]

¡Epaaaaaa! ¡Gracias Unai! :))

Veo que voy a tener que aprender otro idioma (no tengo ni idea de Golang)... jejejejejeje
Voy a intentar esta noche echar a andar tu modificación de InBit y me apunto para cuando vaya al laboratorio la prueba de la imagen de Docker (necesito mi Debian de 64bits... :))) )
No me entretengo más y me pongo a ello... :)))

Ya te cuento. Muchas gracias de nuevo. ;))))
Saludos
Juan Manuel Rico

[Juanma Rico]

¡¡Como mola!! :)))

Ya lo tengo funcionando... :))
Primero lo hice en local directamente desde el propio equipo con Debian (el backend) y luego lo he probado desde un cliente en un equipo con Windows7 dentro de mi red local (solo el frontend)... y efectivamente todo funciona como debe funcionar. :))

No dispongo de tiempo para hacer un vídeo... pero este es el navegador en Windows7, al pulsar el interruptor los mensajes aparecen en la consola del equipo con Debian. :)))  La investigación en profundidad ya la tendré que dejar para otro día.

Algunas reflexiones antes de haber profundizado... (igual cuando lo haga me doy cuenta que son reflexiones tontas...)

• He tenido que establecer la variable de entorno GOPATH al directorio de InBit. Si no se establece, por omisión busca los ficheros en /home/go (sería interesante quizás se añadiera al README.md si siempre es necesario), no entiendo bien el comando "go get ./..." (¿Son tres puntos finales o dos?) , sé que se usa para las dependencias e imagino que los puntos y la barra nada tienen que ver con "subdirectorio anterior o actual"... pero bueno... ya lo averiguaremos.... :)))

Eso sí, a pesar de establecer el GOPATH y aunque todo ha funcionado, me sigue lanzando el siguiente mensaje al hacer el get:

go install: no install location for directory /home/juanma/Proyectos/FPGAwars/InBit outside GOPATH

For more details see: 'go help gopath'

Pero bueno... imagino que es cuestión de leerse la ayuda con calma... :))

Mañana seguimos.
Saludos
Juan Manuel Rico

[1138-4EB]

Veo que voy a tener que aprender otro idioma (no tengo ni idea de Golang)... jejejejejeje

Sabes C, por lo tanto, ya sabes Golang. Pásate por https://tour.golang.org/welcome/1 y sorpréndete de lo mucho que sabes de Golang, sin saberlo ;)

Básicamente es un versión "moderna" de C. Compilado y con tipado estático y estructural. Lo que aporta a C es recolector de basura, programación concurrente "gratis" y compilación multiplataforma "gratis". Además, tiene un planteamiento muy estricto en lo que respecta a cómo se deben distribuir las librerías y cómo hay que organizar el espacio de trabajo. Te tienes que acostumbrar, pero luego todo funciona igual.

Viniendo del hardware, a mí lo que me maravilla es la facilidad para programar de forma concurrente (ejecutar tareas en "paralelo" y comunicarlas entre ellas). Si en vez de ejecutar una función como "mifuncion(arg1,arg2)" ejecutas "go mifuncion(arg1,arg2)", se lanza en paralelo. Y santas pascuas.

Nunca he tenido tiempo suficiente y motivación para meterme con C++ o Java. Sin embargo, golang me enganchó en cuanto hice el tour. Es el lenguaje de sistema que utilizo desde entonces: para aplicaciones CLI, backends web, parser y manipulador de JSON/YAML/XML, generación de SVG, interfaces gráficas con QML (Qt)...

La combinación de cobra y viper es sencillamente awesome (https://awesome-go.com/):

- https://github.com/spf13/cobra
- https://github.com/spf13/viper

Pero, dejando a un lado lo interesantísimo que puede ser utilizar golang, si lo prefieres puedes hacer exactamente lo mismo con otros lenguajes de programación. No soy muy fan de Python, pero parece que con Flask y jQuery es bastante sencillo también: http://flask.pocoo.org/docs/0.12/patterns/jquery/ O con Perl: http://archive.oreilly.com/oreillyschool/courses/javascript2/javascript207.html

me apunto para cuando vaya al laboratorio la prueba de la imagen de Docker (necesito mi Debian de 64bits... :))) )

¿No te he hablado de https://labs.play-with-docker.com/? Puedes crear todos los workspace que quieras. En cada uno puedes crear todos los nodos que quieras. Los workspace duran 4 horas y tienen 4 GB. Es gratis y sólo necesitas una cuenta de dockerhub para utilizarlo. Por ejemplo:

docker run --rm -it 11384eb/elide:alpine-run sh -l
apk update
apk add git
git clone https://github.com/juanmard/screen-logo
cd screen-logo
yosys -o output.blif -S *.v

Eso sí, no escribas ninguna contraseña. Si quieres guardar cambios que hayas hecho, lanza un contenedor hacdias/filemanager antes de elide y bájate un tarball:

docker run --rm -dv $(pwd):/srv -p 80:80 hacdias/filemanager --no-auth -s /srv -p 80
docker run --rm -itv $(pwd):/work 11384eb/elide:alpine-run sh -l
...

BTW, hacdias/filemanager es una aplicación cliente-servidor con el frontend escrito en Vue.js y el backend en golang: https://github.com/hacdias/filemanager

Para usar gtkwave, sí que tienes que ejecutarlo en local, por el momento. Bájate https://github.com/1138-4EB/elide/blob/develop/docker_guiapp.sh y ejecuta:

./docker_guiapp.sh --rm -it 11384eb/elide:alpine-run sh -l

gtkwave se lanzará dentro del contenedor, pero utilizará las X del host, por lo que se mostrará la ventana como cualquier otra que tengas en el escritorio.

NOTAS:

- 11384eb/elide:alpine-run son 159MB de descarga y hacdias/filemanager son 7MB.
- No he probado a compartir el puerto serie con el contenedor de elide para programar la FPGA.
- hacdias/filemanager permite editar ficheros de texto. Lo cual quiere decir que puedes tener filemanager abierto en una pestaña y la terminal de play-with-docker en otra pestaña (o en dos ventanas del navegador). En una editas el código y en la otra simulas/sintetizas. En la práctica, es un mini-IDE que puedes usar donde quieras. Sólo necesitas tener en local las herramientas para programar el bitstream.

¿Entiendes ahora que mi interés en icestudio es ver si se puede reciclar toda la parte de edición de los diagramas para añadirla como un plugin a filemanager? De ahí, el "empeño" principal en golang o en tener una API medianamente documentada para implementarla. Lo de quitar apio es sólo porque ahora mismo no veo valor añadido para los usuarios que utilicen docker (sí para todos los demás). Si ves alguna carencia en la imagen, indícamelo y se puede añadir (python ya está instalado para yosys, graphviz y xdot).

Ya lo tengo funcionando... :))

¡No pierdes el tiempo!

No dispongo de tiempo para hacer un vídeo... pero este es el navegador en Windows7, al pulsar el interruptor los mensajes aparecen en la consola del equipo con Debian.

Me alegra saber que funciona de un equipo Windows a uno GNU/Linux :D. Yo lo había probado localmente en Windows y por red entre equipos GNU/Linux. En realidad no hay ningún motivo por el que no debería haber funcionado, pero nunca se sabe XD.

He tenido que establecer la variable de entorno GOPATH al directorio de InBit. Si no se establece, por omisión busca los ficheros en /home/go (sería interesante quizás se añadiera al README.md si siempre es necesario), no entiendo bien el comando "go get ./..." (¿Son tres puntos finales o dos?) , sé que se usa para las dependencias e imagino que los puntos y la barra nada tienen que ver con "subdirectorio anterior o actual"... pero bueno... ya lo averiguaremos.... :)))

Son tres puntos finales. He sido un poco mal profe con esto. Me dio pereza explicarlo porque, bien o mal, a través de los errores sabía que ibas a poder probarlo. Golang tiene una estructura de directorios estricta:

- GOPATH
  - bin
  - src
    - github.com
      - 1138-4EB
        - InBit
      - ogier
        - pflag
      - gorilla
        - mux

Por lo tanto, la forma "limpia" de hacerlo sería:

export GOPATH=$(pwd)
go get github.com/gorilla/mux
go get github.com/ogier/pflag
go install github.com/1138-4EB/InBit

Y el binario de InBit estaría disponible en $GOPATH/bin. Lo que pasa es que no he cambiado la configuración de mi fork en github. Por lo tanto, al hacer go install se descargaría la rama master, que es la de Obijuan.

Al ejecutar go get ./... has descargado primero todas las dependencias externas definidas en "imports", al principio de main.go. Después, se ha intentado ejecutar go install, pero como no estás en el directorio correcto con respecto a $GOPATH, dice que no sabe dónde colocar el binario. Por eso, después de go get, hay que ejecutar go build. build es lo mismo que install, pero deja el binario en la carpeta donde están las fuentes, en lugar de moverlo a $GOPATH/bin.

Por otro lado, yo siempre utilizo la imagen oficial "golang" de docker (me da pereza hasta instalar golang en el equipo). Esta tiene GOPATH definido por defecto, por lo que, aun con el error que comentas de "go install", funciona:

docker run --rm -itp 80:80 golang sh
git clone -b golang-backend https://github.com/1138-4EB/InBit

cd InBit
go get ./...

go run main.go -v

Fíjate que aquí he utilizado "go run" en vez de "go build" y ejecutar después el binario. Es exactamente lo mismo.

Pero bueno... imagino que es cuestión de leerse la ayuda con calma... :))

Efectivamente. Aunque, esto es lo que me molesta de golang. Es muy incómodo no poder hacer git clone e inmediatamente después go run. Utilizo el script builder.sh adjunto para que no de problemas porque el directorio en el que estás trabajando no esté dentro de $GOPATH/src/... Ejecutarlo con la variable de entorno DEPSONLY=true es equivalente a go get ./..., pero sin errores. Ten en cuenta que lo uso dentro de la imagen golang de docker. Nunca lo he probado en local.

Por último, aunque no lo he añadido todavía, se puede convertir el contenido de la carpeta public en texto binario e incluirlo dentro de main.go. De esta forma, tanto el frontend como el backend se distribuyen en un solo fichero: descargar y ejecutar.

- https://stackoverflow.com/questions/13904441/whats-the-best-way-to-bundle-static-resources-in-a-go-program
- https://github.com/jteeuwen/go-bindata
- https://github.com/jimmysawczuk/go-binary
- https://github.com/rakyll/statik

Evidentemente el backend ocupará más en RAM.

Saludos

[1138-4EB]

Parece que al enviar el mensaje anterior los GIFs se han convertido en imágenes estáticas. Los adjunto.

[1138-4EB]

En tar tendrá que ser.

[Juanma Rico]

Gracias Unai por todos tus comentarios y propuestas... :))

Hoy me ha dado tiempo a poco... ya en el primer enlace que me has propuesto me he enganchado... jajajajaja
El tour hoy no me ha dado tiempo a acabarlo, pero Golang parece muy interesante... :)))
Tanto como para seguir enganchado, terminar de hacer el tour mañana e intentar llegar al final de tu post si no me "engancho" en otro enlace interesante...jejejejeje
Mañana con más tiempo haré lo posible para llegar a las propuestas de Docker... A ver si lo consigo... ;))

Un saludo
Juan Manuel Rico

[Juanma Rico]

Buenas Unai,

he echado otro rato... para que veas que tus post me dan para varios días aunque no te lo creas... ;)))
Hitos de hoy:

• Terminado el tour de bienvenida de Golang. En los ejercicios no me he parado demasiado, pero creo que me llevo una idea general como para poder serguir (e incluso modificar) un código existente. ;))
  
  
• Descubiertas algunas aplicaciones realmente sorprendentes en awesome-go.com. En proceso de probar alguna... :))
  
  
• Creada la cuenta de Docker y realizadas pruebas en play-with-docker.
  Al copiar los comandos que escribiste en una instancia todo funciona bien menos las bibliotecas de Yosys. Me da el siguiente error:
  
  8.1. Executing HIERARCHY pass (managing design hierarchy).
  ERROR: Module `\SB_PLL40_CORE' referenced in module `\vga_controller' in cell `\uut' is notpart of the design.
  
  Para solucionarlo he tenido que buscar el fichero donde está la definición del módulo PLL y copiarlo al de trabajo, es decir:
  
  $ cp /usr/local/share/yosys/ice40/cells_sim.v /work/screen-logo
  
  Luego parece que es cosa de la configuración de las bibliotecas de Yosys en la imagen de Docker.
  
  
• También me ha dado tiempo a probar el contenedor de hacdias/filemanager.... muy chulo... :)))
  Lo que ya no me ha dado tiempo es probar el gtkwave, para la próxima que disponga de Docker en local.
  
  
• Y finalmente me ha dado tiempo a probar el contenedor de go...
  

No me ha dado tiempo a más...

Mañana seguiremos.

Saludos

Juan Manuel Rico