EDITED:
I forgot to mention, thath, I’m not the creator of UIThemeXP. The creators name is Steve Wirts, and the announcement of this package can be found on Pharo Maillist

Para entenderme mejor, quizás, habría que aclarar, que toda mi vida he desarrollado aplicaciones en Delphi, y todas ellas eran aplicaciones de Gestión, Control de presencia, etc…. Como bien dice mi querido colega, y siempre referenciado amigo Notxor, por las facilidades que Delphi ofrece, puede hacer que cojas malos hábitos, como el no separar la capa de la Vista con la del modelo. De hecho, una frase (citada a mi manera) que me gustó que dijo fué: “Qué hace Delphi en cuanto creas un nuevo proyecto? Plantarte un formulario delante del morro”.

Siempre que he querido estudiar/ojear un nuevo lenguaje, qué es de lo primero que he hecho? buscar un GUI builder. Y es que, estoy obsesionado con el GUI, y aquí, podríamos encontrar mi primer problema con Squeak. La interfaz de Squeak, es perfecta para etoys y aplicaciones educativas, e incluso para entornos en desarrollo, pero, como decía en otra entrada, si a un cliente le presento una aplicación de control de producción, que parece desarrollada con Playdo, me tira el proyecto a la cabeza, y no vale, digamos, la escusa de la mejora en la productividad, o la robustez de la plataforma. Porque para el cliente, sigue siendo plastilina, y él, es quien paga.

Y no, la solución no es usar Seaside, o Aida o SWT para dotar a la aplicación de una interfaz web. Web es para Web, escritorio, es para escritorio. La masificación de Internet nos ha dado muy malos hábitos. Ahora parece que todo debe funcionar a través de internet. Existe la alternativa de wxSqueak, que son bindings para wxWidgets, pero es un proyecto en fase Beta, que creo no avanza demasiado rápido. Está Polymorph, pero sólo son unos pequeños decorados, que si bien lo arreglan, tampoco del todo. También existe la alternativa, que andaba ojeando hace no mucho, que era usar una interfaz xul, pero el framework existente está ligado totalmente a Seaside.

Qué quiero decir con ésto? Nada. Simplemente quería desahogarme. Me encanta Squeak. Un “entorno” que funciona en Windows, Linux, MacOS, Windows Mobile, y unas cuantas plataformas más. Me proporciona portabilidad (abro la imágen con la VM de otro sistema operativo, y todo continúa donde estaba, magia? no, las cosas bien hechas), una comunidad con bastante movimiento, persistencia intrínseca en la imágen o bases de datos orientadas a objetos integradas, un lenguaje (Smalltalk) totalmente de objetos con un “IDE” muy poderoso y con acceso a poder modificar cualquier parte del sistema a placer (pero no tengo conocimientos para hacer los cambios que quiero en el GUI), y cuál es el problema, no me gusta el GUI. Comprenden mi frustración?

Puede que dentro de poco Squeak cambie, o puede que no cambie nunca, o puede que avancen los bindings para widgets nativos, o algún framework para enlazar con XUL o algo similar, pero mientras, sólo puedo “aguantarme, y joderme”

P.D.: Aunque luego aparezcan widgets nativos, seguiré quejándome porque fijo, habrá que crear toda la interfaz a base de picar código :D

Principalmente, me dedico al desarrollo de software de gestión. Para este tipo de proyectos, C, lo veo matar moscas a cañonazos. C podrá ser rápido, con ejecutables pequeños, y un sin fin de bondados que los puristas querrán venderme etc..etc… pero, siendo realistas, para software de gestión, CRUD, ABM, o como quieras llamarlo, es una soberana tontería hacerlo en un lenguaje como C/C++, (a no ser, que sepas bastante C, lo hagas por aprender, o simplemente, es que no conoces otra cosa) existiendo alternativas de alto nivel que te ahorran muchos quebraderos de cabeza.

Como bien decía en uno de los comentarios mi amigo Notxor, no nombré a Java. Java, cumple bastantes por no decir casi todos de los requisitos anteriormente mencionados. Es un lenguaje con el que tengo una relación Amor/Odio. Básicamente, siempre he querido ponerme a hacer cositas en él, pero, por A o por B, siempre he acabado apartándolo de mi vista. Me compré un libro de Java2 hará unos años, que apenas he comenzado a leerlo. Además, al igual que Notxor, siempre me gusta ser el “rarito” que usa ese lenguaje que la gente apenas conoce :)

Muchas veces, me he preguntado - ¿Si no fuese tan cabezón, y usase lenguajes más conocidos, no me ahorraría problemas? -. Por eso, últimamente andaba haciéndole ojitos a Mono. La verdad es que no me desagrada demasiado la idea de ponerme a programar (de nuevo) en “.NET” (con todas esas ventajas que muchos creen han llegado del cielo de la mano de Dios, y llevan existiendo en Delphi eónes, pero eso es otra historia), pero, siempre que pienso en Mono, y comienzo a descargar la plataforma, IDEs etc.. me viene a la cabeza Lazarus/FreePascal, y a la par, no me quito de la cabeza Smalltalk.

Parte de la culpa la tiene Squeak. La verdad es que me gusta mucho la filosofía Smalltalk, su sintaxis, pero, en cambio, odio que todo vaya integrado en una ventana, y por mucho que la gente intente hacer pensar lo contrario,su Look&Feel, lo hacen parecer un juguete.

