IMS..una de nuestras aplicaciones

Al principio no pensábamos publicar aquí los proyectos que ejecutamos, pero por un pedido de la gente que nos lee vamos a hacerlo.

IMS es una aplicación que desarrollamos para un correo privado, una empresa de servicios postales. Esta aplicación fue construida sobre Squeak, con Seaside y Glorp como ORM. La base de datos es un PostgreSQL. Antes de continuar quería aclarar que estamos usando base de datos a pedido del cliente, además esta base después alimenta otros sistemas y un cubo OLAP.

Es por lo antes dicho que elegimos hacer la persistencia sobre una base de datos, y no sobre la misma imagen o sobre un magma. (La verdad que se nos paso por la cabeza GEMSTONE, pero la billetera aprieta y el cliente no nos miro con buena cara cuando hablamos de esa inversión. )
Esta aplicación es una aplicación de gestión como cualquier ERP, pero enfocada al negocio del correo postal.
Aparte de la aplicación web desarrollamos un panel de control en Morphic, para que un administrador pueda ver el estado de la aplicación y pueda realizar algunas operaciones basicas. El know how que hay en el cliente es casí nulo, así que debimos dejarle todo cocinado y al alcance la mano, "APB" como se dice en Argentina.
Usamos Scriptaculous para facilitar la interacción con el usuarios. (drap & drop, ligthboxes, etc.), además de hacer el entorno mas agradable al usuarios.(por los efectos...)
Aunque en muchos casos tuvimos que hacer mix, entre Javascript y Smalltalk, el resultados es satisfactorio.
De estas necesidades de mix uno de nuestro socios, nuestro TVP, se le ocurrió que sería bueno desarrollar una librería de componente WEB con SWT y ST2JS, cosa que ya propuso a la comunidad de Seaside. Aunque la versión actual no tiene estos componentes, esta nueva idea abrirá muchas posibilidades y por eso no quería dejar e mensionarla. Sobre este tema seguramente mi socio escribirá un post en la medida de lo posible.
IMS maneja un volumen mensual de aproximado de quinientas mil (500.000) piezas y es utilizado por casi todo el personal de nuestro cliente, que son 600 personas.
Nuestro cliente tiene 5 sucursales, las cuales operan vía VPN sobre un único servidor que se encuentra hosteado en sus oficinas centrales. Este servidor es un windows 2003 (personalmente hubiera puesto otra cosa, pero es lo que hay.), El hardware es un Dell chiquito, (PowerEdge^TM 840) que cuesta al rededor de U$S 1000.
Esto muchos no lo dicen pero, el hecho que squeak y seaside utilicen muchisimos menos recursos que su competencia del mainstream, termina redundando en que hay que hace una menor inversión en hardware.
La aplicación mantendrá un historia del 5 años para todas las operaciones sobre las piezas que se entreguen.
La verdad que hasta el momento, estamos muy contentos con la respuesta que esta teniendo el sistema.
El cliente, que al principio, no con mucha confianza, nos acepto que hiciéramos el sistema en esta tecnología, a pesar todos los mitos que hay dando vuelta al redodor de Smalltalk, esta mas que satisfecho.
Por ultimo y para terminar quería remarcar que gracias a que esta aplicación este construida en smalltalk, ya con 2 meses en producción, termino siendo una diferencial de negocio importante, porque pudimos adaptar su aplicación a nuevas funcionalidades , en tiempo record.

Tips #2: La performance se encuentra buscando la raiz de las cosas

Hoy estaba desarrollando y me encontré con una verdad que termina siendo un tip.
Algo que amo de Smalltalk y especialmente de Squeak es que se puede acceder directamente hasta el core de las cosas.
En la búsqueda que nace de nuestra curiosidad natural de seres humanos, se llega al conocimiento de la implementación de cada cosa.
De esta manera pude mejora la performace de mi desarrollo.

tenía en mi código algo parecido a:

|temp|
temp:=aCollection collect[:aObject | aObject doSomeThing ]
^temp size

resulta que la implementación de size, es un contador que suma 1 por cada elemento de la colección.

|tally|
tally := 0.
self do: [:each | tally := tally + 1].
^tally

En una aplicación que no maneja muchos registros, esto sería una cosa trivial, pero en mi aplicación que maneja cientos de miles de registros (una aplicación de servicio postal) cambiar el código anterior por el siguiente, significo una diferencia como la que existe entre el día y la noche , porque recorro una sola vez la colección.

^aCollection
inject: 0 into: [:cuenta :aObject |
aObject doSomeThing.
cuenta:= cuenta + 1 ]

Esto solo fue posible, por lo menos para mi, por tener la posibilidad de ver la implementación de cada uno los elementos (Collection en este caso particular.)que componen la plataforma. Cosas que otros ambiente del mainstream no pasa y estas atado a "prueba y error" o búsquedas interminables (googlear todo el día).

Aunque suene redundante, Amo este ambiente y cada día entiendo menos porque no es adoptado como tecnología principal por mas gente.


PD: Aquellos que tiene miedo a la performance de Squeak, les cuento que esta aplicación comenzó desarrollándose en dot.net con nhibernate y postgreSql como DB. Después de pasado un mes de desarrollo decidí tirar todo y desarrollarla en Squeak , con Seaside y Glorp como ORM. Esto me dio la oportunidad de comparar la performance en una aplicación real y no benchmarks de laboratorio (dado que ya tenía desarrollado un modulo en .net ) con el mismo modelo y el mismo soporte de persistencia (la DB), comparativamente hay una mejora de performance del 30% a favor de Squeak. Se pueden sacar muchas conclusiones y buscar la raíz de esta mejora en distintas partes de la plataforma, pero lo concluyente y la principal diferencia que termina afectando la perfomance es la cultura de la gente que esta detrás de cada entorno. Ya sea por su gente o por las prueba empíricas, puedo afirmar que Squeak esta listo para competir de par a par con cualquier plataforma comercial del mainstream y salir victorioso con mejora sustanciales. Por lo cual no tema y tirense a la pileta que hay agua.