Claudio Campos empezó a desarrollar sistemas profesionalmente en 1989 (a los 17 años), y en forma independiente desde el año 1995. En 1997 hace su primer contacto con Smalltalk (SUGAR), y a partir de ahí comenzó su viaje con la tecnología de objetos, trabajando con Smalltalk en diversos dominios: class library 3D, smalltalk en dispositivos móviles con recursos reducidos, I+D en lingüística computacional y procesamiento semántico, GIS y logística.
Nota del editor: SUGAR "Smalltalk User Group of Argentina" fue una organización que unió a todos los programadores de Smalltalk en Argentina y el primer sitio en Internet relacionada con Smalltalk en español. 1992-1997.

Podrías contarnos un poco tus experiencias en el uso de S8. El uso que yo le he dado a S8 es muy amplio. Quizás te puedo comentar los últimos desarrollos que estoy haciendo en Android (usando A8). Algunos son internos, no son desarrollos que esté haciendo para publicar en U8, sino parte de un proyecto comercial. En realidad no tengo muchas cosas en producción con S8. Lo que estoy haciendo es un trabajo de evaluación de costos de migración/actualización de plataforma. Siempre este tipo de tareas llevan tiempo. Tiempos para resolver las cosas nuevas que ocurren, tiempo para probar que los productos subyacentes realmente funcionen como dicen que funcionan. Porque hay cosas que no tienen que ver con Smalltalk sino con la plataforma de ejecución que hay por debajo.
Por ejemplo si hablamos de NodeJS si bien hay cierta estabilidad en el proyecto, existen cambios constantes. También en el caso de HTML5 en el nivel de desktop como de Mobile en algunos momentos había cosas que no eran soportadas en el Mobile y en otros momentos sí. Con lo cual algunas pruebas que uno hace quedan rápidamente invalidadas. Específicamente en el soporte para HTML5. Esto hace que hoy por hoy, en mi caso particular (no sé si esto es positivo o negativo), todo esto está en concepto de evaluación. No en un desarrollo maduro y funcional.

¿Qué problemas de soporte en HTML5 encontras? No veo problemas de soporte en S8 en particular. Hay tiempos que son necesarios dedicar para ver si determinada característica funciona o no. En un momento había comenzado con la proyección de usar PhoneGap para hacer una aplicación hibrida, pero después el PhoneGap comenzó en una fase de cierta inestabilidad. De todas maneras eran proyecciones. Dentro de lo que hago, trato de buscar lo más práctico –teniendo en cuenta que soy unipersonal y no cuento con personal para poner a investigar muchas cosas-. Es decir, trato de buscar lo que me funcione y me de cierta proyección en el tiempo. No puede ser demasiado marginal y debe verse moderno.

…más apegado a lo estándar. Si… yo siempre fui medio marginal. Hace más de 10 años que vivo de Smalltalk, con lo cual eso ya es ser marginal. Pero para vivir de Smalltalk tampoco me puedo ir al otro extremo. Entonces tengo que evaluar cuidadosamente donde ir para continuar usando Smalltalk.

Y cuáles eran las problemáticas que veías en PhoneGap? Hay cosas que funcionaban en PhoneGap y no funcionan mas… no invertí tiempo en ver cuántas y cuáles cosas no funcionaban mas (fallas en PhoneGap). Probablemente sea trivial lo que hay que tocar. Pero aunque uno está experimentando y evaluando, eso hace que nos genere cierto escozor y que por ahí habría que esperar a que madure un poco más… Esto siempre es en caso en que sea necesario acceder a funciones nativas de un dispositivo, en multiples plataformas móviles, si estamos hablando de PhoneGap en particular. Este último tiempo hice varios ciclos ahí. Desarrolle una aplicación de geolocalización, es una aplicación que tiene que ver con la actividad de la empresa a la que le estoy desarrollando, que es la misma que fue presentada en Smalltlak 2007 donde se accede a la posición del dispositivo y se hace una geolocalización de los lugares a donde las personas se pueden dirigir, que son los puntos de recolección que tiene la empresa. Esto en su momento había pensado encararlo con PhoneGap y S8, y que funcione en iPhone y Android y después con el tema del PhoneGap… estamos avanzando con una aplicación para Android solamente. Con la posibilidad, que no la descarto en un futuro, de usar PhoneGap para incluir iPhone y resolver cuales son los problemas que hay si esto empieza cobrar más estabilidad a medida que pasa el tiempo. Actualmente tengo todo implementado usando solamente S8 (incluyendo la geolocalización). Después tenemos si una aplicación de uso interno que es en Android pero que dependemos un poco la disponibilidad de dispositivos industriales.
Nota del editor: el framework de PhoneGap ha sido actualizado por un soporte completo de Cordova soportando mas dispositivos.

