Caminando con Pier - Introducción

Esta semana estuve ocupado armando el nuevo sitio de Smallworks (si, próximamente nos mudaremos a un sitio completo de esta “empresita”, en la cual habrá blogs propios).
Como parte de este trabajo (en realidad, como única parte realmente ardua de él), tuve que aprender Pier.

¿Que es Pier?
Es un Content Management System (CMS) hecho sobre Seaside, que corre en Squeak (hay ports para VisualWorks y GemStone, también). Pier tiene todos los elementos que requiere un CMS (facilidad de extensión y estilización y customización); tiene además algunos agregados que muchos otros no tienen: la orientación a componentes extensibles y una buena cantidad de componentes ya disponibles; finalmente, tiene algunas características con las que no cuenta ningún otro CMS: la posibilidad de “embeber” componentes en una página e inclusive incluir como componentes otras aplicaciones Seaside completas, transformándose así en una suerte de portal.
Toda esta maravillosa potencialidad viene con su costo: Si bien es increíblemente sencillo de usar, esto es así sólo después de dar un paso, hacer un pequeño “click” y entender el funcionamiento... al menos, eso me pasó a mí, quizás porque nunca antes había lidiado con un CMS... y como muchas de las cosas del mundo Squeak, Pier esta bastante pobremente documentado, lo cual es un problema, porque es realmente una herramienta muy poderosa.
En fin, como parte del trabajo de hacer andar nuestro sitio, escribí un pequeño “paso a paso” con todo lo que yo necesité hacer para tener la página andando bien. Sólo que es un poco largo para poner como un solo post... así que lo voy a partir en distintos posts, que insertaré en estos días.

Por cierto, en estos momentos hay una linda competencia en el mundo squeak para ver cual de los dos principales CMSs -Seaside/Pier o Aida/Scribo- utilizar para la página web. Por supuesto yo voto por Pier, pero sé que hay quienes leen este blog y prefieren Aida. De cualquier manera, eso esta aún lejos de ser definido... y no creo que a nadie le importe mucho mi opinión a la hora de decidirlo ;)

Whiteboard, parte 2

Continúo con la historia de whiteboard .

En el último post conté cómo llegamos a la decisión de compartir los posts utilizando los mismos tags para esto.

Bien, Otra cosa que queríamos tener era la posibilidad de crear grupos de usuarios para compartir los posts destinados siempre al mismo grupo. Para esto lo que definimos fue que al taguear un post con un label que coincida con el título de otro post, este heredaría los permisos de aquel post. De esta manera armar un grupo sería tan sencillo como crear un nuevo post, ponerle un título representativo y agregarle los usuarios al mismo. Luego, cualquier posts que hiciera referencia a este sería visto por todos los usuarios referenciados.

Suena un tanto confuso. Mejor lo explico con un ejemplo.

Quiero generar una serie de posts que van a servir para discutir temas relacionados a whiteboard, así que creo un post titulado "Grupo whiteboard", a ese post lo tagueo con los siguientes tags: estebanlm@smallworks.com.ar diogenes.moreira@smallworks.com.ar juanjoe@smallworks.com.ar

Este nuevo post es agregado en las respectivas vistas de cada uno de estos tres usuarios y cualquiera de ellos podría modificarlo e inclusive borrar su nombre de la lista de tags, con lo que automáticamente dejaría de ver el post.

Ahora agrego un nuevo post con algún comentario referente a whiteboar y quiero que mis compañeros lo vean. Esto lo logro agregando el tag "grupo whiteboard"

Dado que el usuario no es más que un tag, también puedo agrupar tags de la misma manera. Esto nos da una posibilidad de agrupar los posts en carpetas, solo que cada post pertenece a n carpetas y cada carpeta tiene n parents, con lo que las posibilidades de organización son muy grandes.

Bueno, espero que se haya entendido, otro día sigo

¿El año de Smalltalk?

Este es un "meta-post", un post que habla de otro post: leí este artículo publicado por Randal Schwartz en el que afirma que "este tiene que ser el año de Smalltalk" y menciona algunos puntos que creo que son interesantes: 

