[Nuevo IDE] mxgraph + golang + Jekyll/Hugo

[una...@gmail.com]

Hola,

Para poner en práctica algunas de las ideas planteadas en este hilo, he creado un playground en https://github.com/1138-4EB/elide . Es una solución web compuesta por tres 'sites', que se desarrollan de forma independiente:

• 'landing': página hecha a mano en HTML y CSS, basada en bootstrap y font-awesome, sólo para redirigir a las otras dos secciones. De hecho, podría ser una redirección a grapheditor.
  
• 'grapheditor': aplicación principal, basada en mxgraph (JavaScript), que a su vez utiliza XML y CSS.
  
• 'doc': sitio web estático generado con Jekyll/Hugo/Sphinx a partir de ficheros Markdown/RST. Los templates se adaptan en HTML + CSS + , respectivamente, Ruby, Golang o Python.

Para permitir la ejecución en local, he escrito un microservidor estático en golang. Por el momento lo único que hace es servir la aplicación, pero el objetivo es que haga las veces de backend. Para probarlo, sólo es necesario que tengáis Golang instalado. Alternativamente, podéis usar cualquiera de las imágenes de Docker.

mkdir work
cd work
git clone --depth=1 https://github.com/1138-4EB/elide
cd elide/backend
export GOPATH=$(pwd)
go get -d ./...
go build
./backend -p 80 -d ../frontend

• Lo anterior descargará el repositorio, compilará el servidor para vuestra arquitectura y lo ejecutará para servir la aplicación. Podréis utilizarla accediendo con vuestro navegador a 'localhost'. Si por cualquier razón tenéis algún servicio corriendo ya en el puerto 80, podeís usar cualquier otro.
• Si no os fáis de ejecutar código porque sí, lo que me parece muy razonable, el código fuente son 60 líneas muy explícitas: https://github.com/1138-4EB/elide/blob/master/backend/main.go
  
• En la página principal hay un enlace a grapheditor. También podéis acceder directamente a localhost/grapheditor.
  
• Si intentáis acceder a localhost/doc, os dirá que no hay nada. Esto es porque la demo es sólo para que veáis el editor. Podéis copiar cualquier web estática a elide/frontend/doc y la mostrará.
• Si queréis llenarlo rápidamente, en elide/hugo están las fuentes de una web de prueba. Tenéis que descargar el binario de Hugo y generar la web estática:

cd elide/hugo/themes
curl -L http://github.com/1138-4EB/beautifulhugo/archive/master.tar.gz | tar xz
mv beautifulhugo-master beautifulhugo
cd ../..
mkdir tmpHugo
cd tmpHugo
wget https://github.com/spf13/hugo/releases/download/v0.19/hugo_0.19_Windows-64bit.zip
unzip hugo_0.19_Windows-64bit.zip
cd ../hugo
../tmpHugo/hugo_0.19_windows_amd64.exe -t beautifulhugo -D -d ../frontend/doc/


Características más relevantes de esta propuesta:

