Spoon, según la definición que dá Craig Latta en su web (ya que no he encontrado nada en el Swiki oficial),

“Spoon, es un sistema de programación mínimo de Objetos, con nuevos enfoques a la organización, colaboración y despliegue”.

Supongo, pues todavía no han dado muchas más noticias, éste sistema, junto a los DeltaStreams, o ChangeSets, o Installer scripts, o/y mezcla de todos y demás parafernalias, nos montaríamos, partiendo de una imágen mínima, nuestro entorno.

A ver que se va cociendo en los próximos días.

ShareThis

Es una pequeña entrada interesante de leer, donde como conclusión, y de acuerdo con él, podríamos decir que éste, es el año de Smalltalk, el año de reinventar el futuro.

No dejéis de echarle una ojeada.

ShareThis

Vueltas y más vueltas, cuando la solución, la tenía ahí delante, Squeak mismo me la proporciona.

Para poner en antecedentes a aquellos que se incorporen recientemente al blog, desde hace bastante tiempo, llevo buscando un plugin que me permitiese mostrar código coloreado en el blog, y por supuesto, indentado. Probé distintos plugins, como WP-CodeBox, CodeColorer, y demás, pero, o no me hacían el retorno de carro, o mostraban bloques sin sentido donde se veía de todo menos el código.

Hoy, retomando InciGest para ver por donde lo dejé (ya que tuve un pequeño problema estúpido y no me dejaba grabar el paquete con monticello, y he preferido no seguir modificando), me he dado cuenta de una opción que nos ofrece el menú contextual de Squeak. Se llama Copy HTML.

Es decir, que los trozos de código que veo, los puedo copiar directamente como HTML, y pegarlos aquí al tuntun, y me hace un pegado perfecto (además del coloreado).

Por ejemplo, el método que muestra las compañías en InciGest:
IncigestApp>>viewMain
viewMain
    | e |
    e := WebElement new.
    e addTextH1: ‘Company data ‘ , self observee companyName.
    e add: self hierarchyLinks.
    e addBreak.
    e addBreak.
    e table class: #webGrid.
    e cell addText: ‘C.I.F.: ‘.
    e newCell addTextBold: self observee cif.
    e newRow.
    e cell addText: ‘Address: ‘.
    e newCell addTextBold: self observee address.
    e newRow.
    e cell addText: ‘City: ‘.
    e newCell addTextBold: self observee city.
    self add: e

Si bien no es la manera más elegante, funciona! y a la perfección.

Ahora sólo queda tomar aire, y re-pegar todo el código (al menos el del tutorial de Aida), con este nuevo sistema.

Madre mía, anda que no le he dado vueltas….y lo tenía ahí delante…..

ShareThis

Es una pequeña web, sencilla, y con 4 cosillas de momento, pero gracias a las facilidades que nos ofrece Smalltalk, podríamos ampliarlo fácilmente.

De momento, para los curiosos, quiero compartir como está diseñada. No entraremos en sí el modelo es bueno o malo, es algo que estoy haciendo para aprender el framework Aida/Web a la par de Smalltalk, y me estoy basando sobre todo en el tutorial que ya traduje, y que que podéis mirar aquí.

Poniendo en antecedentes
La función de la aplicación, es, que los técnicos registren las incidencias que se realizan a los clientes de la empresa. Actualmente, el modelo está pensado con idea que distintas empresas compartan la misma aplicación, pero no olvidar, que es una simple web que se ha hecho con métodos didácticos.

Comenzando
El proyecto lo he dividido en 3 categorías.
InciGest-Aida: Contiene los objetos “Aida” para su representación web.
InciGest-Core: Contiene el modelo principal del sistema.
InciGest-Test: Contiene los test de los objetos.

:InciGest-Core:
IGObjeto: Ésta, es una clase abstracta, hereda directamente de Object, y su función, es servir como capa entre Object y todos los objetos de la aplicación, por si se necesitase añadir algo común a todos.

InciGest: Es el manejador de la aplicación. Es un singleton, y es el encargado de realizar las tareas principales del sistema.

IGEmpresa: Las instancias de esta clase, representan cada una de las empresas dadas de alta en sistema.

De momento existen más objetos, pero iré diciéndolos según avancemos en el proyecto, y vayamos usándolos. Mañana, como funcionan los objetos internamente y como vincularlos con el framework web Aida.

ShareThis

Intentaré explicar un poco mejor lo que ya dije.

GNU Smalltalk, es una implementación de Smalltalk concebida para funcionar en modo scripting.

Cuando ejecutamos ‘gst’, carga en memoria una imágen base sobre la que trabajar con los Objetos básicos para poder comenzar a hacer algo, y nos ofrece una shell interactiva, como la que puede ofrecernos Python, o Ruby, etc….

A partir de aquí, podemos, desde esta shell, crear nuevas clases, instanciarlas etc.. Digamos, que sería un workspace en linea de comandos y sin nada más.