"If there is any year for Smalltalk to regain a commercial visibility, this will be it. I mean, look at all the things coming together:

• the OLPC XO is putting Smalltalk into the hands of thousands of young kids
• Cincom and Gemstone are stepping up to support Seaside in a big way
• Gemstone is offering the single-instance free commercial license and GLASS quickstart appliance
• Squeak's license is finally getting cleaned up
• Seaside is reaching a nice level of maturity
• Seaside running on GNU Smalltalk for those that want a command-line environment
• Croquet is maturing, even being adopted as a commercial "virtual meeting" space
• Ruby on Rails has reestablished dynamic languages as useful for the web"

Como saber si te estas conviertiendo en un lider?, simple, lee este post

Si un psicólogo lee este post seguramente va a decir que estoy buscando justificar la "Locura" o "Utopía" que puede parecer Smallworks. Y tiene razón, pero quería compartir con todos los que nos leen algunas de las cosas que "Nos" diferencian a los lideres.

Se que si estas leyendo este post seguramente hay mucho de estas cualidades en forma de potencial dentro tuyo, solo tienes que dar ese paso que hace la diferencia.

Cualidades de un Líder

Un líder es motivado por la mejora, el cambio. No hay nada mas deprimente para un líder estar en ambiente en el que no exista la posibilidad de cambio. Esto lo mata. Si estas en esta situación y te sentís que se te va la vida.... ya tienes la primera cualidad de un líder.

Un líder esta motivado, tiene miedo al cambio como cualquier, pero tiene el valor de enfrentarlo... la necesidad del cambio es mayor que el miedo y las estructuras en las que vive. Esta necesidad lo lleva a ir mas allá de lo que nunca llego. Un líder digno de seguir es aquel que te guía a lugares donde nunca llegaste... y el tampoco. Un líder no espera a controlar su miedo, viaja con él

Un líder no es una persona que tiene una capacidad especial para ver las oportunidad o la inteligencia para pensar mejor las cosas, es una persona que tiene las mismas cualidades intelectuales y cognitivas que vos, solo que tiene el valor de arriesgar lo necesario en pos de la promesa de un cambio.

Un líder es precavido, y ahora me voy a para un poco, porque es común encontrar muchas malas interpretaciones sobre este punto. El líder se preocupa por las personas que lo siguen y los efectos de sus acciones, pero no deja que esto lo frene. Hay muchos que esconden el miedo en la "precaución". Por eso algunas diferencias entre precaución y miedo. (según Andy Stanley).

• La precaución es cerebral, el miedo es emocional.
• La precaución tiene origen en la información, el miedo tiene origen en la imaginación.
• El precavido calcula riesgos, el temeroso evita los riesgos.
• La precaución tiene como objetivo el éxito, el temor tiene como objetivo no fracasar.
• La precaución esta enfocada en el progreso, el temor estar enfocado en la protección de lo actual.

Si un líder no es precavido, esta muy cerca de recibirse de idiota y deja de ser líder.

Como lideres nunca sabemos los reales efectos de nuestras acciones, dado que nuestras acciones y sus resultados empujan a muchos otros a seguir el mismo camino, destrozando las antiguas estructuras y preconceptos.

Por ejemplo en Smallworks creemos fervientemente en un nuevo modelo de negocio del software, además que la calidad y la pasión de las cosas que nos gustan pueden coexistir. Realmente no sabemos si nuestros aportes a la comunidad en materia de administración y/o desarrollo de software (espacialmente en la comunidad squeak) van a generar algún cambio, pero en estos humildes comienzos, nuestra experiencia esta motivando a nuestros amigos (algunos informáticos y otros no.) a seguir sus sueños.

No se si a Amazon se le ocurrió vender libros por internet... pero ellos fuero los que tuvieron el valor de comenzar algo nuevo.

Google no invento los buscadores, pero ellos fueron los que tuvieron el valor de convertir su buscador en el mejor y a raíz de esto el mercado informático ya no es el mismo.