Qué sería esto? Dispositivos industriales, son dispositivos que están preparados para sobrevivir en ambientes adversos. Tienen carcasas anti-shock, seguridad, etc. No son dispositivos de consumo estándar. Por ejemplo en este contexto estamos hablando de gente que va en camiones, se les puede caer el dispositivo, hay polvo, lluvia, etc. Para eso estamos usando dispositivos que actualmente todos vienen con Windows. Ahora están saliendo algunos dispositivos nuevos (Android), y también en su momento habíamos evaluado ponerle protección a los dispositivos comunes pero usando Android. Esto si ya es una aplicación más grande, no importa que para iPhone no exista. En este caso A8 es perfecto, porque está muy bien hecho, tiene una integración con el SDK de Android con la capa de Java muy buena, por lo menos de las posibilidades que brinda, de lo que se puede hacer. Tiene muy bien resuelto el tema de cómo acceder a recursos locales dentro de la misma aplicación, empaquetados dentro de la misma aplicación, y a la vez acceder a recursos remotos. Se puede hacer cross domain request, donde se puede acceder a recursos locales como remotos con lo cual es en este caso la aplicación de geolocalización lo que tiene es algunos assets que son imágenes, páginas y archivos de S8 que se cargan junto a la instalación de la aplicación y luego hay un servidor Smalltalk que le sirve novedades e información.

y la parte del mapa como está resuelta? La Parte del mapa lo hacemos con el Google Maps, es todo HTML5. Esto es una aplicación Web corriendo con S8.

Sistema Coltex: planificación y optimización de rutas

Seria enriquecer el mapa con todos los assets y la info generada en S8. Claro, la aplicación es local (instalada) y corre en el dispositivo en una WebView. Pero es Web, en el sentido remoto y local. Es decir la aplicación interactúa con un servidor remoto Smalltalk que le sirve pedacitos de aplicación. Desde el servidor estoy bajando información, objetos y también trozos de chunk para actualizar, si hubiera la necesidad de actualizar/customizar la aplicación. Después tengo otras cosas hechas en otros Smalltalks, pero estoy trabajando en la migración de toda la plataforma de desarrollo. He trabajado a nivel de la integración de servidores NodeJS. Tengo un framework de aplicación desarrollado propio; hace más o menos 8 años que estamos trabajando con ese framework. Es totalmente independiente del dialecto, mi evaluacion de la migración a S8 indica que sería bastante posible. Lo que tengo que definir mejor son cambios de infraestructura en el enfoque. Porque lo que hoy tenemos en las aplicaciones son cosas que funcionan en un server y en el caso de migrar a S8 pueden funcionar en el cliente. Esto te cambia la modalidad de trabajo, es un cambio importante. El server deja de tener tanta importancia.
No estoy con la idea de levantar los frameworks en S8. Estoy con la idea de hacer un ciclo más sobre esos frameworks y reescribirlos sobre S8.

…pero algo de eso has migrado, aunque sea partes chicas de desarrollo. Si claro, el modelo del dominio es el mismo. Lo he enganchado en una imagen S8 y he hecho persistencia desde el browser. No hay ningún problema.

…en este punto esto fue una evaluación. Si, es así. Si tuviéramos que formalizarlo en una oración más estructurada diría que mis evaluaciones concretas de pruebas de tomar el modelo del dominio del sistema –que es bastante grande, es un sistema de logística, con planificación, con gestión, etc- son positivas. Este sistema no es el de geolocalizacion. Este último es un utilitario del sistema. Si no me refiero al sistema grande, el sistema de la empresa. Según mi evaluación la migración es perfectamente posible. Exige trabajo porque lo cambiaria para que en vez de correr en el server, corriera en el cliente. Con lo cual hay un trabajo de adaptación. Pero yo no voy a hacer un trabajo de adaptación por arriba, sino que voy a emprender un nuevo ciclo de implementación con este nuevo modelo.
Actualmente nuestras aplicaciones son Web, están trabajando en Smalltalk -me refiero a la aplicación central de la empresa– esta aplicación tiene un modelo de gestión de información muy complejo de cómo se llevan a cabo todas las planificaciones logísticas de la empresa. La aplicación gano un premio en el 2010, salió segunda en un concurso de logística y primera salió en coca-cola, con lo cual la aplicación tiene cierta notoriedad. Tiene gestión optimizada de recursos, con optimización de más de 30 a 40 lugares a visitar dentro de Europa, sabiendo cuales son los trayectos más cortos, coordinación de tiempo, un montón de cosas. Tiene un modulo móvil para registrar toda la información que se realiza fuera de línea.