Ahora, que esté concebido como scripting, no implica que sólo funcione así. Este concepto se escapa un poco de la filosofía Smalltalk, ya que éste es más que sólo un lenguaje de programación. Una de las cosas más importantes de Smalltalk, es su entorno. En el mundo smalltalk, entendemos como entorno, un “mundo” donde los objetos conviven y se envían mensajes los unos a los otros. Este “mundo”, también es un objeto, como todo en Smalltalk.

En el caso de Squeak, cuando lo iniciamos, éste, levanta todo el sistema de Objetos, incluido su sistema visual. Desde ese entorno, es desde donde accedemos a las poderosas herramientas que Smalltalk nos provee, como los distintos Browsers para poder navegar por los objetos del sistema, los inspectores, el catálogo online de paquetes Squeakmap o Universes, el poderoso depurador integrado, la interfaz para SUnit, y un largo etcétera que hace el desarrollo de Smalltalk, distinto a todo lo demás.

¿Pero entonces, en qué se distingue GST de Squeak?
Como ya he dicho, la concepción de GST, fué proveer de un smalltalk de scripting. Un smalltalk al que le pasamos código incrustado en un archivo, y éste lo evalúa como pueda hacer Python, pero realmente, no hace las cosas muy distintas a como las hace Squeak.

En Squeak, cuando abrimos la imágen, en ésta, ya está por defecto todas las herramientas “visuales” a nuestro alcance, puesto como ya he dicho, sin ellas, Smalltalk no es más que un simple lenguaje de programación y no tiene nada especial. En GST, la imágen base, sólo levanta los objetos básicos y el sistema que permite que puedan enviarse mensajes los unos a los otros, y no levanta por defecto ningún subsistema visual, ya que éste, es un paquete aparte. En cambio, con un script, podríamos cargar Blox (la parte visual de GST), Swazzo, Seaside y dependencias, y grabar ese estado de la memoria en un archivo de imágen, para que al volver a ejecutar, todo estuviese cargado de igual manera que hace Squeak.

De hecho, el script Browser.st, lo único que hace es lo siguiente.

Siento que el código no esté indentado ni coloreado, pero estoy teniendo problemas con el plugin de wordpress que hace ésto

(Smalltalk includesKey: #BLOX) ifFalse: [
PackageLoader fileInPackage: 'Browser'.
ObjectMemory snapshot
]!