Y por ultimo, una de las señales que te van asegurar que sos un líder en lo que estas haciendo, es que muchas, pero muchas personas te van a decir que lo que queres cambiar no esta bien, no es rentable, no es posible y los no que se te ocurran.
No lo hacen de mala onda, sino que son gente que tiene el ingrediente fundamental de un líder, el "Valor de enfrentar sus miedos".

También como líder te va a rodear gente "rara", fuera de lo común. Ustedes se imaginan como lo catalogaron a Alan Kay cuando definio la DynaBook, seguramente lo habran catalogado de "raro". No te asustes porque es generalmente esta gente la que tiene la capacidad de ver el cambio.

Claro hay que diferenciar a los "locos", que hay muchos por ahí sin ver la realidad, pero no te asusten los "raros", seguramente alguien dice de vos los mismo por tus espaldas.

En resumen un líder es aquel que termina siendo un factor de cambio para su medio.

Si queres un mundo mejor, empezá a crearlo.
Si queres un trabajo mejor, empezá a crearlo.
Si queres crear algo nuevo, no evites el miedo y las ansiedades.... Enfrentalos.

Es posible que el seguir tu visión te lleve a lugares que aun no están iluminados...pero no temas, acordate cuando eras chicos y tenias miedo a la oscuridad...con el tiempo el miedo se va. Con el cambio , la innovación y el liderazgo es lo mismo.

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.

Whiteboard, historia