…todo esto esta implementado en Smalltalk Web. Todo eso lo tenemos implementado en Smalltalk y hay una interfaz web y otra desktop. Toda la aplicación es en Smalltalk y la UI es un poco “despreciable” en el sentido en que no influye tanto en la aplicación en si la parte de interface. En realidad tenemos una interface web, una en Windows Mobile, una en Windows desktop, y en este momento tenemos una interface Android, usando siempre la misma aplicación por detrás.

Este nuevo ciclo de implementación sobre S8 que nombras, ¿hacia dónde está dirigido? Es decir, S8 tiene tantas formas de funcionar… S8 es tan amplio como lo es Smalltalk, pero es más amplio todavía porque es moderno.
¿Por qué me quiero mover a S8?, porque tengo una plataforma de ejecución moderna, más variada, muchos más lugares donde puedo ejecutar mis objetos. Hoy puedo implementar con S8 servidores de 64bit con NodeJS, como también correr una aplicación mobile en Android, en iPhone, o en iPad, extensiones de Chrome, o en cualquier browser que soporte HTML5 y ECMAScript5.

¿Qué ganancia verías en este nuevo ciclo de implementación? Es acceder a plataformas que por el momento no tengo. Para migrar lo migro y punto, es lo mismo. Pero ¿para qué voy a migrar si voy a tener lo mismo? Antes trabajaba con el browser con javascript. Ahora tengo la posibilidad de trabajar en el browser en Smalltalk. Tengo Smalltalk en el servidor y en el browser, con todo lo que implica eso. Para ser más concreto, por ejemplo, si se arma una página web o cualquier interface de usuario, o cualquier prueba que hagas en un browser, te las tenés que arreglar con las herramientas que te provee el browser, con el firebug, etc, herramientas muy limitadas, mas todos las validaciones, llamadas que se hacen al server, usando ajax, etc. Con Smalltalk es totalmente interactivo, un ambiente dentro del browser. Esto da la posibilidad de experimentar cosas que antes no pensaba porque no tenía ganas de gastar tiempo. Si bien javascript es dinámico no me da esa posibilidad que me da Smalltalk, con S8 estoy trabajando de la misma manera (el sistema es homogéneo y moderno, todo sigue siendo unObjeto). De manera subyacente es la misma plataforma de ejecución. S8 nos plantea una apertura de algo que no tenía, por lo rudimentario (bajo nivel) que es el javascript y las herramientas que tiene. Y a nivel de servidor me plantea una apertura a un modelo de ejecución que me parece mucho más moderno que las maquinas virtuales de Smalltalk comunes para servidor. Si lo queremos poner en términos de ganancia, es que te abre posibilidades, te abre el juego de una manera que antes no era posible.

Siempre que se habla de migración se habla de costos… Yo nunca migro. Migración es tomar lo que está escrito y cachetearlo un poco para que ande en otro lado. Como Smalltalker uno hace siempre las cosas de nuevo. A veces por cuestiones de compromisos cacheteas algo para que ande pero después lo reescribís.
Con el tiempo arme una capa de aplicación web y a partir de ahí tengo todo independiente del dialecto, con lo cual yo podría poner todo eso en S8 y seguir trabajando de la misma manera, pero… si dejo todo igual me pierdo o dejo de aprovechar todas las posibilidades que me abre S8. Porque pondría todo en el servidor con NodeJS y seguiría trabajando de la misma manera en el browser. Y ahora voy a trabajar de las dos maneras. Con Smalltalk en el servidor y en el cliente. Y si puedo trabajar con Smalltalk en el cliente, puedo conectar dos clientes sin el server en el medio...

