[View]  [Edit]  [Lock]  [References]  [Attachments]  [History]  [Home]  [Changes]  [Search]  [Help] 

Entrevista a Sergio Garcia Canto (Hágalo Ud. mismo)

Con lo que hay en U8/S8 ¿como podes desarrollar como en un Smalltalk tradicional?
Tomé parte de las tools que están en U8 y las fui modificando, específicamente la capacidad de browsear código remoto. Es decir en un instante dado tengo N imágenes S8 corriendo en distintos tabs del chrome una con las tools de S8 modificadas y las demás con aplicaciones que quiero ver en funcionamiento, y que pueden ser browseadas a través de CHB remotos.
La tool permite abrir Workspaces o CHB remotos, entonces nos da una serie de opciones direcciones IP (o nombres de nodos en la red) en las cuales hay imágenes S8 que pueden ser exploradas.
How do you can develop as in a traditional Smalltalk?
I took part of U8 tools and modified it. Specifically the ability to browse remote code. Having n S8 images running in different chrome tabs; one with S8 modified tools and others with applications that I want to see in operation it can be browsed remotelly.
The tool allows to open remote Workspaces and/or CHB, giving us several IP addresses options (or node names in the network) in which there are S8 images that can be explored.


¿Las tools de desarrollo son locales?
La tool es local en el sentido que corre en un tab de chrome, aunque es servida por un servidor de desarrollo (un nodejs corriendo en el puerto 8080), algo típico para desarrollar. Las imágenes que se quieren explorar remotamente pueden estar en ese servidor de desarrollo o en otro nodo de la red. Sobre la tool cuando pido un CHB “local” estoy explorando la imagen S8 que está corriendo en el Chrome correspondiente a las tools de desarrollo. Si pido un CHB “nodejs ip xxx.xxx.xxx” estoy explorando la imagen que está corriendo en el nodejs.
Are the development tools 'local'?
The tool is local in the sense that runs on a Chrome tab, but is served by a development server, a nodejs running on port 8080, which is typical for development. The explorable images can be remote in the development server or a different network node. With the tool when I ask for a "local" CHB, I am exploring S8 image is running in the corresponding development tools to Chrome. If I ask for a CHB "nodejs ip xxx.xxx.xxx" I'm exploring the image that is running on the nodejs.

¿El nodejs que se usa para servir otras imágenes S8 está corriendo una imagen S8?
el nodejs ejecutando como otro proceso del S.O. y corriendo una imagen S8 que no es visual, no hay nada relacionado con las tools. Es decir, al browsear la imagen S8 del servidor no tiene la clase S8Tool. Ademas podríamos ver que en la fase de arranque de la imagen S8-servidor-nodejs se cargan un monton de modulos: websocket, http, filesystem, so, mongodb, etc, y posteriormente se lanza un servicio (websocket server) corriendo en el puerto 9060, por donde se rutearan todos los request de las herramientas de desarrollo. Posteriormente se lanza un servicio file server en el puerto 8080. Entonces la forma típica de trabajo es: un browser corriendo una imagen con las tools de desarrollo que se conecta con el nodejs que es el realmente el que guarda las imágenes.
Is Nodejs serving other S8 images, running a S8 image?
The nodejs running as another S.O. process and running a S8 image that is non-visual, nothing related tools. That is, this image has not the S8Tool[] class. We may also see that in starting phase of S8-server-nodejs image, a lot of loaded modules: websocket, http, filesystem, so, mongodb, etc, and then a service (websocket server) is launched running on port 9060, where all of the development tools request will be routed. Subsequently, a file server service is launched on port 8080. So the typical way of working is a browser running an image with development tools that connects to the nodejs which is really who saves images.

¿Es posible hacer un “save” de un método?
Si se puede. Aunque deberíamos hacer un distinción entre cambiar el comportamiento de la imagen y guardar los fuentes en algún archivo. Se hacen las dos cosas pero por separado. Modificar la imagen es algo muy simple pero guardar el fuente es más complejo. Hay que tener en cuenta que lo que tengo desarrollado no son herramientas maduras para producción es algo ad-hoc, aun le falta desarrollo(34:20). En el primer caso para modificar el comportamiento de la imagen puedo abrir un Workspace remoto y explorar y modificar los objetos.
Is it possible to do a "save" method?
Yes you can. Although we should make a distinction between behavior change and save the image in source files. This things are done but separately. Modifing the image is very simple but save the source is more complex. Keep in mind that I have developed tools that are not mature 'production' is somewhat ad-hoc development. In the first case to modify the behavior of the image I can open a remote Workspace and explore and modify objects.