Bueno, yo no voy a pegar pantallas, ni fotos. Mi intención es contar en tres o cuatro posts de qué se trata whiteboard (http://www.squeaksource.com/Officious.html).

Primero que nada un poco de historia.

Hace poco más de un año, cuando la idea de lanzarnos en un emprendimiento basado en Squeak iba tomando forma, decidimos crear un producto que nos permita entrar en el mercado por un lado, e ir probando la tecnología y definiendo formas de trabajo, por otro. Fue así como surge Officious.

Officious es una herramienta colaborativa, pensada para aquellos que trabajan en oficinas, con acceso a computadoras e internet. El objetivo central de la herramienta es generar un espacio donde se puedan compartir comentarios, tareas, concursos, organización de almuerzos, salidas, etc.

La premisa más importante fue la de la simplicidad de uso orientada a usuarios sin conocimientos técnicos.

Bien. Luego de unas cuantas idas y vueltas la cosa quedó así. 

La aplicación va a contar con una especie de tablón de anuncios al que se le pueden agregar distintos tipos de entradas ya prearmadas, como un sticky, un almuerzo, una nota comentable, etc. A cada una de estas entradas las denominamos "post"

La organización de este tablón de anuncios (whiteboard) se va a realizar mediante tags. La navegación la pensamos similar a delicious (hasta el nombre le choreamos) donde haciendo click en un tag se muestran solo los posts marcados con ese tag.

Cada usuario, verá su propio whiteboard, con posts suyos y posts de otros usuarios que le hayan compartido. Cada post podrá ser compartido a distintos usuarios.

El otro tema a resolver fue el compartir los posts. No queríamos toda una funcionalidad aparte donde el usuario tenga que pasar por la traumática tarea de entrar en una pantalla especial para compartir su post (que esas cosas solo las hacen los administradores de redes, vamos).

La decisión que tomamos fue la de utilizar los mismos tags para eso. O sea, si el usuario juan crea un post y le pone el tag "jose". El usuario jose automáticamente va a ver aparecer el post en su whiteboard, y además lo puede modificar.

Con esto ya teníamos una linda idea (y potente) para comenzar a trabajar.

La sigo en la próxima...

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.

Un sueño

No me puedo quejar. Hace años ya que laburo cómodo. Hago lo que me gusta, tengo mis libertades de movimiento, y no me va mal. Pero algo falta, siempre falta algo. Ya estoy llegando a la quinta década, y siento que tengo que hacer algo más. Es aquí donde entra Smallworks. Este proyecto no es independizarse y montar mi propia empresa. Eso podría haberlo hecho hace rato ya. Smallworks es un sueño, es querer armar algo nuevo, algo propio. Este sueño compartido con Diogenes y Esteban es lo que nos moviliza a seguir adelante, a ir contra gigantes, aunque a veces sintamos que son solo molinos y estamos perdiendo el tiempo.

Nuestro trabajo es creativo, vivimos de llegar a lugares donde solo hay una expresión de deseo e irnos dejando el deseo concretado en una aplicación. Lo hacemos, coordinamos grupos de trabajo, sufrimos las dificultades del desarrollo, las ansiedades de los tiempos tiranos y ambientes hostiles. Pero lo disfrutamos, lo nuestro es crear y esta quizá sea NUESTRA creación, desde cero, desde la nada y hacia un objetivo que parece un molino, pero que en realidad es un gigante. 

Procesos

Bueno, yo no soy escritor como mis amigos/socios, pero voy con mi granito de arena.

Allá por el 2000 cuando paloteabamos java, pasamos varias veces por el dilema de la persistencia, CMP, BMP, ORM, o lo que anduviera dando vueltas en ese momento. Casi siempre terminamos en alguna solución ad-hoc. Lo que nunca faltó es el requerimiento de que la persistencia tenía que ser independiente del motor de bases de datos. No se quién nos metió eso en la cabeza, porque jamás escuché a ningún cliente pidiendo eso, pero de repente pegarse a Oracle, IBM o lo que fuera se había transformado en tabú.

Y así fue como comenzamos a nivelar para abajo, haciendo cosas espantosas con DAOs insoportablemente pesados y que oscurecían toda posibilidad de aprovechar las ventajas del motor de base de datos subyacente, y a veces hasta de las propias características del SQL. Por suerte el amigo Gavin nos sacó bastantes de esos problemas de encima.

Hoy estaba pensando en nuestros queridos procesos, y de repente me cayó la ficha que estamos haciendo lo mismo. Queremos un proceso que nos solucione todo, que sea independiente de las personas que lo ejecuten, que sea pa'todos igual. Tiene sus ventajas, claro, y bastantes más que la persistencia, cierto también. Pero de vuelta vamos nivelando para abajo, perdemos las características propias de cada uno de los participantes, y a veces hasta las propias características de las personas en general.

Los procesos sirven, y mucho, pero no deberían intentar jamás tratar de anular las diferencias que nos hacen personas.

Una alegría para el alma

Hoy empecé el día con una buena noticia, seleccionaron mi tesis (la generación "Y" y su impacto en el mercado informático), como una de las mejores del 2007 y el poster de la misma en este momento esta expuesto en el salón central de la facultad (UADE).
El cuerpo de la tesis estará disponible aquí y la nota que fue publicada en la revista .Code sobre el tema puede verse aqui .

Bueno Solo quería compartir mi alegría con todo ustedes y agradecerles a todos los que me apoyaron durante este duro tiempo de investigación.

Smalltalk vs. la ignorancia

Cuando era niño jugaba una versión del Trivia (juego de mesa estilo parchís, pero con preguntas y respuestas) que tenía una particularidad: si nadie sabía la respuesta, avanzaba en el tablero una ficha, normalmente negra, apodada “la ignorancia”. Yo odiaba que esa ficha llegara antes que nosotros, me sentía un tonto que no sabía nada.
Bueno, hace un par de semanas ocurrió un episodio que me hizo recordar esa etapa de mi vida, quisiera compartirlas con ustedes:

En una de sus charlas de negocio, uno de mis socios quedó consternado por una de las preguntas que le hizo uno de los socios de la empresa con la que se habría la posibilidad de asociarnos.
La charla fue más o menos como se había planificado, hasta ese momento: se presentó de una forma más bien poco profunda (así estaba pensada) nuestra forma de trabajar y nuestras tecnologías preferidas, así como las ventajas que veíamos, al menos para empresas medianas (pues creemos que las empresas grandes tienen compromisos -no fundados en razones tecnológicas, la mayoría de las veces-, que les impiden moverse en diferentes direcciones a las establecidas por lo que llamamos “el mainstream”, la corriente principal, la moda.
Volviendo al tema, la charla iba mas o menos bien, hasta que uno de los presentes interrumpió a mi socio y sin más soltó la pregunta: “¿Además de las ventajas de productividad, por qué deberíamos ofrecerle al Banco Galicia una solución en Smalltalk y Seaside, en lugar de hacerlo en .Net?”. Mi socio se quedó con la boca abierta. Después de todo, la charla había empezado aclarando que veíamos nuestra solución más bien para empresas medianas, y el Banco Galicia claramente no entra en esa escala.
En consecuencia, mi socio no tuvo una respuesta satisfactoria (ni ninguna respuesta, bah).
Y no es que no tengamos una, simplemente no queríamos darla: nos propusimos desde el primer día no defender una tecnología haciendo comparaciones con otras, sino a través de la ponderación de sus propias cualidades. Creemos que con eso alcanza para convencer a aquellos que busquen realmente una solución viable para su negocio.
Bien, pese a eso, yo me quedé con una espina clavada... creo que hay muy buenas razones para que un banco (El Galicia o cualquiera) pueda escoger una solución basada en Smalltalk para su negocio, voy a exponer las primeras tres que se me vienen a la mente:

1. El principal propósito de Smalltalk es la simulación del mundo real. Es un ambiente donde el modelado de sistemas sumamente complejos se hace mucho más fácil que en cualquier otro. No es que en otros lenguajes u otras formas de ver el desarrollo de software no lo permita, es simplemente que en Smalltalk es mas sencillo, mas “natural”.
   
2. Programar en Smalltalk es altamente productivo. Puedo demostrarlo en cualquier momento, pero detenerme en este detalle sería perder el foco del post (una búsqueda en google de “smalltalk productivity” arrojará literalmente miles de resultados. Cualquier negocio (bancario o de cualquier tipo) puede beneficiarse de esto. 
   
3. Smalltalk se adapta con facilidad a los cambios constantes. Los sistemas bancarios son particularmente dinámicos y requieren adaptaciones frecuentemente, debido a cambios en la legislación (en nuestro país esto es cosa de todos los días), pero también a la adaptación a un mercado altamente competitivo. 
   

Sin embargo, y pese a la cantidad de cualidades y casos de éxito que hay, siempre existen los que se niegan a considerar siquiera la posibilidad de utilizar Smalltalk o cualquier otro lenguaje dinámico, siempre con las mismas excusas:

Soporte

Es un clásico de las empresas grandes, siempre dicen “vamos a ir con la tecnología tal, porque con ella tengo soporte y con la que ustedes proponen no”.
Bien, sobre esto... me genera bastante mal humor, siempre que lo dicen.
Una plataforma que cambia cada dos o tres años, y te fuerza a migrar cada vez a su nueva “solución”, no es soporte de calidad.
Una plataforma que crea algo totalmente distinto cada dos o tres años, y te fuerza a cambiar tu arquitectura para adaptarse a la nueva cosa, no es soporte de calidad.
Una plataforma donde los que te atienden son empleados de un callcenter que tienen un manual de instrucciones y no los creadores de la misma, no es soporte de calidad. Si encima tiene el soporte tercerizado en el tercer mundo (donde vivimos) y el soporte “de calidad” esta en el primero, es aún peor.
Productividad

Se sostiene una y otra vez que soluciones pre-hechas (tipo ensamblaje de componentes, etc.) permite alcanzar mejor productividad en los proyectos.
Psé... ni siquiera vale la pena detenerse aquí. Ya se sabe lo que pasa con las soluciones pre-hechas: no están realmente pensadas para el negocio que las requiere, sino para casos generales. Los componentes son caros y además tienen el código cerrado, por lo que entran en el ciclo de soporte lamentable mencionado en el punto 1.
Además, sostener que Smalltalk no es productivo es simplemente no tener idea de lo que se habla.
Falta de desarrolladores

Se sostiene que “todos programan Java o .Net, no hay programadores en el mercado para realizar un desarrollo que no se haga con una de estas plataformas”.
Este es un punto altamente cuestionable, sobre todo en Argentina, donde todas las carreras serias tienen formación en programación orientada a objetos y en Smalltalk.

¿Quien utiliza Smalltalk?
Por supuesto, los “casos de éxito” son importantes: nadie quiere arriesgarse a utilizar una herramienta sin que sea plenamente probada, y si bien es cuestionable en determinados ámbitos, es cierto que no se puede pedir a ningún negocio que tome un riesgo si no tiene una buena razón para hacerlo. Afortunadamente, hay empresas de primer linea mundial (y nacional) que utilizan Smalltalk para sus soluciones... y lo que es más importante, muchas de ellas lo hacen desde hace muchos años. Las siguientes empresas las encontré haciendo una investigación de 5’ con google, no son las únicas ni mucho menos, pero bastan como ejemplo: JPMorgan, Telecom, Repsol-YPF, Texas Instruments, Mercap SRL, Merrill Lynch, Swiss National Bank, y muchos más....


De cualquier forma, me quedó picando el tema y en futuros posts pienso hablar de cómo lograr calidad en el software usando Smalltalk (Squeak, en particular)

Diseñando (con CSS) aplicaciones web

Estoy haciendo un sistema muy pequeño de subastas inversas. Para el mismo estoy usando una arquitectura Squeak, Seaside y Magma (ah, las cosas divertidas de la vida). Uno de los requerimientos originales era que el sistema fuera fácilmente modificable por un diseñador gráfico, en un momento no determinado del desarrollo (es decir, no lo tenia disponible de entrada).
Por supuesto, se supone que siempre debería ser así, que los programadores no deberían tener nada que ver con el diseño, que los diseñadores no deberían meterse con el código, que blablabla... pero todos los que tenemos alguna experiencia en el desarrollo de aplicaciones web sabemos que no es así nunca, que el diseño de las pantallas tiene repercusiones en el diseño de la aplicación y viceversa.
Bueno, esta tarea, con Seaside se hace bastante trivial (en realidad, con cualquier framework orientado a componentes debería ser posible, pero en particular con Seaside, por algunas características como la capacidad de agregar decorators dinámicamente).
Para probar esto, trabajé durante dos semanas sin consideraciones “artísticas”, pero con algunas decisiones importantes en el armado de los componentes.
Para que se vea cuan cierto es que no me fijé, pueden ver como se veía la aplicación hasta ayer a la tarde:

Poca onda con los diseños

Y miren ahora los resultados de la aplicación con un rato de trabajo (y de robarme asquerosamente estilos de otros sitios), y, sobre todo, sin tocar absolutamente nada del código escrito. Todo a través de CSS:

Así esta mejor

Le falta mucho, pero a pesar de lo poderosos que son los componentes de Seaside y el CSS2, yo sigo siendo un humilde programador, con un talento para hacer el look&feel de las aplicaciones tendiente a cero. Imagínense lo que un verdadero diseñador puede hacer.

Para que esto funcione, hay que desarrollar los componentes siguiendo un par de pautas:

En primer lugar, todos los componentes plausibles de ser tocados por CSS deberían estar englobados en un div. Resolví esto creando un decorator, que se le puede agregar a cada componente que lo requiera.
En segundo lugar, internamente, los componentes también deben estar divididos en secciones, demarcadas por otros tantos divs.
Por ejemplo, un componente tendrá esta forma:


initialize
super initialize.
self addDecoration: SWCustomizableDecoration new.

renderContentOn: html
html heading level1; with: 'Edición de subasta'.
html heading level2; with: 'Datos generales'.
html form: [
html div class: #data; with: [ self renderBasicOn: html ].
html div class: #sheets; with: pliegos.
html div class: #buttons; with: [ self renderButtonsOn: html ] ]