Se está construyendo un sistema el cual debido a su naturaleza fuera de lo común tiene cerca de 200 métodos que devuelven un String simplemente.

En la siguiente imagen se muestra 1 de estos métodos, como el sistema está relacionado con el PMI, el texto que se muestra es copyright  © de PMI.org.

Problema

Por cada uno de estos 200 métodos hay que crear otro método derivado que replique un mismo patrón, por lo hay que crear 200 nuevos métodos. Es un trabajo que tedioso que lleva tiempo y es propenso a errores.  Aquí es donde nos “salva” la REFLEXIÓN y la META PROGRAMACIÓN, en este caso es bastante sencilla.

Como quedaría el método luego de aplicar el patrón a mano:

Habría que aplicar el mismo patrón para otros 199 metodos y así sucesivamente. Con este nuevo método #changeRequestsNew tendría una instancia con la descripción que devuelve el método original (#changeRequests) que es solamente texto, que es justamente lo que quiero para este método y el resto.

Patrón

1. nombreNuevoMetodo := Nombre del método actual  + ‘New’. En este caso: changeRequests + ‘New’ = changeRequestsNew

2. El argumento que se pasa al mensaje #name:  debe ser el nombre del método actual, pero separado por un espacio y cada palabra en mayúsculas.  En este caso es:

name: ‘Change Requests’ - recordar el nombre del método actual (self) es #changeRequests

3. El argumento que se pasa al mensaje #description:  debe  ser una llamada al método actual que devuelve un String. En este caso es:

description: self changeRequests. – la descripción queda con el String del método original.

Este patrón debe aplicarse a 199 métodos más…

Solución

La solución me tomo unos 5 minutos ! y consiste en implementar un método en la clase CompiledMethod. En Smalltalk cada vez que creo un método se crea una instancia de esta clase CompiledMethod, y esta clase es editable y modificable como cualquier otra.