(Smalltalk includesKey: #BLOX)
ifFalse: [
stdout nextPutAll: 'BLOX not loaded, is Tcl/Tk installed?'; nl
]
ifTrue: [
stdout nextPutAll: 'Starting window environment...'; nl.
BLOX.BLOXBrowser.BrowserMain new initialize
]!

ObjectMemory quit!

Si miráis las primeras líneas, comprueba si Blox ya está cargado, y si no, carga el paquete Browser para que levante el sistema, y lo graba como imágen. Si ya existe, entonces carga el Browser principal. Es decir, la parte visual de GST existe, y si ésto lo grabásemos no habría diferencia con Squeak (menuda herejía acabo de soltar), salvo la más importante de todas.

Repidiéndome hasta la saciedad, lo más importante de un sistema Smalltalk es su entorno. Y el problema de GST, es que su entorno está muy muy verde. Apenas contiene un par de Browsers, éstos no funcionan al 100% como deberían, y encima en TCL/TK. Faltan muchas herramientas como interfaz para SUnit, o más importante aún, como dice mi querido amigo Notxor, mejorar el debugger, que es una de las herramientas más importantes en Smalltalk. Ésto obliga a que practicamente, tengas que desarrollar apoyado en un simple editor de texto (y los que conozcan smalltalk, por muy potente que sea un editor, saben porqué digo “simple”), y trabajar “a pelo”, y de ésta manera, pierdes toda la potencia que Smalltalk puede ofrecer, pero Roma, no se construyó en un día.

Si es cierto que como dije, existen muchos paquetes de acceso a Datos, para trabajar a través de la red, está portado el servidor web Swazzo y el framework web Seaside, pero repito, volviendo a lo dicho, sin las herramientas básicas “smalltalkrianas”, todo ésto, en mi humilde opinión, no sirve para nada.

No quiero decir con ésto que GST no sirva para nada, todo lo contrario. De los pocos días que llevo mirando GST, basta que se terminase y mejorase un poco el Browser, para que ya se pudiese trabajar directamente sobre él sin depender de un editor, y a partir de ahí, hacer y mejorar todo lo demás, sería “coser y cantar”. Pero se necesita ayuda (ya dije ésto antes no? :D )

Paolo, además, comentó que se podría portar Morphic sobre SDL para usarlo como base en la parte visual de GST, pero como ya comenté en mi anterior entrada, para esto, hace falta gente que colabore en el proyecto (esto también lo dije no? :D )

ShareThis

Existen distintas variedades de Smalltalk, pasando por implementaciones comerciales, gratuitas, y/u OpenSource. Yo hablaré de las opciones OpenSource, ya que las comerciales o gratuitas como VisualWorks, VisualSmalltalk, Smalltalk/X etc.. O no corren fuera de Windows y/o Linux, o sus licencias se escapan a mi presupuesto, o las dos cosas etc… Pero éso, no significa que no sean verdaderos monstruos del desarrollo, usados en la actualidad en Bancos, empresas de servicios financieros, y la lista podría continuar.

Bajo OpenSource, podríamos decir que tenemos tres opciones principales (ya que las demás, parece no estar demasiado activas ahora mismo.

• Squeak: Del que siempre he hablado y el que hizo que me enamorara de Smalltalk.
• GNU Smalltalk: Una opción con un futuro prometedor
• SYX: La implementación que se está desarrollando Luca Bruno, creador de SqueakGTK

Actualmente, Squeak, es estable, y usado en varios proyectos comerciales de gran envergadura. Es el que siempre he seguido y sigo más de cerca.

SYX, es en lo que anda trabajando Luca Bruno. Un smalltalk con soporte nativo para GTK, y que ya se ejecuta en plataformas como Windows Mobile.

GNU Smalltalk (GST a partir de ahora), actualmente mantenido por Paolo Bonzini, es del que hablaré en esta entrada.

Si no ves el logotipo, es porque tu navegador no lee archivos SVG.

La razón por la que GST ha atraido mi atención estos días, no la sé explicar. Quizás es por estar a medias, y sentirme útil. O quizás porque llevo 3 años ojeando Squeak, pero por falta de tiempo no hacer nada en él. Necesito algo nuevo. Aire fresco, y siempre me han atraido los proyectos raros.

Hasta ahora siempre había ojeado Squeak, ya que es quizás, la única implementación opensource estable (al menos que yo conozca) que funciona en los “tres grandes” (Windows, Linux y MacOS). Además, una de las principales ventajas de Smalltalk, es el concepto de imágen o entorno, como queráis llamarlo, donde todos los objetos conviven en memoria y las utilidades (Browsers, inspectores de código etc..), se encuentran a mano a golpe de click y que al grabar,y volver abrir, todo sigue igual, con todos los objetos corriendo como si hubiésemos hecho una foto.

En cambio, la filosofía de GST es funcionar principalmente como lenguaje de scripting, algo, que en principio, no tiene sentido en Smalltalk, ya que éste, más que un lenguaje de programación, hay que verlo como una plataforma con su entorno y demás donde desarrollar.

El tema, es que GST, también entiende el concepto de imágen. Podemos arrancarlo, cargar algunos paquetes, y hacer una “foto” de esos objetos en un archivo de imágen, que posteriormente podemos cargar. Sólamente, que hay ciertas utilidades que o están incompletas, o no existen todavía, como por ejemplo, una Interfaz para SUnit, o un Depurador y Browsers mejorados.

Por defecto, GST levanta un sistema con los objetos mínimos para que funcione, Object, Collections etc.. A partir de ahí, podemos cargar los objetos que necesitamos y luego guardar ese estado de memoria.

Seaside y Swazzo por ejemplo, ya funcionan sobre GST, y hay librerías de acceso para PostgreSQL, MySQL, SQLITE, bindings para OpenGL, Cairo, etc…

No es que GST sea mejor, o con mejores perspectivas que Squeak, ni mucho menos, GST, es simplemente una alternativa para aquellos, que quieren aprovecharse de la Orientación a Objetos de Smalltalk, sin tener que lidiar por narices con la imágen. O simplemente gente que quiere aprender a desarrollar máquinas virtuales o colaborar creando un entorno para GST. O quiera crear aplicaciones obre TCL/TK sin morir en el intento

Obviamente, en comparación con Squeak por ejemplo, le falta mucho camino. Squeak tiene una extensa librería de objetos y paquetes. Mientras que GST sólo tiene portados algunos, y le falta un depurador en condiciones, una interfaz para SUnit, un catálogo online estilo Universes o SqueakMap, y mucho trabajo por hacer. Aunque igualmente , existe una aplicación para portar código smalltalk a GST.

Que perfiles harían falta? Yo diría que por un lado, se necesita gente con experiencia en C que ayude a Paolo con la parte de la VM, mejorándola, creando código más portable, etc… Gente con experiencia en Smalltalk para ayudar a ampliar los paquetes disponibles y crear nuevas utilidades gráficas, y gente, con o sin experiencia para colaborar probando, reportando errores, traduciendo etc.. En definitiva, gente con ganas de colaborar en un proyecto interesante..sea usándolo o desarrollando desde sus entrañas la VM. Aunque no tengas experiencia, aprendiendo y sobre la marcha puedes colaborar de mil maneras.

Nos vemos por IRC (freenode.net) en #gnu-smalltalk, o en la lista de correo Help-Smalltalk

ShareThis