Que no se me malinterprete, soy un enamorado de Smalltalk, y precisamente, no duro más de 2 días en un lenguaje distinto por eso mismo, pero, a un cliente, no le puedo presentar una aplicación, donde las ventanas parecen hechas de plastilina, y aunque PolyMorph arregla algo, no es una solución final factible.

Sólo hay un lenguaje que me tuvo un pelín más enganchado, (y que seguramente intente retomar para ver la velocidad de la nueva VM), y es Ruby. Quizás por la fuerte influencia de Smalltalk en él. En su momento, lo aparté debido a problemas que tenía para cargar la librería Fox para el GUI, en mi MAC no había narices que funcionase, puede que le eche un vistazo de nuevo.

Volviendo a Smalltalk, es verdad que existen alternativas con widgets nativos para la interfaz. Pero…
cuál de ellas funciona en Win, Mac y OSX? VisualWorks y Squeak.
Apliquemos otro filtro, cuál de ellos me puedo permitir? Squeak

Resumiendo, da igual si Mono, Java, Lazarus/FreePascal, Ruby o lo que exista o lo nuevo que venga…..al final, seguro que acabo programando en smalltalk/Squeak, que es lo único, que sin hacer nada, me funciona en todos los sistemas operativos sin quejas :P

El trabajo me tiene desbordado, y el poco (casi ninguno) tiempo que he tenido, lo he dedicado a los míos y al poker.

Ahora mismo ando ojeando Seaside para poder tener un punto de vista a lo que había estado “estudiando” hasta ahora, Aida/Web, y la verdad es que no me desagrada, pero, por lo poco que he podido ver hasta ahora, sigo opinando que Aida, a simple vista al menos, es más sencillo. Puesto he usado poco estos dos frameworks, no puedo dar una opinón más profunda, por lo que, esperaré a poder ojear más a fondo los dos.

Uno de los tantos proyectos que me gustaría probar, es, ver cuál de los dos es más fácil de conectar con interfaces XUL, así como probar también algo que me tiene desde hace tiempo con la mosca tras la oreja, OpenLaszlo.

Me gustaría encontrar algo, web, que no sea web. ¿Por qué? sencillo. No me gusta la web, pero, a día de hoy, no sólo es lo que se lleva, si no que además, Squeak, tiene un Look&Feel y unas carencias a nivel de usuario que no me convencen para usarlas en producción, por lo que, ando buscando alternativas a nivel Web……..que no sean web.

Ya iré comentando como van todos estos temas.

Actualmente, voy a afrontar, quizás, mi proyecto más importante (del que ya hablaré en otro momento) hasta la fecha, y he tomado la decisión de afrontarlo con el lenguaje (si me oyesen los puristas) que me tiene enamorado en los últimos años. Por ello, he tenido que embarcarme (aunque quizás pronto), en la búsqueda de la persistencia. Por ello, por si a alguien le parece interesante, y quiere ahorrarse trabajo, procuraré explicar por aquí algo sober mis lecturas y pruebas.

Desde Squeak, podemos persistir los datos de muchas maneras distintas, una de ellas (y la más básica de todas), es grabar la imágen. De manera totalmente nativa, y aprovechando el concepto de “imágen” de los sistemas smalltalk, tenemos una forma de poder grabar datos. Evaluando algo tan sencillo como:

Smalltalk snapshot: true andQuit: false.

Y se acabó, ya tenemos todos los objetos grabados, sin el uso de XML, librerías externas, frameworks, ni nada de nada. Pero, obviamente, este sistema, tiene muchas desventajas. Una de ellas, y de las más importantes, no es ACID. Si bien es cierto, que muchas veces, nosotros mismos nos calentamos demasiado la cabeza, en un sistema en producción no podemos permitirnos el lujo de tener errores.

Por ello, lo ideal es recurrir a bases de datos. Digamos que en BBDD podemos distinguir de manera muy superficial, entre Bases de Datos Relacionales (RDBMS), o Bases de Datos Orientadas a Objetos (OODB).

Las RDBMS (Bases de Datos Relacionales), como MySql, PostgreSQL etc.. son las BBDD que todo el mundo conoce con sus tablas, su filas, sus campos, etc… mientras que las bases de datos orientadas a objetos digamos que guardan los objetos en sí. Obviamente, como programadores Smalltalk que somos, y citando a “Programadores matando un dragón”…

Smalltalk - Llega, analiza al dragón y a la princesa, se da la vuelta y se vá: ellos son muy inferiores

… no vamos a rebajarnos a usar SQL ( :P ), si no lo que queremos, es trabajar directamente con nuestros objetos, por lo que necesitamos un framework de mapeo objeto relacional (ORM).

Por ello, aquí, os muestro una lista de distintas opciones que he ido recolectando y que quiero ojear. Poco a poco detallaré. Algunos paquetes, son multidialecto (como el caso de GLORP), pero sólo me centraré en los casos de Squeak, así, como no comentaré el acceso directo a las BBDD sin pasar por ORM.

• GOODS: OODB desarrollada en C.
• Omnibase: OODB desarrollada en Smalltalk
• Magma: OODB desarrollada en Squeak
• GLORP+SqueakDBX
• GLORP+PostgreSQL
• Gemstone: (Siempre y cuando funcione en arquitectura 32bits)
• Cassandra?

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.

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.

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…..

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.

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 )