La variable [selector] del método actual (#changeRequests) se concatena con ‘New‘ para formar el selector (nombre) del nuevo método a ser creado.  Este nombre se almacena en la variable temporal [newSelector] como un símbolo #asSymbol (es una clase especial de String).

Ahora en la variable temporal [pmpName] formo el nombre según las reglas. La primera letra la paso a mayúscula (first asUppercase asString) y luego proceso el resto.

Ahora proceso todo menos la primera letra (c) [hangeRequests]. Si esta en minúscula copio y si esta en mayúscula agrego un espacio en blanco y copio. Guardo el resultado de la iteración en la temporal [pmpName].

Ahora creo un template para compilar el método en la variable [newMethod]. Uso el nombre del nuevo método y uso el selector actual (nombre actual) para crear la llamada (description: self’, selector,‘). Y por último compilo el template [newMethod] en la clase del método actual (methodClass compile: newMethod).

Ahora solamente cada vez que quiero crear uno de estos 200 métodos simplemente le envio el mensaje #compileMethodStringForPMPNewDocument y me crea el derivado.

En un principio pensé hacer esto con el Code Rewriter pero después opte por implementar un método en CompiledMethod.

El Code Rewriter es una herramienta muy poderosa que sirve para hacer transformaciones masivas de código de forma segura, basicamente suplante un AST por otro AST equivalente (mismo comportamiento) pero más óptimo.

UML Almighty tiene la capacidad de agregar/modificar clases y comportamiento sin necesidad de detener la aplicación.

Esta funcionalidad fue cuidadosamente pensada y diseñada para maximizar la experiencia del usuario en la simulación UML.

Obviamente que la funcionalidad esta inspirada en la misma solución implementada en los diferentes Smalltalk.

En palabras de Malte Ubl de Google (link a post original):

“… También Gilad Bracha (creador del lenguaje de Google Dart) está prometiendo ciclos de edición-depuración-edición-depuración al estilo Smalltalk (sin detener el programa). Si has trabajado alguna vez con Visual Works Smalltalk u otro ambiente Smalltalk que soporte esta funcionalidad, tendrás que estar de acuerdo en que otro ambiente de desarrollo incluyendo los de la corriente principal -mainstream- (C, C++, Java, C#, etc) se siente como de la edad de piedra. “

Poder crear un sistema agregando/modificando/moviendo comportamiento y sin detener el sistema es una ventaja enorme que puede ser comprendida mediante la experimentación con cualquiera de estos sistemas.

En el UML Almighty toda la configuración del comportamiento de la simulación asi como el interfase (GUI) del prototipo se puede hacer on the fly, es decir, con el sistema andando, el sistema nunca se detiene, esta forma de trabajo se asemeja a trabajar con un sistema biológico, que siempre esta en marcha.

Mail de Hernan

¿Te enteraste que este año se hace nuevamente el congreso Smalltalks? (http://www.fast.org.ar/smalltalks2011)
Por ahí te estás preguntando qué puede tener de interesante un congreso sobre un lenguaje que seguro no usas para trabajar y que por ahí no conoces, pero si tenés 5 minutos, lee este mail, te puedo asegurar que no te vas a arrepentir y seguramente querrás venir al congreso

Para empezar, este congreso no es únicamente sobre un lenguaje de programación sino sobre una tecnología y cultura de desarrollo que aún sigue influenciando fuertemente nuestra profesión. Por ejemplo, el año pasado vino a esta conferencia Gilad Bracha. ¿Quién es Gilad Bracha?, por ahí te suena el nombre… bueno, te suena porque es uno de los que está detrás de desarrollo de Dart, el nuevo lenguaje de Google (http://www.dartlang.org/) ¿Y qué tiene que ver Smalltalk? Justamente Gilad Bracha fue uno de los desarrolladores de Strongtalk (http://www.strongtalk.org/), el Smalltalk más rápido en su época, que utiliza compilación adaptiva, Polimorphic Inline Caching (PIC), tipado de variables opcional, etc. Todas soluciones que ahora se están implementando en Dart. Este año nos visita uno de sus más íntimos colaboradores, Vassili Bykov, implementador del UI de Newspeak, el último lenguaje en el que estaba trabajando.

Pero no solo Smalltalk tiene algo que ver en lo que está sucediendo con Dart, sino también en Ruby… ¿escuchaste hablar de MagLev? (http://ruby.gemstone.com/) Es el servidor de objetos transaccionales y automáticamente persistibles para Ruby, ¿adiviná de dónde viene? MagLev es la implementación de Ruby corriendo sobre GemStone/S, un servidor de objetos transaccionales y persistibles para Smalltalk que tiene más de 25 años y que ahora VMWare compró por su gran potencial y solución como administrador de memoria transaccional para Java, si no lo sabías mirá http://www.springsource.com/products/data-management/gemfire65  ¿Qué tiene que ver con el congreso? que justamente viene al mismo Martin McClure, responsable de MagLev y Norman Green, arquitecto de GemStone! o sea, el que tiene la papa!! ¿Tenés dudas sobre las bases de objetos? ya sabés donde podés obtener las respuestas.

Pero por ahí a vos no te interesa nada de esto… por ahí cómo funcionan los lenguajes de programación o cómo están implementados no es lo tuyo, vos haces aplicaciones web y solo necesitás que la infraestructura escale, persista información rápido, etc. Si ese es tu interés, tenemos un lugarcito para vos también. ¿Escuchaste hablar de GLASS? (http://seaside.gemstone.com/) Es la implementación de Seaside, un framework dinámico basado en continuations para aplicaciones web usando GemStone! (http://www.seaside.st/). O sea, desarrollas una aplicación web como si fuese una aplicación desktop y tenés gratis la transaccionabilidad y persistencia a nivel objetos… y lo que es mejor, sin base de datos relacionales!!! Si!!!!, no más hybernate, no más SQL, no más tablas, solo objetos!…. Por ahí te parece una locura, por ahí te parece que no tiene sentido… te aconsejo que no saques ninguna conclusión y no dejes de venir a escuchar a Dale Henrichs, el encargado de este producto quien nos contará todos los detalles del mismo y cómo influye en los desarrollos web.

¿Aún no te convencí? ok… dejame intentar un poquito más… ¿Conoces a Alan Kay? ¿Turing award, “padre de la computadora personal”, creador de Smalltalk? (http://en.wikipedia.org/wiki/Alan_Kay) No, no, no viene él, todavía ,  pero vienen Ian Piumarta y Kim Rose, dos de los más íntimos colaboradores de Alan Kay en los proyectos que están llevando adelante en su fundación sobre lenguajes de programación mínimos como OMeta y ambientes de enseñanza como SqueakLand. (http://www.vpri.org/index.html). ¿Te interesa saber cómo usar la computadora para enseñar? Le vas a poder preguntar a Kim. Te interesa saber cómo implementar una buena VM, lo vas a tener a Ian cerquita para conversar.

Si aún estás leyendo y no fuiste al final de la página significa que aún no te convencí… hmmm, a ver qué te parece esto: MOOSE (http://www.moosetechnology.org), una plataforma para hacer análisis de tus programas, no importa si están escritos en Java, C++, C# o Smalltalk, te permite ver visualmente el diseño de tu sistema no usando esos diagramitas simples de UML sino por medio de gráficos especialmente preparados para reconocer rápidamente algunos errorcitos que por ahí tiene tu sistema . Tudor Girba, desarrollador de esta plataforma vendrá a comentarnos cómo funciona, cómo está desarrollada y qué podés hacer con ella puesto que además es gratis!

Por ahí ya estás aburrido de leer tanto, no te culpo y tampoco me culpes a mi! es un congreso excelente! no te lo podés perder!, puesto que la cosa no termina acá… si te interesa saber sobre los principales ambientes de desarrollo en Smalltalk tanto opensource como comerciales, tendrás la oportunidad de conversar con Markus Denker de Pharo (http://www.pharo-project.org/home)  y John O’Keefe, arquitecto de VASmalltalk (http://www.instantiations.com/)

¿Muchos temas relacionados con la industria no? ¿y qué hay acerca de investigación, aún se investiga algo en con Smalltalk? Te comento que este es el segundo año consecutivo que el congreso tiene una sección completamente dedicada a la investigación, con un comité evaluador envidiable y con publicaciones en journals. Por lo tanto, si te interesa hacer investigación con objetos y necesitas que tus publicaciones sean en congresos reconocidos, te comento que Smalltalks es uno de ellos. Y no me quiero olvidar de la docencia universitaria… Smalltalk sigue siendo el lenguaje utilizado para enseñar objetos en casi todas las universidades y no para enseñar meramente un lenguaje de programación comercial.

Y a pesar de todo esto, de toda esta gente que nos va a visitar y con quienes podremos compartir su experiencia y la nuestra, falta lo más importante: La comunidad argentina de Smalltalk, una de las principales comunidades en el mundo de esta tecnología. Es esta comunidad que hace 5 años está organizando este congreso a todo pulmón y hace 3 años viene ganando de manera consecutiva el primer y tercer puesto del “Esug Technology Award”, premio a los mejores desarrollos hechos en Smalltalk a nivel mundial! y lo más interesante es que los ganadores son de distintas universidad de nuestro país como la UBA, la UAI y la UTN!
Y la comunidad no se limita a eso… ¿sabés que hay un Smalltalk argentino? ¿un Smalltalk desarrollado por un argentino y utilizado a nivel mundial? se llama Cuis y su desarrollador Juan Vuletich (http://www.jvuletich.org/Cuis/Index.html), quien además está llevando adelante el desarrollo de Morphic 3.0 y trabajó junto a Alan Kay desarrollando Squeak. ¿O sabías que el layer open source para comunicarse con base de datos relacionales desde Pharo o Squeak más usado también fue desarrollado por argentinos? o que el framework de serialización de objetos opensource Fuel también fue desarrollado por un argentino? Te suenan Mariano Martinez Peck, Guillermo Polito, Martín Dias, Esteban Lorenzano entre otros?, ellos son parte de nuestra comunidad y nos recuerdan constantemente la muy buena capacidad técnica que tenemos en nuestro país. También es argentino el arquitecto de la VM de Smalltalk más rápida que hay, la de VisualWorks (http://www.cincomsmalltalk.com/main/products/visualworks/) y le podés preguntar cómo hizo para acelerar hasta cerca de un 70% el GC en el último año, y vas a poder escuchar una charla de un argentino que es smalltalkero hace más de 20 años… ¿te imaginás cómo sería tu productividad si estuvieras trabajando hace más de 20 años en el mismo lenguaje? ¿un lenguaje que además sigue dando mucho a nuestra profesión?… Esta gente es parte de esta gran comunidad y también participarán de este maravilloso evento…. este congreso no es solo importante por la gente que viene sino por la gente que ya está!

Espero haberte convencido, espero que te hayas dado cuenta que este congreso no es acerca de un lenguaje de programación sino de una comunidad de desarrolladores que quiere compartir con vos lo que conoce y también aprender de vos. Si querés ayudar a que esta comunidad siga creciendo, si querés ayudar a que este congreso siga siendo un congreso de desarrolladores y para desarrolladores, anotate acá: http://www.fast.org.ar/smalltalks2011 Es gratis y te puedo asegurar que no te vas a arrepentir. Podes ver las charlas que se darán en:  http://www.fast.org.ar/smalltalks2011/talks

Este año se hace del 3 al 5 de Noviembre, en la Universidad de Quilmes. Y no está cerrada sólo al mundo de los objetos, este año Fidel (Pablo E. Martínez López), uno de los referentes argentinos de Programación Funcional, una comunidad que comparte que en definitiva somos todos desarrolladores, dará una charla sobre objetos! Mirá las reacciones que ya está provocando: http://vimeo.com/30529851

Este año se realiza una vez más la conferencia Smalltalk en Argentina, como siempre vienen expertos de todo el mundo.

El link a la conferencia es: http://www.fast.org.ar/smalltalks2011

Entre los oradores destacados se encuentran: Ian Piumarta (Viewpoints Research Institute), Kim Rose (Viewpoints Research Institute), Tudor Girba (Moose Technology), Vassili Bykov (Newspeek), John O’Keefe (IBM VisualAge), Marcus Denker (INRIA Lille-Nord Europe), Martin McClure (GemStone Systems), Dale Henrichs (GemStone Systems), James Foster (GemStone Systems), Norman Green (GemStone Systems).

Las Charlas

Análisis de un Diseño Basado en Traits sin Subclasificación - Diego Campodonico, por más info sobre TRAITS click aqui 

Customizando Pharo Smalltalk - Nicolas Paez

DBXTalk: actualización - Guillermo Polito, DBXTalk es un framework de mapeo Objetos-Base Relacional

Validación de Código Estático para Traits - Juan Sebastian Aizcorbe, por más info sobre TRAITS click aqui 

Mark and Compact Scavenger Garbage Collectior in Smalltalk - Javier Burroni

GemStone actualización y Hoja de Ruta - Norm Green

VA Smalltalk actualización del producto - John O’Keefe

GemStone/S para principiantes - Martin McClure,  más info sobre GemStone/S click aquí y aquí.

Fuel: Cluster de objetos serializados - Martin Dias

Simulated Annealing - Guillermo Amaral

Otro Traductor de Smalltalk a C/C++  - Ricardo Moran

Herramientas Web para GemStone/S (64 bits) - James Foster

Los 10 Mandamientos de TDD (test driven development) - Hernan Wilkinson

CUE es esto -  Dan Rozenfarb

Hablemos tODE - Dale Henrichs, tODE (the Object Development Environment)

Para atrapar a un ratón mejor - Ian Piumarta

Monstruos de la IT: ¿Qué ha hecho para la educación? - Kim Rose

Humane assessment with Moose - Tudor Girba

Construyendo Browsers con Glamour - Tudor Girba

Trayendo ideas BDD a Pharo Smalltalk - Nahuel Garbezza, BDD (Behaviour-driven development)

Pharo Smalltalk un año después - Marcus Denker

Investigación en RMOD - Marcus Denker

Smalltalk, C# y JavaScript - Angel J Lopez

IronSmalltalk - Todor Todorov

Construyendo tus propias imágenes (Smalltalk) con Pharo Smalltalk usando Metacello - Mariano Martinez Peck

Que aprendi enseñando Smalltalk y por que estoy tan contento con Smalltalk - Hernan Wilkinson

10 años de Diversión en Caesar System - Leandro Caniglia

GRID – Grid Reports Interactivly Designed - Carla Florencia Griggio

Visualizar la ejecución de Software para identificar anomalías - Juan Pablo Sandoval Alcocer

Los method spies o (métodos espías) son una herramienta muy útil a la hora de programar y/o analizar un sistema (son otra “joyita“ de Smalltalk).

Los métodos espías son secciones adicionales de código que se insertan de forma invisible dentro los métodos existentes. El código de los métodos espías tiene acceso total a todas las variables del método en el cual fue insertado – self, parameters, temporaries, instance variables, class variables, etc.

Un método espía puede ejecutar cualquier tipo de código válido desde un simple “self halt” hasta hacer un diagnostico complejo del código que se esta ejecutando (por ejemplo generar un reporte con determinadas características y grabarlo en disco, si estoy estudiando la performance u otro asunto).

Dentro de los métodos espías existe la pseudo variable “thisSpy” que hace referencia al método espía en si mismo, además existe otras dos pseudo variables: context y activationContext. Una es para tener acceso a todas las activaciones del spy (en ese métdo) y la otra para tener acceso a la activación en ejecución.

Los métodos espías se usando durante el proceso de desarrollo y son eliminados cuando se hace el deployment o implantación.

Algunas de las ventajas de tener métodos espías son:

* Inserción y eliminación transparente: insertar un spy en no afecta el código original del método. Puedo estudiar el método sin tener que modificarlo.

* Rápido: insertar un spy es un proceso sumamente rápido y sencillo.

* Controlable: los spies puede ser habilitados o deshabilitados de forma individual o en masa.

* Fácil de realizar Seguimiento:  simplemente con la opción Browse Method Spies obtengo todos los spies del sistema.

* Flexible: usando las pseudo variables thisSpy, context y activationContext, un spy tiene control sofisticado sobre su propia ejecución. Por ejemplo, podemos hacer que un spy se ejecute un vez sola, o X veces dependiendo del tipo de argumentos y variables de la ejecución.

Ejemplo

En la siguiente imagen se muestra el método #agregarTareaAntecesora de la clase TareaDiariaComposite, el cual tiene 2 métodos espías (uno simple y otro complejo).

Los métodos espías se insertan usando el mouse y el menu contextual, y dónde se insertó el Spy el fondo queda en color rojo.

El primer Spy es simplemente un #halt. En el segundo caso se hacen algunas operaciones más complejas.

Como se ve en el ejemplo el Spy no modifica el código/método original y además tiene acceso a elementos de la ejecución.

Conclusiones

* No uso más el famoso (self halt) para investigar métodos, ahora inserto un Spy.

* Cambia totalmente la forma en la que se realiza la depuración (debug) de los sistemas, brindando un poderosa herramienta de análisis.

* No esta limitado a un Spy por método (como en caso de los methods wrappers, notar que son cosas diferentes).

* Se hace todo dentro del entorno gráfico de Smalltalk (en este caso Dolphin Smalltalk)

Aclaración

Los  métodos espías son parecidos a los methods wrappers pero son totalmente diferentes, ya que estos últimos son para ejecutar pre y post condiciones. Si bien se parecen no son lo mismo.

Hemos publicado el código fuente del UML Almighty para la versión Dolphin Professional.

Se puede bajar aqui: http://twit.io/2Jn.

Cuando se libere la versión Dolphin Community 6.2 (próximo upgrade) publicaremos los fuentes para esta versión.

El instalador con la Aplicación de Escritorio (incluye el Web Server)  ya esta lista para bajar:
http://twit.io/2Jt.
Esta es la versión  Full de UML Almighty sin restricción alguna.

Para acceder a la Simulación Web:
user: admin
password: password

Hay dos modelos instalados en la Máquina Virtual UML, ambos puede ser removidos.

Estos modelos son ejemplos de como Simular Aplicaciones UML.

UML Almighty Open Source UML Simulation

Executable UML

The PostgreSQL Licence (TPL)

This is a template license. The body of the license starts at the end of this paragraph. To use it, say that it is The PostgreSQL License, and then substitute the copyright year and name of the copyright holder into the body of the licnese. Then put the license into a file called “LICENSE” in your software distribution. 

Copyright (c) $YEAR, $ORGANIZATION

Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.

IN NO EVENT SHALL $ORGANISATION BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF $ORGANISATION HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

$ORGANISATION SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN “AS IS” BASIS, AND $ORGANISATION HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Actualización del Sitio Web

En los próximos días estaremos actualizando la página y poniendo el nuevo instalador y el código fuente para bajar. El código fuente demorará un días más ya que debemos remover el framework de seguridad de licencias que esta en la aplicación actual.

Para poder editar el código fuente se necesita el ambiente de programación Dolphin (www.object-arts.com), la versión Community de Dolphin es gratis y viene con todo el código fuente del ambiente de programación.

Que hace UML Almighty

* Genera una aplicación Web/Desktop customizable a partir de un Diagrama de Clases (utilizando un arvhivo XMI).

* Se puede programar comportamiento, los Diagramas de Sequencia pueden ser ejecutados.

* La aplicación generada es una Simulación (con prototipo customizable) y Ejecución del diseño UML (UML ejecutable – Executable UML).

* Asegura en un 100% que el diseño ejecuta y puede ser programado sin contratiempo para los proagramdores.

Estamos viendo que licencia Open Source es la mejor para el UML Almighty, pero la cantidad de posibilidades es bastante grande y algunas licencias son extensas y en ocasiones no muy claras. Hasta ahora la licencia más cerca de lo que queremos es The PostgreSQL Licence (TPL).

Los objetivos a buscar

* Código fuente libre (para futuras versiones o aplicaciones derivadas).

* Aplicaciones o Distribuciones Derivadas que mantengan la misma licencia.

* Que no se pueda cobrar por el software en si o por extensiones.

* Que si se puedan vender servicios (SaaS – software as a service).

Público Objetivo

* Programadores, Analistas, Ingenieros de sistemas en proyectos utilizando UML.

* Empresas que utilizan UML en sus proyectos.

* Instituciones Educativas (con orientación informática) cuyos planes de estudio incluyan UML.

* Investigadores de Máquinas Virtuales y Meta Programación, etc.

Que hace

* Genera una aplicación Web/Desktop customizable a partir de un Diagrama de Clases.

* Se puede programar comportamiento por lo que los Diagramas de Sequencia pueden ser programados y ejecutados.

* La aplicación generada es una Simulación (con prototipo customizable) y Ejecución del diseño UML.

* Asegura en un 100% que el diseño ejecuta y puede ser programado sin contratiempo para los proagramdores.

En esta ocasión voy a describir la arquitectura del framework GLASS (gemstone/s – linux – apache – seaside – smalltalk) con más detalle, y luego voy hacer una comparación sencilla con Ruby on Rails.

También ver el blog de Avi Bryant (Twitter) sobre GemStone/S y Ruby on Rails: http://www.avibryant.com/2008/03/ive-had-a-numbe.html

En la comparación solamente se mostrarán las diferencias, cada uno puede sacar sus conclusiones según su conocimiento.

La siguiente imagen denota de forma detallada (pero no completa) la arquitectura de GLASS:

Network: representa la web y los diferentes clientes web que se conectan con GLASS.

Database host: es el repositorio alojado físicamente en un servidor. El repositorio se puede dividir en N extent, cada extent es un archivo en disco.

Transaction logs host: es el LOG de transacciones de GemStone/S que puede estar ubicado en otro servidor diferente del  repositorio (como en este caso).

Stoned Process: el proceso Stoned es el coordinador del repositorio y de los procesos Gem. Este proceso se encarga de guardar y recuperar objetos del repositorio en disco, asi como asegurar la concurrencia de los procesos Gem y la consistencia del repositorio. El proceso Stoned puede correr en el mismo host que los Gem o no (esto es configurable).  Los conflictos de actualización son resueltos por el proceso Stoned. Hay un Stoned por repositorio.

Gem Process: son (procesos) máquinas virtuales que le dan vida a los objetos del repositorio, ejecutan métodos de las clases, alteran objetos y crean nuevos, etc. Cada Gem actual como un repositorio único para los clientes. Los procesos Gem también pueden actualizar el repositorio si esa actualización no entra en conflicto con algún otro proceso Gem.

Shared Page Cache: son segmentos de memoria virtual del SO. Cuando los objetos son accedidos a disco entonces se van cargando en el Shared Page Cache. Si un objeto todavía no ha sido accedido entonces cuando se lee por primera vez se carga en el Shared Page Cache, luego el próximo Gem que requiera ese objeto no tiene que acceder a disco. Como se ve en la figura puede haber más de un Shared Page Cache, estos se llaman Remote Shared Page Cache. Las sincronización entre los diferentes Shared Page Cache se haceautomáticamente  y es transparente para el desarrollador. Hay procesos (que son invisibles cuando estamos desarrollando) que se encargan de copiar y mantener actualizados los diferentes Shared Page Cache.

Continuations

Esta plataforma de desarrollo soporta Continuations. Continuations da la capacidad de persistir la pila de ejecución de un proceso Gem (recordar un Gem es una máquina virtual) y guardarla en el repositorio. Luego otro proceso Gem puede acceder a esa pila de ejecución en el repositorio, cargarla en memoria y continuar con su normal . Por lo que no hay que preocuparse en identificar que proceso Gem se hizo cargo de que petición.

Debug

Si ocurre un error en nuestra aplicación web somos capaces de guardar la pila de ejecución en el repositorio, y luego acceder al servidor y como DBAs levantar la pila de ejecución y analizar el error.

Si !!! todo el contexto del error se guarda en el repositorio y vamos a poder explorar todo los objetos involucrados en ese error, y ejecutar paso a paso lo que hizo el usuario para que surgiera ese error.

Escalabilidad

GLASS soporta escalabilidad horizontal, es decir, que a cualquier problema de performance se puede agregar más servidores para albergar más procesos Gem. Como los procesos Gem son las máquinas virtuales entonces tengo más recursos para responder a las diferentes peticiones.

Sistemas Reales

Toda esta arquitectura puede correr sobre el mismo servidor o distribuido en N servidores.

JP Morgan

Hay sistemas en producción dónde cientos de máquinas (de los mismo usuarios de la intranet) albergan cientos de procesos Gem. En este caso al escalabilidad es horizontal.

London Petroleum Exchange

Un solo servidor alberga toda la aplicación, este servidor es un AIX Power 6 con 512 Gb de memoria.

Comparación con Ruby on Rails

No soy experto en Ruby on Rails solamente conozco parte de la arquitectura.

Una aplicación Ruby on Rails típica consta de: un cluster de servidores para soportar la base de datos, varios caches en memoria, varios procesos que se encargan del funcionamiento de los objetos y la renderización de páginas web.

Normalmente la base de datos es MySQL y se ubica en unos o más servidores, luego hay varios servidores que albergan los caches en memoria (memcached) (el número de servidores para MySQL es el mismo que para los memcached), y se activan entre 8 y 12 worker processes para realizar el procesamiento, llamados mongrels (incluyen el interprete Ruby y el Web Server Mongrel).

Los mongrels aceptan las peticiones web y ejecutan el código de la aplicación. Los objetos dentro de los worker processes están vivos, envían y reciben mensajes, ejecutan métodos, cambian los estados de los objetos Ruby, etc. Los objetos solamente existen en la memoria de un mongrel en particular.

Estos objetos se persisten en la base de datos usando los Active Records de Ruby. Cuando un mongrel modifica un objeto, y la transacción hace commit entonces objeto se actualiza en MySQL, y cuando algún otro proceso lo lea obtendrá la versión actualizada del objeto.  Los objetos dentro de MySQL están muertos, no hacen nada hasta que son puestos dentro del algún proceso mongrel.

Ruby on Rails y GLASS (gemstone/s linux smalltalk seaside)

MAGLEV hace posible el desarrollo de aplicaciones Ruby sobre GemStone/S, con una la arquitectura idéntica a la de Smalltalk.