En este punto se abre un abanico de posibilidades que nadie se esperaba… Creo que esa es la clave de lo que es interesante resaltar por lo menos, es lo que creo desde mi lugar. Yo soy más activo que reflexivo con estas cosas. Soy más de hacer en vez de teorizar por qué lo hago. En el caso de Smalltalk uno va dejándose llevar en el hacer. Con lo cual mucho de lo que te cuento tiene más que ver con esa percepción que uno tiene de trabajar en Smalltalk.-

Sergio Garcia Canto tiene un amplio recorrido como docente de POO (UBA, UNlaM, UB), como así también una sólida experiencia como desarrollador Smalltalk en el ámbito industrial. En los últimos años ha tenido la oportunidad de volcarse al mundo del entretenimiento, específicamente en el área de eventos y juegos. Algunas de sus experiencias se remontan a los inicios de S8, donde pudo recorrer distintas modalidades de trabajo, hasta llegar a moldear su propio entorno de desarrollo.

Podrías contarnos un poco tus experiencias en el uso de S8. El S8 me parece muy interesante. Tengo bastantes cosas hechas en Smalltalk y notaba que el soporte Smalltalk estaba decayendo bastante. Y por otro lado se producía también el efecto que algunos Smalltalks se volvieron muy inestables, hay demasiadas versiones, etc. Además, mi opinión es que a nivel tecnología quien está marcando el rumbo es Google. Se desarrollan cosas con características similares a las que yo desarrollo en Smalltalk. En su mayoría cosas simples y bien concretas. Estas son el tipo de aspectos que yo suelo investigar que están desarrolladas en Google y que intento capitalizar en mis trabajos.

¿Por ejemplo? El Goolge Maps, es algo muy grande y funciona rapidísimo. No hay flash, solo HTML5 y javascript. Yo ya me estaba orientando a usar HTML5+Javascript. Para mi forma de trabajo me simplifica mucho. Hay un montón de beneficios y yo ya venía por ese lado. Al encontrarme con S8, me pareció que estaba muy bueno porque es una forma de seguir los pasos de Google, usando toda la experiencia que ya tengo hecha en Smalltalk. Esto a mi me da la facilidad de trasladar código en concreto, de muchísimas cosas que ya tengo.
Tuve un trabajo alrededor de agosto del 2012, una reunión empresarial de Telefónica y de Movistar donde se reúnen todos los líderes de las empresas y evalúan como mejorar cosas. Hacia dónde va la empresa, etc. Y me pidieron dos cosas para ese evento: tenía que hacer un juego, que se jugaba en unos dispositivos multitouch, una trivia. Y después me pidieron hacer la asistencia de dinámicas de grupo. Cada 8 personas había una computadora. Eso generalmente se hace en papel ahora me lo habían pedido en computadora.

¿Qué serian dinámicas de grupo? En estas reuniones van alrededor de 1000 personas, lo cual hace muy difícil una puesta en común, o que alguien lea lo que dicen todos para sacar las conclusiones. Entonces dan una máquina cada determinada cantidad de personas (en este caso fueron 800 personas y era una notebook cada 8 personas, con unas 100 mesas). Luego se hizo una exposición de un tema, y posteriormente se pidió que la gente escriba en tres puntos un resumen, o lo que más le llamo la atención, o lo que más le sirve de la charla para su trabajo diario de lo que se hablo hasta el momento. Dinámicas de grupo hay muchas técnicas, pero en este caso se usaba para anotar las conclusiones y después se juntaba el registro de todos. La persona que guiaba la dinámica podía decir: “bueno miremos lo que dijo la mesa tal”.
Para hacer desde cero esto tenía menos de una semana. Y tenía que salir andando bien. Entonces decidí probar el S8.
Yo ya venía haciendo cosas de este estilo. Es decir, ya he hecho cosas para otros eventos y lo venía haciendo sobre javascript en el cliente y el servidor con Squeak. Mi idea con S8 era tener NodeJS como servidor y en el cliente tener S8 directamente.
He llegado a estar un día sin dormir, menos de una semana para hacer algo y además en estas cosas que es todo marketing se gasta mucha plata. No puede fallar. Mucha presión. Pero, yo sé que esa es la mejor forma de probar algo. Bajo presión con poco tiempo y tener que sacar andando algo si o si, para mi es la mejor forma de probar algo.
Lo hice en S8, el juego salió bien! Tuve solo problemas con los acentos y las ‘ñ’ un tema de codificación de caracteres que no lo pude resolver como corresponde. Lo que hice fue algo muy simple, en el servidor le cambiaba esos caracteres por otros tres caracteres ASCII y enviaba las preguntas en esa forma desde el servidor al cliente.