• El backend ocupa menos de 6MB. mxgraph ocupa menos de 1MB. Todo grapheditor ocupa 8MB. Casi 3MB de 'frontend' es la imagen de fondo de la protada. Aún así, todo no llega a los 15MB.
• La compilación cruzada en golang es prácticamente gratis. Concretamente, 10 plataformas en 3 minutos y 12 segundos (https://travis-ci.org/1138-4EB/go/builds/208085914). Está soportado ARM: https://github.com/golang/go/wiki/GoArm
  
• Todo el contenido puede empotrarse en un sólo binario estático. No lo he hecho, porque la idea es que podáis hacer pruebas/cambios y verlos al momento. Pero para distribuirlo, se empaqueta todo en zip y se añade como variable dentro del backend: http://mattjibson.com/blog/2014/11/19/esc-embedding-static-assets/ . Embeber el contenido no impide que durante la ejecución se siga mirando el directorio local y sirviendo cualquier contenido adicional.
  

En lo que respecta a la aplicación en sí, no es más que el ejemplo más completo de la página: https://jgraph.github.io/mxgraph/javascript/examples/grapheditor/www/index.html Puede que os parezca muy limitado o excesivamente diferente a Icestudio. Pero pensad que mxgraph es una librería pensada específicamente para construir aplicaciones interactivas basadas en diagramas. Aquí tenéis casi una centena de ejemplos, cada uno explicando como utilizar una característica concreta: https://jgraph.github.io/mxgraph/javascript/index.html Por ejemplo:

• wires es para hacer circuitos electrónicos. Tiene bloques con puertos, resistencias, condensadores... Cómo implementar los puertos se muestra en el ejemplo ports.
  
• layers muestra el soporte para capas.
• En monitor se ve cómo se pueden incluir animaciones a partir de recursos externos (léase resultados de una simulación).
• JSONdata muestra como interactuar con información en formato JSON.
• En clipboard se ve cómo copiar información de una pestaña a otra.
  
• En mxDraw los contenedores son 'grupos' con nombre y otras características, por lo que sirven para implementar la estructura entitdad-arquitectura.
• dynamicloading Carga dinámica y animaciones.
• hierarchical layout, orgchart y orthogonal muestran los diferentes algoritmos para posicionar elementos en pantalla automáticamente.
• Cómo cambiar el estilo de los menús con CSS en menustyle.
• ...

La raíz de la documentación está en https://jgraph.github.io/mxgraph/ . El manual de lo que es el cliente JavaScript, en https://jgraph.github.io/mxgraph/docs/manual.html , incluye un 'Hello world' completo, y cómo ir adaptándolo para añadir funcionalidades.

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

Otras referencias interesantes de la propuesta:

• La concurrencia en Go es parte del lenguaje, no un parche posterior. La diferencia entre llamar a una función o lanzarla en paralelo es tan simple como añadir la palabra 'go' delante. Además, la comunicación entre procesos paralelos se hace a través de variables, llamadas 'channels'. Estos channels no son más que FIFOs, donde una o más funciones escriben y otra(s) leen. Ejemplo completo en 20 líneas: https://tour.golang.org/concurrency/2
  
• Otto permite interpretar código JS en go. A la inversa, GopherJS permite escribir código en go y ejecutarlo en JS. Por lo que el desarrollo no se limita sólo a quienes sepan JS.
• La posibilidad de ejecutar cógido en go dentro del JS permite reemplazar los JSON en la comunicación cliente-servidor por ficheros glob: http://stackoverflow.com/questions/29282231/go-json-decoding-is-very-slow-what-would-be-a-better-way-to-do-it
• Este proyecto tiene el frontend en Angular2 y dos backends, uno en NodeJS y otro en go: https://github.com/tuxin-skeleton
• Este otro proyecto en JS, convierte Verilog a JSON y después lo dibuja: https://github.com/JohnDRO/Golirev-IDE . Lo más interesante es que utiliza yosysJS, por lo que ni siquiera requiere desarrollar la sincronización entre frontend y backend.
  

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

Para hacerlo más user-friendly, se puede añadir una línea a /etc/hosts de forma que se acceda mediante 'elide.app', o cualquier otro dominio inventado, en lugar de 'localhost'. Además, me gustaría poder utilizar 'editor.elide.app' y 'doc.elide.app'. Sin embargo, esto es un poco más complicado, porque http://stackoverflow.com/questions/42730590/local-subdomains-for-a-standalone-application/42797862#42797862 En cualquier caso, es algo puramente cosmético.

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

Actualmente los backends de ejemplo de mxgraph están en Java, PHP y NET. Ninguno de ellos me convence, porque echarían por tierra la principal bondad: único binario estático de menos de 20MB. No obstante, podéis apreciar que lo único que hay que implementar son las funciones de carga y guardado de ficheros. De hecho, seguramente puedan hacerse en JS, aunque en el ejemplo se incluyan en el backend justamente para mostrar cómo es la coordinación.

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

Para no duplicar esfuerzos, actualmente estoy centrándome en la parte en Go:

• El rutador para gestionar de forma diferente las peticiones de cada dominio.
• Si incluir DNS en el backend o editar /etc/hosts con varias líneas.
• Probar cómo funciona eso de transmitir información entre el frontend y el backend. Técnicamente es muy sencillo, pero nunca lo he hecho: https://nathanleclaire.com/blog/2013/11/30/fear-and-loathing-with-golang-and-angular-js/
• Por el momento, si arrancáis el servidor con la opción verbose, '-v', conforme naveguéis y pinchéis en diferentes elementos del editor, veréis que el servidor muestra las peticiones completas (tipo de petición, navegador, versión, hora, etc.).
  

El objetivo principal como microaplicación es ofrecer una GUI para cargar múltiples bitstreams y visualizar un mapa de memoria donde colocarlas en el orden y posiciones deseados. Después, enviar el resultado al backend para que corra la versión de icemulti que estoy implementando en go. Con la carga que espero, me llevará un par de semanas por lo menos.

Después, analizaré qué hay que implementar del backend, antes de profundizar en qué aprovechar de icestudio.

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

¿Alguien tiene una Raspberry Pi y estaría dispuesto/a a ejecutar la aplicación para ver cómo va de fluída?

Saludos