Y esa exploración cómo funciona.
es similar a un "inspect", pero lo hago via el comando “show it” con un menú contextual de la misma manera en que se opera con los demás Smalltalks. Y modificar la imagen via “do it”(44:03). Ese Workspace se está ejecutando en la imagen remota. Cuando la porción de código seleccionado se le hace un “do it” o un “show it”, toma el string que representa código y se envía a la otra imagen, se ejecuta y luego devuelve el string con la respuesta. De esta manera se puede operar sobre una imagen remota. Dicho en otras palabras no se está haciendo nada de manera local, solo se está enviando y recibiendo. Todo por websockets y utilizando el servidor nodejs como intermediario. En un típico escenario estaríamos corriendo dos imágenes en el browser, una con las tools de desarrollo y otra con otra imagen con una aplicación, ambas dos servidas a través del puerto 8080 aunque comunicándose vía otro puerto (en mi caso el 9060) para propósitos de desarrollo.
Este mismo esquema también lo tengo funcionando en un dispositivo Android. Con las herramientas de desarrollo, puedo abrir un CHB o un workspace, y me aparecerá, disponible para seleccionar, el nodo Android con el nombre del modelo de dispositivo y su ip. De esta manera se puede abrir un CHB o un Workspace remoto en un S8 dentro de un Android.
That exploring how it works.
It is similar to "inspect", but I do via the "show it" with context menu command in the same way in which it operates with other Smalltalks. Changing the image is via "do it". That Workspace is running on the remote image. When you selected a portion of code and make a "do it" or "show it", it takes the string representing code and sent to the other image; is executed and then returns the string with the response. This way you can operate on a remote image. In other words, it is not doing anything locally, the only activity is sending and receiving. All through websockets and using nodejs server as an intermediary. In a typical scenario we'd be running two images in the browser, one with the tools of development and another with image with an application, both served through port 8080, while communicating via another port (in my case 9060) for developing purposes.
This same pattern is also working on an Android devices. With development tools, I can open a CHB or Workspace, selecting the option with the Android node (it shows Android device model name and IP). In this way you can open a remote Workspace or CHB exploring a S8 within Android.


Entonces con Android no cambia nada. Las imágenes se intercomunican vía el 9060 con el nodejs como intermediario.
Es correcto, es lo mismo, aunque algo interesante también es que varias imágenes de desarrollo con las herramientas remotas pueden estar inspeccionando una misma imagen. Si se publica en la red la imagen con las herramientas remotas y el “servidor intermedio” permitiría que dos personas estén explorando y/o modificando la misma imagen. Esto es posible, aunque no tiene aun ningún mecanismo de control. Falta mucho por desarrollar y formalizar, serian necesarios inspectores y debuggers. Pero lo que tengo hecho fue impulsado por la necesidad.
So nothing changes with Android. Images can intercommunicate via 9060 with nodejs as an intermediary.
That's right, it's the same, but something interesting is that several images with remote tools may be inspecting the same image. If remote tools and the "intermediate server" it is published on the web allows two people exploring and/or modifying the same image. This is possible, even though it has no control mechanism. Much remains to develop and standarize, would be needed inspectors and debuggers. But what I have done it was driven by necessity.

Y el manejo del código fuente?
Como comentaba antes, aquí está separado la modificación de la imagen de la acción de guardar el código fuente. En S8 existe el concepto de categoría y hago uso de eso. Si a un string que tiene el nombre de una categoría le envío el mensaje #fileOut, eso se graba en un fileSystem, quien lo hace es el S8 servidor corriendo en nodejs, manteniendo cada imagen como un proyecto. De esta manera todas las fuentes los tengo particionados en categorías. Eventualmente cuando es necesario reconstruir la imagen tengo un build configurado para que se ensamble desde un conjunto de categorías precompiladas. Ademas para tener respaldo a medida que se hacen los cambios, tengo las cosas versionadas de manera de poder simular algo similar (con menos información) a un change.log.
And what about source code management?
As I mentioned before, changing the image it is separate of save source code. In S8 there is the concept of 'category' and I make use of it. If a string has the name of a category I cand send the #fileOut message so it is recorded in a filesystem. Who does it is the server running on nodejs S8, with each image as a project. In this way all the sources have partitioned into categories. Eventually when you need to reconstruct the image I have a 'build' configured to be assembled from a set of precompiled categories. In addition to having support of changes, I have things versioned way to simulate something similar (with less information) to a change.log.