¿En qué consistía el juego? ¿Eran preguntas y respuestas? Eran trivias. Ponían 10 preguntas con un número variable de respuestas para elegir. Y además había que tomar el tiempo que se tardaba en responder y una forma de puntuar las preguntas. Al final la persona ponía su identificación, participaba y le mostraba el tiempo y el puntaje. Luego el de mayor puntaje era el ganador.
Lo que tenia hecho, que era configurable, era un archivo de texto en el servidor con las preguntas y respuestas. Ahí tenía el problema, yo lo transportaba por medio de ajax y cuando me llegaban lo hacían con los caracteres cambiados. Después decidí probar el local storage en el cliente. La verdad es que me funciono bien.

¿En este caso entonces usaste los storage como almacenamiento distribuido y posteriormente captaste todo lo que estaba grabado en los clientes? Lo que pasa que como es algo muy crítico tengo que tomar varios recaudos. Lo que escribe la gente viaja al servidor en el mismo momento guardándose en un archivo en el servidor (no use base de datos), pero además quedaba guardado en cada cliente. Si tenía un problema podía ir a levantar todos los resultados de un cliente determinado.
En ese momento llegue a algunas conclusiones con respecto al S8. Si hubiera hecho lo mismo directamente en javascript usando una librería grafica como ExtJS (aunque use S8, use también ExtJS) yo creo que me hubiera llevado más tiempo lograr lo que hice.
Usando el S8 me arme un mecanismo que al abrir un browser (Chrome en este caso) me abre otro browser al lado. De manera que en este ùltimo tenía dos paneles de texto. En uno escribía código Smalltalk y cuando lo ejecutaba le pedía que se evalue en el primer browser. Utilizaba un browser como ámbito de desarrollo y otro como espacio donde se ejecutaban las cosas. Fui creando de esa forma. Trabajaba de a poco en uno, e iba armando en el otro, iba viendo y probando en el otro. Si hubiera trabajando en javascript tendría que haber escrito ASCII y ejecutar todo de una vez y ver qué pasaba.

...ahí tuvo el tufillo de Smalltalk de siempre. El S8 que use todavía no tenia los tools como el Class Hierachy Browser (NE. En el momento de esta experiencia aun no existía WI8 + UI8). Era un workspace y nada más. Así y todo trabaje más rápido. Trabaje como se trabaja en Smalltalk, armando en el momento con “las manos” y corrigiendo en el momento. De pronto cuando tenía un problema con algún método lo que hacía era poner el nombre de la clase #methodDictionary #at: el nombre y me aparecía el source. En ese sentido fue muy a pulmón pero creo que hice mucho más rápido que si hubiera hecho directamente en javascript. Extrañe mucho las herramientas. El debugger es vital (NE. En el momento de esta experiencia aun no existía U8 Debugger). Terminaba debuggeando con la consola del Chrome.

Muy impresionante. ¿Y con la trivia como se resolvió? Las trivias las instale de manera local. Eso fue un error. Fue una persona maquina por maquina. Instalaba el Squeak como servidor e instalaba el Chrome, y este llamaba a la dirección de loopback.
Después me arrepentí. Si instalaba el servidor en un solo lugar y centralizaba los resultados y me era más fácil. Eso hubiera sido mucho mejor. Pero hubo muy poco tiempo e hice lo mejor que pude, me falto coordinar con la gente de soporte.

¿Y la asistencia a dinámica de grupo, como sucedió? En un momento me decían: "primera conclusión". Entonces yo desde el servidor mandaba un mensaje al diciendo algo así como, "habilitar primera dinámica". Y automáticamente en la pantalla de los clientes les aparecía una hoja de carpeta. Ahí la gente iba respondiendo. En el momento que terminaba, decía “enviar repuesta” y eso se enviaba al servidor. Luego me decían ”pasemos a la segunda dinámica” y yo habilitaba la segunda dinámica y así sucesivamente.
Eso funciono bien. Me paso algo curioso -hay que tener en cuenta toda la presión que significo todo esto, no?- en un momento me reportan que la trivia no grababa las respuestas. Fui a la máquina que me marcaron como “problemática” y con la consola, empecé a abrir los códigos de los métodos Smalltalk y comencé a poner console.log para ver donde estaba el problema. Y ahí en el mismo cliente, donde mostro el error, encontré el problema y lo arreglé.
Hasta aquí en general a mi me pareció muy bueno. Pero al mismo tiempo me desilusionó un poco el hecho de no tener las herramientas de desarrollo. Además uno tiene todas las limitaciones de sandbox, el esquema de seguridad. Aunque lo del local storage a mi me dejo tranquilo, porque podrías simular un archivo, etc.
Luego en otra ocasión me llaman para otra promoción de otro producto. En esta ocasión requería interacción con una tablet. Para esto implemente un tragamonedas. Ahí es donde necesite la parte de animación.
En ese momento en U8 ya estaba el ambiente con el CHB (Class Hierarchy Browser) y el Workspace. Entonces logre mezclar eso que estaba en U8 (esas herramientas) en mi S8. De manera de tener algo “standalone” sin entrar a algún lado. Le agregue a la imagen de S8 las herramientas de desarrollo. Pero con la salvedad que mantuve la filosofía que comente antes. Por un lado tengo un browser con las herramientas de desarrollo y otro browser donde se plasma lo que se desarrolla. Le cree a este ambiente un CHB y un Workspace remoto. Cuando se comienza el desarrollo al ingresar la url, se abre un Chrome en blanco y al lado otro Chrome con la barra de herramientas. Para comenzar mi desarrollo abrí un CHB remoto y empecé a agregar cosas.
Lo primero que hice fue agregar una imagen que se moviera. Para esto use lo que en DHTML5 se llama canvas. Sucesivamente fui agregando complejidad en el movimiento plasmando velocidad y aceleración, hasta lograr mecanismos que me permitan hacer cosas como mover una imagen con tal velocidad, después lograr mover con una aceleración especifica hasta llegar a una velocidad determinada. Y así iba enriqueciendo la animación hasta ir acercándolo a lo que necesitaba en el tragamonedas, el “jackspot”.

Este proceso si fue bien al estilo Smalltalk. Como agarrar una plastilina e irlo moldeando. Como aprende un nene cuando es chiquito. Lo pones y ves que pasa. Si se cae entonces hay que ponerle algo, etc.

Es importante esto último. La idea del S8 es que siga manteniendo el espíritu Smalltalkero de siempre. Cuando comencé a usar el canvas, fui a internet y busque un ejemplo. Algo abordable en javascript y simple. Una vez probado (asegurándome que funciona correctamente) lo meto dentro de Smalltalk. Y al meterlo en Smalltalk, la próxima vez que lo tengo que usar no tengo que escribir todo. Escribo tres palabras y ya está funcionando.
Cuando tenía que hacer algo nuevo, por ejemplo que un elemento div me aparezca siempre centrado, esto lo investigue una vez, arme un mensaje que decía “colocar el frame centrado” y me olvide!
Supongamos que para hacer eso en javascript tengamos que escribir diez líneas. Por mi experiencia yo se que de esas diez líneas yo podría automatizar seis, siete no más. Hay tres que las tengo que modificar si o si cada vez que lo uso. En cambio en Smalltalk, no. Es muy simple volver a usar las cosas.
Antes del evento de Telefónica, tuve cuatro mas. Variante más o menos la complejidad y la presión siempre es la misma. Las veces anteriores yo no tenía S8 y trabaje todo con javascript. Fui acumulando código en javascript de esas experiencias...

Podríamos decir que previo a S8 ya tenías experticia en javascript. Justamente por eso lo comento. Yo comparo lo que me costaba antes encontrar donde estaba el pedazo de código que podía reusar (porque yo sabía que estaba hecho esa porción de código) pero encontrarlo era algo muy costoso. Y además, lo copiaba y no me funcionaba… tenía que copiarlo todo y sacarle líneas. En cambio con S8 trabajando a pulmón, no me paso.
Esta comparación que hago me pareciera que no es algo subjetivo…

El uso que le has dado a S8 es a muy bajo nivel. Inclusive sin usar casi nada, solo con una consola javascript y editores de texto. Seguramente cuando la herramienta alcance cierta madurez (NE. En el momento de esta entrevista WI8 + UI8, ni U8 Debugger tenían el nivel de desarrollo que tienen hoy), la gente con menos experticia lo podrá vivenciar de manera más accesible. …en el comienzo de los desarrollos uso indistintamente javascript y Smalltalk (mediante la sintaxis de {}) pero a medida que se sigue desarrollando se puede ir acomodando el uso de los trozos de código de bajo nivel (javascript), armando el código Smalltalk. A mí el uso de S8 me ayudo a organizar el código, me ayudo en la abstracción. Algo que necesitaba. Necesitaba abstraer para hacer más rápido.
Otro aspecto para destacar es que reacomodar clases en javascript no es trivial. En Smalltalk es más fácil detectar que falta alguna clase en el medio. Es decir, detectar que se tiene comportamiento desparramado por varias clases y que estos retazos de comportamiento podrían ir en una sola clase, me pareciera que es más notorio en Smalltalk. Poder ver esto en código javascript y poder articularlo, requiere que uno tenga que tener una capacidad de abstracción muy grande, casi como un jugador de ajedrez. Tener todo en la cabeza y ver el panorama por adelantado.-

Pasaron nueve meses desde el Newsletter Vol 1. Miguel Isasmendi ha logrado avances importantes en el desarrollo de MVP.
Miguel, podrías contarnos un poco el estado actual del desarrollo? La contribución actual no refleja MVP con los últimos avances. La contribución de desarrollo en la que trabajo a diario aun necesita testeo, no esta totalmente "publicable". Los cambios más visibles son que abandoné el modelo de interface visual tabular (por medio de tabs) para pasar a uno de ventanas. Obviamente todavía puede ser configurado para volver a ese modelo u otro de ser necesario.

Y mas en detalle ¿qué otros avances nos podrías contar? El TreeView tiene soporte de lazy loading, hay menúes contextuales, tooltips, ventanas, un especie de desktop donde residen las ventanas. He logrado desacoplar los estilos de los widgets de manera que ahora tengo temas para los que me valgo de CSS. El MVP viene con dos temas: el default theme y el MetroStyle. Este mecanismo de estilado permite trabajar en el cambio del look por afuera del framework. Similar a como sucede en HTML.
También habría que nombrar la consolidación de JSON como forma de serialización de las vistas.

MVP con tema MetroStyle

¿Podrías contarnos algo sobre este mecanismo de serialización? Básicamente la estructura y configuración de las vistas y los presentadores estan serializadas en JSON. Esa serialización es tomada y las vistas y presentadores son recreados. He trabajado bastante en la optimización de esta fase. En otros Smalltalks como VisualWorks o Dolphin el tipo de serialización es distinto.
Por otro lado aun no existe un ViewBuilder. En mi to-do se encuentra el ViewBuilder; trabajar manualmente sobre JSON es especialmente engorroso para las vistas o presentadores complejos.

¿Cuánto se desvió el desarrollo de lo que estaba proyectado? Por ejemplo en Dolphin vos habías comentado algunos puntos en común. No me desvié mucho de Dolphin. La metáfora construida para Dolphin, como mecanismo, sigue estando. Mi implementación de MVP internamente funciona distinto. Por ejemplo, las vistas comprenden el mismo protocolo de creación que los presentadores. Me incline hacia un manejo un manejo de manera uniforme y, como comentaba previamente también se cambio la interacción de los objetos que realizan la deserialización para conseguirlo.

¿Que features nuevas se pueden esperar a futuro implementadas en tu MVP? Aun me falta desarrollar una barra al estilo taskbar donde se minimice las ventanas. Digamos, actualmente hay manejo de ventanas pero aun es muy básico. Me falta un mecanismo de layout de los componentes gráficos configurable a nivel de objetos y separando la implementación, etc. También me falta toda la parte de los diálogos modales de confirmación, error y advertencia. A nivel mas general estoy focalizando todo el esfuerzo en el navegador y aumentar la usabilidad del framework en el desarrollo. Lograr una herramienta más potente algo más cercano a un IDE básico.-

Los encuentros betaworks son reuniones periódicas (una por semana) en un día estipulado y de duración fija abierto a cualquier persona registrada como usuario de U8. Estas reuniones tienen como objetivo realizar progresos en el desarrollo de U8 de manera en conjunta, y responder preguntas en relación a U8/S8.

¿Deseas participar en la próxima reunión? Envía un mail a info@smalltalking para chequear la fecha y duración y obtener a la información para acceder al salón virtual. También, puedes chequear smalltalking mail list por un anuncio de reunión o puedes leer la información en nuestra swiki.